如何用 Claude Code 构建一个在你睡觉时也能发布功能的软件工厂

我曾以为我在用 AI 写代码。

实际上，我只是打字更快了。

区别就在这儿——以及改变一切的 7 代理系统。

保存好这篇文章。它能帮你省下数月时间。

没人谈过的问题

那个看起来高效实则低效的循环：

→ 让 Claude 构建一个功能 → 它生成代码 → 出问题了 → 粘贴错误回去 → 它修补代码 → 又出问题了 → 再次询问

第一天：感觉像魔法。

第三十天：你花在监督 AI 上的时间比过去写代码的时间还多。

同样的逻辑出现在 3 个不同的地方。

Claude 忘记了你两周前定下的约定。

新功能破坏了旧功能。

测试要么缺失要么肤浅。

你醒来才发现：不是 AI 不行。

是你的工作流程不行。

真正的问题是结构性的。

当你在 Claude Code 中输入“构建这个功能“时，你是在要求一个 AI 会话同时扮演：

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

所有角色一拥而上。

在同一次混乱的对话中。

计划中的错误假设变成了错误的数据库模型。

错误的数据库模型变成了错误的 API。

错误的 API 变成了错误的 UI。

等你发现问题时，错误已经蔓延到了各处。

这就叫做凭感觉编程。

而且它有明显的天花板。

转变：从凭感觉编程到软件工厂

真正改变一切的关键：

真正的工程团队不会在单次大对话中工作。

不同的人负责不同的工作：

→ 有人澄清用户问题 → 有人思考架构 → 有人构建 API → 有人构建 UI → 有人思考边界情况 → 有人做审查

当这一切被压缩到一次 AI 会话中时，错误会悄无声息地累积。

解决办法是将工作拆分给专门的智能体。

每个智能体获得：→ 一个专注的任务 → 自己干净的上下文窗口 → 只给它实际需要的工具 → 关于它不能触碰什么的严格规则

结果是：一个软件工厂。

一个开发者 + 七个专注的智能体 = 一个协作团队。

以下是让这一切运转起来的七个智能体。

7 个智能体

智能体 1：代码库研究员

开发者在使用 AI 时犯的最大错误？

一上来就要求写代码。

AI 接受提示词，通过猜测来填补空白，然后开始生成代码。

糟糕的设计就这样悄悄潜入。

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

它的唯一职责：在写任何一行代码之前，检查代码库并解释事物是如何运作的。

它的工作：→ 梳理相关文件及其角色 → 记录要遵循的现有模式 → 查找已构建的类似功能 → 标记风险（时区、多租户、重试逻辑） → 列出哪些测试需要更新

它不能做什么：→ 编辑文件（仅限只读访问） → 运行任何修改状态的命令 → 做假设——它会询问确认

工具：仅限 Read、Grep、Glob。

规则：每次构建前都要先探索，无一例外。

研究员总是第一个运行。

智能体 2：故事撰写者

大多数功能失败不是因为代码错了。

而是因为问题从未被清晰定义。

故事撰写者在任何技术决策做出之前，将一个粗略的功能想法转化为一个真实的用户故事。

它接收的输入：→ 你粗略的功能描述 → 研究员的发现

它输出的内容：

一个用户故事：“作为一个[角色]，我想要[行为]，以便[结果]。”

**验收标准：**可以直接被测试验证的陈述。正常路径。失败路径。业务规则。

**边界情况：**边界、重试、多租户相关问题。

**范围外：**明确不会构建的内容。

**待解问题：**它确实不知道的事情——从不猜测。

它不能做什么：→ 编造业务规则 → 编写任何代码或技术设计 → 在事情确实不清楚时继续推进

工具：仅限 Read。

规则：在一切进展之前，你阅读这个故事并批准它。

这是拯救下游所有环节的人工检查点。

智能体 3：规格书撰写者

故事获得批准后，规格书撰写者将其转化为一份技术概要。

这是每个构建智能体都要遵循的蓝图。

它接收的输入：→ 你已批准的用户故事 → 研究员的发现 → 你项目的 CLAUDE.md 规则

它输出的内容：

→ 数据模型变更（字段、类型、迁移） → 后台流程 / 处理流程 → API 变更（端点、请求/响应格式） → 前端变更（组件、页面、钩子） → 所需测试（成功、失败、边界情况） → 风险与待解问题 → 每个将要变更的文件

它不能做什么：→ 编辑任何文件 → 凭空发明新的基础设施——会明确指出来 → 跳过租户隔离或时区问题 → 留下未回答的问题

工具：仅限 Read、Grep、Glob。

规则：这份概要就是第二个人工检查点。

在触碰任何文件之前，你阅读并批准它。

如果你看到“将 ID 存储在内存中“——那就是你的红旗。

现在就抓住它。而不是在 10 个文件被修改之后。

智能体 4：后端构建者

现在开始构建。

后端构建者实现功能的后端部分——而且只做后端部分。

