企业官网建设流程全解析

如果你和我一样，曾经在 Claude Code 里"手把手"教它改代码，一条指令一句话，改一个登录模块能来回拉扯十几轮，那你一定知道什么叫低效单步聊天。我是在一个周五下午彻底受够的——那个下午我什么都没干成，光顾着在对话窗口里给 AI 当测试员。那时候我还不知道多Agent编排、闭环自愈这套玩法，更没听过Routine脚本化，每次对话就像带一个聪明但记性极差的新人，说一步走一步。后来我把这套架构跑通，同样一个模块，从十几轮对话压缩到一次任务下发加自动修复。这篇文章就来拆解我在真实项目里怎么做的，包括任务怎么拆、子Agent怎么写、自动修复怎么控风险、Routine怎么固化，以及一路踩过的坑。适合已经用过 Claude Code、或者正在犹豫要不要把它从"聊天框"升级成"施工队"的开发者。

1. 单步聊天的痛点：我为什么受够了"手把手"教 AI 干活

1.1 单步模式的真实体验

先说说大多数人对 Claude Code 的第一印象：它确实比普通聊天机器人强得多，能读文件、能跑命令、能改代码，但默认的使用方式还是"一问一答"。我早期用它做重构时，对话基本长这样：

• 我：看一下auth/login.ts的登录逻辑，找出 session 过期后没有跳转的问题。
• 它：改好了，在userService里加了判断。
• 我：那UserController里调用userService的地方也要同步判断。
• 它：好的，改了。
• 我：还有前端调/api/auth/status的地方，你顺手检查一下。
• 它：检查了，没问题，但在login.vue里发现一个重复请求的隐患，要不要一起改？
• 我：改吧。
• 它：改完了，顺便把 eslint 报错修了四个。

几十轮下来，代码确实动了，但我的注意力被撕成碎片。每次它改完，我还得自己跑一遍 lint、编译、测试，发现问题再丢回去。这不是"用 AI 编程"，这是"给 AI 当测试员"。最讽刺的是，AI 生成代码的速度越来越快，但整个项目的交付速度没有任何提升，因为瓶颈根本不在"写代码"，而在"人来来回回确认"。

我后来复盘，发现单步模式有三个结构性的设计问题，不是简单"多问几轮"就能解决的。

1.2 三个致命浪费：上下文丢失、反馈回路过长、人工成为唯一闭环节点

第一个浪费：上下文丢失。Claude Code 的上下文窗口再大，也扛不住几十轮对话里的信息堆积。早期约束会被后续对话冲淡，比如我第一轮明明说过"不要动sendEmail函数"，第八轮它还是擅自改了调用处。这不是它笨，而是我把太多信息以对话形式丢进窗口，期望它全记住，而我自己的原始需求描述又不够结构化。单步模式的本质是"记忆靠聊天记录"，而聊天记录是会稀释的。

第二个浪费：反馈回路过长。人工模式下，一个"改代码→验证"的循环要走完"它输出→我读→我判断→我提新需求→它再执行"整整五步，半分钟眨眼就过去了。一个大任务里如果有几十个这样的循环，大量时间就耗费在沟通路上。AI 的执行能力再强，也被这个慢速回路拖住了。

第三个浪费：人工成为唯一闭环节点。整个流程里，AI 只是个执行器，所有纠错、验收、范围控制都得由人发起。我是唯一的判断节点，它没有能力发现自己改坏了，更不会自动跑测试去验证。单步模式把 A 的智能浪费在"等指令"上，却把人的精力浪费在"盯细节"上。

1.3 从"对话"到"委托"：心智模型的转变

我后来把这个转变叫"从对话到委托"。对话的意思是：我命令，它执行，我验收。委托的意思是：我定义目标、边界、标准，它自己拆解、自己执行、自己验证、自己汇报。

这个转变不需要换工具。Claude Code 本来就具备子代理、终端执行、项目记忆这些能力，只是默认交互方式把人引导向了单步对话。我后面做的三件事——多Agent编排、闭环自愈、Routine脚本化——本质就是把这三项能力组合起来，让 AI 从"回答问题的聊天机器人"变成"能自我管理的小型施工队"。

