1. 从焚诀这个词说起Opus 5.5 到底更新了什么第一次看到焚诀这个词我愣了几秒。圈内人把模型版本迭代叫焚诀大概是因为每次新版本发布都像烧掉旧攻略一样之前调好的提示词、踩过的坑、攒下的经验一夜之间可能就失效了。Claude Opus 5.5 这次发布我第一时间上手跑了几轮说实话变化没有想象中那么天翻地覆但有几个点确实值得单独拎出来讲。先明确一件事Opus 5.5 是 Anthropic 在 Opus 系列上的又一次迭代定位依然是旗舰级推理模型。它主要面向的是复杂推理、长上下文理解、代码生成与重构、多步骤任务编排这类场景。如果你平时只是拿它写写文案、改改邮件那这次升级对你感知不会太强但如果你在用 Claude Code 做工程化开发、用 Sub-agent 做任务拆分、或者依赖 CLAUDE.md 做项目级上下文管理那这次更新里的几个细节值得你花半小时重新调一遍配置。我这次实测的重点放在三个方向一是推理深度与 effort 参数的关系二是Claude Code 里 Sub-agent 的调度表现三是CLAUDE.md 在新版本下的解析逻辑有没有变化。这三个方向基本覆盖了大多数重度用户的核心工作流。下面我会把每个方向的实测过程、遇到的坑、以及我最终采用的配置方案完整写出来你可以直接抄作业也可以根据自己的项目规模做调整。需要提前说明的是我测试的环境是 macOS VS Code Claude Code 插件Node 版本 20.xnpm 全局安装。Windows 用户走 WSL 的路径我也顺带验证了一部分后面会单独提。整个测试周期大概三天跑了十几个不同类型的任务从简单的函数重构到跨文件的重型重构都有覆盖。2. effort 参数这次最容易被忽略但最影响体验的改动2.1 effort 到底是什么为什么它比模型版本更重要很多人盯着Opus 5.5这个版本号看却忽略了 effort 这个参数。我用一句话解释effort 决定了模型在回答前愿意想多久。你可以把它理解成给模型分配的思考预算——预算给得少它快速给你一个还行的答案预算给得多它会反复推敲、自我检查、甚至推翻自己之前的思路。这次 Opus 5.5 对 effort 的响应曲线做了调整。我实测下来的感受是低 effort 下的输出质量比上一代更稳了但高 effort 下的深度思考收益变得更明显。也就是说effort 的档位差异被拉大了。以前你可能觉得 low 和 high 差别不大现在这个差距会直接体现在代码质量和推理链完整性上。我做了个对比测试同一个任务把一个 300 行的 Python 脚本重构成模块化结构拆成 4 个文件保持所有原有功能不变。分别用 low、medium、high 三档 effort 跑effort 档位耗时输出质量主要问题low约 40 秒能跑但边界处理粗糙漏了 2 个异常分支import 顺序混乱medium约 2 分钟结构清晰基本可用有 1 处变量命名不一致high约 5 分钟结构清晰附带重构说明无明显问题还主动补了类型注解这个表格不是让你无脑选 high。关键在于任务复杂度和 effort 要匹配。简单任务用 high 是浪费时间和额度复杂任务用 low 是给自己挖坑。2.2 我的 effort 选择策略按任务类型分档踩了几次坑之后我总结出一套自己的分档策略分享给你low单文件小改动、格式化、重命名、写注释、简单的字符串处理。这类任务模型不需要想直接做就行。medium跨文件的中等重构、写单元测试、调试一个明确的报错、生成常规业务代码。这是我最常用的档位性价比最高。high架构级重构、复杂算法实现、多步骤任务编排、需要模型自己发现问题的场景。比如帮我找出这个模块的性能瓶颈并优化这种就必须 high。提示不要一次性把所有任务都设成 high。我试过连续跑 high结果不仅慢而且模型有时候会过度思考把简单问题复杂化反而引入不必要的抽象层。还有一个细节effort 是可以动态调整的。我的做法是先用 medium 跑一遍看输出质量如果发现模型理解偏了或者深度不够再针对性地用 high 重跑那一个环节。这样比一上来就 high 更省时间。2.3 effort 和 Sub-agent 的联动一个反直觉的发现这次测试里最让我意外的发现是Sub-agent 的 effort 继承逻辑变了。在之前的版本里主 agent 设了 highSub-agent 默认也会用较高的 effort。但 Opus 5.5 里Sub-agent 似乎有了自己的 effort 默认值不完全跟随主 agent。我实测的场景是主 agent 用 high 做任务编排拆出 3 个 Sub-agent 分别处理数据层、逻辑层、接口层。结果发现 Sub-agent 的输出深度明显低于主 agent 的预期有几个 Sub-agent 甚至直接给了骨架代码就交差了。后来我手动在每个 Sub-agent 的配置里显式指定 effort问题才解决。这个坑很隐蔽因为你不看 Sub-agent 的详细日志根本发现不了。我的建议是只要用了 Sub-agent就在每个 Sub-agent 的配置里显式写清楚 effort不要依赖继承。多写一行配置省下的是反复调试的时间。3. CLAUDE.md 在新版本下的解析变化与写法调整3.1 CLAUDE.md 的定位它不是提示词是项目宪法先给不熟悉的朋友补个基础。CLAUDE.md 是 Claude Code 在项目根目录读取的一个约定文件你可以把它理解成给模型看的项目说明书。每次 Claude Code 启动或者进入一个新任务时它会自动读取这个文件把里面的内容作为项目级上下文注入。很多人把 CLAUDE.md 当成提示词仓库往里塞一大堆指令。我早期也这么干结果发现效果越来越差。后来我想明白了CLAUDE.md 不是提示词它是项目宪法。宪法只写原则和边界不写具体操作。具体操作应该放在任务描述里。Opus 5.5 对 CLAUDE.md 的解析有个明显变化它对结构化内容的权重更高了。什么意思如果你用 Markdown 的标题、列表、表格来组织 CLAUDE.md模型会更好地识别哪些是规则、哪些是背景信息、哪些是示例。如果你写成一坨纯文本模型的理解会打折扣。3.2 我现在的 CLAUDE.md 模板结构经过几轮调整我现在的 CLAUDE.md 大概是这个结构你可以参考# 项目概述 一句话说明项目是什么、技术栈是什么。 # 目录结构约定 - src/ 放源码 - tests/ 放测试 - docs/ 放文档 # 代码规范 - 使用 2 空格缩进 - 函数命名用 camelCase - 所有导出函数必须有 JSDoc # 禁止事项 - 不要修改 config/ 下的文件 - 不要引入新的第三方依赖除非明确要求 # 常用命令 - 构建npm run build - 测试npm test这个结构的关键在于分区明确。模型能清楚知道哪部分是背景、哪部分是硬性规则、哪部分是参考信息。我实测下来这种结构化的 CLAUDE.md 比纯文本版本的指令遵循率高出一大截。3.3 一个容易踩的坑CLAUDE.md 太长反而有害我见过有人把 CLAUDE.md 写到 2000 多行恨不得把整个项目的所有细节都塞进去。这是个典型的误区。CLAUDE.md 越长模型的注意力越分散真正重要的规则反而被淹没在噪音里。我的经验值是CLAUDE.md 控制在 100 到 300 行之间。超过这个范围你就该考虑把一些内容拆到子目录的 CLAUDE.md 里或者干脆放到任务描述里按需提供。Opus 5.5 在这方面有个改进它对 CLAUDE.md 的分层读取支持更好了。你可以在子目录里放一个局部的 CLAUDE.md模型进入那个目录时会自动叠加读取。这个特性对于大型 monorepo 特别有用——根目录放全局规则每个子包放自己的局部规则。注意子目录的 CLAUDE.md 是叠加而不是覆盖。也就是说根目录的规则依然生效子目录的规则是在此基础上追加。如果你想让子目录的规则覆盖根目录需要在子目录里显式写明以下规则优先于根目录。4. Sub-agent 调度这次更新里最值得深挖的部分4.1 Sub-agent 解决的是什么问题先说清楚 Sub-agent 存在的意义。当你让 Claude Code 处理一个复杂任务时如果所有工作都在一个上下文里完成会出现两个问题一是上下文越来越长模型注意力下降二是不同子任务之间互相干扰比如写代码的时候被测试逻辑带偏。Sub-agent 的思路是主 agent 负责拆解和编排Sub-agent 负责执行具体子任务。每个 Sub-agent 有自己独立的上下文互不干扰。这就像工地上项目经理和工人的关系——项目经理不需要亲自搬砖他只需要把任务拆清楚、分下去、验收结果。Opus 5.5 在 Sub-agent 调度上的改进主要体现在两个方面一是拆解粒度更合理了二是Sub-agent 之间的依赖处理更智能了。4.2 实测一个跨文件重构任务的 Sub-agent 表现我设计了一个测试任务把一个包含 8 个文件的旧模块重构要求统一错误处理方式、抽取公共逻辑、补充类型定义。这个任务天然适合拆成多个 Sub-agent。我让主 agent 自己决定怎么拆。它的拆解方案是Sub-agent A分析现有代码输出重构方案Sub-agent B根据方案抽取公共逻辑Sub-agent C统一错误处理Sub-agent D补充类型定义主 agent整合并验证这个拆解比我预期的要合理。特别是它把分析单独拆成一个 Sub-agent这个做法很聪明——分析阶段的输出是后续所有工作的基础单独拆出来可以保证分析质量也方便我在中间介入检查。实测下来整个任务跑了大概 12 分钟比我手动做快了不止一倍。但过程中也暴露了一个问题Sub-agent B 和 Sub-agent C 有轻微冲突。B 抽取公共逻辑时改动了错误处理的调用方式C 不知道这个改动还在按旧方式统一错误处理。最后是主 agent 在整合阶段发现的又花了两分钟修复。4.3 避免 Sub-agent 冲突的三个实操技巧基于上面的踩坑我总结了三个技巧第一在任务描述里明确依赖顺序。不要指望模型自己理清所有依赖。你可以在任务里写先完成 A再基于 A 的结果做 B这样主 agent 编排时会考虑顺序。第二给每个 Sub-agent 划定明确的文件边界。如果两个 Sub-agent 可能改到同一个文件就要提前警告模型或者干脆合并成一个 Sub-agent。文件冲突是 Sub-agent 协作里最常见的问题。第三要求 Sub-agent 输出变更摘要。让每个 Sub-agent 在完成后输出一份简短的变更说明主 agent 整合时可以参考。这个习惯能大幅降低整合阶段的返工率。冲突类型典型场景预防手段文件冲突两个 agent 改同一文件划定文件边界或合并 agent逻辑冲突A 改了接口B 还在用旧接口明确依赖顺序风格冲突不同 agent 用不同命名风格在 CLAUDE.md 里统一规范重复劳动两个 agent 做了同一件事任务描述里写清职责边界5. 安装与升级那些文档里不会写的细节5.1 从零安装 Claude Code 的完整路径虽然网上教程很多但我还是把关键步骤和容易出问题的地方写一下因为我在帮朋友装的时候发现很多教程漏掉了几个关键点。macOS 和 Linux 下最省事的方式是用 npm 全局安装npm install -g anthropic-ai/claude-code装完之后直接运行claude就能启动。但这里有个坑如果你的 npm 全局目录没有写权限自动更新会失败。报错信息大概是auto-update failed: no write permission to npm prefix。解决办法是重新配置 npm 的全局目录或者用 sudo 安装不推荐。Windows 用户我强烈建议走 WSL。原生 Windows 下 Claude Code 的体验有不少小问题WSL 里跑基本和 Linux 一致。WSL 的安装步骤# 在 WSL 里先装 Node curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt-get install -y nodejs # 然后装 Claude Code npm install -g anthropic-ai/claude-codeVS Code 用户可以直接装 Claude Code 插件插件会自动调用本地的 CLI。如果你在 VS Code 里找不到 start in cowork 之类的选项大概率是插件版本和 CLI 版本不匹配升级一下就好。5.2 在线升级的正确姿势Claude Code 的升级有两种方式自动和手动。自动升级默认是开的但前面说了npm 权限问题会导致自动升级失败。手动升级就是重新跑一遍安装命令npm update -g anthropic-ai/claude-code我个人的习惯是关掉自动升级手动控制版本。原因很简单自动升级可能在你正跑一个重要任务时把版本换了导致行为不一致。手动升级可以让你在空闲时升级升级完先跑几个测试任务验证一下。提示升级前建议把当前的 CLAUDE.md 和常用配置备份一下。虽然大部分情况下配置是兼容的但大版本升级偶尔会有解析逻辑变化备份能让你快速回滚。5.3 关于不登录用其他模型这件事网上有不少讨论是关于能不能不登录、或者接入其他模型的。我的建议是优先用官方支持的路径。官方路径的稳定性和功能完整性是最好的第三方接入往往会缺失一些特性比如 Sub-agent 调度、CLAUDE.md 解析这些深度功能在非官方路径下可能表现不一致。如果你确实有接入其他模型的需求建议先在小项目上验证确认核心功能都能正常工作再迁移到主力项目。不要一上来就在重要项目上试出了问题排查成本很高。6. 把 Opus 5.5 用出价值的几个实战心得6.1 任务描述的质量决定输出质量的上限用了这么久我最大的体会是模型能力的提升永远替代不了任务描述的质量。Opus 5.5 再强你给它一个模糊的需求它也只能给你一个模糊的答案。我现在写任务描述有个固定套路背景 目标 约束 验收标准。举个例子背景这是一个电商订单模块目前所有逻辑都堆在一个 800 行的文件里。 目标拆分成 order-service、order-validator、order-repository 三个文件。 约束不改变任何对外接口不引入新依赖保持现有测试全部通过。 验收标准拆分后每个文件不超过 300 行所有原有测试通过新增至少 3 个边界测试。这样写出来的任务模型基本一次就能做对。反过来如果你只写帮我重构一下订单模块那结果就只能看运气了。6.2 善用先分析后执行的两段式工作流对于复杂任务我强烈建议拆成两段先让模型分析并输出方案你确认后再让它执行。这个习惯能帮你省下大量返工时间。具体做法是第一轮任务只要求输出分析和方案不要求改代码。你看完方案觉得方向对了再开第二轮让它执行。如果方案有问题你在第一轮就能发现改起来成本很低。Opus 5.5 在分析阶段的表现比上一代好不少它会主动指出一些你没考虑到的问题比如这个改动可能影响 X 模块、建议先补测试再重构。这些提醒很有价值别忽略。6.3 上下文管理该清理的时候要清理Claude Code 的会话是有上下文累积的。你聊得越久上下文越长模型的表现可能越不稳定。我的做法是一个任务一个会话任务完成就开新会话。不要在一个会话里连续做多个不相关的任务。如果任务确实很长中间需要保留上下文那就定期用/compact之类的命令压缩一下历史。压缩会丢失一些细节但能换来更稳定的表现这个取舍是值得的。6.4 关于焚诀的心态最后说点心态上的东西。每次新版本发布圈子里都会有一波焚诀焦虑——之前攒的经验是不是没用了提示词是不是要重写了我的看法是底层的工作方法不会因为版本迭代而失效。任务怎么拆、上下文怎么管、CLAUDE.md 怎么写这些是方法论层面的东西模型升级只会让好的方法效果更好不会让好的方法变差。真正需要重新调的是那些依赖具体参数和具体行为的技巧比如 effort 档位的选择、Sub-agent 的配置细节。所以别焦虑。花半小时把新版本的几个关键变化摸清楚把配置调一遍剩下的该干嘛干嘛。工具是拿来用的不是拿来供着的。我在实际使用中发现Opus 5.5 最舒服的用法是medium effort 结构化 CLAUDE.md 按需 Sub-agent这个组合。大部分日常任务用这套配置就够了遇到硬骨头再单独上 high。这套组合我跑了三天稳定性很好没有出现明显的翻车情况。如果你刚开始用不妨从这个组合起步再根据自己的项目特点微调。 
长河君 · 2026/10/26 17:19:30 · 阅读 1.2k Claude Opus 5.5 实测：effort 参数、CLAUDE.md 与 Sub-agent 调度深度解析
1. 从焚诀这个词说起Opus 5.5 到底更新了什么第一次看到焚诀这个词我愣了几秒。圈内人把模型版本迭代叫焚诀大概是因为每次新版本发布都像烧掉旧攻略一样之前调好的提示词、踩过的坑、攒下的经验一夜之间可能就失效了。Claude Opus 5.5 这次发布我第一时间上手跑了几轮说实话变化没有想象中那么天翻地覆但有几个点确实值得单独拎出来讲。先明确一件事Opus 5.5 是 Anthropic 在 Opus 系列上的又一次迭代定位依然是旗舰级推理模型。它主要面向的是复杂推理、长上下文理解、代码生成与重构、多步骤任务编排这类场景。如果你平时只是拿它写写文案、改改邮件那这次升级对你感知不会太强但如果你在用 Claude Code 做工程化开发、用 Sub-agent 做任务拆分、或者依赖 CLAUDE.md 做项目级上下文管理那这次更新里的几个细节值得你花半小时重新调一遍配置。我这次实测的重点放在三个方向一是推理深度与 effort 参数的关系二是Claude Code 里 Sub-agent 的调度表现三是CLAUDE.md 在新版本下的解析逻辑有没有变化。这三个方向基本覆盖了大多数重度用户的核心工作流。下面我会把每个方向的实测过程、遇到的坑、以及我最终采用的配置方案完整写出来你可以直接抄作业也可以根据自己的项目规模做调整。需要提前说明的是我测试的环境是 macOS VS Code Claude Code 插件Node 版本 20.xnpm 全局安装。Windows 用户走 WSL 的路径我也顺带验证了一部分后面会单独提。整个测试周期大概三天跑了十几个不同类型的任务从简单的函数重构到跨文件的重型重构都有覆盖。2. effort 参数这次最容易被忽略但最影响体验的改动2.1 effort 到底是什么为什么它比模型版本更重要很多人盯着Opus 5.5这个版本号看却忽略了 effort 这个参数。我用一句话解释effort 决定了模型在回答前愿意想多久。你可以把它理解成给模型分配的思考预算——预算给得少它快速给你一个还行的答案预算给得多它会反复推敲、自我检查、甚至推翻自己之前的思路。这次 Opus 5.5 对 effort 的响应曲线做了调整。我实测下来的感受是低 effort 下的输出质量比上一代更稳了但高 effort 下的深度思考收益变得更明显。也就是说effort 的档位差异被拉大了。以前你可能觉得 low 和 high 差别不大现在这个差距会直接体现在代码质量和推理链完整性上。我做了个对比测试同一个任务把一个 300 行的 Python 脚本重构成模块化结构拆成 4 个文件保持所有原有功能不变。分别用 low、medium、high 三档 effort 跑effort 档位耗时输出质量主要问题low约 40 秒能跑但边界处理粗糙漏了 2 个异常分支import 顺序混乱medium约 2 分钟结构清晰基本可用有 1 处变量命名不一致high约 5 分钟结构清晰附带重构说明无明显问题还主动补了类型注解这个表格不是让你无脑选 high。关键在于任务复杂度和 effort 要匹配。简单任务用 high 是浪费时间和额度复杂任务用 low 是给自己挖坑。2.2 我的 effort 选择策略按任务类型分档踩了几次坑之后我总结出一套自己的分档策略分享给你low单文件小改动、格式化、重命名、写注释、简单的字符串处理。这类任务模型不需要想直接做就行。medium跨文件的中等重构、写单元测试、调试一个明确的报错、生成常规业务代码。这是我最常用的档位性价比最高。high架构级重构、复杂算法实现、多步骤任务编排、需要模型自己发现问题的场景。比如帮我找出这个模块的性能瓶颈并优化这种就必须 high。提示不要一次性把所有任务都设成 high。我试过连续跑 high结果不仅慢而且模型有时候会过度思考把简单问题复杂化反而引入不必要的抽象层。还有一个细节effort 是可以动态调整的。我的做法是先用 medium 跑一遍看输出质量如果发现模型理解偏了或者深度不够再针对性地用 high 重跑那一个环节。这样比一上来就 high 更省时间。2.3 effort 和 Sub-agent 的联动一个反直觉的发现这次测试里最让我意外的发现是Sub-agent 的 effort 继承逻辑变了。在之前的版本里主 agent 设了 highSub-agent 默认也会用较高的 effort。但 Opus 5.5 里Sub-agent 似乎有了自己的 effort 默认值不完全跟随主 agent。我实测的场景是主 agent 用 high 做任务编排拆出 3 个 Sub-agent 分别处理数据层、逻辑层、接口层。结果发现 Sub-agent 的输出深度明显低于主 agent 的预期有几个 Sub-agent 甚至直接给了骨架代码就交差了。后来我手动在每个 Sub-agent 的配置里显式指定 effort问题才解决。这个坑很隐蔽因为你不看 Sub-agent 的详细日志根本发现不了。我的建议是只要用了 Sub-agent就在每个 Sub-agent 的配置里显式写清楚 effort不要依赖继承。多写一行配置省下的是反复调试的时间。3. CLAUDE.md 在新版本下的解析变化与写法调整3.1 CLAUDE.md 的定位它不是提示词是项目宪法先给不熟悉的朋友补个基础。CLAUDE.md 是 Claude Code 在项目根目录读取的一个约定文件你可以把它理解成给模型看的项目说明书。每次 Claude Code 启动或者进入一个新任务时它会自动读取这个文件把里面的内容作为项目级上下文注入。很多人把 CLAUDE.md 当成提示词仓库往里塞一大堆指令。我早期也这么干结果发现效果越来越差。后来我想明白了CLAUDE.md 不是提示词它是项目宪法。宪法只写原则和边界不写具体操作。具体操作应该放在任务描述里。Opus 5.5 对 CLAUDE.md 的解析有个明显变化它对结构化内容的权重更高了。什么意思如果你用 Markdown 的标题、列表、表格来组织 CLAUDE.md模型会更好地识别哪些是规则、哪些是背景信息、哪些是示例。如果你写成一坨纯文本模型的理解会打折扣。3.2 我现在的 CLAUDE.md 模板结构经过几轮调整我现在的 CLAUDE.md 大概是这个结构你可以参考# 项目概述 一句话说明项目是什么、技术栈是什么。 # 目录结构约定 - src/ 放源码 - tests/ 放测试 - docs/ 放文档 # 代码规范 - 使用 2 空格缩进 - 函数命名用 camelCase - 所有导出函数必须有 JSDoc # 禁止事项 - 不要修改 config/ 下的文件 - 不要引入新的第三方依赖除非明确要求 # 常用命令 - 构建npm run build - 测试npm test这个结构的关键在于分区明确。模型能清楚知道哪部分是背景、哪部分是硬性规则、哪部分是参考信息。我实测下来这种结构化的 CLAUDE.md 比纯文本版本的指令遵循率高出一大截。3.3 一个容易踩的坑CLAUDE.md 太长反而有害我见过有人把 CLAUDE.md 写到 2000 多行恨不得把整个项目的所有细节都塞进去。这是个典型的误区。CLAUDE.md 越长模型的注意力越分散真正重要的规则反而被淹没在噪音里。我的经验值是CLAUDE.md 控制在 100 到 300 行之间。超过这个范围你就该考虑把一些内容拆到子目录的 CLAUDE.md 里或者干脆放到任务描述里按需提供。Opus 5.5 在这方面有个改进它对 CLAUDE.md 的分层读取支持更好了。你可以在子目录里放一个局部的 CLAUDE.md模型进入那个目录时会自动叠加读取。这个特性对于大型 monorepo 特别有用——根目录放全局规则每个子包放自己的局部规则。注意子目录的 CLAUDE.md 是叠加而不是覆盖。也就是说根目录的规则依然生效子目录的规则是在此基础上追加。如果你想让子目录的规则覆盖根目录需要在子目录里显式写明以下规则优先于根目录。4. Sub-agent 调度这次更新里最值得深挖的部分4.1 Sub-agent 解决的是什么问题先说清楚 Sub-agent 存在的意义。当你让 Claude Code 处理一个复杂任务时如果所有工作都在一个上下文里完成会出现两个问题一是上下文越来越长模型注意力下降二是不同子任务之间互相干扰比如写代码的时候被测试逻辑带偏。Sub-agent 的思路是主 agent 负责拆解和编排Sub-agent 负责执行具体子任务。每个 Sub-agent 有自己独立的上下文互不干扰。这就像工地上项目经理和工人的关系——项目经理不需要亲自搬砖他只需要把任务拆清楚、分下去、验收结果。Opus 5.5 在 Sub-agent 调度上的改进主要体现在两个方面一是拆解粒度更合理了二是Sub-agent 之间的依赖处理更智能了。4.2 实测一个跨文件重构任务的 Sub-agent 表现我设计了一个测试任务把一个包含 8 个文件的旧模块重构要求统一错误处理方式、抽取公共逻辑、补充类型定义。这个任务天然适合拆成多个 Sub-agent。我让主 agent 自己决定怎么拆。它的拆解方案是Sub-agent A分析现有代码输出重构方案Sub-agent B根据方案抽取公共逻辑Sub-agent C统一错误处理Sub-agent D补充类型定义主 agent整合并验证这个拆解比我预期的要合理。特别是它把分析单独拆成一个 Sub-agent这个做法很聪明——分析阶段的输出是后续所有工作的基础单独拆出来可以保证分析质量也方便我在中间介入检查。实测下来整个任务跑了大概 12 分钟比我手动做快了不止一倍。但过程中也暴露了一个问题Sub-agent B 和 Sub-agent C 有轻微冲突。B 抽取公共逻辑时改动了错误处理的调用方式C 不知道这个改动还在按旧方式统一错误处理。最后是主 agent 在整合阶段发现的又花了两分钟修复。4.3 避免 Sub-agent 冲突的三个实操技巧基于上面的踩坑我总结了三个技巧第一在任务描述里明确依赖顺序。不要指望模型自己理清所有依赖。你可以在任务里写先完成 A再基于 A 的结果做 B这样主 agent 编排时会考虑顺序。第二给每个 Sub-agent 划定明确的文件边界。如果两个 Sub-agent 可能改到同一个文件就要提前警告模型或者干脆合并成一个 Sub-agent。文件冲突是 Sub-agent 协作里最常见的问题。第三要求 Sub-agent 输出变更摘要。让每个 Sub-agent 在完成后输出一份简短的变更说明主 agent 整合时可以参考。这个习惯能大幅降低整合阶段的返工率。冲突类型典型场景预防手段文件冲突两个 agent 改同一文件划定文件边界或合并 agent逻辑冲突A 改了接口B 还在用旧接口明确依赖顺序风格冲突不同 agent 用不同命名风格在 CLAUDE.md 里统一规范重复劳动两个 agent 做了同一件事任务描述里写清职责边界5. 安装与升级那些文档里不会写的细节5.1 从零安装 Claude Code 的完整路径虽然网上教程很多但我还是把关键步骤和容易出问题的地方写一下因为我在帮朋友装的时候发现很多教程漏掉了几个关键点。macOS 和 Linux 下最省事的方式是用 npm 全局安装npm install -g anthropic-ai/claude-code装完之后直接运行claude就能启动。但这里有个坑如果你的 npm 全局目录没有写权限自动更新会失败。报错信息大概是auto-update failed: no write permission to npm prefix。解决办法是重新配置 npm 的全局目录或者用 sudo 安装不推荐。Windows 用户我强烈建议走 WSL。原生 Windows 下 Claude Code 的体验有不少小问题WSL 里跑基本和 Linux 一致。WSL 的安装步骤# 在 WSL 里先装 Node curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt-get install -y nodejs # 然后装 Claude Code npm install -g anthropic-ai/claude-codeVS Code 用户可以直接装 Claude Code 插件插件会自动调用本地的 CLI。如果你在 VS Code 里找不到 start in cowork 之类的选项大概率是插件版本和 CLI 版本不匹配升级一下就好。5.2 在线升级的正确姿势Claude Code 的升级有两种方式自动和手动。自动升级默认是开的但前面说了npm 权限问题会导致自动升级失败。手动升级就是重新跑一遍安装命令npm update -g anthropic-ai/claude-code我个人的习惯是关掉自动升级手动控制版本。原因很简单自动升级可能在你正跑一个重要任务时把版本换了导致行为不一致。手动升级可以让你在空闲时升级升级完先跑几个测试任务验证一下。提示升级前建议把当前的 CLAUDE.md 和常用配置备份一下。虽然大部分情况下配置是兼容的但大版本升级偶尔会有解析逻辑变化备份能让你快速回滚。5.3 关于不登录用其他模型这件事网上有不少讨论是关于能不能不登录、或者接入其他模型的。我的建议是优先用官方支持的路径。官方路径的稳定性和功能完整性是最好的第三方接入往往会缺失一些特性比如 Sub-agent 调度、CLAUDE.md 解析这些深度功能在非官方路径下可能表现不一致。如果你确实有接入其他模型的需求建议先在小项目上验证确认核心功能都能正常工作再迁移到主力项目。不要一上来就在重要项目上试出了问题排查成本很高。6. 把 Opus 5.5 用出价值的几个实战心得6.1 任务描述的质量决定输出质量的上限用了这么久我最大的体会是模型能力的提升永远替代不了任务描述的质量。Opus 5.5 再强你给它一个模糊的需求它也只能给你一个模糊的答案。我现在写任务描述有个固定套路背景 目标 约束 验收标准。举个例子背景这是一个电商订单模块目前所有逻辑都堆在一个 800 行的文件里。 目标拆分成 order-service、order-validator、order-repository 三个文件。 约束不改变任何对外接口不引入新依赖保持现有测试全部通过。 验收标准拆分后每个文件不超过 300 行所有原有测试通过新增至少 3 个边界测试。这样写出来的任务模型基本一次就能做对。反过来如果你只写帮我重构一下订单模块那结果就只能看运气了。6.2 善用先分析后执行的两段式工作流对于复杂任务我强烈建议拆成两段先让模型分析并输出方案你确认后再让它执行。这个习惯能帮你省下大量返工时间。具体做法是第一轮任务只要求输出分析和方案不要求改代码。你看完方案觉得方向对了再开第二轮让它执行。如果方案有问题你在第一轮就能发现改起来成本很低。Opus 5.5 在分析阶段的表现比上一代好不少它会主动指出一些你没考虑到的问题比如这个改动可能影响 X 模块、建议先补测试再重构。这些提醒很有价值别忽略。6.3 上下文管理该清理的时候要清理Claude Code 的会话是有上下文累积的。你聊得越久上下文越长模型的表现可能越不稳定。我的做法是一个任务一个会话任务完成就开新会话。不要在一个会话里连续做多个不相关的任务。如果任务确实很长中间需要保留上下文那就定期用/compact之类的命令压缩一下历史。压缩会丢失一些细节但能换来更稳定的表现这个取舍是值得的。6.4 关于焚诀的心态最后说点心态上的东西。每次新版本发布圈子里都会有一波焚诀焦虑——之前攒的经验是不是没用了提示词是不是要重写了我的看法是底层的工作方法不会因为版本迭代而失效。任务怎么拆、上下文怎么管、CLAUDE.md 怎么写这些是方法论层面的东西模型升级只会让好的方法效果更好不会让好的方法变差。真正需要重新调的是那些依赖具体参数和具体行为的技巧比如 effort 档位的选择、Sub-agent 的配置细节。所以别焦虑。花半小时把新版本的几个关键变化摸清楚把配置调一遍剩下的该干嘛干嘛。工具是拿来用的不是拿来供着的。我在实际使用中发现Opus 5.5 最舒服的用法是medium effort 结构化 CLAUDE.md 按需 Sub-agent这个组合。大部分日常任务用这套配置就够了遇到硬骨头再单独上 high。这套组合我跑了三天稳定性很好没有出现明显的翻车情况。如果你刚开始用不妨从这个组合起步再根据自己的项目特点微调。