它接收的输入：→ 已批准的技术概要 → 研究员的发现 → 你项目的 CLAUDE.md

它构建的内容：→ API 路由 → 服务和业务逻辑 → 数据库访问和迁移 → 后台任务 → 为它写的所有代码编写单元测试

它不能做什么：→ 触碰 React 组件、页面或客户端钩子（那是智能体 5 的事） → 未经指示发明新的依赖项 → 修改约定范围外的文件 → 在没有运行类型检查、lint 和测试套件的情况下停止

完成后，它会返回一份摘要：→ 每个新增或编辑的文件 → 每个被复用的现有助手方法或模式 → 任何本来会有所帮助的 CLAUDE.md 规则

工具：Read、Edit、Write、Bash——仅限于后端文件夹。

分离是关键所在。

后端构建者永远不会意外破坏前端。

智能体 5：前端构建者

前端构建者实现 UI 部分——而且只做 UI 部分。

它首先读取后端构建者的摘要。

这一点很重要。

它按照后端产生的 API 来使用它。

它不会发明新的端点。

如果 API 格式对 UI 来说不合适，它会将不匹配作为反馈提出来——而不是作为一个补丁。

它接收的输入：→ 已批准的技术概要 → 研究员的发现 → 后端构建者的摘要（API 契约）

它构建的内容：→ React 组件和页面 → 客户端钩子和状态 → 加载和错误状态 → 为它写的所有代码编写组件和单元测试

它不能做什么：→ 触碰服务、API 路由、工作进程或迁移（那是智能体 4 的事） → 发明端点或响应格式 → 未经指示添加依赖项 → 在没有运行类型检查、lint 和测试套件的情况下停止

工具：Read、Edit、Write、Bash——仅限于前端文件夹。

两个构建者。

两个干净的上下文窗口。

一个绝无可能破坏另一个的工作。

智能体 6：测试验证者

两个构建者都为各自的代码编写了单元测试。

这还不够。

测试验证者只做一件事：证明该功能确实做到了用户故事中承诺的效果。

它编写验收测试。

不是单元测试。

是验收测试。

这些测试从外部测试功能——就像真实用户体验它的方式一样。

它接收的输入：→ 已批准的用户故事（包含所有验收标准） → 已批准的技术概要 → 两个构建者的摘要

它输出的内容：→ 一个验收测试文件，覆盖每个验收标准 → 一份报告：哪些标准通过了，哪些失败了，哪些无法干净地覆盖

它不能做什么：→ 修改任何后端或前端代码 → 为不可测试的标准编造变通方案 → 如果某个标准实际上没有被覆盖，就标记为已覆盖

如果测试失败：该功能不满足故事的要求。

它会精确报告哪个标准失败了。

它不会修补代码。

那要回到对应的构建者那里。

工具：Read、Edit、Write（仅限测试文件）、Bash。

规则：在验收测试通过之前，你还没有完成一个功能。

智能体 7：实现验证者

这个智能体负责抓住其他所有人都遗漏的问题。

验证者将当前的实现与已批准的故事和概要进行比较——并报告差距。

它从不修复任何东西。

它只是说实话。

每次都会运行的检查：

→ 故事中尚未实现的验收标准 → 没有测试覆盖的失败路径 → 安全问题：缺少认证检查、租户隔离漏洞、日志中的秘密信息、暴露给客户端的原始错误 → 在约定范围之外变更的文件 → 与 CLAUDE.md 或现有代码不一致的模式 → 应该复用现有助手方法的重复逻辑 → 概要中悄悄跳过的时区或多租户问题

输出总是按严重程度分组：

严重 — 合并前必须修复 重要 — 合并前应修复 次要 — 基于意见，由审查员决定

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

如果没有任何问题，它会直说。

它不会为了显得全面而编造问题。

工具：仅限 Read、Grep、Glob。

这个智能体是工厂值得信赖的原因。

一份自己评分的论文毫无价值。

一个只看到磁盘上的内容——而不是它如何被写出来的——的验证者才是诚实的。

链条如何运行

完整流程——一个提示启动一切：

你打开 Claude Code 并输入：

“为超过 7 天未付款的发票构建发票提醒功能。”

以下是后续发生的事情，无需你再输入任何内容：

第 1 步 → 研究员 梳理你的发票、支付和邮件代码。返回相关文件、现有模式、风险。

第 2 步 → 故事撰写者 产出用户故事和验收标准。

⏸ 暂停：你阅读并批准故事。

第 3 步 → 规格书撰写者 将批准的故事转化为技术概要。

⏸ 暂停：你阅读并批准概要。（就在这里抓住那个“将 ID 存储在内存中“的错误。）

第 4 步 → 后端构建者 实现服务、API 路由、BullMQ 任务和单元测试。返回：变更的文件、复用的模式、全部测试通过。

