企业官网建设流程全解析

1. 这次更新到底改了什么：从标题拆解核心变化

先把话说在前头，标题里那个“焚诀”是圈内人的戏称，指的是那种“一出手就把旧工作流烧干净”的大版本更新。Claude Opus 5.5 这次带来的不是小修小补，而是把几个关键能力同时往上抬了一档：推理深度、代码代理（Agent）的自主性、以及围绕CLAUDE.md和 Sub-agent 的工程化协作方式。如果你之前只是把 Claude 当成一个“更聪明的聊天框”，那这次更新之后，你大概率会重新理解它到底能干什么。

我先把这次更新里最值得关注的几个点摆出来，后面再逐个拆：

• 推理档位（effort）可调：不再是固定强度，而是可以按任务难度手动或自动分配“思考预算”。
• Sub-agent 机制成熟：一个主任务可以拆给多个子代理并行处理，各自有独立的上下文和工具权限。
• CLAUDE.md成为项目级配置中枢：相当于给整个仓库写一份“给 AI 看的 README”，约束它的行为边界。
• Claude Code 的工程化能力增强：从单文件补全，进化到能理解整个项目结构、跑测试、改配置、提交变更。

这四点合在一起，本质上是在回答一个问题：当模型足够强之后，怎么让它稳定地、可复现地、按你的规矩干活？这才是 Opus 5.5 真正想解决的事。

1.1 为什么“焚诀”这个说法不算夸张

我接触过不少做 AI 辅助开发的团队，大家普遍的痛点不是“模型不够聪明”，而是“聪明但不可控”。你让它改一个函数，它顺手把三个不相关的文件也动了；你让它跑测试，它给你编一个看起来很像但根本不存在的命令。这种“聪明带来的副作用”比模型笨更让人头疼。

Opus 5.5 这次的思路很明确：把智能和约束分开管理。智能交给模型，约束交给CLAUDE.md和 Sub-agent 的权限设计。你可以在项目根目录写清楚“这个仓库用 pnpm 不用 npm”“测试命令是pnpm test:unit”“不要动migrations/目录下的文件”，模型就会老老实实照做。这种“先立规矩再干活”的模式，才是它被称为“焚诀”的原因——旧的那套“靠提示词反复纠正”的玩法，确实可以烧掉了。

1.2 适合谁来认真研究这次更新

我的判断是，以下三类人应该花时间把这次更新吃透：

第一类是独立开发者和小团队技术负责人。你们没有专门的 AI 工程团队，但需要一个人顶三个人用，Opus 5.5 的 Sub-agent 和CLAUDE.md能帮你把重复性工作真正自动化。

第二类是中大型项目里的效率工具维护者。你们关心的是怎么让整个团队用上统一的 AI 工作流，而不是每个人各自摸索一套提示词。CLAUDE.md就是团队级标准化的抓手。

第三类是对 AI 代理机制好奇的技术爱好者。你想搞清楚 Sub-agent 到底怎么调度、effort 档位怎么影响输出质量，那这次更新提供了很好的观察样本。

如果你只是偶尔用 AI 写写邮件、改改文案，那这次更新的很多细节你可能用不上，但了解“effort 可调”和“项目级配置”这两个概念，对你以后用任何 AI 工具都有帮助。

2. 核心机制拆解：effort、Sub-agent 与 CLAUDE.md 到底怎么配合

这一部分我想把三个核心机制讲透。很多人看到新功能就急着上手，结果因为不理解底层逻辑，用出来的效果还不如旧版本。我踩过这个坑，所以建议你先花十分钟把原理搞清楚，后面能省下大量试错时间。

2.1 effort 档位：给模型分配“思考预算”的正确姿势

effort这个词直译是“努力程度”，但在 Opus 5.5 的语境里，它更准确的含义是推理预算档位。你可以把它想象成给一个员工派活时说“这个事你花半小时想想就行”还是“这个事你花一整天仔细琢磨”。任务难度不同，分配的思考资源也应该不同。

根据我的实测和社区反馈，effort 大致可以分成几个档：

这里有个很多人忽略的点：effort 不是越高越好。我试过把所有任务都开到最高档，结果发现两个问题。一是响应时间明显变长，简单任务也要等很久；二是模型容易“过度思考”，在本来很明确的问题上反复纠结，反而引入不必要的复杂度。就像你让一个资深工程师去改一个变量名，他可能会顺手给你重构整个模块，这不是你想要的。

提示：如果你不确定该用哪档，先用自动档跑一遍，观察模型的推理过程，再根据结果决定下次手动指定哪档。这个“先观察再调优”的习惯，能帮你快速建立对 effort 档位的直觉。

2.2 Sub-agent：把大任务拆成小任务并行推进

