我以为自己是在用 AI 写代码。
实际上，我只是打字更快了。
区别就在这里——以及那套彻底改变一切的 7 个 Agent 系统。
收藏好。它能帮你省下几个月的时间。
没人提起的真正问题
那种看似高效实则无效的循环：
→ 让 Claude 构建一个功能 → 它生成代码 → 出问题了 → 把错误贴回去 → 它打补丁 → 又出别的问题 → 再问一遍
第一天：感觉像魔法。
第三十天：你花在监督 AI 上的时间比过去写代码的时间还多。
同样的逻辑出现在了三个不同的地方。
Claude 忘了你两周前设下的规范。
新功能搞坏了旧功能。
测试要么缺失要么浅薄。
你猛然醒悟：AI 没问题。
是你的工作流程有问题。
真正的问题是结构性的。
当你往 Claude Code 里输入“构建这个功能”时，你其实是在让一个 AI 会话同时扮演：
→ 产品分析师 → 架构师 → 后端工程师 → 前端工程师 → 测试工程师 → 代码审查员
全挤在一个混乱的对话里。
方案里的错误假设变成错误的数据库模型。
错误的数据库模型变成错误的 API。
错误的 API 变成错误的 UI。
等你发现时，错误已经蔓延到了每个角落。
这叫做氛围编码（vibe coding）。
而且它有一个硬天花板。
转型：从氛围编码到软件工厂
真正改变一切的是什么：
真正的工程团队不会靠一场大对话来工作。
不同的人负责不同的事：
→ 有人澄清用户问题 → 有人思考架构 → 有人构建 API → 有人构建 UI → 有人思考边界情况 → 有人审查
当你把所有这些压缩到一个 AI 会话里时，错误就会悄悄叠加。
解决办法是把工作分给 专门的 Agent。
每个 Agent 负责：→ 一个明确的任务 → 自己干净的上下文窗口 → 只有它真正需要的工具 → 严格的权限限制，不能碰不该碰的东西
结果就是：一个软件工厂。
一个开发者 + 七个专注的 Agent = 一个协同团队。
以下是让这套机制运作起来的七个 Agent。
7 个 Agent
Agent 1：代码库研究员
开发者使用 AI 时犯的最大错误是什么？
上来就要代码。
AI 接受提示，靠猜测填补空白，然后开始生成。
糟糕的设计就这样悄悄溜进来了。
代码库研究员解决了这个问题。
它唯一的工作是：在写一行代码之前，先检查代码库并解释一切是如何运作的。
它做的事情：→ 映射相关文件及其角色 → 记录现有模式供后续遵循 → 查找已经构建过的类似功能 → 标记风险（时区、多租户、重试逻辑） → 列出需要更新的测试
它不能做的事情：→ 编辑文件（只读权限） → 运行任何会修改状态的命令 → 做假设——它会问而不是猜
工具：仅限 Read、Grep、Glob。
规则：先探索再构建，每次如此。
研究员先跑。永远如此。
Agent 2：故事撰写者
大多数功能失败的原因不是代码写错了。
而是问题从未被清晰定义过。
故事撰写者会在任何技术决策做出之前，把一个粗略的功能想法变成真实的用户故事。
它收到的输入：→ 你粗略的功能描述 → 研究员的发现结果
它产出的内容：
一个用户故事： “作为一个 [角色]，我想要 [行为]，以便 [结果]。”
验收标准： 测试可以直接验证的陈述。正常路径。失败路径。业务规则。
边界情况： 边界、重试、多租户问题。
不在范围内： 明确声明不构建什么。
未决问题： 它确实不知道的事情——从不猜测。
它不能做的事情：→ 发明业务规则 → 写任何代码或技术设计 → 在真正不清楚的情况下继续推进
工具：仅限 Read。
规则：你先读这个故事，批准它，然后才能进行其他操作。
这是能拯救后续所有环节的人为检查点。
Agent 3：规格编写者
故事批准后，规格编写者把它变成一份技术简报。
这是所有构建 Agent 都会遵循的蓝图。
它收到的输入：→ 你批准的用户故事 → 研究员的发现结果 → 你项目的 CLAUDE.md 规则
它产出的内容：
→ 数据模型变化（字段、类型、迁移） → 后台流程 / 处理流程 → API 变化（端点、请求/响应结构） → 前端变化（组件、页面、钩子） → 需要编写的测试（成功、失败、边界情况） → 风险和未决问题 → 每一个将要变更的文件
它不能做的事情：→ 编辑任何文件 → 发明新的基础设施——而是明确指出来 → 跳过租户隔离或时区问题 → 留下未回答的问题
工具：仅限 Read、Grep、Glob。
规则：这份简报是第二个检查点。
你读它，批准它，然后才能动任何一个文件。
如果你看到“把 ID 存在内存里”——那就是你的危险信号。
现在就抓住它。不要在改了 10 个文件之后才发现。
Agent 4：后端构建者
现在开始构建。
后端构建者实现功能的后端部分——而且只做后端部分。
它收到的输入：→ 批准的技术简报 → 研究员的发现结果 → 你项目的 CLAUDE.md
它构建的内容：→ API 路由 → 服务和业务逻辑 → 数据库访问和迁移 → 后台任务 → 它写的每段代码的单元测试
它不能做的事情：→ 碰 React 组件、页面或客户端钩子（那是 Agent 5 的活） → 未经指示就添加新依赖 → 修改约定范围之外的文件 → 在运行类型检查、lint 和测试套件之前停下来
完成后，它返回一份总结：→ 添加或修改的每个文件 → 复用的每个现有辅助函数或模式 → 任何本应添加到 CLAUDE.md 的规则
工具：Read、Edit、Write、Bash——只限于后端文件夹。
分离的意义就在这里。
后端构建者永远不会意外搞坏前端。
Agent 5：前端构建者
前端构建者实现 UI 部分——而且只做 UI 部分。
它先读后端构建者的总结。
这一点很重要。
它消费的 API 完全按照后端产出的样子。
它不会发明新端点。
如果 API 的形状对 UI 不合适，它会作为反馈指出差异——而不是偷偷打补丁。
它收到的输入：→ 批准的技术简报 → 研究员的发现结果 → 后端构建者的总结（API 契约）
它构建的内容：→ React 组件和页面 → 客户端钩子和状态 → 加载和错误状态 → 它写的每段代码的组件测试和单元测试
它不能做的事情：→ 碰服务、API 路由、工作进程或迁移（那是 Agent 4 的活） → 发明端点或响应结构 → 未经指示就添加依赖 → 在运行类型检查、lint 和测试套件之前停下来
工具：Read、Edit、Write、Bash——只限于前端文件夹。
两个构建者。
两个干净的上下文窗口。
零概率一个搞坏另一个的工作。
Agent 6：测试验证者
两个构建者都为各自的代码写了单元测试。
但这还不够。
测试验证者只做一件事：证明这个功能确实能实现用户故事所说的效果。
它写的是验收测试。
不是单元测试。
是验收测试。
这些测试从外部检验功能——就像真实用户会体验的那样。
它收到的输入：→ 批准的用户故事（包含所有验收标准） → 批准的技术简报 → 两个构建者的总结
它产出的内容：→ 一个验收测试文件，覆盖每一个验收标准 → 一份报告：哪些标准通过了，哪些失败了，哪些无法干净地覆盖
它不能做的事情：→ 修改任何后端或前端代码 → 为不可测试的标准发明变通方案 → 把实际上未覆盖的标准标记为已覆盖
如果测试失败：功能不满足故事的要求。
它会精确报告哪个标准失败了。
它不会去修补代码。
修复工作回到对应的构建者那里。
工具：Read、Edit、Write（仅限于测试文件）、Bash。
规则：验收测试通过之前，你不算有了这个功能。
Agent 7：实现验证者
这是那个能抓住所有其他人遗漏问题的 Agent。
验证者把当前的实现与批准的故事和简报进行对比——然后报告差异。
它从不修任何东西。
它只是说出事实。
每次运行时它都会检查：
→ 故事中尚未实现的验收标准 → 没有测试覆盖的失败路径 → 安全问题：缺失的认证检查、租户隔离漏洞、日志中的秘密、暴露给客户端的原始错误 → 在约定范围之外被修改的文件 → 与 CLAUDE.md 或现有代码不一致的模式 → 应该复用现有辅助函数的重复逻辑 → 简报中悄悄遗漏的时区或多租户问题
输出总是按严重程度分组：
Critical（严重）——合并前必须修复
Important（重要）——合并前应该修复
Minor（次要）——基于意见，由审查者决定
每个发现都包含文件路径和行号。
如果没有任何问题，它会直说。
它不会为了显得全面而编造问题。
工具：Read、Grep、Glob 仅限。
这个 Agent 就是为什么这套工厂值得信赖。
一份自己批改的试卷毫无价值。
一个只看到磁盘上有什么——而不是代码是怎么写出来的——的验证者才是诚实的。
整个链条如何运作
完整流程——一个提示就能启动一切：
你打开 Claude Code 输入：
“为超过 7 天未支付的发票构建发票提醒功能。”
接下来发生的事情，你不需要再输入任何内容：
第 1 步 → 研究员 映射你的发票、支付和邮件相关代码。返回相关文件、现有模式、风险。
第 2 步 → 故事撰写者 生成用户故事和验收标准。
⏸ 暂停：你阅读并批准故事。
第 3 步 → 规格编写者 把批准的故事变成技术简报。
⏸ 暂停：你阅读并批准简报。（就在这里抓住那个“把 ID 存在内存里”的错误。）
第 4 步 → 后端构建者 实现服务、API 路由、BullMQ 任务和单元测试。返回：修改的文件、复用的模式、所有测试通过。
第 5 步 → 前端构建者 读取后端构建者的 API 总结，构建管理 UI 面板和提醒按钮，编写组件测试。所有测试通过。
第 6 步 → 测试验证者 为所有六条验收标准编写验收测试。报告：7 个通过，1 个失败——手动触发没有检查租户所有权。
第 7 步 → 验证者 发现这个问题。报告为 Critical，附有文件路径和行号。
→ 循环回到后端构建者。 修复应用。全部 8 个验收测试通过。验证者再次运行。干净通过。
⏸ 暂停：你审查并打开 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 路由保持精简。”）
→ 不要做什么（“不要添加 cron——用 BullMQ。不要记录原始支付负载。”）
→ 指向更深层文档的链接（docs/billing.md、docs/architecture.md）
保持 100-300 行。
每次 AI 犯了让你意外的错误，就问自己：CLAUDE.md 里加一条规则能不能防止这个问题？
加上规则。
几周后，你的 CLAUDE.md 就会变成 AI 犯过的每个错误假设的记录——你的会话质量也会明显提升。
上下文漂移——无声的杀手：
大多数 Claude Code 会话不会戏剧性地失败。
它们会慢慢漂移。
一个错误假设进入了上下文。
模型在此基础上继续构建。
你让 Claude 构建订阅管理。
它设计成：User → Subscription。
你记起来：订阅属于公司，而不是用户。
如果你只说“不，订阅属于公司”——Claude 会打补丁。
现在你的代码里同时飘着 user.subscriptionId 和 company.subscriptionId。
规则：
→ 小拼写错误？直接修改就行。
→ 架构假设错了？扔掉这个会话，用正确的假设重新开始，把它写进第一个提示里。
一个带着正确心智模型的干净会话，永远比打过补丁的会话强。
结果：实际改变了什么
工厂模式之前：
→ 氛围编码循环：提示 → 生成 → 错误 → 修补 → 重复
→ 会话上下文中堆满噪音
→ 错误假设堆积成破碎的功能
→ 一个工程师一次只能做一件事
→ 每个功能都要等合适的人有空
工厂模式之后：
→ 结构化的链条：研究 → 故事 → 简报 → 构建 → 验证 → 确认
→ 每个 Agent 拥有干净的上下文窗口，只包含它需要的内容
→ 错误假设在简报批准阶段就被抓住——而不是在改了 10 个文件之后
→ 一个工程师交付一个完整的垂直切片：后端、前端、测试、验证
→ 团队的最佳知识存在于 Agent 中——而不是困在人们的大脑里
真正的转变：
支付专家构建了一个支付集成 Agent。
现在团队里的每个工程师都能交付一个涉及计费的功能。
无需等待。
无需交接。
前端主管的组件模式存在于前端构建者 Agent 里。
DevOps 工程师的 CI 检查存在于一个钩子里。
QA 主管的边界情况存在于测试验证者的规则里。
专家知识，以 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 会写出文件。你审查并提交。
5. 创建 feature-factory 编排技能。让 Claude 来写——它会读取你的 7 个 Agent 文件并串联整个链条。
6. 创建 build-with-tests 技能。描述你的团队如何构建：匹配现有模式、测试与代码一同编写、最后运行类型检查。
7. 添加一个 pre-commit 钩子。阻止提交包含 .env、.key、.pem 或 secrets.json 文件的提交。只需 5 分钟。能防止灾难。
8. 用完整链条跑一个真实的功能。选一个小功能。观察哪里卡住了。添加规则。工厂会自我调优。
总时间：2-3 小时。
然后跑几个功能。
3-4 次之后，工厂就熟悉你的代码库了。
你会花更少的时间监督。
更多的时间决定接下来构建什么。
7 个 Agent —— 快速参考
→ 研究员 —— 在构建任何东西之前映射代码（仅 Read）
→ 故事撰写者 —— 把想法变成带有验收标准的用户故事（仅 Read）
→ 规格编写者 —— 把故事变成技术简报（仅 Read）
→ 后端构建者 —— 构建 API、服务、任务、单元测试（仅限于后端文件夹）
→ 前端构建者 —— 构建组件、页面、钩子、UI 测试（仅限于前端文件夹）
→ 测试验证者 —— 根据用户故事编写验收测试（仅限于测试文件）
→ 验证者 —— 把实现与故事和简报对比，报告差异（仅 Read）
3 个人为检查点：
→ 批准故事
→ 批准简报
→ 批准 PR
其他一切都自动运行。
大多数使用 Claude Code 的开发者仍在做氛围编码。
提示 → 生成 → 修补 → 祈祷。
这没有错。
但它有一个天花板。
工厂模式不是把你从流程中移除。
而是把你从不需要你的部分中移除。
你留在那些需要你判断力的环节中：
这是正确的问题吗？这是正确的设计吗？这个可以安全上线吗？
Agent 处理中间的所有事务。
这就是把 AI 当作更快键盘的区别——
和把 AI 当作一个协同团队的区别。
如果这篇文章对你有用：
→ 转发分享给你的朋友
→ 关注 @sairahul1 获取更多类似的分析
→ 收藏起来——你会想回头查阅这 7 个 Agent
我写关于 AI、产品构建以及你睡觉时也能运行的系统。
