企业官网建设流程全解析

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 三种安装路径的实际对比

安装方式我实测下来主要三条路，各有适用场景，我做了个对比表：

我自己的主力机是 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：

1. 调研 agent：扫描代码库，列出所有没有测试覆盖的模块，输出一份清单和优先级建议。
2. 编写 agent：按清单逐个模块写测试，每个模块独立跑，互不干扰。
3. 验证 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 排查速查表

7. 我踩过的坑和几条实在建议

聊了这么多技术细节，最后说几条纯经验的东西，都是我真金白银踩出来的。

第一条，别一上来就追求全自动。很多人刚上手就想让 Claude Code 一口气把整个需求做完，结果跑偏了还得从头收拾。正确节奏是：先让它做小任务，你盯着看，确认它的理解和你一致，再逐步放权。信任是攒出来的，不是配出来的。

第二条，CLAUDE.md 和 effort 是性价比最高的两个投入。前者一次写好长期受益，后者调对了能省大量等待时间。相比之下，纠结用哪个模型、装哪个版本，收益反而没那么大。

第三条，Sub-agent 的拆分粒度要克制。我一开始特别兴奋，什么都想拆，结果协调成本爆炸。后来想明白了：拆分的目的是隔离上下文，不是为了显得架构高级。如果一个任务本身上下文需求就不大，老老实实一个会话跑完更省事。

第四条，保留人工审查环节。不管模型多强，它写的代码你都得看。我见过太多人直接接受模型的改动，结果埋了个隐蔽 bug，几天后才发现。把模型当高效助手，别当甩手掌柜。

这套工作流我用了两周，最大的感受是：工具的上限取决于使用者的编排能力。同样的 Opus 5.5，有人用得磕磕绊绊，有人用得行云流水，差别不在模型，在于你有没有把任务拆清楚、把约定写明白、把力气花对地方。焚诀的核心从来不是烧，是精准。