Sub-agent 是这次更新里我觉得最有想象力的部分。传统用法是你和模型一对一对话，它一次只能专注一件事。Sub-agent 的思路是：主代理负责拆解和协调，子代理负责各自执行。

举个我实际遇到的场景。我要给一个老项目加一套单元测试，涉及十几个模块。以前的做法是我一个个模块跟模型聊，聊完一个再聊下一个，上下文还容易串。用 Sub-agent 之后，我可以让主代理先分析项目结构，然后给每个模块分配一个子代理，各自独立写测试、跑测试、报告结果。主代理最后汇总，我只需要看汇总报告和关键 diff。

这种模式的好处很明显：

• 上下文隔离：子代理之间互不干扰，不会出现“改 A 模块时把 B 模块的上下文带偏”的问题。
• 并行效率：多个子代理可以同时工作，整体耗时大幅缩短。
• 权限可控：你可以给不同子代理设置不同的工具权限，比如只读的子代理不能改文件。

但这里有个坑我要提醒你：Sub-agent 不是越多越好。我一开始兴奋地把任务拆成二十个子代理，结果主代理的协调开销反而成了瓶颈，而且子代理之间的依赖关系没处理好，出现了重复劳动。后来我总结出一个经验：子代理数量控制在 3 到 7 个之间比较舒服，超过这个数，协调成本会超过并行收益。

2.3 CLAUDE.md：给 AI 看的项目说明书

CLAUDE.md这个文件，我愿称之为这次更新里“最不起眼但最重要”的东西。它放在项目根目录，模型每次进入这个项目都会先读它。你可以把它理解成一份“给 AI 看的 README”，里面写清楚这个项目的规矩。

我自己的CLAUDE.md通常包含这几块内容：

# 项目约定 ## 技术栈 - 包管理器：pnpm（不要用 npm 或 yarn） - 测试框架：vitest - 代码风格：ESLint + Prettier，提交前必须跑 lint ## 常用命令 - 安装依赖：pnpm install - 跑测试：pnpm test:unit - 构建：pnpm build ## 禁止事项 - 不要修改 migrations/ 目录下的文件 - 不要直接改 package.json 里的版本号 - 不要删除任何 .env 文件 ## 代码规范 - 所有新函数必须有 JSDoc 注释 - 组件文件用 PascalCase 命名 - 工具函数用 camelCase 命名

写这个文件的过程，其实也是你梳理项目规范的过程。很多团队平时没有明确写下来的约定，现在被迫写清楚了，这本身就是一种收益。而且一旦写下来，模型就会严格遵守，比你在每次对话里重复提醒高效得多。

注意：CLAUDE.md的优先级很高，但也不是万能的。如果模型发现你的指令和实际代码冲突（比如你写了用 pnpm，但项目里只有 package-lock.json），它会提示你确认。这时候别嫌烦，认真检查一下，往往是你的配置该更新了。

3. 从零上手：Claude Code 的安装与项目接入实操

原理讲完了，接下来是动手环节。这部分我会尽量写得细，让不同基础的人都能跟着做。需要说明的是，具体安装命令可能随版本变化，我写的是当前主流做法，你实际操作时以官方最新文档为准。

3.1 环境准备：先把基础打牢

在装 Claude Code 之前，有几件事要先确认好，不然装到一半卡住很浪费时间。

第一，确认你的操作系统和终端环境。Windows 用户我强烈建议用 WSL（Windows Subsystem for Linux），因为很多命令行工具在原生 Windows 上会有路径和权限的坑。macOS 和 Linux 用户直接用系统终端就行。我用的是 Ubuntu 环境，整体体验最顺。

第二，确认 Node.js 版本。Claude Code 依赖 Node.js 运行，建议用 18 以上的 LTS 版本。你可以用下面的命令检查：

node -v npm -v

如果版本太低，建议用 nvm 管理 Node 版本，这样切换起来方便：

# 安装 nvm（具体命令以官方为准） curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash # 安装并使用 Node 20 nvm install 20 nvm use 20

第三，确认 npm 全局目录的写权限。这是新手最容易踩的坑。很多人装的时候报auto-update failed: no write permission to npm prefix，就是因为 npm 全局目录没有写权限。解决办法是重新配置 npm 的全局目录到你自己的用户目录下：

# 创建用户级全局目录 mkdir -p ~/.npm-global # 配置 npm 使用这个目录 npm config set prefix ~/.npm-global # 把这个目录加入 PATH（写入 ~/.bashrc 或 ~/.zshrc） export PATH=~/.npm-global/bin:$PATH # 重新加载配置 source ~/.bashrc

这样配置之后，全局安装的包都在你自己的目录下，不会再遇到权限问题。这个坑我踩过不止一次，每次换新机器都要重新配一遍，所以建议你直接写进自己的环境初始化脚本里。

3.2 安装 Claude Code：一步步来