想清楚这一点之后，我做的第一件事，就是不再把大任务直接丢给同一个对话窗口，而是拆给多个 Agent 分工协作。

2. 多Agent编排：把大任务拆成一个能并行干活的小团队

2.1 主Agent加子Agent的结构：编排者与被编排者

很多人听到"多Agent"第一反应是"多开几个 Claude Code 窗口"。这个理解是错的。多开窗口只是并行度，不是编排。真正的多Agent编排是：一个主Agent负责理解全局目标、拆解任务、分发子任务、汇总结果和验收质量；多个子Agent各自只专注于一个明确的小目标，比如"梳理现有认证链路的接口清单"或者"重写 session 续期逻辑"。

主Agent的角色更像项目负责人，它不亲自写每一行代码，而是把大任务切成可独立交付的模块，然后拿着"任务书"去派活。子Agent拿到任务书后，在它自己的上下文空间里工作，看到的文件范围、讨论深度都围绕这个子任务，不会被全局信息干扰。等子Agent交回结果，主Agent再统一合并、验证。

这样做的好处非常直观：每个子Agent的上下文都更干净，不会出现"聊了十轮之后忘了第一轮约束"的情况；多个子Agent可以并行处理互不依赖的文件；主Agent可以像项目经理一样，哪块出问题就只重跑哪块，不用整个任务推倒重来。

2.2 实操案例：老项目登录模块重构的三线并行

我拿一个真实案例来说。上个月我把一个老项目的登录认证模块整段重构，整个任务涉及后端接口、session 存储、前端跳转逻辑、单元测试四块。用单步模式的话，我预计要浪费整整一个下午。用多Agent编排，我把任务拆成三条线，交给了三个子Agent：

• Agent A（梳理线）：只负责读代码。任务书是"梳理用户表结构、session 存储方式、现有/api/auth/*接口清单，输出一份接口与数据流文档，不改任何代码"。
• Agent B（改造线）：等 Agent A 的输出，负责重写登录、登出、session 续期的后端逻辑，要求"遵循 Agent A 文档中标注的接口签名，不得破坏旧字段兼容"。
• Agent C（测试线）：独立编写针对认证链路的单元测试和边界用例，包括 token 过期、并发登录、重复登出等场景，测试用例先于改造完成。

主Agent负责协调：先把 Agent A 派出去，等它产出文档后，把文档摘要合并进 Agent B 和 Agent C 的任务上下文，然后让 B、C 并行推进。最后主Agent统一过一遍 lint、类型检查、测试，发现问题再丢回对应子Agent修复。

这个流程跑完，整个重构耗时大约四十分钟，其中我真正介入的只有开头写任务书、中间看一次 Agent A 的梳理文档、最后验收测试报告。对比以前"我盯着改一行看一行"的方式，效率提升不是一倍两倍，而是数量级的差距。

2.3 子Agent的"任务书"怎么写：目标、边界、验收标准缺一不可

多Agent编排能不能跑起来，核心在于任务书的质量。我踩过不少坑，最早给子Agent派活时写得很随意，比如"看一下登录逻辑"，结果它交回来的东西根本不是我要的。现在我的任务书固定包含五个要素：

• 目标：一句话说清这个子Agent要交付什么。不是"处理登录"，而是"重写authService.login，使其在用户被禁用时返回明确错误码而非通用 401"。
• 输入范围：允许读哪些文件、禁止动哪些文件。这一点极其关键，否则子Agent容易越界改到别人的模块。
• 上下文引用：相关文档、接口定义、其他子Agent等会产出什么，按什么格式引用。
• 验收标准：怎么算完成。比如"所有新增代码通过npm run typecheck""新增测试覆盖sessionExpired分支"。
• 禁止事项：明确告诉它不要做什么，比如"不要修改数据库迁移脚本""不要动第三方 SDK 封装"。

你可以理解为给一个能力很强但方向感需要校准的实习生写开工单。写清楚，它一次就能做对；写模糊，来回返工的成本比你自己干还高。

2.4 编排粒度：不是拆得越细越好

