# 用 Claude Code 搭一座软件工厂：你睡觉时它在发版
> **作者**: [@sairahul1](https://x.com/sairahul1)（Rahul，NicheTrafficKit 创始人）
> **发布**: 2026-05-25
> **原文**: https://x.com/sairahul1/status/2058832033628241931
我以为我在用 AI 写代码。
其实我只是打字快了点。
差别在哪里——以及那套改变一切的 7-agent 系统。
存下来。能省你几个月。
## 没人愿意聊的那个问题
**那个看着很有效率、其实没有的循环：**
→ 让 Claude 实现一个 feature → 它生成代码 → 出错了 → 把报错粘回去 → 它打个补丁 → 别处又坏了 → 再问一遍
第 1 天：感觉像魔法。
第 30 天：你监督 AI 的时间比之前自己写代码还多。
同一段逻辑出现在 3 个不同地方。
两周前你定下的命名规范，Claude 忘了。
新 feature 把老 feature 撞坏。
测试要么没写，要么写得很浅。
某天你突然意识到：不是 AI 在失败。
是你的工作流在失败。
**真正的问题是结构性的。**
你在 Claude Code 里敲下 "build this feature" 那一刻，等于让一个 AI session 同时扮演：
→ 产品分析师 → 架构师 → 后端工程师 → 前端工程师 → 测试工程师 → Code reviewer
全部一起。
全在同一团乱糟糟的对话里。
计划里的错误假设变成错误的数据库模型。
错误的数据库模型变成错误的 API。
错误的 API 变成错误的 UI。
等你发现的时候，错误已经扩散到所有角落。
这就叫 vibe coding。
它有一道很硬的天花板。
## 转变：从 vibe coding 到软件工厂
**真正改变一切的事情：**
真正的工程团队不会在一团对话里开干。
不同的人扛不同的活：
→ 有人厘清用户问题 → 有人想架构 → 有人写 API → 有人写 UI → 有人想边界情况 → 有人做评审
把这些全压进一个 AI session，错误就开始悄悄地、复利式地累积。
**解决办法是把工作拆给若干专业 agent。**
每个 agent 拿到的是：→ 一个聚焦的职责 → 自己干净的 context window → 它真正用得上的工具 → 不许碰什么的硬约束
结果就是一座软件工厂。
一个开发 + 七个聚焦的 agent = 一个协作的团队。
下面就是让这套东西转起来的七个 agent。
## 七个 Agent
### Agent 1：Codebase Researcher（代码库勘探员）
开发者用 AI 时最大的错误是什么？
第一步就让它写代码。
AI 接住 prompt，自己脑补缺失的部分，开始生成。
烂设计就是从这里钻进来的。
Codebase Researcher 解决这个问题。
**它唯一的活：在写下第一行代码之前，把代码库摸清楚、把现状解释清楚。**
它做什么：→ 标出相关文件和它们的角色 → 记录下需要遵循的现有模式 → 找出已经实现过的相似 feature → 提示风险（时区、多租户、retry 逻辑）→ 列出哪些测试需要更新
它不能做什么：→ 编辑文件（只读）→ 跑任何会改状态的命令 → 替你做假设——不会就问
工具：Read、Grep、Glob，仅此。
**铁律：每一次，都先勘探再开建。**
Researcher 永远跑第一棒。
### Agent 2：Story Writer（用户故事撰稿人）
大多数 feature 失败，不是因为代码错。
是因为问题从一开始就没说清楚。
Story Writer 在任何技术决策落下之前，先把一个粗糙的 feature idea 转成一个真正的用户故事。
它的输入：→ 你那段粗糙的 feature 描述 → Researcher 的勘探结果
它的输出：
**一条用户故事**："As a [角色], I want [行为], so that [结果]."
**验收标准（Acceptance criteria）**：测试可以直接验证的陈述句。Happy path、失败路径、业务规则。
**边界情况（Edge cases）**：边界值、retry、多租户问题。
**不在范围内（Out of scope）**：明确**不**做的事。
**遗留问题（Open questions）**：它真不知道的——绝不瞎猜。
它不能做什么：→ 凭空发明业务规则 → 写任何代码或技术设计 → 在确实模糊的地方硬推下去
工具：仅 Read。
**铁律：你读完这条故事并批准，之后才能进行任何后续动作。**
这是第一个 human checkpoint，下游的所有事都靠它兜底。
### Agent 3：Spec Writer（技术规约作者）
故事被批准之后，Spec Writer 把它转成一份技术 brief。
这份 brief 是后面所有 build agent 的施工蓝图。
它的输入：→ 你批准的用户故事 → Researcher 的勘探结果 → 项目里的 CLAUDE.md 规则
它的输出：
→ 数据模型变更（字段、类型、migrations）→ 后台流程 / 处理流程 → API 变更（endpoints、请求/响应结构）→ 前端变更（components、pages、hooks）→ 需要的测试（成功、失败、边界）→ 风险与遗留问题 → 每一个会被改动的文件
它不能做什么：→ 编辑任何文件 → 凭空发明新基础设施——而是显式标出来 → 跳过租户隔离或时区相关问题 → 留下没回答的问题
工具：Read、Grep、Glob，仅此。
**铁律：这份 brief 是第二个 human checkpoint。**
你读完批准，之后才会有第一个文件被动到。
如果你看到 "store IDs in memory" 这种字眼——这就是红旗。
现在抓出来。不要等 10 个文件已经被改完。
### Agent 4：Backend Builder（后端构建者）
现在才开始施工。
Backend Builder 实现这个 feature 的后端那一半——而且**只有**后端那一半。
它的输入：→ 已批准的技术 brief → Researcher 的勘探结果 → 项目的 CLAUDE.md
它构建什么：→ API routes → Services 与业务逻辑 → 数据库访问与 migrations → 后台 jobs → 它写的所有东西的 unit tests
它不能做什么：→ 碰 React component、page 或 client-side hook（那是 Agent 5 的活）→ 没指令地引入新依赖 → 改动约定范围之外的文件 → 不跑 typecheck、lint 和测试套件就交差
完事之后它返回一份摘要：→ 添加或编辑过的每个文件 → 复用过的每个现有 helper 或 pattern → 任何能帮上忙的 CLAUDE.md 规则
工具：Read、Edit、Write、Bash——仅限后端目录。
分工本身就是重点。
**Backend Builder 永远不可能不小心把前端搞坏。永远不可能。**
### Agent 5：Frontend Builder（前端构建者）
Frontend Builder 实现 UI 那一半——而且**只有** UI 那一半。
它会先读 Backend Builder 的摘要。
这一点很重要。
它严格按后端实际产出的形态消费 API。
它不会自己发明新的 endpoints。
如果 API 形状对 UI 来说不顺手，它会把这个不匹配作为反馈抛出来——而不是自己打补丁。
它的输入：→ 已批准的技术 brief → Researcher 的勘探结果 → Backend Builder 的摘要（API 契约）
它构建什么：→ React components 和 pages → 客户端 hooks 和 state → 加载态和错误态 → 它写的所有东西的 component 测试和 unit tests
它不能做什么：→ 碰 services、API routes、workers 或 migrations（那是 Agent 4 的活）→ 自己发明 endpoints 或响应结构 → 没指令地加依赖 → 不跑 typecheck、lint 和测试套件就交差
工具：Read、Edit、Write、Bash——仅限前端目录。
两个 builder。
两个干净的 context window。
一个搞坏另一个工作的概率：零。
### Agent 6：Test Verifier（测试验证者）
两个 builder 都给自己的代码写了 unit test。
那不够。
**Test Verifier 只做一件事：证明这个 feature 真的实现了用户故事说的事情。**
它写 acceptance test。
不是 unit test。
是 acceptance test。
这种测试从外部、按真实用户体验它的方式，去测这个 feature。
它的输入：→ 已批准的用户故事（含全部验收标准）→ 已批准的技术 brief → 两个 builder 的摘要
它的输出：→ 一个覆盖每条验收标准的 acceptance test 文件 → 一份报告：哪些标准过了，哪些挂了，哪些没法干净地覆盖
它不能做什么：→ 修改任何后端或前端代码 → 给不可测的标准编 workaround → 把没真正覆盖的标准标成覆盖
**如果某个测试挂了：这个 feature 不满足故事的要求。**
它会精确地报告是哪一条标准挂了。
它不会动代码。
那是相应 builder 的活。
工具：Read、Edit、Write（仅测试文件）、Bash。
**铁律：在 acceptance test 全过之前，你没有 feature。**
### Agent 7：Implementation Validator（实现校验员）
这个 agent 抓的是其他人都漏掉的东西。
Validator 把当前实现和已批准的故事 + brief 做对照——并报告缺口。
它从不修任何东西。
它只说真话。
它每一次都会跑这一整套检查：
→ 故事里的验收标准有哪些还没实现 → 哪些失败路径没测试覆盖 → 安全问题：缺失的鉴权检查、租户隔离漏洞、log 里的密钥、原始报错暴露给客户端 → 在约定范围之外被改动的文件 → 与 CLAUDE.md 或现有代码不一致的模式 → 应该复用现有 helper 而出现的重复逻辑 → brief 里写了但被悄悄跳过的时区或多租户问题
输出永远按严重度分组：
**Critical** —— 合并前必须修 **Important** —— 合并前应当修 **Minor** —— 主观判断，由 reviewer 拍板
每一条发现都带文件路径和行号。
如果没毛病，它会直接说没毛病。
它不会为了显得认真就编出问题。
工具：Read、Grep、Glob，仅此。
这个 agent 是工厂为什么可信的原因。
自己给自己打分的卷子毫无价值。
只看磁盘上有什么、不看是怎么写出来的——这样的 validator 才诚实。
## 整条链怎么跑
**完整流程——一句 prompt 启动一切：**
你打开 Claude Code，输入：
*"Build invoice reminders for invoices unpaid for more than 7 days."*
之后你不再敲一个字，下面这些会发生：
**Step 1** → Researcher 把 invoice、payment、email 相关代码摸一遍。返回相关文件、现有 pattern、风险。
**Step 2** → Story Writer 产出用户故事和验收标准。
**⏸ 暂停：你读故事并批准。**
**Step 3** → Spec Writer 把已批准的故事转成技术 brief。
**⏸ 暂停：你读 brief 并批准。**（"store IDs in memory" 这种错误就在这里抓出来。）
**Step 4** → Backend Builder 实现 service、API route、BullMQ job 和 unit tests。返回：变更过的文件、复用过的 pattern、所有测试 green。
**Step 5** → Frontend Builder 读 Backend Builder 的 API 摘要，构建后台 UI 卡片和提醒按钮，写 component tests。所有测试 green。
**Step 6** → Test Verifier 给六条验收标准写 acceptance tests。报告：7 过，1 挂——manual trigger 没检查租户归属。
**Step 7** → Validator 抓到这个问题。标为 Critical，附文件路径和行号。
**→ 回到 Backend Builder 那里。** 修复落地。8 条 acceptance tests 全过。Validator 再跑一遍。Clean。
**⏸ 暂停：你 review，开 PR。**
三个 human checkpoints。
其他全自己跑。
## 地基：agent 能干活之前，你需要先准备好这些
**CLAUDE.md —— 跨 session 不丢的记忆：**
每次你打开 Claude Code，它都是零记忆开局。
CLAUDE.md 解决这个。
它是放在 repo 根目录的 Markdown 文件，每个 session 自动加载。
它是项目永久事实的栖身地：
→ 你的技术栈（Next.js App Router、Node.js、Prisma、BullMQ、Resend）→ 你的命令（npm run dev、npm test、npx prisma migrate dev）→ 架构规则（"业务逻辑放在 services 里。API routes 保持薄。"）→ 不要做什么（"不要加 cron——用 BullMQ。不要把 raw payment payload 写进 log。"）→ 指向更深文档的链接（docs/billing.md、docs/architecture.md）
控制在 100-300 行。
每次 AI 犯一个让你意外的错，问自己：CLAUDE.md 里有没有一条规则能挡住这个？
加上那条规则。
几周后，你的 CLAUDE.md 就会变成"AI 曾经搞错过的所有假设"的清单——你的 session 也会肉眼可见地变好。
**Context drift —— 沉默的杀手：**
大多数 Claude Code session 不是戏剧化地崩掉。
它们是慢慢飘掉。
一个错误假设钻进 context。
模型继续在它上面盖楼。
你让 Claude 实现订阅管理。
它设计成：User → Subscription。
你想起来：subscription 属于 company，不属于 user。
如果你只说一句 "no, subscriptions belong to companies"——Claude 会打补丁。
现在 `user.subscriptionId` 和 `company.subscriptionId` 同时漂在代码里。
**铁律：**
→ 小拼写错？inline 改掉。→ 架构假设错了？把对话整段扔掉，重开一个新会话，把正确的假设直接焊进第一句 prompt。
任何时候，"心智模型对了的全新 session" 都比 "打过补丁的旧 session" 要好。
## 结果：到底改变了什么
**工厂之前：**
→ Vibe coding 循环：prompt → 生成 → 报错 → 打补丁 → 重复 → Session context 被噪声塞满 → 错误假设复利累积成坏掉的 feature → 一个工程师一次只能做一件事 → 每个 feature 都得等"对的人"有空
**工厂之后：**
→ 结构化链路：research → story → brief → build → verify → validate → 每个 agent 都拿到一个只装它需要的东西的干净 context → 错误假设在 brief 批准时就被抓出来——不是 10 个文件改完之后 → 一个工程师交付一整片纵切：后端、前端、测试、校验 → 团队最好的知识住在 agent 里——而不是被锁在某个具体的人身上
**真正的转变：**
支付专家做了一个 payments-integration agent。
现在团队里每个工程师都能交付涉及 billing 的 feature。
不用等。
不用交接。
前端 lead 的 component pattern 住在 frontend-builder agent 里。
DevOps 工程师的 CI 检查住在一个 hook 里。
QA lead 的边界情况住在 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 然后 commit。
**5.** 创建 feature-factory orchestrator skill。让 Claude 写——它会读你那 7 个 agent 文件并把链路接起来。
**6.** 创建 build-with-tests skill。描述你们团队怎么写代码：匹配现有 pattern、代码和测试同写、最后跑 typecheck。
**7.** 加一个 pre-commit hook。拦住任何包含 `.env`、`.key`、`.pem` 或 `secrets.json` 的提交。5 分钟搞定。能避免大灾难。
**8.** 用一个真实 feature 跑通整条链。挑个小的。看它在哪儿磕绊。补规则。工厂会自己调谐。
**总耗时：2-3 小时。**
然后跑几个 feature。
3-4 个之后，工厂就摸熟你的代码库了。
你监督的时间会变少。
决定下一步建什么的时间会变多。
## 七个 Agent —— 速查表
→ **Researcher** —— 在动手之前先把代码摸一遍（仅 Read）→ **Story Writer** —— 把 idea 转成带验收标准的用户故事（仅 Read）→ **Spec Writer** —— 把故事转成技术 brief（仅 Read）→ **Backend Builder** —— 写 API、services、jobs、unit tests（仅后端目录）→ **Frontend Builder** —— 写 components、pages、hooks、UI tests（仅前端目录）→ **Test Verifier** —— 对照用户故事写 acceptance tests（仅测试文件）→ **Validator** —— 把实现对照故事和 brief，报告缺口（仅 Read）
**3 个 human checkpoints：** → 批准故事 → 批准 brief → 批准 PR
其他全自己跑。
---
大多数用 Claude Code 的开发者还在 vibe coding。
prompt → 生成 → 打补丁 → 祈祷。
这没错。
只是它有天花板。
工厂不是把你从流程里赶出去。
它是把你从那些不需要你的环节里赶出去。
你留在你的判断真正重要的环节：
这是不是对的问题？这是不是对的设计？这真的能 ship 吗？
中间的所有事，agent 来处理。
这就是"把 AI 当快一点的键盘"和"把 AI 当一支协作团队"的差别。
---
如果觉得有用：
→ 转发给你的圈子 → 关注 [@sairahul1](https://x.com/sairahul1)，会有更多类似的拆解 → 收藏这篇——你会想回头查那 7 个 agent 的
我写 AI、做产品、以及那些你睡着时也在跑的系统。