个人知识库

2026-05-31-232613-tg-6eed81

17分钟阅读

实战：手把手教你用 7 个 Agent 将 Vibe Coding 升级为专家级开发流程

BlockTempo 動區動趨 转载 @sairahul1 的实战长文：把「一个 AI 对话同时扮六个角色」的 Vibe Coding，拆成 7 个各持单一职责、干净上下文与严格工具边界的 Agent，串成 研究 → 故事 → 简报 → 建造 → 验证 → 确认 的软件工厂链，只留 3 个人类审核点。

基本信息

核心观点

  1. Vibe Coding 的天花板是结构性的，不是模型能力问题：当你在 Claude Code 里输入「帮我做这个功能」，等于要求同一个对话同时扮演 产品分析师 → 架构师 → 后端工程师 → 前端工程师 → 测试工程师 → 代码审查员。计划里错的假设会变成错的数据库模型，错的模型变成错的 API，错的 API 变成错的 UI——「等你发现时，错误已经扩散到到处都是」。原文的金句是「第 1 天：这像魔法。第 30 天：你花在监督 AI 的时间，比过去自己写代码还多」。

  2. 7 个 Agent 的隔离点不在「聪明」，而在工具权限边界：研究员 / 故事撰写者 / 规格撰写者 / 验证员 是只读（Read、Grep、Glob）；后端建造者只能碰后端文件夹；前端建造者只能碰前端文件夹；测试验证者只能写测试文件。结果是「后端建造者永远不可能不小心弄坏前端」——职责隔离直接消灭了交叉污染这一类错误。

  3. 3 个人类审核点是质量保险，其余全自动：核准用户故事（人类审核点 1）→ 核准技术简报（人类审核点 2）→ 核准 PR（人类审核点 3）。原文对这个设计的判断是「工厂不是把你从流程里踢出去，它是把你从『不需要你判断』的部分里踢出去」——人类只留下「这是对的问题吗？这是对的设计吗？这个可以安全上线吗？」。

  4. 上下文漂移是无声杀手，处理规则是「架构级错误必须丢对话重开」：大部分 Claude Code 对话不是戏剧性失败，而是漂移——一个错假设进入上下文，模型继续往上叠加。原文的例子：你要它做「订阅管理」，它设计成 User → Subscription；你后来才想起订阅属于「公司」而不是「用户」，如果只是说「不对，订阅属于公司」，Claude 会打补丁，于是 user.subscriptionId 与 company.subscriptionId 同时飘在四处。规则：小错字直接 inline 修正；架构假设错了，把整个对话丢掉从头开始，把对的假设烙进第一个 prompt。

  5. 专家知识以 Agent 的形式被共享，不再被困在「谁有空」：付款专家做一个 payments-integration Agent，此后团队每个人都能出带账务的功能；前端 lead 的组件模式住在 frontend-builder Agent 里；QA lead 的边界情况住在 test-verifier 规则里。原文的收束是「这就是『把 AI 当成更快的键盘』和『把 AI 当成一支协调团队』的差别」。

实操内容保留

代码/配置

（原文无代码块；以下为原文给出的目录结构与配置形态。）

.claude/agents/                      # 用 Claude Code 的 /agents 指令建立 7 个 Agent 定义文件
.claude/skills/feature-factory/       # orchestrator skill：串起整条链
.claude/skills/build-with-tests/      # 描述团队「怎么建造」的 skill
.claude/hooks/                        # pre-commit hook 等

CLAUDE.md 应包含的四类内容（原文示例，技术栈以 Next.js 项目为例）：

技术栈：Next.js App Router、Node.js、Prisma、BullMQ、Resend
指令：npm run dev / npm test / npx prisma migrate dev
架构规则：「商业逻辑放在 services。API 路由保持薄。」
不要做：「不要加 cron——用 BullMQ。不要把原始付款 payload 写进 log。」
深入档案的指标：docs/billing.md、docs/architecture.md

规模建议：保持在 100–300 行。每次 AI 犯了一个让你惊讶的错误，问自己「如果 CLAUDE.md 里有一条规则，这次能避免吗？」然后把规则加进去。

