Claude Code 多 Agent 软件工厂：如何让功能在你睡觉时自动交付

我以为自己是在用 AI 写代码。

后来才发现，我只是打字变快了。

真正的区别在于：不是让 Claude Code 帮你补几段代码，而是搭建一套 7 个 Agent 协作的软件工厂，让它在你睡觉时也能推进功能。

这套方法可能帮你少走几个月弯路。

没人认真讨论的问题

很多人用 Claude Code 的流程，看起来很高效，其实并不是。

典型循环是这样的：

• 让 Claude 构建一个功能
• 它生成代码
• 某个地方报错
• 你把错误粘回去
• 它修一下
• 另一个地方又坏了
• 你继续问

第 1 天，这像魔法。

第 30 天，你会发现自己花在监督 AI 上的时间，可能比以前手写代码还多。

同一段逻辑出现在 3 个地方。

Claude 忘了你两周前设定的项目约定。

新功能把旧功能弄坏了。

测试要么没有，要么非常浅。

然后你突然意识到：不是 AI 失败了。

是你的工作流失败了。

真正的问题是结构性的。

当你在 Claude Code 里输入“帮我构建这个功能”时，你其实是在要求同一个 AI 会话同时扮演：

• 产品分析师
• 架构师
• 后端工程师
• 前端工程师
• 测试工程师
• 代码审查员

所有角色挤在同一个混乱对话里。

一开始计划里的错误假设，会变成错误的数据模型。

错误的数据模型，会变成错误的 API。

错误的 API，又会变成错误的 UI。

等你发现问题时，错误已经扩散到很多文件里了。

这就是所谓的 vibe coding。

它确实能跑起来。

但它有明显天花板。

从 Vibe Coding 到软件工厂

真正改变结果的，不是继续写更长的提示词。

而是换一种工作方式。

真实工程团队从来不是在一个巨大对话里完成所有事情。

不同人负责不同工作：

• 有人澄清用户问题
• 有人思考架构
• 有人构建 API
• 有人构建 UI
• 有人考虑边界情况
• 有人负责审查

当你把这些工作全部压进一个 AI 会话里，错误就会悄悄叠加。

解决办法，是把工作拆给不同的专用 Agent。

每个 Agent 都只拿到：

• 一个明确任务
• 一个干净上下文窗口
• 它真正需要的工具
• 严格规定它不能碰什么

最终得到的，就是一个软件工厂。

一个开发者，加上 7 个聚焦 Agent，就像一个协调好的小团队。

下面是这 7 个 Agent。

7 个核心 Agent

Agent 1：代码库研究员

开发者使用 AI 时，最大的错误是什么？

一上来就让 AI 写代码。

AI 会接受提示词，用猜测填补空白，然后开始生成。

糟糕的设计，也就是从这里混进去的。

代码库研究员就是为了解决这个问题。

它唯一的任务是：在写任何代码之前，先检查代码库，并解释现有系统是如何工作的。

它会做什么：

• 梳理相关文件及其作用
• 记录应该遵循的现有模式
• 找出已经实现过的类似功能
• 标记风险，比如时区、多租户、重试逻辑
• 列出需要更新的测试

它不能做什么：

• 不能编辑文件，只能读取
• 不能运行任何会修改状态的命令
• 不能做假设，不清楚就提问

工具权限：Read、Grep、Glob。

核心规则：每次构建之前，必须先探索。

研究员永远第一个运行。

Agent 2：用户故事撰写员

很多功能失败，不是因为代码写错了。

而是因为问题从一开始就没有定义清楚。

用户故事撰写员会把一个粗略功能想法，变成真正可执行的用户故事。

在任何技术决策之前，它必须先完成这一步。

它接收的输入：

• 你的粗略功能描述
• 代码库研究员的发现

它产出的内容：

一条用户故事：

“As a [role], I want [behaviour], so that [outcome].”

验收标准：测试可以直接验证的语句。包括正常路径、失败路径和业务规则。

边界情况：包括边界输入、重试、多租户相关问题。

不在范围内：明确说明这次不做什么。

开放问题：它真正不知道的问题。

绝不猜。

它不能做什么：

• 不能编造业务规则
• 不能写代码或技术设计
• 遇到真正不清楚的地方，不能继续往下推进

工具权限：Read only。

核心规则：你必须先阅读并批准这份用户故事，然后才能继续。

这是第一个人工检查点。

