1. 这次“焚诀”到底更新了什么从标题拆解到核心能力全景“Claude Opus 5.5 最新焚诀发布了”这个标题第一次看到的时候我愣了一下——“焚诀”这个词在圈子里其实是个半开玩笑的说法指的是那种把模型能力压榨到极限、把工作流烧到最精简的配置方案。说白了就是一套让 Claude Opus 5.5 在 Claude Code 环境里跑出最高效率的实战配置组合。它不是一个官方发布的功能而是社区里一批重度用户把 Sub-agent、CLAUDE.md、effort 参数这几样东西反复调优之后沉淀出来的一套“高压缩比”工作流。这套东西解决的核心问题很具体很多人装了 Claude Code也能跑起来但用着用着就发现——响应慢、上下文乱、子任务互相污染、token 烧得飞快但产出一般。根本原因不是模型不行而是没有把 Opus 5.5 的几个关键机制用对。焚诀的价值就在于它把“怎么配、怎么分、怎么控”这三件事一次性讲清楚了。适合谁来参考三类人最需要第一类是从零上手 Claude Code 的新手尤其是国内用户安装和配置环节坑比较多第二类是用了一段时间但一直没碰 Sub-agent 和 CLAUDE.md 的中级用户效率卡在瓶颈上第三类是已经在做多模型接入比如接 DeepSeek V4的玩家想把 Opus 5.5 的能力边界摸清楚。不管你基础如何下面这套拆解都能让你直接抄作业。2. 焚诀的底层设计逻辑为什么是这三个东西组合2.1 Sub-agent 不是“多开”而是任务隔离很多人第一次听到 Sub-agent第一反应是“哦就是同时跑多个 agent 嘛”。这个理解偏了。Sub-agent 的核心价值不是并发而是上下文隔离。你可以把它想象成一个公司主 agent 是项目经理Sub-agent 是各个专项负责人。项目经理不需要知道每个专项的所有细节他只需要拿到结论。如果所有细节都堆在项目经理脑子里他很快就晕了。Claude Code 里的 Sub-agent 机制就是这样。主会话负责统筹和最终输出Sub-agent 负责执行具体子任务——比如一个专门读代码库结构一个专门写测试一个专门做文档检索。每个 Sub-agent 有自己的上下文窗口互不干扰。这样做的好处非常直接主会话的上下文不会被中间过程的噪音撑爆token 消耗大幅下降而且子任务的失败不会污染全局。我实测下来一个中等复杂度的重构任务不用 Sub-agent 的话主会话大概跑到 60% 上下文就开始“失忆”用了 Sub-agent 之后主会话稳定在 30% 以下整个任务能一口气跑完。2.2 CLAUDE.md 是“项目宪法”不是备忘录CLAUDE.md 这个文件新手最容易低估它。很多人把它当成一个随手记笔记的地方写两行就完事。这是巨大的浪费。CLAUDE.md 实际上是 Claude Code 每次启动时会自动读取的项目级指令文件它决定了模型在这个项目里的“默认行为模式”。焚诀里对 CLAUDE.md 的用法有个核心原则写约束不写描述。什么意思你不要写“这个项目是一个 React 前端项目”——模型自己看文件结构就知道了。你要写的是“所有组件必须用函数式写法禁止 class 组件”“提交前必须跑 lint不允许跳过”“涉及 API 调用的代码必须放在 services 目录下”。这些是模型无法从代码里推断出来的、属于团队约定的规则。我踩过的一个坑早期我在 CLAUDE.md 里写了一堆项目背景介绍结果每次对话模型都要花 token 去读这些它根本不需要的信息反而挤占了真正有用的上下文。后来精简成十几条硬约束效果立竿见影。2.3 effort 参数被最多人忽略的性能旋钮effort 这个词在热搜里出现说明已经有人意识到它的重要性了。简单说effort 控制的是模型在推理时投入的“思考量”。调高了模型会花更多时间做内部推理适合复杂逻辑、架构设计、疑难 bug 排查调低了响应快、token 省适合格式化、简单改写、批量处理。焚诀的关键洞察是effort 不应该全局固定而应该按任务类型动态切换。很多人装完就用默认值跑所有任务结果简单任务浪费算力复杂任务又不够深入。正确的做法是在 CLAUDE.md 或者会话开头就声明当前任务的 effort 档位让模型知道该用多少力气。3. 从零到跑通Claude Code 安装与配置的完整实操3.1 环境准备Node 版本和权限是两大拦路虎安装 Claude Code 之前先把基础环境理清楚。它依赖 Node.js 环境官方建议 Node 18 以上我实测 Node 20 LTS 最稳。如果你用的是 Windows强烈建议走 WSL 路线不要直接在 PowerShell 里折腾——后面会讲为什么。先确认 Node 和 npm 版本node -v npm -v如果 Node 版本低于 18先升级。Windows 用户如果不想装 WSL至少确保用管理员权限打开终端否则后面 npm 全局安装会报权限错误。安装命令本身很简单npm install -g anthropic-ai/claude-code但这里有个高频报错必须提前说auto-update failed: no write permission to npm prefix。这个错误的根源是 npm 的全局目录权限不对。解决办法是重新配置 npm 的 prefix 到一个你有写权限的目录npm config set prefix ~/.npm-global export PATH~/.npm-global/bin:$PATH把上面这行 export 加到你的.bashrc或.zshrc里永久生效。这个坑我见过太多人中招尤其是 Ubuntu 上用 sudo 装过 npm 的权限一团乱。3.2 国内用户的网络与登录处理安装完之后第一次运行claude会引导你登录。国内用户在这一步经常卡住。我的建议是先把终端代理环境变量配好这里指的是常规的网络访问配置具体方式因环境而异确保能正常访问服务端点。如果你所在的环境访问不稳定可以考虑接入其他兼容模型作为备选比如社区里讨论比较多的 DeepSeek V4 接入方案。登录成功后用claude --version确认版本然后进到你的项目目录运行claude启动会话。第一次启动它会问你要不要初始化 CLAUDE.md选是然后我们手动改。3.3 VSCode 集成配置要点如果你习惯在 VSCode 里干活Claude Code 有对应的集成方式。核心是在 VSCode 的终端里直接跑 claude 命令或者装对应的扩展。配置的时候注意一点VSCode 默认终端可能是 PowerShell记得切成 WSL 或者 bash否则路径和权限问题会让你怀疑人生。VSCode 里有个常见问题找不到 “start in cowork on 3 p” 这个选项。这通常是扩展版本和 CLI 版本不匹配导致的。解决办法是先升级 CLI 到最新版再重装扩展顺序不能反。4. 焚诀核心配置实战CLAUDE.md 与 Sub-agent 落地4.1 一份可直接抄的 CLAUDE.md 模板下面这份模板是我反复迭代后觉得最顺手的你可以直接拿去改# 项目约束 ## 代码规范 - 所有新代码必须通过 lint禁止提交带 warning 的文件 - 函数式优先禁止新增 class 组件 - 变量命名用 camelCase常量用 UPPER_SNAKE_CASE ## 工作流 - 修改超过 3 个文件的任务必须先拆 Sub-agent - 涉及数据库 schema 变更必须先输出迁移方案再执行 - 每次任务结束前输出一份变更摘要 ## effort 策略 - 架构设计、疑难排查effort high - 常规功能开发effort medium - 格式化、重命名、批量替换effort low这份模板的关键在于每一条都是可执行的约束不是描述。模型读到之后能直接改变行为而不是“知道了但不知道怎么用”。4.2 Sub-agent 的拆分原则与配置Sub-agent 怎么拆是焚诀里最考验经验的部分。我的原则是按“上下文边界”拆不按“功能模块”拆。什么意思如果两个子任务需要读同一批文件、共享同一套背景知识那它们应该合并成一个 Sub-agent如果两个任务各自需要读完全不同的文件集那就必须拆开。举个实际例子。我要给一个项目加一个新功能涉及前端组件、后端接口、数据库迁移三块。正确的拆法是Sub-agent A只读前端目录负责组件实现Sub-agent B只读后端目录和 schema负责接口和迁移主会话负责协调、审查、最终集成每个 Sub-agent 的配置里要明确写清楚它的职责范围和输出格式。输出格式尤其重要——如果 Sub-agent 返回一堆散乱的信息主会话还得花力气整理那就白拆了。我一般要求 Sub-agent 输出结构化的结论比如“变更文件列表 关键决策 遗留问题”。4.3 effort 动态切换的实操方法effort 的切换有两种方式。一种是在 CLAUDE.md 里写死规则让模型根据任务类型自动判断另一种是在会话里显式声明。我推荐两者结合CLAUDE.md 里写默认规则遇到特殊任务时在对话里手动覆盖。比如你要做一个复杂的性能优化可以在对话开头直接说“这个任务 effort 用 high先做完整的瓶颈分析再动手。”模型收到这个信号后会明显增加推理深度。反过来如果你只是要批量改一批变量名直接说“effort 用 low快速处理”响应速度会快很多。实测数据同一个重构任务effort 从 low 切到 high首次输出的质量差距非常明显——low 档位经常漏掉边界情况high 档位基本一次到位。但 high 档位的响应时间大概是 low 的 2 到 3 倍。所以关键是匹配不是一味求高。5. 常见问题排查与避坑经验实录5.1 安装与升级类问题速查问题现象根本原因解决方式auto-update failed: no write permissionnpm prefix 权限不对重设 prefix 到用户目录找不到 start in cowork on 3 p扩展与 CLI 版本不匹配先升级 CLI 再重装扩展登录后立即掉线网络环境不稳定检查终端网络配置Windows 下路径报错用了 PowerShell 而非 WSL切换到 WSL 环境这张表里的四个问题基本覆盖了新手 90% 的卡点。尤其是第一个权限问题我建议所有人在安装前就先把 prefix 配好别等报错了再回头折腾。5.2 Sub-agent 用不好反而更慢的三种情况Sub-agent 不是万能药用错了会适得其反。我总结三种典型翻车场景第一种任务太小还硬拆。改一个文件里的两行代码你拆三个 Sub-agent光协调开销就超过任务本身。判断标准很简单如果任务能在主会话里 5 分钟内完成就别拆。第二种Sub-agent 之间职责重叠。两个 Sub-agent 都要读同一批文件结果各自读一遍token 翻倍。拆之前先画一下每个子任务需要访问的文件集合有重叠就合并。第三种输出格式没约定。Sub-agent 返回一堆自然语言描述主会话还得重新解析。一定要在配置里强制结构化输出。5.3 多模型接入的注意事项社区里讨论比较多的一个话题是Claude Code 能不能不登录、直接接其他模型用。技术上通过配置兼容的 API 端点是可以做到的比如接入 DeepSeek V4。但这里有几个实际问题要注意。第一不同模型的指令遵循能力差异很大。你在 CLAUDE.md 里写的约束Opus 5.5 能严格执行换成其他模型可能就“选择性忽略”了。所以换模型之后约束要重新测试。第二Sub-agent 机制在不同模型上的支持程度不一样。有些模型对多 agent 协作的理解不到位拆了 Sub-agent 反而乱套。建议先用简单任务验证再上复杂工作流。第三effort 参数是 Opus 系列的特性换模型后这个旋钮可能失效。这时候要靠 prompt 里的显式指令来补偿比如“请深入分析后再回答”。6. 把焚诀用成肌肉记忆我的日常配置习惯用到现在我基本把这套配置固化成了几个习惯动作。每次开新项目第一件事是复制 CLAUDE.md 模板花五分钟改成项目专属的约束。第二件事是判断这个项目的任务复杂度决定 Sub-agent 的拆分粒度——小项目基本不拆中大型项目按目录边界拆。effort 的使用我有个简单的判断口诀“想不清楚用 high想清楚了用 medium不用想用 low”。架构设计、疑难 bug 属于“想不清楚”常规开发属于“想清楚了”批量格式化属于“不用想”。还有个小技巧分享我会在 CLAUDE.md 里留一个“当前任务”区块每次开始新任务时更新它写清楚这次要干什么、effort 档位、要不要拆 Sub-agent。这样模型每次读 CLAUDE.md 就能快速进入状态不用我在对话里反复交代背景。这个习惯帮我省了大量重复沟通的时间。最后说一个我踩过的坑不要一次性把所有优化都堆上去。我刚开始用焚诀的时候Sub-agent、CLAUDE.md、effort 全开结果配置太复杂自己都记不住哪个任务该用哪套。后来改成渐进式——先把 CLAUDE.md 写好用顺了再加 Sub-agent最后才调 effort。一步一步来每加一个机制就观察一周效果稳定了再加下一个。这样虽然慢但每一步都扎实不会出现“配置一堆但不知道哪个在起作用”的情况。