七个 Agent 规格（原文「它做什么 / 它不能做什么 / 工具」）

#Agent它做什么它不能做什么工具
1程式码库研究员标示相关档案与角色、记录既有模式、找出已建过的类似功能、标示风险（时区、多租户、重试逻辑）、列出需要更新的测试编辑档案、执行会改变状态的指令、做假设（应改成发问）Read、Grep、Glob
2故事撰写者产出使用者故事（「作为 [角色]，我想要 [行为]，这样 [结果]」）、验收标准、边界情况、不在范围内、未解问题发明商业规则、写任何程式码或技术设计、在真心不清楚时继续推进Read
3规格撰写者产出资料模型变动、背景流程、API 变动、前端变动、需要的测试、风险与未解问题、每一个会被改动的档案编辑任何档案、发明新基础设施、跳过租户隔离或时区考量、留下没有答案的问题Read、Grep、Glob
4后端建造者API 路由、Services 与商业逻辑、资料库存取与迁移、背景任务、单元测试；完成后回传档案变更摘要与「如果有 CLAUDE.md 规则会更好」的观察碰任何 React 元件/页面/client-side hooks、在没有指示下发明新依赖、修改范围外的档案、没跑 typecheck+lint+测试就停下Read、Edit、Write、Bash（只限后端资料夹）
5前端建造者React 元件与页面、client-side hooks 与状态、loading/error 状态、元件与单元测试；先读后端建造者的摘要，照 API 产出的样子去用碰 services/API 路由/workers/迁移、发明端点或回应格式、在没有指示下加依赖、没跑 typecheck+lint+测试就停下Read、Edit、Write、Bash（只限前端资料夹）
6测试验证者写验收测试（不是单元测试），覆盖每条验收标准；产出「哪些通过、哪些失败、哪些无法干净覆盖」的报告修改任何后端或前端程式码、为无法测试的标准发明绕道、把实际没覆盖到的标准标为已覆盖Read、Edit、Write（仅测试档）、Bash
7实作验证员对照核准的故事与简报报告落差，每次跑：未实作的验收标准、没有测试覆盖的失败路径、安全议题（缺漏的权限检查/租户隔离漏洞/log 里的金钥/原始错误外泄到 client）、范围外被改动的档案、与 CLAUDE.md 不一致的模式、应重用却重复的逻辑、被悄悄跳过的时区或多租户考量；输出按 Critical / Important / Minor 分组，每个发现附档案路径与行号修任何东西（只报告）；没有问题就说没有问题，不为了显得认真而发明问题Read、Grep、Glob

关键补充：前端建造者的规则是「如果 API 的形状对 UI 而言是错的，它会把不符回报出来，而不是自己打补丁」；测试验证者的规则是「在验收测试通过之前，你还没有这个功能」，失败时它回报哪条标准失败，修补丢回正确的建造者；验证员的规则是「自评的成绩单没有价值」。

操作步骤

8 步设定清单（原文给出的落地路径，总时间 2–3 小时）

  1. 安装 Claude Code → code.claude.com
  2. 建立资料夹结构（见上方代码/配置节的目录）
  3. 写你的 CLAUDE.md（100–300 行：技术栈、指令、架构规则、不要做的清单）
  4. 用 Claude Code 的 /agents 指令建立 7 个 Agent，描述每个 Agent 的角色；Claude 写档案，你审查并 commit
  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. 跑一个真实的功能走完整条链 —— 挑一个小的，观察它在哪里卡住，加规则

原文给的完整链路示例（prompt：「帮我做『超过 7 天未付的发票提醒』功能」）

  • Step 1 → 研究员扫过发票、付款与 email 程式码，回传相关档案、既有模式与风险
  • Step 2 → 故事撰写者产出使用者故事与验收标准；⏸ 暂停：你阅读并核准故事
  • Step 3 → 规格撰写者把核准的故事变成技术简报；⏸ 暂停：你阅读并核准简报（就在这裡抓出「把 ID 存在记忆体裡」的错）
  • Step 4 → 后端建造者实作 service、API 路由、BullMQ 任务与单元测试
  • Step 5 → 前端建造者读后端的 API 摘要，做出 admin UI 区块与提醒按钮，写元件测试
  • Step 6 → 测试验证者為六条验收标准写验收测试；回报 7 条通过、1 条失败——手动触发没有检查租户拥有权
  • Step 7 → 验证员以 Critical 等级回报，附档案路径与行号 → 回到后端建造者修好 → 8 条验收测试全绿 → 验证员再跑一次，干净
  • ⏸ 暂停：你审查并开 PR