环境准备好之后，安装本身其实很简单。主流方式是通过 npm 全局安装：

npm install -g @anthropic-ai/claude-code

装完之后验证一下：

claude --version

能正常输出版本号就说明装好了。如果提示命令找不到，多半是 PATH 没配好，回头检查上一步的export PATH有没有生效。

关于登录，Claude Code 支持直接登录，按提示走授权流程就行。如果你在团队环境里用，建议先跟管理员确认好账号和权限策略，避免装好了却用不了。

提示：安装完成后建议先跑一次claude --help，把常用命令过一遍。很多人装完就直接用，结果不知道有--resume这种恢复会话的命令，白白浪费了之前的上下文。

3.3 在 VS Code 里配置 Claude Code

如果你习惯在 VS Code 里写代码，把 Claude Code 集成进去会顺手很多。配置思路是让 Claude Code 作为终端任务或者通过扩展的方式接入。

一种常见做法是在 VS Code 的settings.json里配置自定义任务，把 Claude Code 挂上去：

{ "tasks": { "version": "2.0.0", "tasks": [ { "label": "Claude Code", "type": "shell", "command": "claude", "problemMatcher": [], "presentation": { "reveal": "always", "panel": "dedicated" } } ] } }

这样你按快捷键就能唤起 Claude Code 的终端面板，不用来回切窗口。我自己的习惯是把常用任务都配好，写代码、跑测试、让 Claude 改代码都在同一个窗口里完成，效率提升很明显。

如果你在 VS Code 里遇到“找不到 start in cowork”之类的提示，通常是扩展版本和 CLI 版本不匹配。解决办法是先升级 CLI 到最新版，再检查扩展是否需要更新。版本对齐这件事在 AI 工具链里特别重要，因为接口变化很快。

3.4 在线升级与版本管理

Claude Code 更新很频繁，保持最新版能用到新功能，但也可能引入不兼容。我的建议是不要盲目追最新，但也不要长期停在旧版。一个折中的做法是：主工作环境用稳定版，另开一个测试环境尝鲜。

升级命令通常是：

npm update -g @anthropic-ai/claude-code

如果升级后出问题，可以回退到指定版本：

npm install -g @anthropic-ai/claude-code@<版本号>

我一般会在升级前记下当前版本号，出问题能快速回退。这个习惯帮我省过好几次重装的时间。

4. 实战工作流：用 Sub-agent 和 CLAUDE.md 跑一个真实任务

光讲概念没意思，我拿一个真实任务走一遍完整流程，你能看到这些机制是怎么配合的。

4.1 任务背景与拆解思路

任务是这样的：一个用 TypeScript 写的后端项目，有十几个 service 文件，但几乎没有单元测试。我要在半天内给核心模块补上测试，覆盖率至少到 70%。

如果按老办法，我一个文件一个文件跟模型聊，估计得聊到天黑。用新工作流，我的拆解是这样的：

1. 先写CLAUDE.md，把测试框架、命令、规范定清楚。
2. 让主代理分析项目结构，识别出核心模块和依赖关系。
3. 按模块分配 Sub-agent，每个子代理负责一组相关文件的测试。
4. 主代理汇总结果，我审查关键 diff 和覆盖率报告。

这个拆解的关键在于先立规矩再分工。如果CLAUDE.md没写好，子代理们各写各的，测试风格会五花八门，最后合并起来很痛苦。

4.2 编写 CLAUDE.md 的实操细节

我针对这个任务写的CLAUDE.md大概是这样：

# 测试任务约定 ## 测试框架 - 使用 vitest，不要用 jest - 断言用 expect，不要用 assert ## 测试文件位置 - 测试文件放在 __tests__ 目录下 - 命名格式：<原文件名>.test.ts ## 测试规范 - 每个测试用例只测一个行为 - 必须包含正常路径和异常路径 - mock 数据放在 __tests__/fixtures/ 下 ## 命令 - 跑单个测试：pnpm vitest run <文件路径> - 跑全部测试：pnpm test:unit - 看覆盖率：pnpm test:coverage ## 禁止事项 - 不要修改被测的源文件 - 不要为了通过测试而放宽断言 - 不要跳过任何失败的测试

写这份文件花了大概十五分钟，但后面省下的沟通成本远超这个投入。特别是“不要修改被测源文件”这条，直接避免了子代理“为了让测试通过而改代码”这种危险操作。

4.3 Sub-agent 的分配与协调

分配子代理时，我按模块依赖关系分组，而不是简单按文件数量平均分。比如用户模块和权限模块耦合紧，就交给同一个子代理；日志模块相对独立，单独一个子代理。

主代理的提示词我大致这么写：

请分析当前项目结构，识别出核心 service 模块及其依赖关系。 按依赖关系将模块分成 5 组，每组分配给一个 Sub-agent。 每个 Sub-agent 的任务是：为分配的模块编写单元测试，遵循 CLAUDE.md 中的规范。 Sub-agent 完成后，请汇总每个模块的测试覆盖率和遇到的问题。