多Agent也不是万灵药。我试过一次把一个小功能拆成八个子Agent并行，结果光合并输出就花了大把时间，子Agent之间还出现了改同一份文件导致的冲突。后来我总结出一个经验：拆分的边界最好是文件级或模块级，而不是函数级。如果两个子Agent要改同一个文件，它们之间就必须通过主Agent同步状态，这个通信成本往往会超过并行带来的收益。

一个比较稳的粒度判断方法：先看这个任务能不能按"读、写、验"三段拆。读任务（梳理、排查、分析）最适合并行；写任务只有在文件边界清晰时才适合并行；验证任务（测试、lint、构建）通常由一个 Agent 统一做，或者由主Agent自己跑。

另外要提醒一点，子Agent交回的结果并不一定完全可信。我一直把多Agent编排当成"初稿生产器"，质量把关仍然要由主Agent和最终的人来做。主Agent在合并代码前，必须自己跑一遍编译和测试，不能因为子Agent说"完成了"就直接信。

3. 闭环自愈：让 Agent 自己写、自己错、自己改，最后才到你手上

3.1 闭环自愈的前提：终端执行与输出反馈

多Agent编排解决的是"任务怎么拆"，接下来要解决"质量怎么保证"。这里就轮到闭环自愈登场。

所谓闭环自愈，是指让 Agent 在执行过程中自己发现问题、自己读取错误、自己修复、再自己验证，直到通过预设标准，而不是把每一次报错都丢回给人类。这个机制的前提是 Claude Code 能在终端里执行命令并读取输出——这也是它区别于普通聊天工具的核心能力之一。

Claude Code 内置了终端执行能力，Agent 可以运行npm run test、python -m pytest、tsc --noEmit这类命令，然后读取标准输出里的报错信息。它看到报错后，能定位到具体文件和行号，修改代码，再重新执行验证命令。这个循环可以完全自动化地重复若干轮，直到验证命令通过。

你可以把这个过程理解成 Agent 给自己装了一个"自动质检员"：写完代码不是直接交差，而是先跑测试，看到红灯就修，修完再看，变绿才提交。

3.2 第一次见识自动修复循环：类型错误到测试通过

我第一次真正感知到这个机制的力量，是在一次重构里让它实现一个函数列表，然后要求"跑完pytest全部通过才算完成"。我原本预期它会写一版代码然后停下来等我验收，结果它做了一件让我愣住的事：

1. 写完函数后，它自动执行了pytest。
2. 测试失败，报了一个类型签名不匹配的错误。
3. 它读取错误信息，定位到自己的类型注解，修改了函数签名。
4. 重新跑测试，又暴露了一个边界条件处理不当的断言失败。
5. 它又去改对应实现，补了一个空值判断。
6. 再跑pytest，全部通过，它才把完整变更汇总给我。

整个过程我没说一个字。之前单步模式下，同样的"写代码→报错→修→再报错→再修"循环至少需要我来回搬运五次报错信息，而那次它在几十秒内就自己完成了。这一步彻底改变了我的用法：从此以后，我给 Agent 下任务时几乎都会附带一句"跑测试跑到全绿"或者"过一遍 typecheck 再交给我"。

3.3 权限放开到什么程度：安全边界怎么划

闭环自愈跑得越顺，就越会诱使人把权限全部放开，让 Agent 想跑什么就跑什么。我不建议这么做，至少不要一上来就全开。Claude Code 的权限模型里，你可以控制它是否能自动接受编辑、是否能自动执行命令，以及哪些命令在允许列表里。

我目前的安全做法是分三档：

• 第一档（推荐日常用）：编辑自动接受，命令执行需要确认，但把高频验证命令加入允许列表（如npm test、tsc --noEmit、git diff）。这样自愈循环能自动跑测试和编译，但遇到安装依赖、删除文件、推送远程等高风险操作时，会停下来问用户。
• 第二档（临时大重构用）：允许一组固定命令自动执行，但限定在仓库内，不给"任意 shell 命令"的全量权限。
• 第三档（尽量别用）：完全跳过权限确认。我只有在一次性容器里跑一次性任务才会这么干，日常工作绝不碰。