关键概念

  • 7 Agent 软件工厂 — 本文的方法论主体，7 个 Agent 的职责/工具/边界矩阵与 3 个人类审核点
  • Vibe Coding — 被升级的起点，「凭感觉写程式」的单一对话模式及其天花板
  • Claude Code — 承载 /agents、skills、hooks 的执行环境
  • 上下文漂移 — 原文单列一节讨论的「无声杀手」，及「架构级错误丢对话重开」规则
  • CLAUDE.md 项目指令 — 存活于每个对话的「永久专案事实」，100–300 行为宜
  • 上下文工程 — 每个 Agent 只装它需要的东西，是对上下文预算的显式分配
  • 人机协同 — 3 个人类审核点的位置设计（核准故事 → 核准简报 → 核准 PR）
  • Multi-Agent 系统 — 本文是「多 Agent 分工 + 权限隔离」的一条具体工程实现路径
  • AI Agent 智能体 — 每个 Agent 的「它做什么 / 它不能做什么 / 工具」三件套定义

与其他素材的关联

  • 与 2026-05-31-blocktempo-7-agents-software-factory 的关系：同一篇原文（同一 URL）的另一版摘要页，由旧 raw（raw/articles/2026-05-31-blocktempo-7-agents-software-factory.md）消化而来；本页由 Telegram 补录 raw 消化，内容同源、侧重一致，互为镜像。
  • 与 2026-05-29-shawn-abu-claude-code-6-weeks 的关系：Shawn 用 6 周、约 1 万元、62,376 条消息交付 8.5 万行代码的应用，其四根支柱中的「CLAUDE.md 合同（273 行，每次踩坑加一条）」与本文「保持 100–300 行 + 每次惊讶的错误就加一条规则」是同一套做法的两个独立实践样本。
  • 与 2026-06-10-agent-engineering-guide、2026-06-13-juejin-50k-usd-ai-coding-lessons 的关系：都属「Agent 工程 / AI 编程失败经验」一脉，本文的独特贡献是给出了工具权限矩阵这一具体的隔离机制，而不只是流程建议。
  • 与 2026-06-03-youtube-multi-agent-accounting-pipeline 的关系：那条素材是财务场景的多 Agent 流水线实录，可与本文的 7 Agent 抽象设计对照看「抽象设计 vs 真实落地」。

原文精彩摘录

我以为我在用 AI 写程式。实际上，我只是打字打得比较快而已。

那个看起来很有产能、其实没有的迴圈：→ 要 Claude 帮你做一个功能 → 它生出程式码 → 某个地方坏了 → 把错误讯息贴回去 → 它修补 → 又坏了另一个地方 → 再问一次。第 1 天：这像魔法。第 30 天：你花在监督 AI 的时间，比过去自己写程式还多。同样逻辑出现在三个不同的地方。Claude 忘了你两週前订下的惯例。新功能弄坏旧功能。测试不是缺少就是写得很浅。你某天醒来才意识到：不是 AI 在失败，是你的工作流在失败。

如果你只说「不对，订阅属于公司」——Claude 会打补丁。现在你就有了同时飘在四处的 user.subscriptionId 与 company.subscriptionId。规则：小错字？直接 inline 修正。架构假设错了？把整个对话丢掉，从头开始，把对的假设烙进第一个 prompt。一个有正确心智模型的干净对话，永远胜过一个打了补丁的对话。

大部分用 Claude Code 的开发者还在 vibe coding。Prompt → 生成 → 补丁 → 祈祷。那不算错。但那有天花板。工厂不是把你从流程裡踢出去。它是把你从「不需要你判断」的部分裡踢出去。

相关页面

关系图谱

快速导航

反向链接