1. 这次更新到底改了什么从“焚诀”说起“焚诀”这个词在圈子里流传有一阵子了最早是社区里对 Claude Code 那套“把上下文烧干净、把任务拆到极致”的工作流的戏称。这次 Opus 5.5 发布配合 Claude Code 的一轮更新把这套玩法推到了一个新阶段。我前后用了大概两周时间把手上几个真实项目从旧版本迁移过来踩了不少坑也摸出了一些门道这篇就把我实际验证过的东西完整摊开讲。先说清楚这篇适合谁看。如果你已经在用 Claude Code 做日常开发想搞清楚 Opus 5.5 到底值不值得切、Sub-agent 和 CLAUDE.md 该怎么配那这篇是写给你的。如果你还没上手 Claude Code只是听说这东西能直接在终端里改代码、跑命令想从零搭一套能用的环境这篇同样能带你走完。我会把安装、配置、模型选择、Sub-agent 编排、CLAUDE.md 写法、effort 参数调优、常见报错排查全部覆盖到尽量做到你照着抄就能跑起来。核心关键词先摆出来Claude Opus、Claude Code、Sub-agent、CLAUDE.md、effort。这五个词基本构成了这次更新的全部骨架。Opus 5.5 是模型底座Claude Code 是承载它的命令行工具Sub-agent 是任务拆解的执行单元CLAUDE.md 是给模型的“项目说明书”effort 则是控制它“用力程度”的旋钮。理解这五者的关系比单纯记命令重要得多。我个人的判断是这次更新最大的价值不在于模型本身强了多少而在于编排能力的成熟。以前你让 Claude Code 干一个稍大的任务它容易一口气吃太多、上下文爆掉、中途跑偏。现在有了 Sub-agent 和更细的 effort 控制你可以像带团队一样带它——谁负责调研、谁负责写、谁负责验证分工明确。这才是“焚诀”真正的含义不是烧掉上下文而是把上下文用在刀刃上。2. 环境搭建从零到能跑通的第一条命令2.1 安装前的心理准备和依赖检查Claude Code 的安装本身不复杂但它的“环境敏感度”比一般 CLI 工具高。我见过太多人卡在第一步不是命令敲错而是 Node 版本、npm 权限、系统架构这些底层东西没对齐。所以别急着复制粘贴安装命令先花两分钟把地基检查一遍。你需要确认三件事Node.js 版本、npm 的全局写入权限、以及终端环境。Node 建议 18 LTS 以上20 更稳。用node -v和npm -v各看一眼。npm 权限这块是重灾区尤其是 macOS 和 Ubuntu很多人用系统自带 Node 装完一执行全局安装就报no write permission to npm prefix——这个报错后面我会专门讲怎么根治。提示如果你在 Windows 上强烈建议走 WSL2而不是原生 PowerShell。Claude Code 大量依赖类 Unix 的路径和命令行为WSL 下体验顺滑得多原生 Windows 下各种路径转义问题会让你怀疑人生。2.2 三种安装路径的实际对比安装方式我实测下来主要三条路各有适用场景我做了个对比表安装方式命令适用场景升级便利性坑点npm 全局安装npm install -g对应包大多数用户首选手动重装或命令升级npm prefix 权限官方安装脚本官方文档提供的脚本想省事、环境干净脚本重跑网络波动包管理器brew 等macOS 用户包管理器统一管版本可能滞后我自己的主力机是 macOS用的是 npm 全局安装因为升级最可控。Ubuntu 服务器上也是 npm配合 nvm 管理 Node 版本避免污染系统环境。这里有个经验永远用 nvm 装 Node不要用系统包管理器装。系统装的 Node 权限归属 root后面 npm 全局装东西必然报权限错改起来很烦。安装完成后第一次运行会让你走登录流程。这里有个常见困惑能不能不登录、接别的模型用技术上 Claude Code 的 harness 是支持配置其他模型端点的社区里也有人接 DeepSeek 之类的模型来跑。但我的建议是如果你要用 Opus 5.5 的完整能力尤其是 Sub-agent 和 effort 这些新特性还是走官方通道因为很多编排逻辑是跟模型能力深度绑定的换模型后效果会打折扣。2.3 编辑器集成VS Code 里的正确姿势很多人不知道 Claude Code 有 VS Code 扩展。装完之后你可以在编辑器里直接唤起它改代码、看 diff 比纯终端舒服。配置要点是先确保终端版能跑通再装扩展扩展会自动复用终端的登录态。如果扩展里提示找不到命令八成是 PATH 没配对检查一下 npm 全局 bin 目录有没有进 PATH。我实际用下来VS Code 集成最适合“边看边改”的场景比如重构一个函数、补测试。但如果是跑长任务、多文件联动我还是回到终端因为终端里 Sub-agent 的输出更完整日志也更好追。3. 模型选择与 effort 参数把力气花在刀刃上3.1 Opus 5.5 相比前代的实际体感差异先泼盆冷水如果你期待 Opus 5.5 是“质的飞跃”可能会失望。它在单轮问答上的提升是渐进的真正拉开差距的是长任务稳定性和指令遵循精度。我拿同一个重构任务在旧版和 5.5 上各跑了一遍旧版跑到第七八个文件开始出现“忘记前面约定”的情况5.5 基本能撑到最后风格也保持一致。这个差异的来源我判断是上下文管理和注意力机制的优化。对写代码这种需要“记住全局约定”的任务稳定性比单点聪明更重要。所以如果你之前因为“跑一半就乱”而放弃 Claude Code这次值得再试一次。3.2 effort 参数到底怎么调effort 是这次最值得聊的参数。你可以把它理解成“思考预算”——调高了模型会花更多时间推理、更谨慎地规划调低了响应快但容易草率。它不是简单的“越高越好”而是要看任务类型。我的实测经验是这样分档的低 effort改个变量名、补个注释、格式化代码。这种任务调高 effort 纯属浪费响应还慢。中 effort写单个函数、修一个明确的 bug、写单元测试。日常主力档位。高 effort跨文件重构、设计新模块、排查诡异 bug。这时候让它多想能省你后面大量返工。注意effort 调高会显著增加 token 消耗和等待时间。我踩过的坑是一个简单的配置修改也开了高 effort结果等了快一分钟纯属自己找罪受。养成“先判断任务复杂度再定档”的习惯。这里有个反直觉的点不是所有复杂任务都适合高 effort。如果任务本身描述模糊你给它再高的 effort它也只是在模糊的方向上想得更久反而可能越想越偏。这时候正确做法是先把任务描述清楚再谈 effort。3.3 模型切换的时机判断Claude Code 里可以在会话中切换模型。我的策略是规划阶段用强模型执行阶段可以降级。比如让 Opus 5.5 先把重构方案和文件清单列出来确认没问题后具体每个文件的机械修改可以交给更轻的模型跑省成本也省时间。这个“强弱搭配”的用法比全程顶配要经济得多。4. Sub-agent 编排像带团队一样用它4.1 Sub-agent 解决的核心痛点Sub-agent 是这次更新里我最看重的功能。在没有它之前一个大任务全塞给主会话上下文很快就被各种中间产物撑爆模型开始“失忆”。Sub-agent 的思路是把任务拆成几个独立的子任务每个子任务开一个干净的上下文去跑只把结果汇报回主线。打个比方这就像你带一个项目主会话是项目经理负责拆解和汇总Sub-agent 是各个执行人各自领一块活干完交结果。项目经理不需要知道每个执行人中间试错了多少次只要最终产物。这样主线的上下文始终清爽。4.2 一个真实的三段式编排案例我拿一个实际任务举例给一个老项目补全测试覆盖。我把它拆成三个 Sub-agent调研 agent扫描代码库列出所有没有测试覆盖的模块输出一份清单和优先级建议。编写 agent按清单逐个模块写测试每个模块独立跑互不干扰。验证 agent跑测试、看覆盖率、检查有没有假测试比如断言写得太松。主会话只做三件事把清单传给编写 agent、把产物传给验证 agent、汇总最终报告。整个过程主线上下文占用很低跑几十个模块也不崩。4.3 编排时的关键注意事项Sub-agent 用起来爽但有几个坑必须提前知道。第一子任务之间不要有隐式依赖。如果编写 agent 需要调研 agent 的中间推理过程那就不该拆开硬拆会导致信息丢失。第二每个 Sub-agent 的输入要自包含。你不能指望它“记得”主会话之前聊过什么该给的上下文要显式塞进去。第三汇报格式要约定好。我一般要求 Sub-agent 用固定结构返回做了什么、产物在哪、有什么遗留问题。格式统一了主会话汇总才不会乱。提示Sub-agent 不是越多越好。我试过一个任务拆了八个 agent结果光是协调开销就超过了收益。经验值是单个任务拆 2 到 4 个 agent 最舒服超过五个就要重新想想是不是拆得太碎了。5. CLAUDE.md给模型写一份靠谱的项目说明书5.1 CLAUDE.md 的作用机制CLAUDE.md 是放在项目根目录的一个约定文件Claude Code 启动时会自动读取它把它当作项目的“背景知识”。你可以理解为每次开新会话模型都会先读一遍这份说明书知道这个项目是干嘛的、代码风格是什么、有哪些禁忌。这个机制的价值在于一致性。没有它的时候你每次开新会话都要重新交代一遍“我们用 TypeScript 严格模式”“测试用 vitest 不用 jest”“别动 legacy 目录”烦且容易漏。有了它这些约定一次写好长期生效。5.2 一份高质量 CLAUDE.md 该写什么我写过多份 CLAUDE.md总结下来这几块最值得写项目定位一句话说清这是什么项目、技术栈是什么。目录结构说明哪些目录是核心、哪些是生成物别动、哪些是历史遗留。代码规范命名习惯、格式化工具、lint 规则、提交信息格式。常用命令怎么跑测试、怎么构建、怎么启动本地服务。禁忌清单明确写出“不要做什么”比如不要改配置文件、不要引入新依赖。禁忌清单这块我要特别强调。模型很“热心”你不说清楚它可能顺手帮你升级个依赖、改个配置结果引入一堆问题。把红线写明白能省很多事。5.3 维护 CLAUDE.md 的节奏CLAUDE.md 不是写完就完事。我的习惯是每次发现模型犯了“本可以避免的错”就往里补一条。比如它又一次用了错误的导入路径我就在规范里写死正确路径。这样这份文件会随着项目演进越来越贴合实际模型的表现也越来越稳。注意CLAUDE.md 别写太长。我见过有人写了上千行结果模型读起来反而抓不住重点。控制在合理长度把最关键的约定放前面细节可以放后面。信息密度比篇幅重要。6. 常见报错与排查实录6.1 安装与权限类问题auto-update failed: no write permission to npm prefix这个报错我遇到太多次了。根因是 npm 全局目录归属不对。根治方法是把 npm 全局目录改到用户目录下或者干脆用 nvm 重装 Node。临时绕过可以加 sudo但我不推荐因为 sudo 装的东西后面权限会更乱。macOS 上还有一类问题是“无法下载”。这通常是网络或证书问题检查一下代理设置和系统时间。系统时间不对会导致证书校验失败这个坑很隐蔽我卡过一次。6.2 运行时的诡异行为有一类问题不是报错而是“行为不对”。比如模型突然开始用错误的风格写代码、或者反复问已经回答过的问题。这种情况八成是上下文被污染了或者 CLAUDE.md 没被正确读取。排查顺序是先确认 CLAUDE.md 在根目录且格式正确再检查是不是会话太长导致上下文溢出必要时开新会话。还有一类是 Sub-agent 不汇报或汇报格式乱。这通常是子任务的输入描述不够清晰或者汇报格式没约定。我的做法是在派发任务时明确写清“完成后请按以下格式返回”把模板直接给它。6.3 排查速查表现象可能原因处理方式安装报权限错npm prefix 归属 root改全局目录或用 nvm无法下载/安装网络或证书问题检查代理与系统时间模型行为跑偏上下文污染或约定未读检查 CLAUDE.md、开新会话Sub-agent 不汇报输入描述不清明确任务与返回格式响应异常慢effort 档位过高按任务复杂度降档找不到命令PATH 未配置把 npm bin 加入 PATH7. 我踩过的坑和几条实在建议聊了这么多技术细节最后说几条纯经验的东西都是我真金白银踩出来的。第一条别一上来就追求全自动。很多人刚上手就想让 Claude Code 一口气把整个需求做完结果跑偏了还得从头收拾。正确节奏是先让它做小任务你盯着看确认它的理解和你一致再逐步放权。信任是攒出来的不是配出来的。第二条CLAUDE.md 和 effort 是性价比最高的两个投入。前者一次写好长期受益后者调对了能省大量等待时间。相比之下纠结用哪个模型、装哪个版本收益反而没那么大。第三条Sub-agent 的拆分粒度要克制。我一开始特别兴奋什么都想拆结果协调成本爆炸。后来想明白了拆分的目的是隔离上下文不是为了显得架构高级。如果一个任务本身上下文需求就不大老老实实一个会话跑完更省事。第四条保留人工审查环节。不管模型多强它写的代码你都得看。我见过太多人直接接受模型的改动结果埋了个隐蔽 bug几天后才发现。把模型当高效助手别当甩手掌柜。这套工作流我用了两周最大的感受是工具的上限取决于使用者的编排能力。同样的 Opus 5.5有人用得磕磕绊绊有人用得行云流水差别不在模型在于你有没有把任务拆清楚、把约定写明白、把力气花对地方。焚诀的核心从来不是烧是精准。