1. 这次“焚诀”到底更新了什么从标题拆解核心变化“Claude Opus 5.5 最新焚诀发布了”这个标题第一次看到的时候我愣了一下——“焚诀”这个词在圈子里其实是个半开玩笑的说法指的是那种“烧算力、烧token、但效果炸裂”的用法组合。说白了就是一套把模型能力压榨到极限的配置方案。这次围绕 Claude Opus 5.5 的更新核心不在模型本身跑分涨了多少而在于围绕 Claude Code 这套终端工具链的一整套工作流发生了实质性变化。先把结论摆前面这次更新真正影响日常使用的是四个东西——CLAUDE.md 的项目记忆机制、Sub-agent 的任务拆分能力、effort 参数的显式控制、以及 Claude Code 本身的安装与升级路径。前三个决定了你“怎么用得更狠”最后一个决定了你“能不能用得上”。很多人卡在第一步安装上后面那些高级玩法根本摸不到所以这篇我会从安装一路讲到焚诀级别的配置。这篇文章适合谁看三类人。第一类是完全没接触过 Claude Code想从零上手的新手第二类是已经装了但只会敲几句 prompt、没玩过 Sub-agent 和 CLAUDE.md 的中间用户第三类是想把 effort 拉满、把 Opus 5.5 当主力生产力工具的重度用户。不管你在哪一层下面都有对应的内容。我先把这次更新的几个关键点用一张表理清楚方便你建立整体认知变化点具体内容对使用者的影响CLAUDE.md项目级持久记忆文件支持分层加载不用每次重复交代项目背景Sub-agent主 agent 可派生子任务并行处理复杂任务拆解效率大幅提升effort 参数显式控制推理投入程度简单任务省钱复杂任务拉满安装升级npm 全局安装 自动更新机制新手最容易卡住的环节这张表你先记着后面每一块我都会展开讲。需要强调的是所谓“焚诀”不是某个隐藏开关而是把上面这几个能力组合起来用——CLAUDE.md 喂足上下文Sub-agent 拆分任务effort 按需拉高三者叠加才是完整形态。单独用任何一个效果都差一大截。2. 安装与升级新手最容易翻车的第一关2.1 不同系统的安装路径选择Claude Code 的安装方式官方主推的是 npm 全局安装。这一步看起来简单但我在群里见过太多人卡在这里。先说清楚原理Claude Code 本质上是一个跑在终端里的命令行工具通过 npm 分发所以你的机器上必须先有 Node.js 环境。Windows 用户这里有个分叉。原生 Windows 环境下直接装也能跑但实际体验下来WSLWindows Subsystem for Linux是更稳的选择。原因很实际Claude Code 大量依赖类 Unix 的文件操作和 shell 命令在 WSL 里跑路径处理、权限管理、脚本执行都不会出幺蛾子。原生 Windows 下偶尔会遇到路径分隔符和权限的奇怪问题排查起来很烦。Ubuntu 或者 macOS 用户就简单多了直接走标准流程。安装命令本身不复杂npm install -g anthropic-ai/claude-code装完之后验证一下claude --version能打印出版本号就说明装好了。如果提示 command not found八成是 npm 的全局 bin 目录没加到 PATH 里这个后面排查章节会细讲。2.2 自动更新失败与权限报错的根治热词里有个报错特别高频auto-update failed: no write permission to npm prefix。这个错误的本质是——Claude Code 想自动更新自己但它没有往 npm 全局目录写文件的权限。为什么会这样因为很多人当初是用sudo npm install -g装的装出来的文件属主是 root普通用户自然没权限覆盖。解决办法有两个方向。第一个方向是改 npm 的全局目录把它指到用户自己的目录下这样以后所有全局包都不需要 sudomkdir -p ~/.npm-global npm config set prefix ~/.npm-global然后把~/.npm-global/bin加到你的 PATH 里重新装一遍 Claude Code。这个方案的好处是一劳永逸以后升级再也不会报权限错。第二个方向是手动升级绕过自动更新npm update -g anthropic-ai/claude-code如果你就是想快速解决用 sudo 跑这条也行但治标不治本下次自动更新还会报同样的错。我个人强烈建议走第一个方向花五分钟配置好后面省心。注意改完 npm prefix 之后一定要确认新目录在 PATH 里否则会出现“装了但找不到命令”的情况。用echo $PATH检查一下。2.3 在线升级与版本回滚的实操Claude Code 的升级节奏挺快有时候新版本会引入一些行为变化。我的习惯是升级前先记下当前版本号万一新版有问题可以回滚npm install -g anthropic-ai/claude-code版本号在线升级的话如果自动更新是好的它会在启动时提示你有新版本。手动触发就是重新跑一遍 install 命令。这里有个经验升级完先在一个不重要的项目里试跑一下确认 CLAUDE.md 加载、Sub-agent 调用都正常再放到主力项目上用。我踩过一次坑某次升级后 CLAUDE.md 的加载优先级变了导致项目里一堆约定失效排查了半天才发现是版本问题。3. CLAUDE.md把项目背景一次性喂饱3.1 CLAUDE.md 到底是什么为什么它这么关键CLAUDE.md 是 Claude Code 的项目级记忆文件。你可以把它理解成“给这个项目写的一份说明书”每次 Claude Code 在这个目录下启动都会自动读取它把里面的内容作为上下文的一部分。为什么这个东西是焚诀的核心因为大模型有个天然短板——它不记得你上次说了什么。你每次开新会话都得重新交代“这个项目用什么框架、代码风格是什么、哪些目录不能动、测试怎么跑”。这些重复劳动累积起来非常消耗精力。CLAUDE.md 就是把这个重复交代的过程固化下来一次写好次次生效。它的加载是有层级的。通常有这么几层用户级全局对所有项目生效、项目级放在项目根目录对这个项目生效、以及子目录级针对特定模块。层级之间是叠加关系越靠近当前工作目录的优先级越高。这个设计很合理——全局放你的通用偏好项目级放项目约定子目录级放模块特殊规则。3.2 一份高质量 CLAUDE.md 应该写什么我见过很多人写的 CLAUDE.md 要么太啰嗦要么太简略。太啰嗦会把上下文窗口占满太简略又起不到作用。经过多次迭代我总结出一个比较实用的结构项目概述一两句话说清楚这个项目是干嘛的技术栈是什么目录结构约定哪些目录放什么哪些是生成产物不要手动改代码风格命名规范、缩进、注释语言、是否用某种 lint 规则常用命令怎么跑测试、怎么构建、怎么启动开发服务器禁忌事项哪些文件绝对不能动哪些操作需要先确认举个实际的例子一个前端项目的 CLAUDE.md 可能长这样# 项目说明 这是一个基于 React TypeScript 的电商后台管理系统。 ## 目录约定 - src/components 放通用组件 - src/pages 放页面级组件 - src/api 放接口封装不要在这里写业务逻辑 - dist 是构建产物禁止手动修改 ## 代码风格 - 组件用函数式不用 class - 缩进 2 空格 - 注释用中文 - 提交前必须过 eslint ## 常用命令 - 开发npm run dev - 测试npm run test - 构建npm run build ## 禁忌 - 不要修改 package.json 里的依赖版本除非明确要求 - 不要删除任何 .env 文件这份文件写下来大概两百字但它能省掉你每天几十次的重复交代。这就是焚诀的第一层——用固定的上下文换取稳定的输出质量。3.3 CLAUDE.md 的维护心得与常见误区维护 CLAUDE.md 有几个心得值得分享。第一它是活的不是写完就不管。项目演进过程中约定会变CLAUDE.md 也要跟着更新。我一般会在每次大的架构调整后顺手改一下。第二不要把它当成文档仓库。有些人恨不得把整个 README 都塞进去结果上下文被占满真正重要的约定反而被淹没。CLAUDE.md 只放“Claude 需要知道才能正确干活”的信息其他背景知识放 README 就行。第三善用分层。全局的 CLAUDE.md 放你个人的通用偏好比如“回答用中文”“代码注释要详细”。项目级的放项目约定。这样切换项目的时候个人偏好自动继承不用重复写。提示如果你发现 Claude Code 没有按 CLAUDE.md 里的约定执行先确认文件是不是放在了正确的目录以及有没有被更高优先级的配置覆盖。层级问题是最常见的“约定失效”原因。4. Sub-agent把复杂任务拆开并行处理4.1 Sub-agent 的运作机制Sub-agent 是这次更新里我觉得最有想象力的能力。简单说主 agent 在遇到复杂任务时可以派生出若干子 agent每个子 agent 负责一块独立的子任务各自带着自己的上下文去干活干完把结果汇报给主 agent。这个机制解决了一个核心痛点单个上下文窗口装不下复杂任务的全部信息。比如你要重构一个大型模块涉及十几个文件如果全塞进一个会话上下文很快就爆了模型开始“忘事”。Sub-agent 把任务拆开每个子 agent 只关心自己那一块上下文压力就分散了。它的工作方式有点像现实中的项目分工。主 agent 是项目经理负责拆解任务、分配工作、汇总结果子 agent 是执行者各自埋头干自己的活。这种结构天然适合那种“可以并行、彼此依赖少”的任务。4.2 什么任务适合拆给 Sub-agent不是所有任务都适合拆。我总结了一个判断标准如果子任务之间需要频繁互相参考对方的中间结果那就不适合拆如果子任务相对独立只是最后汇总那就非常适合。适合拆的典型场景批量修改多个独立文件比如给每个组件加统一的类型定义并行调研多个方案比如同时研究三种实现路径的优劣大规模代码审查每个子 agent 审一个模块生成多个互不依赖的文档或配置不适合拆的场景需要全局一致性的重构改一处会影响另一处强顺序依赖的任务第二步必须等第一步的结果上下文高度耦合的调试我个人的经验是拆之前先想清楚“汇总”这一步怎么做。如果子 agent 的产出没法干净地合并那拆了反而添乱。焚诀的第二层就在这里——用并行换时间但前提是任务本身可并行。4.3 Sub-agent 实操中的坑与技巧实操下来Sub-agent 有几个坑值得提前知道。第一个是上下文隔离带来的信息丢失。子 agent 默认看不到主 agent 的完整上下文所以你在派任务的时候得把必要的背景信息明确传下去。我一般会在派发指令里把相关的 CLAUDE.md 约定和关键约束复述一遍。第二个是结果汇总的格式问题。如果每个子 agent 返回的格式五花八门主 agent 汇总起来会很痛苦。解决办法是在派任务时就规定好返回格式比如“用统一的 JSON 结构返回包含文件名、修改内容、状态三个字段”。第三个是并行度别拉太满。理论上你可以同时开很多子 agent但实际受限于资源和服务端的处理能力开太多反而会互相拖慢甚至触发限流。我一般控制在三到五个并行超过这个数就分批处理。注意Sub-agent 的产出一定要人工过一遍再合并。我遇到过子 agent 各自改得都对但合到一起就冲突的情况因为它们在隔离环境下看不到彼此。合并前的冲突检查不能省。5. effort 参数按需分配推理算力5.1 effort 参数的本质是什么effort 这个参数直译是“努力程度”它控制的是模型在推理时投入的算力。effort 拉高模型会花更多时间“思考”推理链更长对复杂问题的处理更细致effort 拉低响应更快、消耗更少但遇到难题容易草率。这个设计背后的逻辑很朴素不是所有任务都值得用全力。你问一个简单的语法问题和让它设计一套系统架构需要的推理深度天差地别。如果所有请求都按最高 effort 跑既慢又贵如果都按最低跑复杂任务的质量又保证不了。effort 参数就是让你自己权衡。从成本角度看effort 和 token 消耗是正相关的。effort 越高模型内部产生的推理 token 越多账单自然越厚。所以焚诀的第三层其实是精细化的成本控制——把高 effort 用在刀刃上。5.2 不同任务该怎么设置 effort我摸索出一套自己的设置习惯供参考任务类型建议 effort理由简单问答、格式转换低不需要深度推理快就行常规代码编写中平衡质量和速度复杂调试、架构设计高需要多步推理和权衡关键决策、方案评审最高值得为质量买单实际操作中我会先用一个中等 effort 跑一遍看结果质量。如果发现模型明显没想透再提高 effort 重跑。这种“先试后调”的方式比一上来就拉满更经济。有个细节值得注意effort 和 prompt 质量是互补的不是替代关系。你 prompt 写得含糊effort 拉再高也救不回来反过来prompt 写得清楚中等 effort 就能出好结果。所以别指望靠拉高 effort 来弥补需求描述的模糊。5.3 effort 与 Sub-agent 的组合玩法把 effort 和 Sub-agent 结合起来能玩出一些有意思的组合。比如一个大型重构任务主 agent 用高 effort 做整体规划和任务拆解子 agent 用中等 effort 执行具体的文件修改。这样既保证了顶层设计的质量又控制了执行层的成本。再比如调研类任务可以让多个子 agent 用不同 effort 跑同一个问题然后对比结果。低 effort 的快速给个方向高 effort 的深入验证。这种“多档位对比”在需要交叉验证的场景下特别有用。我个人的体会是effort 的调节应该跟着任务的重要性走而不是跟着任务的复杂度走。有些任务很复杂但错了也无所谓比如生成测试数据低 effort 就行有些任务很简单但错了代价很大比如改生产环境的配置那就值得拉高 effort 反复确认。6. 常见问题与排查技巧实录6.1 安装类问题速查安装环节的问题占了新手求助的一大半我整理成一张速查表报错信息根本原因解决办法command not foundnpm bin 目录不在 PATH把 npm prefix 的 bin 目录加进 PATHno write permission to npm prefix全局目录属主是 root改 npm prefix 到用户目录重装auto-update failed同上权限问题手动 npm update 或修权限Node 版本过低依赖要求新版本 Node升级 Node 到 LTS 版本WSL 里路径找不到跨系统路径格式问题统一在 WSL 文件系统内操作这张表基本覆盖了九成安装问题。遇到报错先对号入座比盲目搜索快得多。6.2 使用类问题的排查思路使用过程中的问题更隐蔽一些。比如“CLAUDE.md 不生效”排查顺序是先确认文件位置对不对再确认有没有被更高层级覆盖最后确认文件内容格式有没有问题比如 markdown 语法错误导致解析失败。再比如“Sub-agent 结果不对”先看派发指令里的背景信息够不够再看子任务拆分是否合理最后看汇总逻辑有没有问题。这三个环节任何一个出问题最终结果都会跑偏。“effort 调高了但质量没提升”这种情况通常是 prompt 本身有问题。effort 只能放大模型的能力不能弥补需求的模糊。这时候该做的是回去把需求描述清楚而不是继续加 effort。6.3 我踩过的几个真实坑说几个我自己踩过的坑都是文档里不会写的。第一个坑在错误的目录启动 Claude Code。有次我在一个子目录里启动结果项目级的 CLAUDE.md 没被加载模型完全不知道项目约定输出一堆不符合规范的代码。后来养成习惯启动前先pwd确认一下位置。第二个坑CLAUDE.md 写太长导致关键信息被稀释。早期我恨不得把所有细节都写进去结果模型抓不住重点。后来精简到只留最关键的约定效果反而更好。上下文是稀缺资源得省着用。第三个坑Sub-agent 并行太多触发限流。有次一口气开了八个子 agent结果一半超时失败。后来控制在五个以内稳定多了。并行不是越多越好得看实际承载能力。第四个坑升级后没回归测试。前面提过某次升级改了 CLAUDE.md 的加载逻辑我没及时发现导致一个项目的约定失效了好几天。现在升级后必做一次小范围验证。提示把上面这些坑整理成一份自己的检查清单每次遇到问题先过一遍清单能省下大量排查时间。7. 把焚诀用成日常一套可复制的配置模板讲了这么多最后落到一套可以直接抄的配置上。我的日常配置是这样的全局 CLAUDE.md 放个人通用偏好比如回答语言、注释风格、代码审查的严格程度。项目级 CLAUDE.md 放项目约定结构参照前面第 3 节给的模板。effort 默认设中等遇到复杂任务临时拉高。Sub-agent 只在任务确实可并行时才用并行度控制在五个以内。这套配置跑下来日常开发效率提升很明显。最直观的感受是重复交代项目背景的时间几乎归零了模型一上来就知道该按什么规矩干活。Sub-agent 在处理批量任务时省下的时间也很可观尤其是那种“改二十个文件”的活拆开并行比串行快好几倍。如果你刚开始用我的建议是别一上来就追求全套焚诀。先把安装搞定再写好 CLAUDE.md用顺了再尝试 Sub-agent 和 effort 调节。一步一个脚印比一次性堆满配置然后被各种问题劝退要靠谱得多。这套东西的价值不在于配置多花哨而在于它能不能真正融进你的日常工作流让你少干重复活、多干有价值的事。