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

作者 @sairahul1 拆解了从「Vibe Coding」升級到「软體工廠」的工作流革命：把單一 AI 对話拆成 7 个專责代理人：研究員、故事撰寫者、規格撰寫者、后端建造者、前端建造者、測試验证者、实作验证員，每个只擁有單一職责、乾淨的上下文与嚴格边界。
（前情提要：串聯万物的 MCP 加上 Web3，能成下一波 AI 百倍敘事嗎？）
（背景補充：最強投资大師幫你打工！集結巴菲特、蒙格、Cathie Wood…19 个 AI Agent 幫你分析市场）

本文目錄

Toggle

• 沒有人在談的那个问題
• 转折:从 Vibe Coding 到软體工廠
• 七个代理人
  • 代理人 1:程式碼庫研究員(Codebase Researcher)
  • 代理人 2:故事撰寫者(Story Writer)
  • 代理人 3:規格撰寫者(Spec Writer)
  • 代理人 4:后端建造者(Backend Builder)
  • 代理人 5:前端建造者(Frontend Builder)
  • 代理人 6:測試验证者(Test Verifier)
  • 代理人 7:实作验证員(Implementation Validator)
• 整條链是怎麼跑的
• 基礎:代理人能运作之前,你需要这个
  • CLAUDE.md ── 存活於每个对話的記憶
  • 上下文漂移 ── 那个无聲的殺手
• 結果:真正改變的是什麼
  • 工廠之前:
  • 工廠之后:
  • 真正的转變:
• 这个週末就做出你自己的版本
  • 8 步设置清單:
• 七个代理人 ── 快速參考

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

这篇要说的就是两者的差異——以及徹底改變一切的「7 代理人系统」。

把这篇存下来。它会幫你省下好幾个月。

沒有人在談的那个问題

那个看起来很有产能、其实沒有的循環:

→ 要 Claude 幫你做一个功能 → 它生出程式碼 → 某个地方壞了 → 把错誤訊息貼回去 → 它修補 → 又壞了另一个地方 → 再问一次

第 1 天:这像魔法。

第 30 天:你花在監督 AI 的时间,比过去自己寫程式还多。

同樣的逻辑出现在三个不同的地方。Claude 忘了你两週前訂下的慣例。新功能弄壞舊功能。測試不是缺少就是寫得很淺。

你某天醒来才意识到:不是 AI 在失敗,是你的工作流在失敗。

问題的本质是結構性的。

当你在 Claude Code 裡输入「幫我做这个功能」,你其实是在要求一个 AI 对話同时扮演:

→ 产品分析師 → 架構師 → 后端工程師 → 前端工程師 → 測試工程師 → 程式碼審查員

全部一次到位。在同一个一團亂的对話裡。

计畫裡错的假设,会變成错的资料庫模型。错的资料庫模型,会變成错的 API。错的 API,会變成错的 UI。

等你发现时,错誤已经擴散到處都是。

这就是所謂的 vibe coding(憑感覺寫程式)。

它有一道很硬的天花板。

转折:从 Vibe Coding 到软體工廠

真正改變一切的关鍵:

真正的工程團队,不会在一个大型对話裡工作。

不同的人擁有不同的工作:

→ 有人釐清使用者问題 → 有人思考架構 → 有人寫 API → 有人寫 UI → 有人思考边界情況 → 有人做審查

当你把所有这些塌縮成一个 AI 对話,错誤就会悄悄地累加。

修正之道,是把工作拆給專门化的代理人。

每一个代理人会得到:

→ 一个聚焦的工作 → 自己乾淨的上下文視窗 → 只擁有它真正需要的工具 → 对它「不可碰觸的範圍」有嚴格規則

結果:一座软體工廠。

一个开发者 + 七个聚焦的代理人 = 一支協调的團队。

以下就是让这件事运作的七个代理人。

七个代理人

代理人 1:程式碼庫研究員(Codebase Researcher)

开发者用 AI 时最大的错誤是什麼?

把「要程式碼」当成第一步。

AI 接受 prompt,做出猜測去填補空白,然后开始生成。糟糕的设计就是在这时偷偷溜进来。

研究員修正这件事。