为什么这么谨慎？因为自愈能力是把双刃剑。权限放得越开，Agent 就越可能在一次错误判断下执行破坏性操作，比如git reset --hard或者rm -rf。我自己没出过大事，但见过朋友的项目被自愈循环里的一条错误命令清掉了一堆未提交的修改。从此我坚定了一条原则：让 AI 自己修复代码，但不让它自己决定做破坏性操作。

3.4 自愈失控的止损设计：防止无限循环烧时间

闭环自愈最容易被忽视的问题，是"自愈"变成"复读机"。有些错误不是改代码能解决的，比如测试环境连不上数据库、某个外部服务超时、依赖冲突无法自动解决。这时候 Agent 如果被设定成"必须跑到全绿"，它就会陷入"改一下→跑→报另一个错→再改→再跑"的无限循环，不仅浪费时间，还可能在错误的道路上越走越远。

我现在会在任务书里明确止损规则，固定写三句话：

• 连续三次尝试仍然失败时，停止自动修复，整理报错日志和已尝试的方案，等人类决策。
• 执行任何非验证性命令（安装删除、网络请求、文件移动）前，先报告将由用户确认。
• 如果错误信息的根因指向外部环境而非代码，直接停手，不做无意义的代码乱改。

这个"三次即止"的规则看起来简单，但能省下很多无谓的 token 消耗和时间。自愈要有，但要让它"有边界地自愈"，否则 AI 的固执比新人的固执更可怕，因为新人至少会觉得累，而 Agent 可以无穷无尽地试下去。

4. Routine脚本化：把高频工作流变成 Agent 的肌肉记忆

4.1 CLAUDE.md 不只是记忆文档，是流程契约

多Agent编排解决了怎么拆任务，闭环自愈解决了怎么保质量，但每次开新任务、新会话时，Agent 都要重新理解项目上下文，这个启动成本依然很高。Routine脚本化解决的就是这个问题：把高频、重复、成熟的工作流固化成可复用的脚本和约定，让 Agent 一进项目就知道"这套活应该怎么干"。

Claude Code 里最基础的 Routine 载体就是CLAUDE.md。很多人的理解是"给 AI 看的项目说明文档"，但我更愿意把它当成流程契约。它不是简单地记录项目信息，而是要写清楚"在这个项目里干活时必须遵守的流程和标准"。

举个例子，我的一个前端项目CLAUDE.md里固定包含几段内容：项目启动命令和调试方式、代码风格规范（如命名规则、组件拆分粒度）、禁止事项（如不得直接改生成文件）、以及"任何改动完成后必须运行npm run lint && npm run typecheck"这类硬性约束。这样哪怕开一个全新的会话，Agent 一读到文件就知道规矩是什么，而不是我在对话里反复重申。

4.2 三层 Routine 结构：命令脚本、流程文档、子Agent定义

用久了之后，我发现 Routine 不应该只是"写一段说明文字"，而是有层次结构的。我现在把 Routine 分成三层，从轻到重：

• 第一层：命令脚本层。把一套验证命令或构建命令封装成一个脚本，比如scripts/check.sh里串起lint + typecheck + unit test。Agent 只需要执行一个脚本，不用记一长串命令，也不容易漏步骤。这是成本最低、立竿见影的 Routine。
• 第二层：流程文档层。在CLAUDE.md或专门的docs/routines/目录下，把某个完整流程写成带顺序、带验收标准的 checklist。比如"发布流程"会写清楚：先跑全量测试、再构建产物、再打 tag、再推送镜像、最后做健康检查。Agent 按着 checklist 走，每完成一步勾一步。
• 第三层：子Agent定义层。把某个固定角色固化成子Agent，比如"测试补齐专员""代码审查员""迁移脚本生成器"。每个子Agent有自己的专属任务模板、工具偏好和输出格式，主Agent需要时直接调用，不用每次重新描述角色。

这三层可以单独用，也可以叠起来。我实际项目里的做法是：命令脚本解决"怎么验证"，流程文档解决"按什么顺序做"，子Agent定义解决"谁来做"。三者合在一起，就是一套完整的 Routine 体系。

4.3 实操：一条发布流程 Routine 的完整编写过程

举一个我自己正在用的例子：版本发布流程。以前每次发布都是一次混乱的"人肉多步操作"，现在我把整个流程写成了 Routine，Agent 每次都能按同一套标准执行。

