1. 这次更新到底改了什么从“焚诀”说起“焚诀”这个词在圈子里流传开来其实带着点调侃的意味——意思是这套配置一旦调好模型就像被打通了任督二脉输出质量和执行效率会有肉眼可见的跃升。Claude Opus 5.5 这一版发布之后我第一时间在自己的主力工作流里跑了一轮从代码生成、长文档重构到多步骤任务编排整体感受是它不是一个简单的版本号递增而是把“模型能力”和“工程化调用方式”这两件事绑得更紧了。具体来说这次更新最值得关注的有三个方向。第一是effort 参数的语义变得更细腻不再是简单的“快/慢”二选一而是可以在推理深度、工具调用频率、上下文回溯次数之间做更精细的权衡。第二是Sub-agent 机制的成熟度明显提升主 agent 可以把子任务派发给专门的子 agent各自维护独立的上下文窗口最后再汇总结果这对处理那种“一个任务里嵌套七八个不同领域子问题”的场景特别有用。第三是CLAUDE.md 项目级配置的权重被进一步强化它不再只是一个“给模型看的说明文件”而是真正参与到任务规划、工具选择、输出格式约束的决策链路里。如果你之前只是把 Claude 当成一个“更聪明的聊天框”那这次更新之后我建议你换个思路把它当成一个可配置、可编排、可沉淀经验的执行引擎。下面我会从整体设计思路、核心细节、实操流程、常见问题四个层面把这次“焚诀”到底怎么烧、烧在哪、怎么复现一条一条拆开讲。2. 整体设计思路为什么是“配置驱动”而不是“提示词驱动”2.1 从“写好提示词”到“搭好工作台”早期用 Claude 的时候大家比拼的是谁提示词写得巧。但用过一段时间就会发现提示词这东西有两个致命问题一是不可复用换个项目、换个任务类型之前那套话术基本要重写二是不可维护一个提示词写到三千字改一处就牵一发而动全身最后没人敢动。这次 Opus 5.5 的更新方向本质上是在推着大家从“提示词工程”转向“配置工程”。CLAUDE.md 就是这个转变的锚点。它放在项目根目录下模型在每次任务开始前会读取它里面写清楚这个项目的技术栈、目录结构约定、代码风格、禁止事项、常用命令。这样一来你不需要在每个对话里重复交代背景模型自己就知道“这个项目用 pnpm 不用 npm”“测试文件放在tests下”“不要动 legacy 目录”。我实测下来一个写得好的 CLAUDE.md 能把重复解释成本降低七成以上。更重要的是它让团队协作成为可能——以前每个人的提示词都是私货现在配置进仓库谁拉下来都能用同一套规则。2.2 Sub-agent 的设计哲学分而治之各管一摊Sub-agent 这个概念其实不新鲜但这次落地得比较扎实。核心逻辑是主 agent 负责拆解和调度子 agent 负责执行和返回。每个子 agent 有自己独立的上下文不会把主 agent 的上下文撑爆。举个我实际遇到的例子我要重构一个老项目涉及数据库 schema 调整、API 层改写、前端组件适配三块。如果全塞给一个 agent上下文很快就满了而且它会在三个领域之间反复横跳输出质量下降。用 Sub-agent 之后我让主 agent 分别派三个子任务一个专门看 schema 和迁移脚本一个专门改 API 路由和 service 层一个专门处理前端调用。三个子 agent 并行跑各自返回结构化结果主 agent 最后做一致性校验。这里的关键设计考量是上下文隔离。子 agent 不需要知道全局所有细节它只需要知道自己那一摊的输入和输出契约。这跟微服务的思想很像——边界清晰接口稳定各自独立演进。2.3 effort 参数不是“越慢越好”而是“匹配任务复杂度”effort 这个参数容易被误解。很多人以为调高就是“让模型多想一会儿”其实它的作用更接近资源分配策略。低 effort 适合那种确定性高、步骤固定的任务比如格式化代码、生成样板文件高 effort 适合需要多轮推理、工具调用、自我校验的任务比如架构设计、复杂 bug 定位。我自己的经验是不要全局设一个值而是按任务类型动态调。日常的代码补全、注释生成用低 effort 就够了响应快、成本低遇到需要跨文件分析、多方案对比的场景再切到高 effort。Opus 5.5 在这块的调度比上一版顺滑很多切换时不会出现明显的“性格突变”。3. 核心细节解析CLAUDE.md、Sub-agent、effort 三件套怎么配3.1 CLAUDE.md 到底该写什么很多人第一次写 CLAUDE.md 会写成“项目说明书”把 README 的内容复制一遍。这是误区。CLAUDE.md 的目标读者是模型不是人所以它应该写模型做决策时需要知道、但光看代码看不出来的信息。我一般会分这几块来写项目定位与边界这个项目是干什么的哪些目录是核心哪些是历史遗留不要动。技术栈与版本约束Node 版本、包管理器、框架版本、数据库类型。这些信息模型猜不出来必须明确。代码风格与命名约定缩进、引号、命名法、文件组织方式。写清楚之后模型生成的代码基本不用再手动调格式。常用命令dev、build、test、lint 的具体命令。模型需要跑验证时会直接调用。禁止事项不要改某文件、不要引入某依赖、不要用某 API。这一块能省掉大量返工。一个实操技巧CLAUDE.md 不要一次写太长先写核心约束跑几轮之后把模型反复问你的问题补进去。它是活的文档不是一次性作业。3.2 Sub-agent 的拆分粒度怎么定拆分粒度是个经验活。拆太粗等于没拆拆太细调度开销比执行还大。我的判断标准是如果一个子任务需要独立的上下文才能做好就值得拆。具体来说以下几种情况适合拆 Sub-agent场景是否拆理由跨多个技术栈的改造拆每个栈的上下文差异大混在一起容易串味需要大量文件读取的分析拆避免主上下文被文件内容撑爆独立的验证/测试任务拆验证逻辑和执行逻辑分离结果更可信单一文件的简单修改不拆调度成本高于收益强依赖前序步骤结果的任务不拆拆了反而要来回传状态我踩过的一个坑是把“写测试”和“写实现”拆成两个子 agent结果两边对接口的理解不一致测试跑不过。后来改成同一个 agent 先写实现再写测试或者让主 agent 先把接口契约定死再分发问题就解决了。拆分的核心不是任务数量而是接口契约是否清晰。3.3 effort 的档位选择与切换时机effort 的档位我一般分三档来用低档格式化、重命名、生成注释、写简单 CRUD。这类任务路径明确不需要探索。中档常规功能开发、bug 修复、代码审查。需要一定推理但不需要多方案对比。高档架构设计、性能优化、复杂问题定位、多方案权衡。需要反复推演和自检。切换时机上我的做法是在任务描述里显式说明而不是靠模型自己猜。比如“这是一个需要仔细权衡的方案设计任务请用高 effort 处理”模型会据此调整策略。Opus 5.5 对这类指令的响应比之前更准确不会出现“说了高 effort 但还是草草了事”的情况。4. 实操过程从零搭一套可复用的工作流4.1 环境准备与基础配置不管你用哪种方式接入第一步都是把基础环境理顺。我自己的主力环境是 macOS VS Code但下面这套流程在 WindowsWSL和 Ubuntu 上同样适用。先确认 Node 环境。Claude Code 这类工具对 Node 版本有要求建议用 18 以上node -v npm -v如果版本太低用 nvm 切一下nvm install 20 nvm use 20然后是安装。全局安装的方式最省心npm install -g anthropic-ai/claude-code安装完之后验证一下claude --version这里有个常见坑npm 全局目录权限问题。如果你看到auto-update failed: no write permission to npm prefix这类报错说明 npm 的全局前缀目录当前用户没有写权限。解决办法是改 npm 前缀到用户目录npm config set prefix ~/.npm-global export PATH~/.npm-global/bin:$PATH把上面这行 export 写进.bashrc或.zshrc以后就不会再遇到权限问题。这个坑我在 Ubuntu 上遇到过两次Windows WSL 里也遇到过一次本质都是权限归属问题。4.2 VS Code 与 PyCharm 的插件配置VS Code 里配置 Claude Code核心是让它能在项目根目录正确读取 CLAUDE.md。我的做法是在项目根目录建一个.claude目录里面放配置文件CLAUDE.md 放在项目根。如果你用 PyCharm插件配置逻辑类似但要注意工作目录的设置。PyCharm 默认的工作目录有时是项目根有时是当前文件所在目录这会导致 CLAUDE.md 读不到。手动把工作目录固定到项目根就行。一个实操细节在 VS Code 的 settings.json 里把终端的默认工作目录设成项目根这样无论从哪个入口启动模型看到的上下文都是一致的。{ terminal.integrated.cwd: ${workspaceFolder} }4.3 写一份能打的 CLAUDE.md下面是我在一个中型前端项目里实际用的 CLAUDE.md 骨架你可以直接抄去改# 项目约定 ## 技术栈 - 框架React 18 TypeScript 5 - 构建Vite - 包管理pnpm禁止使用 npm/yarn - 测试Vitest Testing Library ## 目录结构 - src/components通用组件每个组件一个目录 - src/features业务功能模块按领域划分 - src/lib工具函数纯函数优先 - src/types全局类型定义 ## 代码风格 - 使用函数式组件 hooks - 禁止 class 组件 - 类型定义优先用 interface联合类型用 type - 导入顺序外部依赖 → 内部模块 → 类型 ## 常用命令 - 开发pnpm dev - 构建pnpm build - 测试pnpm test - 类型检查pnpm typecheck ## 禁止事项 - 不要修改 legacy/ 目录下的任何文件 - 不要引入新的 UI 库现有组件库够用 - 不要用 any实在需要就用 unknown 类型守卫这份文件写完之后我让模型做一个新功能它生成的代码基本一次过 lint 和 typecheck省掉了大量来回。4.4 Sub-agent 的实际编排Sub-agent 的编排我一般用“主 agent 定契约 → 子 agent 执行 → 主 agent 校验”这个三段式。第一步主 agent 先输出一份任务拆解和接口契约。比如重构任务契约里要写清楚每个子任务的输入是什么、输出是什么格式、依赖哪些前置结果。第二步按契约派发子任务。每个子任务描述里带上 CLAUDE.md 的路径让子 agent 自己读配置。第三步主 agent 收集结果做一致性校验。这一步很关键因为子 agent 之间可能对同一个接口有不同理解主 agent 要负责对齐。我实测下来这套流程处理一个涉及 15 个文件的重构任务比单 agent 串行处理快了将近一倍而且输出质量更稳定。4.5 effort 的动态调整实战在一个典型的开发日里我的 effort 使用是这样的早上处理 issue 列表大部分是简单修复用低 effort 批量过遇到一个性能问题切到高 effort 做火焰图分析和方案对比下午写新功能用中 effort晚上做代码审查切回中 effort 但加上“请重点检查边界条件”的指令。这里有个技巧把 effort 和任务描述绑定而不是和会话绑定。同一个会话里不同任务可以用不同 effort模型会根据当前任务描述来判断。Opus 5.5 在这块的上下文切换做得比较自然不会因为前面用了高 effort 就一直保持高消耗。5. 常见问题与排查技巧实录5.1 安装与权限类问题问题现象可能原因解决思路auto-update failed: no write permissionnpm 全局目录无写权限改 npm prefix 到用户目录命令找不到PATH 未包含全局 bin 目录把 prefix/bin 加入 PATHWSL 下安装后无法启动环境变量未在 WSL 内生效在 WSL 的 shell 配置里重新 export插件里读不到 CLAUDE.md工作目录不对固定工作目录到项目根这类问题的共同点是环境隔离。Windows 和 WSL 是两套环境VS Code 的终端和系统终端也可能是两套环境。排查时先确认“你在哪个环境里执行命令”再确认“那个环境的 PATH 和权限是什么”。5.2 配置不生效类问题CLAUDE.md 写了但模型不遵守通常有三个原因。一是文件位置不对必须在项目根目录子目录里的不会被自动读取。二是内容太模糊比如写“代码要规范”模型不知道什么叫规范要写成“使用 2 空格缩进、单引号、尾随逗号”。三是和任务描述冲突任务里说“快速实现”配置里说“必须写测试”模型会优先响应任务描述。我的经验是配置管长期约束任务描述管当次目标。两者不要打架打架时以任务描述为准但任务结束后要回头检查配置是不是需要更新。5.3 Sub-agent 结果不一致类问题子 agent 之间结果对不上根因基本都是契约不清晰。比如一个子 agent 认为接口返回{ data, error }另一个认为返回{ result, message }最后合并时必然出问题。解决办法是在派发前让主 agent 先输出一份接口定义所有子 agent 都基于这份定义工作。如果任务复杂可以先让主 agent 只做契约设计确认无误后再派发执行。多花五分钟定契约能省掉半小时的返工。5.4 性能与成本类问题高 effort 用多了响应会变慢成本也会上去。我的控制策略是默认中档按需升降。具体来说日常任务用中档批量简单任务临时降到低档复杂任务手动升到高档。不要全局设高档那是浪费。另外Sub-agent 虽然能提升质量但每个子 agent 都是一次独立的调用成本是叠加的。所以拆分粒度要控制不要为了拆而拆。我的经验是一个任务如果拆成超过 5 个子 agent就要重新审视拆分逻辑是不是合理。6. 我踩过的坑和几条实在建议第一个坑是过度依赖 CLAUDE.md。我一开始把什么细节都往里写结果文件长到两千多字模型读取时反而抓不住重点。后来精简到核心约束效果更好。CLAUDE.md 是“宪法”不是“法典”写原则和边界不写具体实现。第二个坑是Sub-agent 拆得太细。有次我把一个简单的表单改造拆成“写类型”“写组件”“写校验”三个子 agent结果三个 agent 对字段命名的理解不一致合并时改了半天。后来改成单 agent 一次做完反而更快。拆分的收益来自上下文隔离如果任务本身上下文很小拆了就是负收益。第三个坑是effort 设太高导致过度思考。有次我让模型改一个明显的拼写错误忘了调低 effort结果它给我分析了半天这个变量名的语义合理性。低 effort 不是“偷懒”是“匹配任务”。最后分享一个我一直在用的小技巧每次任务结束后花一分钟回顾一下这次哪些配置起了作用、哪些没起作用把有效的补进 CLAUDE.md把无效的删掉。这套工作流不是一次配好就完事它是随着项目一起长的。跑上一个月你会发现自己重复解释的东西越来越少模型一次做对的概率越来越高这才是“焚诀”真正的意思——不是某个神秘参数而是一套越用越顺的配置习惯。 Claude Opus 5.5 焚诀实战：CLAUDE.md、Sub-agent 与 effort 配置驱动工作流
1. 这次更新到底改了什么从“焚诀”说起“焚诀”这个词在圈子里流传开来其实带着点调侃的意味——意思是这套配置一旦调好模型就像被打通了任督二脉输出质量和执行效率会有肉眼可见的跃升。Claude Opus 5.5 这一版发布之后我第一时间在自己的主力工作流里跑了一轮从代码生成、长文档重构到多步骤任务编排整体感受是它不是一个简单的版本号递增而是把“模型能力”和“工程化调用方式”这两件事绑得更紧了。具体来说这次更新最值得关注的有三个方向。第一是effort 参数的语义变得更细腻不再是简单的“快/慢”二选一而是可以在推理深度、工具调用频率、上下文回溯次数之间做更精细的权衡。第二是Sub-agent 机制的成熟度明显提升主 agent 可以把子任务派发给专门的子 agent各自维护独立的上下文窗口最后再汇总结果这对处理那种“一个任务里嵌套七八个不同领域子问题”的场景特别有用。第三是CLAUDE.md 项目级配置的权重被进一步强化它不再只是一个“给模型看的说明文件”而是真正参与到任务规划、工具选择、输出格式约束的决策链路里。如果你之前只是把 Claude 当成一个“更聪明的聊天框”那这次更新之后我建议你换个思路把它当成一个可配置、可编排、可沉淀经验的执行引擎。下面我会从整体设计思路、核心细节、实操流程、常见问题四个层面把这次“焚诀”到底怎么烧、烧在哪、怎么复现一条一条拆开讲。2. 整体设计思路为什么是“配置驱动”而不是“提示词驱动”2.1 从“写好提示词”到“搭好工作台”早期用 Claude 的时候大家比拼的是谁提示词写得巧。但用过一段时间就会发现提示词这东西有两个致命问题一是不可复用换个项目、换个任务类型之前那套话术基本要重写二是不可维护一个提示词写到三千字改一处就牵一发而动全身最后没人敢动。这次 Opus 5.5 的更新方向本质上是在推着大家从“提示词工程”转向“配置工程”。CLAUDE.md 就是这个转变的锚点。它放在项目根目录下模型在每次任务开始前会读取它里面写清楚这个项目的技术栈、目录结构约定、代码风格、禁止事项、常用命令。这样一来你不需要在每个对话里重复交代背景模型自己就知道“这个项目用 pnpm 不用 npm”“测试文件放在tests下”“不要动 legacy 目录”。我实测下来一个写得好的 CLAUDE.md 能把重复解释成本降低七成以上。更重要的是它让团队协作成为可能——以前每个人的提示词都是私货现在配置进仓库谁拉下来都能用同一套规则。2.2 Sub-agent 的设计哲学分而治之各管一摊Sub-agent 这个概念其实不新鲜但这次落地得比较扎实。核心逻辑是主 agent 负责拆解和调度子 agent 负责执行和返回。每个子 agent 有自己独立的上下文不会把主 agent 的上下文撑爆。举个我实际遇到的例子我要重构一个老项目涉及数据库 schema 调整、API 层改写、前端组件适配三块。如果全塞给一个 agent上下文很快就满了而且它会在三个领域之间反复横跳输出质量下降。用 Sub-agent 之后我让主 agent 分别派三个子任务一个专门看 schema 和迁移脚本一个专门改 API 路由和 service 层一个专门处理前端调用。三个子 agent 并行跑各自返回结构化结果主 agent 最后做一致性校验。这里的关键设计考量是上下文隔离。子 agent 不需要知道全局所有细节它只需要知道自己那一摊的输入和输出契约。这跟微服务的思想很像——边界清晰接口稳定各自独立演进。2.3 effort 参数不是“越慢越好”而是“匹配任务复杂度”effort 这个参数容易被误解。很多人以为调高就是“让模型多想一会儿”其实它的作用更接近资源分配策略。低 effort 适合那种确定性高、步骤固定的任务比如格式化代码、生成样板文件高 effort 适合需要多轮推理、工具调用、自我校验的任务比如架构设计、复杂 bug 定位。我自己的经验是不要全局设一个值而是按任务类型动态调。日常的代码补全、注释生成用低 effort 就够了响应快、成本低遇到需要跨文件分析、多方案对比的场景再切到高 effort。Opus 5.5 在这块的调度比上一版顺滑很多切换时不会出现明显的“性格突变”。3. 核心细节解析CLAUDE.md、Sub-agent、effort 三件套怎么配3.1 CLAUDE.md 到底该写什么很多人第一次写 CLAUDE.md 会写成“项目说明书”把 README 的内容复制一遍。这是误区。CLAUDE.md 的目标读者是模型不是人所以它应该写模型做决策时需要知道、但光看代码看不出来的信息。我一般会分这几块来写项目定位与边界这个项目是干什么的哪些目录是核心哪些是历史遗留不要动。技术栈与版本约束Node 版本、包管理器、框架版本、数据库类型。这些信息模型猜不出来必须明确。代码风格与命名约定缩进、引号、命名法、文件组织方式。写清楚之后模型生成的代码基本不用再手动调格式。常用命令dev、build、test、lint 的具体命令。模型需要跑验证时会直接调用。禁止事项不要改某文件、不要引入某依赖、不要用某 API。这一块能省掉大量返工。一个实操技巧CLAUDE.md 不要一次写太长先写核心约束跑几轮之后把模型反复问你的问题补进去。它是活的文档不是一次性作业。3.2 Sub-agent 的拆分粒度怎么定拆分粒度是个经验活。拆太粗等于没拆拆太细调度开销比执行还大。我的判断标准是如果一个子任务需要独立的上下文才能做好就值得拆。具体来说以下几种情况适合拆 Sub-agent场景是否拆理由跨多个技术栈的改造拆每个栈的上下文差异大混在一起容易串味需要大量文件读取的分析拆避免主上下文被文件内容撑爆独立的验证/测试任务拆验证逻辑和执行逻辑分离结果更可信单一文件的简单修改不拆调度成本高于收益强依赖前序步骤结果的任务不拆拆了反而要来回传状态我踩过的一个坑是把“写测试”和“写实现”拆成两个子 agent结果两边对接口的理解不一致测试跑不过。后来改成同一个 agent 先写实现再写测试或者让主 agent 先把接口契约定死再分发问题就解决了。拆分的核心不是任务数量而是接口契约是否清晰。3.3 effort 的档位选择与切换时机effort 的档位我一般分三档来用低档格式化、重命名、生成注释、写简单 CRUD。这类任务路径明确不需要探索。中档常规功能开发、bug 修复、代码审查。需要一定推理但不需要多方案对比。高档架构设计、性能优化、复杂问题定位、多方案权衡。需要反复推演和自检。切换时机上我的做法是在任务描述里显式说明而不是靠模型自己猜。比如“这是一个需要仔细权衡的方案设计任务请用高 effort 处理”模型会据此调整策略。Opus 5.5 对这类指令的响应比之前更准确不会出现“说了高 effort 但还是草草了事”的情况。4. 实操过程从零搭一套可复用的工作流4.1 环境准备与基础配置不管你用哪种方式接入第一步都是把基础环境理顺。我自己的主力环境是 macOS VS Code但下面这套流程在 WindowsWSL和 Ubuntu 上同样适用。先确认 Node 环境。Claude Code 这类工具对 Node 版本有要求建议用 18 以上node -v npm -v如果版本太低用 nvm 切一下nvm install 20 nvm use 20然后是安装。全局安装的方式最省心npm install -g anthropic-ai/claude-code安装完之后验证一下claude --version这里有个常见坑npm 全局目录权限问题。如果你看到auto-update failed: no write permission to npm prefix这类报错说明 npm 的全局前缀目录当前用户没有写权限。解决办法是改 npm 前缀到用户目录npm config set prefix ~/.npm-global export PATH~/.npm-global/bin:$PATH把上面这行 export 写进.bashrc或.zshrc以后就不会再遇到权限问题。这个坑我在 Ubuntu 上遇到过两次Windows WSL 里也遇到过一次本质都是权限归属问题。4.2 VS Code 与 PyCharm 的插件配置VS Code 里配置 Claude Code核心是让它能在项目根目录正确读取 CLAUDE.md。我的做法是在项目根目录建一个.claude目录里面放配置文件CLAUDE.md 放在项目根。如果你用 PyCharm插件配置逻辑类似但要注意工作目录的设置。PyCharm 默认的工作目录有时是项目根有时是当前文件所在目录这会导致 CLAUDE.md 读不到。手动把工作目录固定到项目根就行。一个实操细节在 VS Code 的 settings.json 里把终端的默认工作目录设成项目根这样无论从哪个入口启动模型看到的上下文都是一致的。{ terminal.integrated.cwd: ${workspaceFolder} }4.3 写一份能打的 CLAUDE.md下面是我在一个中型前端项目里实际用的 CLAUDE.md 骨架你可以直接抄去改# 项目约定 ## 技术栈 - 框架React 18 TypeScript 5 - 构建Vite - 包管理pnpm禁止使用 npm/yarn - 测试Vitest Testing Library ## 目录结构 - src/components通用组件每个组件一个目录 - src/features业务功能模块按领域划分 - src/lib工具函数纯函数优先 - src/types全局类型定义 ## 代码风格 - 使用函数式组件 hooks - 禁止 class 组件 - 类型定义优先用 interface联合类型用 type - 导入顺序外部依赖 → 内部模块 → 类型 ## 常用命令 - 开发pnpm dev - 构建pnpm build - 测试pnpm test - 类型检查pnpm typecheck ## 禁止事项 - 不要修改 legacy/ 目录下的任何文件 - 不要引入新的 UI 库现有组件库够用 - 不要用 any实在需要就用 unknown 类型守卫这份文件写完之后我让模型做一个新功能它生成的代码基本一次过 lint 和 typecheck省掉了大量来回。4.4 Sub-agent 的实际编排Sub-agent 的编排我一般用“主 agent 定契约 → 子 agent 执行 → 主 agent 校验”这个三段式。第一步主 agent 先输出一份任务拆解和接口契约。比如重构任务契约里要写清楚每个子任务的输入是什么、输出是什么格式、依赖哪些前置结果。第二步按契约派发子任务。每个子任务描述里带上 CLAUDE.md 的路径让子 agent 自己读配置。第三步主 agent 收集结果做一致性校验。这一步很关键因为子 agent 之间可能对同一个接口有不同理解主 agent 要负责对齐。我实测下来这套流程处理一个涉及 15 个文件的重构任务比单 agent 串行处理快了将近一倍而且输出质量更稳定。4.5 effort 的动态调整实战在一个典型的开发日里我的 effort 使用是这样的早上处理 issue 列表大部分是简单修复用低 effort 批量过遇到一个性能问题切到高 effort 做火焰图分析和方案对比下午写新功能用中 effort晚上做代码审查切回中 effort 但加上“请重点检查边界条件”的指令。这里有个技巧把 effort 和任务描述绑定而不是和会话绑定。同一个会话里不同任务可以用不同 effort模型会根据当前任务描述来判断。Opus 5.5 在这块的上下文切换做得比较自然不会因为前面用了高 effort 就一直保持高消耗。5. 常见问题与排查技巧实录5.1 安装与权限类问题问题现象可能原因解决思路auto-update failed: no write permissionnpm 全局目录无写权限改 npm prefix 到用户目录命令找不到PATH 未包含全局 bin 目录把 prefix/bin 加入 PATHWSL 下安装后无法启动环境变量未在 WSL 内生效在 WSL 的 shell 配置里重新 export插件里读不到 CLAUDE.md工作目录不对固定工作目录到项目根这类问题的共同点是环境隔离。Windows 和 WSL 是两套环境VS Code 的终端和系统终端也可能是两套环境。排查时先确认“你在哪个环境里执行命令”再确认“那个环境的 PATH 和权限是什么”。5.2 配置不生效类问题CLAUDE.md 写了但模型不遵守通常有三个原因。一是文件位置不对必须在项目根目录子目录里的不会被自动读取。二是内容太模糊比如写“代码要规范”模型不知道什么叫规范要写成“使用 2 空格缩进、单引号、尾随逗号”。三是和任务描述冲突任务里说“快速实现”配置里说“必须写测试”模型会优先响应任务描述。我的经验是配置管长期约束任务描述管当次目标。两者不要打架打架时以任务描述为准但任务结束后要回头检查配置是不是需要更新。5.3 Sub-agent 结果不一致类问题子 agent 之间结果对不上根因基本都是契约不清晰。比如一个子 agent 认为接口返回{ data, error }另一个认为返回{ result, message }最后合并时必然出问题。解决办法是在派发前让主 agent 先输出一份接口定义所有子 agent 都基于这份定义工作。如果任务复杂可以先让主 agent 只做契约设计确认无误后再派发执行。多花五分钟定契约能省掉半小时的返工。5.4 性能与成本类问题高 effort 用多了响应会变慢成本也会上去。我的控制策略是默认中档按需升降。具体来说日常任务用中档批量简单任务临时降到低档复杂任务手动升到高档。不要全局设高档那是浪费。另外Sub-agent 虽然能提升质量但每个子 agent 都是一次独立的调用成本是叠加的。所以拆分粒度要控制不要为了拆而拆。我的经验是一个任务如果拆成超过 5 个子 agent就要重新审视拆分逻辑是不是合理。6. 我踩过的坑和几条实在建议第一个坑是过度依赖 CLAUDE.md。我一开始把什么细节都往里写结果文件长到两千多字模型读取时反而抓不住重点。后来精简到核心约束效果更好。CLAUDE.md 是“宪法”不是“法典”写原则和边界不写具体实现。第二个坑是Sub-agent 拆得太细。有次我把一个简单的表单改造拆成“写类型”“写组件”“写校验”三个子 agent结果三个 agent 对字段命名的理解不一致合并时改了半天。后来改成单 agent 一次做完反而更快。拆分的收益来自上下文隔离如果任务本身上下文很小拆了就是负收益。第三个坑是effort 设太高导致过度思考。有次我让模型改一个明显的拼写错误忘了调低 effort结果它给我分析了半天这个变量名的语义合理性。低 effort 不是“偷懒”是“匹配任务”。最后分享一个我一直在用的小技巧每次任务结束后花一分钟回顾一下这次哪些配置起了作用、哪些没起作用把有效的补进 CLAUDE.md把无效的删掉。这套工作流不是一次配好就完事它是随着项目一起长的。跑上一个月你会发现自己重复解释的东西越来越少模型一次做对的概率越来越高这才是“焚诀”真正的意思——不是某个神秘参数而是一套越用越顺的配置习惯。