它唯一的工作:檢視程式碼庫並解釋现況——在一行程式被寫下来之前。

它做什麼:

• 標出相关檔案与它們的角色
• 記錄既有需要遵循的模式
• 找出已经建过的類似功能
• 標示风险(时区、多租戶、重試逻辑)
• 列出哪些測試会需要更新

它不能做什麼:

• 編辑檔案(只有读取權限)
• 執行任何会改變狀態的指令
• 做假设——它应該改成发问

工具: Read、Grep、Glob,僅此而已。

規則: 每一次,在动工之前都要先探索。

研究員永远先跑。

代理人 2:故事撰寫者(Story Writer)

大部分功能失敗,並不是因为程式碼错了。

而是因为问題从来沒有被清楚定義。

故事撰寫者把粗略的功能構想,變成一个真正的使用者故事——在任何技術決策被做出之前。

输入:

• 你的粗略功能描述
• 研究員的调查結果

产出:

• 一个使用者故事:「作为 [角色],我想要 [行为],这樣 [結果]。」
• 验收標準:可以被測試直接验证的敘述。Happy path、失敗路徑、商业規則。
• 边界情況:边界、重試、多租戶顾慮。
• 不在範圍內:什麼是明確「不会做」的。
• 未解问題:它真心不知道的东西——絕不亂猜。

它不能做什麼:

• 发明商业規則
• 寫任何程式碼或技術设计
• 在有东西真心不清楚时继续推进

工具: Read,僅此而已。

規則: 你要读过这份故事並核准,才会发生下一件事。

这是让下游一切都不出错的关鍵——人類審核点 1。

代理人 3:規格撰寫者(Spec Writer)

故事核准之后,規格撰寫者把它變成一份技術簡报。

这份簡报就是每个建造代理人会遵循的藍圖。

输入:

• 你核准过的使用者故事
• 研究員的调查結果
• 你專案的 CLAUDE.md 規則

产出:

• 资料模型變动(欄位、型別、迁移)
• 背景流程 / 處理流程
• API 變动(端点、request/response 格式)
• 前端變动(元件、頁面、hooks)
• 需要的測試(成功、失敗、边界)
• 风险与未解问題
• 每一个会被改动的檔案

它不能做什麼:

• 編辑任何檔案
• 发明新的基礎设施——而是要明確指出
• 跳过租戶隔离或时区考量
• 留下沒有答案的问題

工具: Read、Grep、Glob,僅此而已。

規則: 这份簡报是人類審核点 2。

你读过、核准,才会有任何一个檔案被动。

如果你看见「把 ID 存在記憶體裡」——那就是紅旗。

现在抓出来。不要等到 10 个檔案被改完。

代理人 4:后端建造者(Backend Builder)

现在才开始建造。

后端建造者实作功能的「后端那一半」——而且只负责后端那一半。

输入:

• 核准的技術簡报
• 研究員的调查結果
• 你專案的 CLAUDE.md

它建造:

• API 路由
• Services 与商业逻辑
• 资料庫存取与迁移
• 背景任務
• 它所寫东西的單元測試

它不能做什麼:

• 碰任何 React 元件、頁面或 client-side hooks(那是代理人 5 的工作)
• 在沒有指示下发明新依賴
• 修改範圍外的檔案
• 沒跑 typecheck、lint 与測試套件就停下

完成后,它会回傳一份摘要:每个新增或編辑的檔案、每个被重用的既有 helper 或模式、任何「如果有 CLAUDE.md 規則会更好」的觀察。

工具: Read、Edit、Write、Bash——只限后端资料夾。

重点就在分离本身。

后端建造者永远不可能不小心弄壞前端。

代理人 5:前端建造者(Frontend Builder)

前端建造者实作 UI 那一半——只负责 UI 那一半。

它会先读后端建造者的摘要。

这很重要。

它会依照后端产出的樣子去使用 API。它不会发明新的端点。

如果 API 的形狀对 UI 而言是错的,它会把不符回报出来——而不是自己打補丁。

输入:

• 核准的技術簡报
• 研究員的调查結果
• 后端建造者的摘要(API 合约)

它建造:

• React 元件与頁面
• Client-side hooks 与狀態
• Loading 与 error 狀態
• 它所寫东西的元件与單元測試

它不能做什麼:

• 碰 services、API 路由、workers 或迁移(那是代理人 4 的工作)
• 发明端点或回应格式
• 在沒有指示下加依賴
• 沒跑 typecheck、lint 与測試套件就停下

工具: Read、Edit、Write、Bash——只限前端资料夾。

两个建造者。两个乾淨的上下文視窗。零机率一个会弄壞另一个的工作。

代理人 6:測試验证者(Test Verifier)

两个建造者都幫自己寫了單元測試。

那不夠。

測試验证者只做一件事:证明这个功能真的做了使用者故事说它要做的事。

它寫的是「验收測試」(acceptance tests),不是單元測試。

验收測試从外部測試功能——就像一个真实使用者会去體验它的方式。

输入:

• 核准的使用者故事(包含所有验收標準)
• 核准的技術簡报
• 两个建造者的摘要

产出:

• 一份覆蓋每个验收標準的验收測試檔
• 一份报告:哪些通过、哪些失敗、哪些无法乾淨覆蓋

它不能做什麼:

• 修改任何后端或前端程式碼
• 为无法測試的標準发明繞道方案
• 把实际沒覆蓋到的標準標为已覆蓋

如果一个測試失敗:这个功能就不滿足故事。

它会回报「哪一條標準失敗了」。它不会去修補程式碼。

修補会被丟回正確的建造者那边。

工具: Read、Edit、Write(僅測試檔)、Bash。

規則:在验收測試通过之前,你还沒有这个功能。

代理人 7:实作验证員(Implementation Validator)

这是那个会抓出大家漏掉的东西的代理人。

验证員会把目前的实作,对照核准的故事与簡报,回报落差。

它从不修任何东西。它只说真話。

每一次它会跑的檢查:

• 故事的验收標準有沒有还沒实作的
• 沒有測試覆蓋的失敗路徑
• 安全议題:缺漏的權限檢查、租戶隔离漏洞、log 裡的密鑰、原始错誤外洩到 client
• 範圍外被改动的檔案
• 与 CLAUDE.md 或既有程式碼不一致的模式
• 应該重用既有 helper 卻被寫成重複逻辑的地方
• 簡报中被悄悄跳过的时区或多租戶考量

输出永远按嚴重度分組:

• Critical — 合併前必修
• Important — 合併前应修
• Minor — 偏意见,審查者自己決定

每一个发现都会附上檔案路徑与行號。

如果沒有问題,它就直接说沒问題。它不会为了顯得认真而发明问題。

工具: Read、Grep、Glob,僅此而已。

这个代理人,是让整座工廠值得信任的原因。

自評的成績單沒有价值。一个只看「磁碟上有什麼」、不看「怎麼被寫出来」的验证員,才是誠实的。

整條链是怎麼跑的

完整流程——一个 prompt 啟动一切:

你打开 Claude Code,输入:

「幫我做『超过 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。

三个人類審核点。其他都自己跑。

基礎:代理人能运作之前,你需要这个

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)
• 架構規則(「商业逻辑放在 services。API 路由保持薄。」)
• 不要做的事(「不要加 cron——用 BullMQ。不要把原始付款 payload 寫进 log。」)
• 深入文件的指標(docs/billing.md、docs/architecture.md)

保持在 100–300 行。

每次 AI 犯了一个让你驚訝的错誤,问自己:「如果 CLAUDE.md 裡有一條規則,这次能避免嗎?」

把規則加进去。

幾週后,你的 CLAUDE.md 就会變成「AI 曾经弄错的所有假设」的記錄——你的对話会明顯變得更好。

上下文漂移 ── 那个无聲的殺手

大部分 Claude Code 对話不会戲劇性地失敗。

它們会漂移。

一个错的假设进入上下文。模型继续往上面疊。

你要 Claude 做「訂阅管理」。它设计:User → Subscription。

你后来才想起:訂阅屬於「公司」,不是「使用者」。

如果你只说「不对,訂阅屬於公司」——Claude 会打補丁。