我把这个 Routine 写成了四段式：

第一段：前置检查。要求 Agent 先跑scripts/check.sh，并确认工作区没有未提交的变更。任何一步失败，立即停止并报告，不进入发布流程。

第二段：版本号与变更日志。要求 Agent 基于工单记录生成版本号建议，更新CHANGELOG.md，格式参照项目历史条目。变更日志按"特性/修复/破坏性变更"分节排序。

第三段：构建与测试。要求 Agent 依次执行npm run build、npm run test:ci，构建产物完整性检查（是否有dist目录、入口文件是否存在）。产物一旦生成，禁止二次修改源码。

第四段：标记与通知。构建测试全绿后，Agent 才被允许执行git tag和推送，并在团队群里输出发布摘要。发布完成后，对该版本打一个冒烟测试的验证标记。

写这条 Routine 花了我大约半小时，但它带来了一个很明显的好处：发布动作从"靠人记顺序、靠人盯步骤"变成了"流程本身的约束力"。第一个人写的顺序，第二个、第三个人执行时不会被遗漏。而且每次发布的表现都高度一致，因为 AI 不会因为当天心情好坏而跳过某个检查。

4.4 组合拳：编排、自愈、Routine 如何串联成完整工作流

Routine 脚本化的真正威力，在于它能把前面提到的多Agent编排和闭环自愈粘合起来。

比如我现在接到一个"新增导出功能"的需求，实际发生的事是这样：主Agent先读CLAUDE.md，确认项目规范和执行顺序。它发现这个需求涉及后端接口、前端页面、导出模板三块，于是按 Routine 里预定义的"需求拆解规则"把它派给三个子Agent。每个子Agent开工时，会自动加载自己的任务专属 Routine（比如测试子Agent会遵循"测试先行的边界用例清单"）。所有子Agent交回结果后，主Agent跑scripts/check.sh，进入闭环自愈循环——lint 挂了就改、测试红了就修——直到全绿。最后主Agent按发布 Routine 的流程推进后续动作。

整个过程里，我的角色只是"表达需求 + 验收最终结果"。中间的拆解、执行、纠错、验证，全部由这套"编排+自愈+Routine"的架构自动完成。这才是 Claude Code 真正意义上的"告别低效单步聊天"。

5. 配置与踩坑：安装、IDE 集成、第三方模型接入的实操记录

说了这么多架构和用法，最后把环境配置里的坑也一并写出来。无论多Agent编排还是闭环自愈，前提是你得把它在正确环境里跑起来。我这些配置踩坑经验都是实打实换来的，照着做能少走很多弯路。

5.1 安装与运行环境：Windows 用户的第一道坎

Claude Code 的本质是一个终端工具，官方提供了 npm 包@anthropic-ai/claude-code，也有一键安装脚本。最直接的安装方式就是：

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

装是很好装，真正的坑在运行环境。如果你是 Windows 用户，踩到"与64位版本的 Windows 不兼容"这类问题一点都不奇怪。Claude Code 的终端交互、文件监听、命令执行在原生 Windows 上表现很不稳定，官方也更推荐在类 Unix 环境里使用。我的建议是 Windows 用户优先用 WSL2，在 WSL 里安装 Node.js 和 Claude Code，然后把项目放在 WSL 文件系统里跑。这样终端交互和文件权限行为都正常得多。

macOS 那边则相对顺畅，直接装完就能用。Linux 服务器上跑也没问题，只要 Node 版本在 18 以上。

5.2 VSCode 集成：在编辑器里用而不是切走终端

很多人不习惯在命令行里对话，那 VSCode 集成是绕不开的。VSCode 接入 Claude Code 的主流方式是安装官方扩展或社区扩展，然后在编辑器底部打开一个专属面板或集成终端来运行它。这样有两个好处：改代码时能看到文件上下文，AI 执行命令时的输出也直接显示在编辑器里，阅读错误信息不用切窗口。

配置 VSCode 集成时，有一个非常容易被忽略的点：权限和终端环境是否一致。有时候在 VSCode 集成终端里跑 Claude Code，它启动时的环境变量和你手动在系统终端里的并不完全相同，导致它找不到某些全局命令（比如pnpm、python3的路径）。遇到这种情况，检查 VSCode 的terminal.integrated.env配置，把必要的 PATH 补进去就行。