第 5 步 → 前端构建者 读取后端构建者的 API 摘要，构建管理 UI 面板和提醒按钮，编写组件测试。全部测试通过。

第 6 步 → 测试验证者 为全部六项验收标准编写验收测试。报告：7 项通过，1 项失败——手动触发没有检查租户所有权。

第 7 步 → 验证者 发现问题。报告为严重，并附上文件路径和行号。

→ 循环回到后端构建者。 修复已应用。全部 8 项验收测试通过。验证者再次运行。干净。

⏸ 暂停：你审查并开启 PR。

三个人工检查点。

其他一切自动运行。

基础：在智能体工作之前，你需要这个

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 路由保持简洁。”） → 不该做的事（“不要添加 cron——使用 BullMQ。不要记录原始支付负载。”） → 指引到更深入的文档（docs/billing.md、docs/architecture.md）

保持在 100-300 行之间。

每次 AI 犯了让你惊讶的错误时，问问自己：CLAUDE.md 中有一条规则能防止这个错误吗？

添加这条规则。

几周后，你的 CLAUDE.md 就成了 AI 做出的每个错误假设的记录——你的会话质量会明显提升。

上下文漂移——无声的杀手：

大多数 Claude Code 会话并不是戏剧性地失败。

它们是逐渐偏离的。

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

模型继续在此基础上构建。

你让 Claude 构建订阅管理。

它设计：用户 → 订阅。

你想起：订阅属于公司，而不是用户。

如果你只说“不，订阅属于公司“——Claude 会修补。

现在你同时有了 user.subscriptionId 和 company.subscriptionId 在飘荡。

规则：

→ 小错误？直接原地修正。 → 架构假设错了？扔掉这个会话，带着正确的假设重新开始一个新的会话。

一个带着正确心智模型的干净会话，每次都胜过修补过的会话。

结果：实际发生了哪些变化

工厂模式之前：

→ 凭感觉编程循环：提示 → 生成 → 错误 → 修补 → 重复 → 会话上下文被噪音填满 → 错误假设累积成损坏的功能 → 一个工程师一次只能做一件事 → 每个功能都在等待合适的人有空

工厂模式之后：

→ 结构化链条：研究 → 故事 → 概要 → 构建 → 验证 → 验证 → 每个智能体获得干净的上下文窗口，只包含它需要的内容 → 错误假设在概要审批阶段就被发现——而不是在 10 个文件之后 → 一个工程师就能交付一个完整的垂直切片：后端、前端、测试、验证 → 团队的最佳知识驻留在智能体中——而不是被困在人的脑子里

真正的转变：

支付专家构建了一个支付集成智能体。

现在团队中的每个工程师都能交付涉及计费的功能。

无需等待。

无需交接。

前端主管的组件模式生活在前端构建智能体中。

DevOps 工程师的 CI 检查生活在一个钩子里。

QA 主管的边界情况生活在测试验证者的规则中。

专家知识，以智能体的形式共享。

而不是被困在可用性上。

如何在这个周末构建你自己的工厂

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 个智能体。描述每个智能体的职责。Claude 编写文件。你审查并提交。

5. 创建 feature-factory 编排器技能。让 Claude 来编写它——它会读取你的 7 个智能体文件并串联整个链条。

6. 创建 build-with-tests 技能。描述你的团队如何构建：匹配现有模式、边写代码边写测试、最后运行类型检查。

7. 添加一个预提交钩子。阻止包含 .env、.key、.pem 或 secrets.json 文件的提交。只需 5 分钟。防止灾难。

8. 让一个真实功能走完整个链条。选一个小的。观察它在哪儿卡住。添加规则。工厂会自我调优。

总时间：2-3 小时。

然后运行几个功能。

经过 3-4 次之后，工厂就熟悉了你的代码库。

你会花更少的时间监督。

更多的时间决定下一步要构建什么。

7 个智能体——快速参考

→ 研究员 — 在构建任何东西之前梳理代码（仅限 Read） → 故事撰写者 — 将想法转化为带有验收标准的用户故事（仅限 Read） → 规格书撰写者 — 将故事转化为技术概要（仅限 Read） → 后端构建者 — 构建 API、服务、任务、单元测试（仅限后端文件夹） → 前端构建者 — 构建组件、页面、钩子、UI 测试（仅限前端文件夹） → 测试验证者 — 针对用户故事编写验收测试（仅限测试文件） → 验证者 — 将实现与故事和概要进行比较，报告差距（仅限 Read）

3 个人工检查点：→ 批准故事 → 批准概要 → 批准 PR

其他一切自动运行。

大多数使用 Claude Code 的开发者仍然在凭感觉编程。

提示 → 生成 → 修补 → 祈祷。

这本身没错。

但它是一座天花板。

工厂并没有把你从流程中移除。

它把你从那些不需要你的部分中移除。

你留在你的判断力至关重要的环节：

这是正确的问题吗？这是正确的设计吗？这个可以安全发布吗？

智能体处理剩下的一切。