现在你就有了同时飄在四處的 user.subscriptionId 与 company.subscriptionId。

規則:

• 小错字?直接 inline 修正。
• 架構假设错了?把整个对話丟掉,从头开始,把对的假设烙进第一个 prompt。

一个有正確心智模型的乾淨对話,永远勝过一个打了補丁的对話。

結果:真正改變的是什麼

工廠之前:

• Vibe coding 循環:prompt → 生成 → 错誤 → 補丁 → 重複
• 对話的上下文塞滿雜訊
• 错的假设累積成壞掉的功能
• 一个工程師一次只能做一件事
• 每个功能都在等对的人有空

工廠之后:

• 結構化的链:研究 → 故事 → 簡报 → 建造 → 验证 → 確认
• 每个代理人擁有乾淨的上下文,只裝它需要的东西
• 错的假设在「簡报核准」就被抓出——不是 10 个檔案之后
• 一个工程師可以出一个完整的垂直切片:后端、前端、測試、验证
• 團队最好的知识住在代理人裡——不被困在「某个人」身上

真正的转變:

付款專家做一个 payments-integration 代理人。从那一刻起,團队每一个工程師都能出帶帳務的功能。不必等待,不必交接。

前端 lead 的元件模式,住在 frontend-builder 代理人裡。DevOps 工程師的 CI 檢查,住在 hook 裡。QA lead 的边界情況,住在 test-verifier 規則裡。

專家知识,以代理人的形式被共享。不被困在「誰有空」这件事裡。

这个週末就做出你自己的版本

8 步设置清單:

2. 安裝 Claude Code → code.claude.com

3. 建立资料夾結構:

   • .claude/agents/
   • .claude/skills/feature-factory/
   • .claude/skills/build-with-tests/
   • .claude/hooks/

4. 寫你的 CLAUDE.md(100–300 行:技術棧、指令、架構規則、不要做的清單)

5. 用 Claude Code 的 /agents 指令建立 7 个代理人。描述每个代理人的角色。Claude 寫檔案。你審查並 commit。

6. 建立 feature-factory orchestrator skill。叫 Claude 幫你寫——它会读你 7 个 agent 檔並接好整條链。

7. 建立 build-with-tests skill。描述你的團队怎麼建造:对齐既有模式、边寫程式边寫測試、最后跑 typecheck。

8. 加一个 pre-commit hook。擋住把 .env、.key、.pem 或 secrets.json 提交进去。5 分鐘搞定,可以避免大型災难。

9. 跑一个真实的功能走完整條链。挑一个小的。觀察它在哪裡卡住。加規則。工廠会自己调整。

總时间:2–3 小时。

跑个幾个功能。3–4 个之后,工廠就认识你的程式碼庫了。

你会花更少时间監督,更多时间決定「接下来要做什麼」。

七个代理人 ── 快速參考

• 研究員(Researcher) — 在任何东西被造之前先掃过程式碼(只读)
• 故事撰寫者(Story Writer) — 把構想變成使用者故事与验收標準(只读)
• 規格撰寫者(Spec Writer) — 把故事變成技術簡报(只读)
• 后端建造者(Backend Builder) — 建造 API、services、jobs、單元測試(只限后端资料夾)
• 前端建造者(Frontend Builder) — 建造元件、頁面、hooks、UI 測試(只限前端资料夾)
• 測試验证者(Test Verifier) — 对使用者故事寫验收測試(只限測試檔)
• 验证員(Validator) — 拿实作对照故事与簡报、回报落差(只读)

3 个人類審核点:

→ 核准故事 → 核准簡报 → 核准 PR

其他都自己跑。

---

大部分用 Claude Code 的开发者还在 vibe coding。Prompt → 生成 → 補丁 → 祈禱。

那不算错。但那有天花板。

工廠不是把你从流程裡踢出去。它是把你从「不需要你判斷」的部分裡踢出去。

你会留在那些「你的判斷真正重要」的環節裡:

这是对的问題嗎?这是对的设计嗎?这个可以安全上線嗎?

中间的所有事情,代理人负责。

这就是「把 AI 当成更快的鍵盤」和「把 AI 当成一支協调團队」的差別。

原文作者：@sairahul1