如果团队使用远程开发，我建议把 Claude Code 装在远程端而不是本地。因为 Agent 要操作的文件、要执行的命令都在远程环境里，装在本地的话，它看到的仓库路径和实际运行环境是割裂的，很多闭环自愈流程会卡在"文件能读但不能跑命令"的尴尬状态。

5.3 本地模型与第三方 API 接入：能跑，但要管理预期

Claude Code 默认对接 Anthropic 的服务，但通过环境变量和兼容 API 网关，也能接到本地模型或第三方模型服务上。社区里常见的做法是用cc-switch这类工具做模型商切换，在 DeepSeek、Qwen、GLM 等模型之间来回换，也有人配置 LM Studio 跑本地模型。

具体操作原理并不复杂：Claude Code 通过环境变量指定 API base 地址和认证 token，只要目标服务提供兼容的对话接口，它就能当作后端模型来用。用cc-switch的好处是它把多套配置封装成可视化的切换界面，不用每次手动改环境变量。

但我要重点提醒三点：

• 第三方模型和本地模型的工具调用能力参差不齐。Claude Code 的多Agent编排、终端执行、闭环自愈高度依赖模型对工具调用的理解。实际测试下来，不同模型的工具调用成功率和遵循指令的稳定性差异很大，换模型后"自愈循环"可能变"复读机"，因为模型读不懂报错该怎么处理。
• 上下文窗口决定多Agent的"内存"。有些第三方模型上下文较短，子Agent跑一半就把任务书忘了，表现就是做着做着偏离目标。这种情况不是 Claude Code 的问题，是后端模型能力的天花板。
• 订阅和计费逻辑要看清。用第三方 API 时，消耗按第三方服务商的计费规则走，和官方订阅是两套体系。不要混着理解。

如果你是在公司内网或受限网络环境里使用，还会遇到另一种报错：提示组织已禁用 Claude Code 的订阅访问权限。这种提示通常不是技术问题，而是组织管理员在后台关闭了 Claude Code 的使用资格。解决办法是找管理员确认，而不是在本地折腾配置。同类情况还有"当前地区不可用"类的提示，第一反应应该是去官方文档核对支持范围，而不是研究所谓的替代姿势，后者既不稳定也容易触碰服务条款。

5.4 桌面版：适合轻度使用，但别指望完整 Agent 能力

Claude Code 也提供了桌面版客户端，对不想碰终端的用户来说友好很多。我个人的体验是：桌面版适合简单问答、轻量代码解释、快速生成脚本，但如果你要做多Agent编排、闭环自愈这种重度任务，最好还是回到终端或 VSCode 集成环境。

原因在于桌面版的本质是"给聊天窗口套了个壳"，它对文件系统、终端命令、权限模型的控制能力没有命令行版那么直接。我见过有人在桌面版里试图让它跑测试修代码，结果它全程只能"看着"项目目录但执行不了命令，自愈闭环根本转不起来。所以我的建议是：桌面版当入口，命令行版当主力。真正的高价值任务，交给完整能力的终端版去跑。

另外，不管用哪个版本，我强烈建议养成一个习惯：开工前花十分钟把CLAUDE.md更新到和当前项目状态一致。我遇到过太多次因为 CLAUDE.md 里的旧命令和新环境不匹配，导致自愈循环一开始就跑偏的情况。文档里的命令过时，Agent 再聪明也没办法；它只会忠诚地执行错的流程，然后困惑地看着失败日志。

我现在的日常状态，已经很少和 Claude Code 一句一句对话了。每天开始工作时，我会把一个需求写清楚丢给主Agent，它自己拆任务、派子Agent、跑验证、修问题，最后给我一份汇总。我需要做的，是定义好"什么算完成"，然后验收它给出的证据。说到底，多Agent编排、闭环自愈、Routine脚本化这三样东西，最终改变的并不是 AI 的能力，而是我作为开发者分配注意力的方式。单步聊天把注意力耗在来回沟通上，这套架构则把注意力留给了真正需要人类判断的地方。