也正是这个检查点，能拯救后面的所有环节。

Agent 3：技术规格撰写员

用户故事被批准之后，技术规格撰写员会把它转换成技术简报。

这份简报，是后续所有构建 Agent 的蓝图。

它接收的输入：

• 已批准的用户故事
• 代码库研究员的发现
• 项目的 CLAUDE.md 规则

它产出的内容：

• 数据模型变更，包括字段、类型、迁移
• 后台流程或业务流程
• API 变更，包括 endpoint、请求和响应结构
• 前端变更，包括组件、页面、hooks
• 必要测试，包括成功、失败和边界情况
• 风险和开放问题
• 所有将被修改的文件

它不能做什么：

• 不能编辑任何文件
• 不能擅自发明新基础设施，必须明确指出需求
• 不能跳过租户隔离或时区问题
• 不能留下未回答的问题

工具权限：Read、Grep、Glob。

核心规则：这份技术简报，是第二个人工检查点。

你必须阅读并批准它，然后才允许碰任何文件。

如果你在这里看到“把 ID 存在内存里”这种方案，这就是红旗。

应该现在拦住。

不要等 10 个文件都被改完之后再发现。

Agent 4：后端构建员

现在才真正开始构建。

后端构建员只负责功能的后端部分。

而且只负责后端。

它接收的输入：

• 已批准的技术简报
• 代码库研究员的发现
• 项目的 CLAUDE.md

它构建的内容：

• API routes
• Services 和业务逻辑
• 数据库访问和迁移
• 后台任务
• 它自己写的所有代码对应的单元测试

它不能做什么：

• 不能碰 React 组件、页面或客户端 hooks，那是 Agent 5 的工作
• 不能擅自添加新依赖
• 不能修改约定范围之外的文件
• 不能在没有运行 typecheck、lint 和测试套件的情况下结束

完成之后，它必须返回总结：

• 新增或编辑了哪些文件
• 复用了哪些现有 helper 或模式
• 哪些 CLAUDE.md 规则本可以帮助它做得更好

工具权限：Read、Edit、Write、Bash。

但只能作用在后端相关目录。

这种隔离才是重点。

后端构建员永远不能意外破坏前端。

Agent 5：前端构建员

前端构建员负责 UI 部分。

同样，只负责 UI 部分。

它会先阅读后端构建员的总结。

这一点很重要。

因为它必须按照后端实际产出的 API 来消费数据。

它不能自己发明新 endpoint。

如果 API 结构不适合 UI，它应该把这个不匹配作为反馈暴露出来。

而不是私自 patch。

它接收的输入：

• 已批准的技术简报
• 代码库研究员的发现
• 后端构建员的总结，也就是 API contract

它构建的内容：

• React 组件和页面
• 客户端 hooks 和状态管理
• Loading 和 error 状态
• 它自己写的所有组件和逻辑对应的测试

它不能做什么：

• 不能碰 services、API routes、workers 或 migrations，那是 Agent 4 的工作
• 不能发明 endpoints 或 response shapes
• 不能擅自添加依赖
• 不能在没有运行 typecheck、lint 和测试套件的情况下结束

工具权限：Read、Edit、Write、Bash。

但只能作用在前端相关目录。

两个构建员。

两个干净上下文窗口。

基本不会出现一个人把另一个人的工作悄悄弄坏的情况。

Agent 6：测试验证员

后端和前端构建员都会给自己的代码写单元测试。

但这还不够。

测试验证员只做一件事：证明这个功能真的满足用户故事。

它写的是验收测试。

不是单元测试。

而是验收测试。

这些测试从外部验证功能，也就是从真实用户体验的角度来测试。

它接收的输入：

• 已批准的用户故事和全部验收标准
• 已批准的技术简报
• 两个构建员的总结

它产出的内容：

• 一个覆盖所有验收标准的验收测试文件
• 一份报告：哪些标准通过了，哪些失败了，哪些无法干净覆盖

它不能做什么：

• 不能修改任何后端或前端代码
• 不能为不可测试标准编造 workaround
• 如果某条标准确实没覆盖，不能假装已经覆盖

如果测试失败：说明功能没有满足用户故事。

它会准确报告失败的是哪条验收标准。

它不会自己修代码。

问题会被送回对应的构建员。

工具权限：Read、Edit、Write，只能写测试文件。

Bash。

