用 Claude Code 搭一座软件工厂
一套 7 个 Agent 的 Claude Code 工作流：从代码库调研、用户故事、技术规格，到前后端实现、验收测试和最终校验。
我以为自己在用 AI 写代码。
后来发现，我只是打字更快了。
差别在这里：一套 7 个 Agent 的系统，可以改变 Claude Code 的使用方式。
这套方法能省掉很多弯路。
很少有人说清楚的问题
那种看起来很高效的循环是这样的：
让 Claude 做一个功能
→ 它生成代码
→ 某处报错
→ 把错误贴回去
→ 它打补丁
→ 另一个地方又坏了
→ 继续追问
第一天，这像魔法。
第 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 接受需求，靠猜测补齐空白，然后开始生成。
糟糕设计就是这样混进去的。
代码库研究员负责阻断这件事。
它唯一的任务：在写任何一行代码前，先检查代码库，解释现有系统如何工作。
它要做的事：
梳理相关文件和职责
记录需要遵循的现有模式
找到已经实现过的相似功能
标出风险：时区、多租户、重试逻辑等
列出未知问题
它不能做的事：
编辑文件，只读访问
运行会修改状态的命令
靠猜测推进，有疑问就提出来
工具：Read、Grep、Glob。
规则：每次先探索，再构建。
研究员永远第一个运行。
Agent 2：用户故事写手
很多功能失败，并非代码写错了。
问题经常出在需求从未被清楚定义。
用户故事写手会把粗略的功能想法整理成真正的用户故事，再进入任何技术决策。
输入：
你的粗略功能描述
代码库研究员的发现
输出：
用户故事：
As a [role], I want [behaviour], so that [outcome].
验收标准：
测试可以直接验证的陈述。包含成功路径、失败路径、业务规则。
边界情况：
边界、重试、多租户相关问题。
不在范围内：
明确不做什么。
开放问题：
确实不知道的事项，绝不猜。
它不能做的事：
编造业务规则
写代码或技术设计
遇到真正不清楚的问题还继续推进
工具：Read。
规则：你先阅读并批准这份故事，再进入下一步。
这个人工检查点能保住后面所有环节。
Agent 3：规格写手
用户故事批准后，规格写手会把它转成技术简报。
这是所有构建 Agent 后续遵循的蓝图。
输入：
批准后的用户故事
代码库研究员的发现
项目里的 CLAUDE.md 规则
输出：
数据模型变更：字段、类型、迁移
后台流程或业务流程
API 变更：端点、请求/响应结构
前端变更：组件、页面、hooks
需要的测试：成功路径、失败路径、边界情况
它不能做的事：
编辑文件
编造新基础设施；如果需要，会明确指出
跳过租户隔离或时区问题
留下未回答的问题
工具：Read、Grep、Glob。
规则：技术简报是第二个人工检查点。
你阅读并批准之后，才允许碰文件。
如果你在这里看到“把 ID 存在内存里”，这就是红旗。
现在抓住它，别等 10 个文件都被改完。
Agent 4：后端构建者
现在才开始构建。
后端构建者只实现功能的后端部分。
输入：
批准后的技术简报
代码库研究员的发现
项目里的 CLAUDE.md
它要构建：
API routes
services 和业务逻辑
数据库访问与迁移
后台任务
它所写代码对应的单元测试
它不能做的事：
碰 React 组件、页面或客户端 hooks，那是 Agent 5 的范围
未经指示引入新依赖
修改约定范围外的文件
没有运行 typecheck 就结束
完成后，它返回摘要：
新增或编辑过的所有文件
复用过的现有 helper 或模式
哪些 CLAUDE.md 规则本可以帮上忙
工具：Read、Edit、Write、Bash，但只限定在后端目录。
拆开的意义就在这里。
后端构建者不会顺手破坏前端。
Agent 5：前端构建者
前端构建者只实现 UI 部分。
它会先读取后端构建者的摘要。
这点很重要。
它完全按后端已经产出的 API 来消费数据。
它不会发明新的端点。
如果 API 结构不适合 UI，它会把不匹配作为反馈提出，避免自己打补丁。
输入：
批准后的技术简报
代码库研究员的发现
后端构建者摘要，也就是 API contract
它要构建：
React 组件和页面
客户端 hooks 与状态
loading 与 error 状态
它所写内容对应的组件测试和单元测试
它不能做的事：
碰 services、API routes、workers 或 migrations，那是 Agent 4 的范围
发明端点或 response shape
未经指示添加依赖
没有运行 typecheck 和测试就结束
工具：Read、Edit、Write、Bash，但只限定在前端目录。
两个构建者。
两个干净上下文窗口。
彼此不会踩到对方的工作。
Agent 6：测试验证员
两个构建者会给自己的代码写单元测试。
这还不够。
测试验证员只做一件事：证明这个功能确实满足用户故事。
它写的是验收测试。
这里写的是验收测试，区别于普通单元测试。
这些测试从外部验证功能，站在真实用户体验的角度看系统。
输入：
批准后的用户故事，包含全部验收标准
批准后的技术简报
两个构建者的摘要
输出：
一个验收测试文件，覆盖每条验收标准
一份报告：哪些标准通过、哪些失败、哪些没法干净覆盖
它不能做的事：
修改任何后端或前端代码
为无法测试的标准编造绕路方案
在标准没有真正覆盖时标记为已覆盖
如果测试失败，说明功能还没满足用户故事。
它会精确报告哪条标准失败。
它不会修代码。
失败项会回到对应的构建者那里。
工具：Read、Edit、Write，只限测试文件，另加 Bash。
规则：验收测试通过前，这个功能还不算完成。
Agent 7：实现校验员
这个 Agent 会抓住其他环节漏掉的问题。
校验员会把当前实现和批准过的用户故事、技术简报逐项对照，然后报告缺口。
它从不修复。
它只说实话。
每次都会检查：
用户故事里的验收标准是否还没实现
失败路径是否缺少测试覆盖
安全问题：缺少鉴权、租户隔离缺口、日志里有 secret、原始错误暴露给客户端
数据完整性问题：竞态条件、重复记录、时区错误、缺少事务
性能问题：N+1 查询、缺少索引、不必要的加载
输出总是按严重程度分组：
Critical：合并前必须修
Important：合并前应该修
Minor：偏意见项，交给审查者判断
每条发现都要附文件路径和行号。
如果没问题，就直接说没问题。
它不会为了显得全面而发明问题。
工具：Read、Grep、Glob。
这就是软件工厂可信的原因。
自己给自己打分的试卷没有意义。
只看磁盘现状、不参与写作过程的校验员，才更诚实。
整条链路如何运行
完整流程只需要一个起始提示词。
你打开 Claude Code，输入：
Build invoice reminders for invoices unpaid for more than 7 days.
后面会这样运行：
Step 1 → Researcher 梳理 invoice、payment、email 相关代码，返回文件、现有模式和风险。
Step 2 → Story Writer 产出用户故事和验收标准。
⏸ PAUSE：你阅读并批准用户故事。
Step 3 → Spec Writer 把批准后的故事转成技术简报。
⏸ PAUSE：你阅读并批准技术简报。
在这里抓住 “store IDs in memory” 这种错误。
Step 4 → Backend Builder 实现 service、API route、BullMQ job 和单元测试，返回文件变更、复用模式和绿色测试结果。
Step 5 → Frontend Builder 读取后端 API 摘要，构建 admin UI tile 和 reminder button，写组件测试，测试通过。
Step 6 → Test Verifier 为全部 6 条验收标准写验收测试，报告：7 条通过，1 条失败——manual trigger 没检查 tenant ownership。
Step 7 → Validator 发现问题，按 Critical 报告文件路径和行号。
→ 回到 Backend Builder，修复完成。8 条验收测试全部通过。Validator 再跑一次，干净。
⏸ PAUSE：你 review，然后开 PR。
三个人工检查点。
其他部分自动运行。
基础：Agent 工作前，先准备这些
CLAUDE.md 是每次会话都能继承的记忆。
每次打开 Claude Code，它都从零记忆开始。
CLAUDE.md 解决这个问题。
它是放在 repo 根目录的 Markdown 文件，每次会话会自动加载。
永久项目事实应该放在这里：
技术栈：Next.js App Router、Node.js、Prisma、BullMQ、Resend
命令：npm run dev、npm test、npx prisma migrate dev
架构规则：Business logic lives in services. API routes should stay thin.
禁止事项：不要在 API route 里写业务逻辑，不要把租户 ID 存进内存
控制在 100 到 300 行。
每次 AI 犯了让你意外的错，都问一句：如果 CLAUDE.md 里有一条规则，能不能防住它？
能防住，就加进去。
几周后，CLAUDE.md 会变成 AI 曾经误判过的假设清单，你的会话质量会明显提升。
上下文漂移是安静的杀手。
大多数 Claude Code 会话不会突然失败。
它们会慢慢漂移。
一个错误假设进入上下文。
模型继续在这个假设上构建。
你让 Claude 做订阅管理。
它设计成：
User → Subscription
你想起来：订阅属于公司，不属于用户。
如果你只说“订阅属于公司”，Claude 会打补丁。
现在代码里可能同时出现：
user.subscriptionId
company.subscriptionId
规则：
小拼写错误：就地纠正。
错误架构假设：丢掉当前对话，带着正确假设开一个干净会话。
一个带着正确心智模型的干净会话，胜过一个一路补丁的旧会话。
结果会发生什么变化
软件工厂之前：
vibe coding 循环：prompt → generate → error → patch → repeat
会话上下文塞满噪音
错误假设叠加成坏功能
一个工程师同一时间只能做一件事
专家知识卡在某个人的脑子里
软件工厂之后：
结构化链路：research → story → brief → build → verify → validate
每个 Agent 都有干净上下文，只拿自己需要的内容
错误假设在 brief 审批时被抓住，不会等到代码写完
前后端可以并行推进
测试和校验属于流程的一部分，不靠事后补救
专家知识被编码进 Agent、skills 和 hooks
真正的变化是：
支付专家可以构建一个 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. 在 Claude Code 里用 /agents 命令创建 7 个 Agent。描述每个 Agent 的角色，让 Claude 写文件，你 review 后提交。
5. 创建 feature-factory orchestrator skill。让 Claude 写，它会读取 7 个 Agent 文件并串起整条链。
6. 创建 build-with-tests skill。描述团队如何构建：匹配现有模式，代码旁边写测试，最后运行 typecheck。
7. 添加 pre-commit hook。阻止提交 .env、.key、.pem 或 secrets.json。5 分钟完成，能避免灾难。
8. 用一个真实小功能跑完整链路。观察它在哪里卡住，然后补规则。工厂会自己调优。
总时间：2 到 3 小时。
然后跑几个功能。
跑过 3 到 4 个之后，这座工厂就开始熟悉你的代码库。
你会少花时间盯着 AI 。
把更多时间放在决定下一步该做什么。
7 个 Agent 速查
Researcher
→ 写代码前先梳理代码库，只读。
Story Writer
→ 把想法转成用户故事和验收标准，只读。
Spec Writer
→ 把故事转成技术简报，只读。
Backend Builder
→ 实现后端范围，写对应测试。
Frontend Builder
→ 实现前端范围，写对应测试。
Test Verifier
→ 写验收测试，验证用户故事。
Implementation Validator
→ 对照故事和规格，报告缺口，只读。
3 个人工检查点：
批准用户故事
批准技术简报
批准 PR
其他部分自动运行。
多数开发者用 Claude Code 时，还停留在 vibe coding：
prompt → generate → patch → hope
这条路能用，但会遇到天花板。
软件工厂不会把你从流程里拿掉。
它会把你从不需要你亲自盯着的部分里拿出来。
你仍然留在需要判断力的位置：
问题选对了吗？
设计选对了吗？
这个东西可以发吗？
中间的执行部分，交给 Agent 。
这就是把 AI 当成一把更快的键盘，和把 AI 当成一支协同团队之间的区别。
如果这套方法对你有用，建议先从一个小功能跑通。别先追求完整自动化，先让研究、故事、规格、构建、验证、校验这条链路真实跑一次。