这里有个细节值得说：我明确要求主代理汇报“遇到的问题”。因为子代理在执行中可能遇到依赖缺失、接口不明确等情况，这些信息对后续修复很重要。如果只汇报“完成了”，你根本不知道质量如何。

4.4 结果验收与人工介入点

子代理跑完之后，我没有直接接受结果，而是做了三件事：

第一，看覆盖率报告。整体覆盖率到没到 70%，哪些模块拖后腿，一目了然。

第二，抽查关键 diff。我重点看了涉及核心业务逻辑的测试，确认断言是真实的，不是那种expect(true).toBe(true)的糊弄写法。

第三，跑一遍完整测试。确认所有测试能通过，没有互相干扰。

这个过程大概花了二十分钟，但非常必要。AI 生成的测试质量参差不齐，人工验收是最后一道防线。我的经验是：AI 能帮你完成 80% 的重复劳动，但剩下 20% 的判断必须你自己来。

5. 常见问题与排查技巧实录

这部分是我和社区里其他人踩过的坑的汇总，按问题类型整理，方便你遇到时快速定位。

5.1 安装与权限类问题

权限问题我前面已经详细讲过，这里补充一个排查思路：遇到权限报错，先看报错信息里的路径，然后检查那个路径的归属和权限。大部分问题都能通过ls -la和whoami定位。

5.2 模型接入与配置类问题

很多人关心能不能用其他模型。我的建议是：先把手头的默认配置跑通，再考虑替换。因为不同模型的接口和行为差异很大，在没跑通基础流程之前就折腾替换，很容易陷入“不知道是配置问题还是模型问题”的困境。

如果你确实需要接入其他模型，核心是找到对应的接口配置方式，把 API 地址、密钥、模型名填对。这个过程和配置任何 API 客户端类似，关键是先在一个最小例子上验证通，再往项目里集成。

5.3 使用过程中的典型故障

故障一：模型不遵守 CLAUDE.md 的约定。先检查文件位置对不对，必须在项目根目录。再检查语法有没有问题，Markdown 格式错误可能导致解析失败。最后确认你的指令和实际项目状态是否冲突。

故障二：Sub-agent 之间重复劳动。这是任务拆解不够清晰导致的。解决办法是在主代理的提示词里明确每个子代理的边界，比如“你只负责 user 模块，不要碰 auth 模块”。

故障三：effort 开太高反而变慢。这是正常的，高 effort 意味着更多推理。解决办法是按任务难度动态调整，别一刀切。

故障四：上下文丢失。长会话中模型可能忘记前面的约定。解决办法是定期用--resume恢复，或者把关键约定写进CLAUDE.md而不是只放在对话里。

提示：我建议你建一个自己的“踩坑笔记”，每次遇到问题就记下来。AI 工具迭代快，但很多坑是反复出现的，有笔记能省很多时间。

5.4 我总结的几条避坑原则

第一条，配置先于使用。花时间把CLAUDE.md和环境配好，比急着上手能省更多时间。

第二条，小步验证。新功能先在小任务上试，确认没问题再上大项目。

第三条，人工验收不可省。AI 再强也是辅助，关键决策和最终质量得你自己把关。

第四条，版本要可控。记录版本号，升级前备份配置，出问题能快速回退。

第五条，别追求一步到位。工作流是迭代出来的，先跑通再优化，比一开始就设计完美流程更实际。

6. 我对这次更新的一点个人判断

用了一段时间 Opus 5.5 之后，我最大的感受是：AI 辅助开发正在从“对话式”转向“工程化”。以前我们比的是谁的提示词写得好，现在比的是谁的项目配置和任务拆解做得好。这个转变对认真做工程的人来说是好事，因为工程能力是可以积累和复用的，而提示词技巧往往很个人化。

CLAUDE.md这个设计我特别欣赏，它把“团队约定”这件事从口头和文档里，变成了模型能直接执行的规则。Sub-agent 则把“并行工作”这个人类团队早就熟悉的模式，搬到了 AI 协作里。effort 档位让资源分配变得可控，不再是一刀切。

如果你还没开始用这套工作流，我的建议是从一个小项目开始，先写一份CLAUDE.md，跑一个 Sub-agent 任务，感受一下。不用追求一次到位，先跑通，再优化。这个过程中你会逐渐建立起自己对 AI 协作节奏的判断，这比任何教程都值钱。

最后分享一个小技巧：我习惯在CLAUDE.md末尾留一个“更新日志”区块，记录每次调整约定的原因。这样过一段时间回头看，能清楚知道哪些约定是有效的，哪些是多余的。这个习惯让我的配置文件一直保持精简，而不是越堆越乱。