核心规则：验收测试没通过之前，就不能算有功能。

Agent 7：实现验证员

这是负责抓漏的 Agent。

其他人没发现的问题，它来发现。

验证员会把当前实现和已批准的用户故事、技术简报进行对比，然后报告差距。

它永远不修复任何东西。

它只说真话。

每次都会检查：

• 用户故事里的验收标准是否还没实现
• 失败路径是否缺少测试覆盖
• 安全问题：缺少 auth 检查、租户隔离漏洞、日志里暴露 secrets、把原始错误暴露给客户端
• 是否修改了约定范围之外的文件
• 是否和 CLAUDE.md 或现有代码模式不一致
• 是否出现了本该复用 helper 的重复逻辑
• 技术简报里提到的时区或多租户问题是否被悄悄跳过

输出必须按严重程度分组：

Critical：合并前必须修复。

Important：合并前应该修复。

Minor：偏主观，交给 reviewer 判断。

每个发现都必须包含文件路径和行号。

如果没有问题，它就直接说没有问题。

不为了显得认真而编造问题。

工具权限：Read、Grep、Glob。

这个 Agent 是软件工厂可信的关键。

自己给自己判分的试卷没有价值。

一个只看磁盘上实际结果，而不关心代码是谁怎么写出来的验证员，才更诚实。

整条链路如何运行

完整流程，只需要一个提示词启动。

你打开 Claude Code，输入：

“为超过 7 天未支付的发票构建 invoice reminders。”

接下来，在你不继续输入的情况下，流程应该这样运行：

Step 1：研究员梳理你的 invoice、payment 和 email 相关代码。返回相关文件、现有模式和风险。

Step 2：用户故事撰写员生成用户故事和验收标准。暂停：你阅读并批准用户故事。

Step 3：技术规格撰写员把已批准的用户故事转成技术简报。暂停：你阅读并批准技术简报。如果里面出现“把 ID 存在内存里”这种错误方案，现在就拦住。

Step 4：后端构建员实现 service、API route、BullMQ job 和单元测试。返回文件变更、复用模式，并确保测试通过。

Step 5：前端构建员读取后端构建员的 API 总结。构建 admin UI tile 和 reminder button，写组件测试，并确保测试通过。

Step 6：测试验证员为全部 6 条验收标准写验收测试。报告结果：7 个通过，1 个失败。失败原因是手动触发没有检查 tenant ownership。

Step 7：验证员发现问题。以 Critical 级别报告，并附上文件路径和行号。然后循环回到后端构建员。修复应用。全部 8 个验收测试通过。验证员再次运行。结果干净。暂停：你最终审查并打开 PR。

整条链路里，只有 3 个真正需要你的人工检查点：

• 批准用户故事
• 批准技术简报
• 批准 PR

其他部分都可以自动推进。

基础：Agent 工作之前，你需要先准备这些

CLAUDE.md：跨会话保留的项目记忆

每次你打开 Claude Code，它本质上都从零记忆开始。

CLAUDE.md 就是为了解决这个问题。

它是放在仓库根目录的 Markdown 文件，每次会话都会自动加载。

这里应该存放永久项目事实：

• 技术栈，比如 Next.js App Router、Node.js、Prisma、BullMQ、Resend
• 常用命令，比如 npm run dev、npm test、npx prisma migrate dev
• 架构规则，比如“业务逻辑放在 services，API routes 保持轻薄”
• 明确禁止事项，比如“不要添加 cron，用 BullMQ；不要记录原始支付 payload”
• 更深文档的入口，比如 docs/billing.md、docs/architecture.md

建议控制在 100—300 行。

每次 AI 犯了一个让你意外的错误，都问自己：如果 CLAUDE.md 里有一条规则，能不能阻止这个错误？

如果能，就加进去。

几周之后，你的 CLAUDE.md 会变成一份记录：它记录了 AI 曾经误解过的所有项目假设。

你的后续会话也会明显变好。

Context Drift：沉默的杀手

大多数 Claude Code 会话，不是突然失败的。

它们是慢慢漂移的。

一个错误假设进入上下文。

模型开始在这个错误假设上继续构建。

比如你让 Claude 构建 subscription management。

它设计成：User → Subscription。

但你突然想起来：订阅其实属于 company，不属于 user。

如果你只是说一句：“不对，subscriptions 属于 companies。”

Claude 会 patch。

结果上下文里可能同时出现 user.subscriptionId 和 company.subscriptionId。

这就是问题开始变脏的地方。

规则很简单：

• 小拼写错误，可以直接在当前会话里改。
• 错误架构假设，直接丢掉这个对话，从新会话开始，并把正确假设写进第一条提示词。

一个带着正确心智模型的干净会话，永远比一个不断补丁的旧会话更好。

结果：真正改变的是什么

软件工厂之前：

• Vibe coding 循环：提示 → 生成 → 报错 → 修补 → 重复
• 会话上下文充满噪音
• 错误假设叠加成坏功能
• 一个工程师一次只能推进一件事
• 每个功能都要等合适的人有空

软件工厂之后：

• 结构化链路：研究 → 用户故事 → 技术简报 → 构建 → 验证 → 校验
• 每个 Agent 都拿到干净上下文，只看到自己需要的内容
• 错误假设在技术简报审批阶段就被抓住，而不是等 10 个文件都改完
• 一个工程师可以交付完整纵向切片：后端、前端、测试、验证
• 团队最好的知识沉淀在 Agent 里，而不是困在某个人脑子里

真正的变化是：支付专家构建一个 payments-integration agent。

于是团队里每个工程师都可以交付涉及 billing 的功能。

不用等待。

不用交接。

前端负责人沉淀的组件模式，进入 frontend-builder agent。

DevOps 工程师的 CI 检查，进入 hook。

QA 负责人的边界情况，进入 test-verifier 规则。

专家知识不再受限于某个人是否有空。

它变成了可复用的 Agent。

这个周末如何搭建你自己的软件工厂

下面是一个 8 步设置清单。

1. 安装 Claude Code

地址：code.claude.com

2. 创建文件夹结构

.claude/agents/
.claude/skills/feature-factory/
.claude/skills/build-with-tests/
.claude/hooks/

3. 编写 CLAUDE.md

控制在 100—300 行。

内容包括：技术栈、命令、架构规则、不要做什么、关键文档入口。

4. 用 /agents 创建 7 个 Agent

在 Claude Code 中使用 /agents 命令。

描述每个 Agent 的角色。

让 Claude 帮你生成文件。

你负责审查并提交。

5. 创建 feature-factory 编排技能

让 Claude 帮你写这个 orchestrator skill。

它会读取你的 7 个 Agent 文件，并把整条链路串起来。

6. 创建 build-with-tests 技能

这个技能描述你的团队如何构建功能：匹配现有模式、代码旁边写测试、最后运行 typecheck。

7. 添加 pre-commit hook

阻止提交包含这些文件：

.env
.key
.pem
secrets.json

这只需要 5 分钟。

但能避免很多灾难。

8. 用一个真实小功能跑完整链路

不要一上来选大功能。

挑一个小功能。

让它完整跑一遍。

观察哪里卡住。

补规则。

优化 Agent。

这个软件工厂会在使用中自己变好。

总时间大约 2—3 小时。

然后用它跑几个功能。

跑完 3—4 个之后，它会越来越理解你的代码库。

你会花更少时间监督。

花更多时间决定下一个应该构建什么。

7 个 Agent 快速参考

• Researcher：在构建前梳理代码，只读。
• Story Writer：把想法转成用户故事和验收标准，只读。
• Spec Writer：把用户故事转成技术简报，只读。
• Backend Builder：构建 API、services、jobs 和单元测试，只能碰后端目录。
• Frontend Builder：构建组件、页面、hooks 和 UI 测试，只能碰前端目录。
• Test Verifier：根据用户故事写验收测试，只能碰测试文件。
• Validator：对比实现、用户故事和技术简报，报告差距，只读。

3 个人工检查点：

• 批准用户故事
• 批准技术简报
• 批准 PR

其他部分都可以自动运行。

最后

大多数开发者还在用 Claude Code 做 vibe coding。

提示。

生成。

修补。

祈祷。

这不是错。

只是有天花板。

软件工厂不会把你从流程中移除。

它只是把你从那些不需要你亲自处理的环节里解放出来。

你仍然留在真正需要判断力的位置：这是不是正确的问题？这是不是正确的设计？这能不能安全发布？

中间的执行部分，交给 Agent。

这就是把 AI 当成更快键盘，和把 AI 当成协作团队之间的区别。

如果你也在实践类似的多 Agent 工作流，欢迎到 云栈社区 与更多开发者一起交流。