AIDive重點摘要
- 這套 playbook 的六個階段,每一階段都以一份提交進版本庫的產出物收尾(intent.md、spec.md、plan.md、PR、事故紀錄)。發表文章和 14 堂課程描述了整體形狀,但都沒有公布任何實測數字。
- 在一個真實的 Express + Prisma 專案上完整跑過一輪,整條鏈修好一個 bug 花了 11 min 31 s、$3.46;直接下提示只要 2 min 13 s、$0.70:耗時 ×5.2、成本 ×4.9,兩邊測試都是綠的。
- 真正的代價是閱讀:為了一個只改一行的 class 修正,產出了 5,488 字的文件,以每分鐘 200 字計算約 27 分鐘。這條鏈把寫作時間換成了閱讀時間。
- 六個階段中有三個在這個情境下划算:Plan(intent.md)、Build(plan mode + CLAUDE.md + TDD)、Deploy(REVIEW.md + hook)。Design 和持續 evals 對單人開發者不划算;Maintain 沒有實際執行。
- spec 階段自己指出了前提缺口:沒有任何組織層級的 skills,所以它從未對照品牌、安全或 UX 政策檢查過。playbook 假設這些 skills 早已寫好。
- 確定性的 gate 有效:PreToolUse hook 在 14 s 內以 exit 2 擋下了部署。而在 hook 觸發之前,模型已經先憑自己的判斷拒絕了一次。
測量結果說明了什麼
playbook 把這個轉變定調為「程式碼不再是瓶頸」,並要求每個階段都以一份提交的產出物收尾,從 intent.md 經過 spec.md 和 plan.md,到 PR 和事故紀錄,Maintain 階段則有控制區間 s1。課程提供了值得引用的具體數字:以 20 到 50 個真實任務作為 eval 測試集、REVIEW.md 中最多 5 個 nit、同時最多 2 到 3 個平行 session,以及「同樣的錯誤犯第二次,就寫進 CLAUDE.md」的規則 s2。最犀利的中立評論把每份產出物由誰起草、由誰驗收列成表格,並稱這份文件「全篇都是廠商說法」、「沒有任何地方有實測」 s4。
修正任務是一個真實的上游 bug:全新 clone 後執行 npx nx test api,開箱即有 1 個 suite 失敗(auth.service.test.ts,"TypeError: Cannot read properties of undefined (reading 'prototype')"),4 個通過,14 個測試為綠,2.2 s。直接路徑在 2 min 13 s、$0.70、40 turns 內讓測試全綠。鏈式路徑,即 intent、spec、plan 再 build,同樣達到全綠,花了 11 min 31 s、$3.46、169 turns。光是機器這一側,就是耗時 ×5.2、成本 ×4.9 s2。
人這一側才是這條鏈傷人的地方。它產出了 5,488 字要讀的文件(intent 558 + spec 2,167 + plan 2,763),以每分鐘 200 字計算約 27 分鐘,而這個修正直接審查的負擔只是一個小小的 diff s4。功能任務(靜音作者)走完整條鏈花了 15 min 13 s、$4.11、158 turns,交付了帶 migration 的 Prisma Mute model、靜音與取消靜音的 endpoint、feed 過濾,共 15 個檔案 1,422 行新增,50 個測試為綠,其中 3 個新增或擴充的測試檔,外加一份 e2e spec。它的產出物共 6,852 字(intent 450 + spec 2,337 + plan 4,065),閱讀約需 34 分鐘 s2。
對 Design 階段的質疑經得起檢驗。LinkedIn 上的批評指出,playbook 隱藏了它的前提:品牌、安全與 UX 的組織 skills 必須事先存在,而且得有人知道怎麼帶 brainstorm s7。agent 在沒人提示的情況下自己證實了這點。spec.md 標記的疑慮 C0 原文如下:"No org skills available. … This spec has therefore not been checked against brand, security or UX policy." 一份超過 2,000 字、只是在複述程式碼庫又無法檢查政策的 spec,正是單人作業時該跳過的階段 s7。
對基礎設施的批評也成立。論點是,當測試打到過期的 fake 時,"the agent sees the tests pass and reports the work finished",因為產出物鏈記錄的是當初決定了什麼,而不是實際跑的是什麼 s8。在這次實驗中,迴圈只驗證了單元測試和 build;review 本身把 nx e2e 列為 "Not run: needs a running server and a seeded DB",把 prisma migrate status 列為 "Not run: needs a DB"。這個綠色的迴圈從未碰過任何線上系統 s8。
Deploy 階段是最便宜的收穫。REVIEW.md 跑了 117 s、花 $0.80:nx test(5/5 個 suite,50 個通過)、nx build(通過)、對照 plan 基準線的 lint 差異(34 對 33,多出的 +1 已被 plan 項目 A3 明確允許),以及 prettier 檢查(9 個檔案失敗,記為 nit N1)。結論:0 個 Important、6 個 nit,其中 5 個列出,1 個因上限而只做摘要。這次 review 拒絕核准自己的工作,說的是 "this agent does not approve",正是課程所寫的職責分離 s2。hook gate 的表現和文件描述的一致:要求在 merge 之前部署時,agent 憑自己的判斷拒絕了、沒有執行腳本,所以 hook 根本沒觸發。merge 之後,部署嘗試被 PreToolUse hook(exit 2)在 14 s 內擋下,並帶出 gate 的訊息 s19。
Evals 寫起來便宜,但很容易寫錯。5 個案例從 git 歷史中產生,花了 283 s、$1.44。兩次執行都跑在錯誤的 base 上,因為 runner 是在修正已 merge 之後才建立分支的,兩個 agent 都察覺了("the bug was already fixed here"),沒有假裝通過。一次 eval 執行約需 60 到 70 s,所以以 playbook 自己建議的 20 到 50 個案例計算,每次 CI 執行大約要 20 到 55 分鐘的 agent 時間 s2。CLAUDE.md 的設定花了 63 s、$0.44,產出一頁提交的文件,是所有做法中最便宜的;一次唯讀的 CI log 分類在 11 s、$0.13 內指出了正確原因 s2。
社群討論串帶進了更廣的遙測數據:在 10,000 名開發者身上,高度使用 AI 的團隊 merge 的 PR 多 98%,但 review 時間增加 91%,PR 大小增加 154% s6。
測量數據
測試方式:整條鏈以 headless 模式執行(claude -p,模型 claude-opus-5-5,權限限定為 acceptEdits 加上 allowlist,--setting-sources project,local),跑在 gothinkster/node-express-realworld-example-app 的暫存 clone 上(Express + TypeScript + Prisma + Docker 中的 Postgres 16,Nx workspace)。每個階段都有計時並記錄到 exp/metrics.jsonl(17 列)。總計:$11.90 加上重跑 hook 的 $0.14,539 + 3 turns,約 41 分鐘的 agent 耗時。
| 階段 | 耗時 | Turns | 成本 |
|---|---|---|---|
| CLAUDE.md 設定(第 5 課) | 63 s | 27 | $0.44 |
| FIX 直接(不走鏈) | 133 s | 40 | $0.70 |
| FIX intent.md | 39 s | 8 | $0.22 |
| FIX spec.md | 162 s | 39 | $0.83 |
| FIX plan.md | 180 s | 46 | $1.00 |
| FIX build | 310 s | 76 | $1.40 |
| FEAT intent.md | 29 s | 6 | $0.18 |
| FEAT spec.md | 118 s | 20 | $0.62 |
| FEAT plan.md | 240 s | 41 | $1.17 |
| FEAT build (TDD) | 526 s | 91 | $2.14 |
| Review (REVIEW.md) | 117 s | 19 | $0.80 |
| Hook 示範(被拒絕) | 20 s | 5 | $0.14 |
| Hook 示範(被擋下) | 14 s | 3 | $0.14 |
| CI 分類(唯讀) | 11 s | 3 | $0.13 |
| Evals:撰寫 5 個案例 | 283 s | 76 | $1.44 |
| Eval 執行 1 / 執行 2 | 72 s / 59 s | 24 / 18 | $0.38 / $0.29 |
| Playbook 階段 | 結論 | 原因 |
|---|---|---|
| Plan (intent.md) | 保留 | 29 到 39 s,能浮現真正的未決問題,杜絕默默做出的架構選擇 |
| Design (spec.md) | 單人作業跳過 | 超過 2,000 字在複述程式碼庫;它的價值建立在不存在的組織 skills 上(它自己的 C0 標記) |
| Build (plan mode + CLAUDE.md + TDD 迴圈) | 保留 | 50 個測試為綠,偏離處有記錄,review 依靠了 plan |
| Test (持續 evals) | 暫時跳過 | 以 playbook 自己的規模,每次 CI 執行 20 到 55 分鐘;base commit 的紀律先出了問題 |
| Deploy (REVIEW.md + hooks) | 保留 | $0.80 的 review 帶真實檢查,外加 14 s 的確定性阻擋 |
| Maintain (控制區間) | 未證實 | 需要數週的正式環境遙測;只是推估,未實際執行 |
限制:一個專案、一位開發者、一天。團隊規模的做法沒有執行,headless 模式把訪談步驟壓縮成單一提示,而 eval 執行只計算每次執行的成本。
週一就做
- 為你的主要專案寫一頁 CLAUDE.md:build、test 和 lint 指令,加上 agent 上週犯的兩個錯誤。提交它。預算 63 s 的 agent 時間。
- 下一個不那麼瑣碎的任務之前,先要求產出 intent.md:目標、非目標、未決事項。回答完未決問題,再讓 agent 做計畫。除非你有組織政策 skills 可以對照,否則跳過 spec.md。
- 在 plan mode 加 TDD 迴圈下執行 build 階段,並要求 plan 記錄偏離處(D1、D2、...),讓 review 有東西可依靠。
- 加入一道 REVIEW.md 檢查,由全新的 session 執行,設定 nit 上限,並加上明確的 "this agent does not approve" 這一行。讓它跑測試、build、lint 差異和格式檢查。
- 設置一個確定性的 gate:當分支不是 main 時,對
deploy以 exit 2 結束的 PreToolUse hook。 - 信任綠色迴圈之前,在 review 底部列出它沒跑過的東西(e2e、migrations、任何需要線上 DB 的項目)。
- 測量你自己的 gate 代價:在同一個小 bug 上為直接路徑和鏈式路徑計時,然後算出你得讀的字數。
延伸閱讀
- 兩道 gate 的變體:一道對抗式 review gate(sdlc-gate),且只有兩個人工決策點,而非每個階段一個,是小團隊務實的形式 s12。
- 完整可安裝的鏈:intent、spec、plan 和 REVIEW 範本、gate 驗證器、eval runner 和控制區間偵測,如果你不想手工搭建骨架 s5。
- 先訪談再規劃:一次問一個問題比一次問一批好,而且 "AI agents don't ask clarifying questions. They assume." 這是一篇沒有計時數據的設定紀錄 s11。
- 為什麼一條固定的流程會被繞過:"a docs fix and a payments migration shouldn't travel the same path",而真正的流程會變得看不見。文中把這份 playbook 和 Kiro、GitHub Spec Kit 歸為一類 s9。
- 平台廠商會賣給你的缺口:從訊號到 intent 的收件、影響範圍路由、指標儀表板。 s13。
- 一家顧問公司自一月起在客戶團隊中實施了同樣形狀的流程(CRAFT),並坦承 "we don't yet have a formal answer for what a control band looks like" s10。
- 一個 intent.md 的實例(Select All 核取方塊),展示這個檔案的作用:把未決事項浮現出來,而不是讓 agent 默默替你選 s14。
來源
- The AI-Native SDLC Playbook (launch post), claude.com。為什麼值得讀:五分鐘掌握六階段形狀與提交產出物的規則。
- The AI-native SDLC playbook (course, 14 lessons), Claude Academy。為什麼值得讀:數字唯一出現的地方(20 到 50 個 eval 任務、5 個 nit 上限、2 到 3 個 session),免費且不需登入。
- The Committed-Artifact Chain, howardism.dev。為什麼值得讀:每份產出物由誰起草、由誰驗收,以及直言 playbook 裡沒有任何東西經過測量。
- bashebr/ai-native-sdlc, GitHub。為什麼值得讀:範本、gate 驗證器和 eval runner,可以直接安裝而不必自己寫。
- Anthropic published an AI-native SDLC playbook, r/ClaudeAI。為什麼值得讀:把 Faros 遙測數據(PR 多 98%、review 時間 +91%)帶進討論的串。
- The AI-native SDLC Playbook is basically "do everything you did before, but inside Claude", LinkedIn。為什麼值得讀:關於隱藏前提的論點,而 spec 階段自己證實了它。
- The AI-Native SDLC Starts With Your Infrastructure, MetalBear blog。為什麼值得讀:過期 fake 的問題,雖是廠商的口吻,但論點本身站得住腳。
- The AI-native SDLC won't be one process, worldprogramming.org。為什麼值得讀:反對所有變更都走同一條路的「繁文縟節」論點。
- Anthropic Wrote the AI-Native SDLC Playbook in August. We Wrote Ours in January., Substack。為什麼值得讀:一個獨立團隊得出同樣的形狀,並承認 Maintain 的缺口。
- AI-Native SDLC: First Try, kyle.pericak.com。為什麼值得讀:唯一親手實作、先訪談的首次嘗試,寫於 playbook 出現之前。
- TsCarpe/claude-sdlc-skills, GitHub。為什麼值得讀:帶有對抗式 review 步驟的兩道 gate 變體。
- Implementing the Anthropic AI-Native SDLC Playbook, Port blog。為什麼值得讀:playbook 遺漏事項的清單,可當作缺口地圖來讀。
- What Is intent.md in Claude Code?, dev.to。為什麼值得讀:一份可以照抄結構的具體 intent.md。
- Hooks guide, Claude Code docs。為什麼值得讀:帶 exit 2 的 PreToolUse hook 如何成為 playbook 所仰賴的確定性 gate。
FAQ
只改一行的修正,整條鏈有值得走的時候嗎?
在這次實驗中沒有:同樣是綠的結果,卻要耗時 ×5.2、成本 ×4.9,外加 5,488 字要讀。小任務只用 intent.md 就好。
為什麼單人作業時要跳過 spec.md?
spec 自己就標記了問題:沒有品牌、安全或 UX 的組織 skills,它無法檢查政策,還花了超過 2,000 字在複述程式碼庫。
Hook 會取代模型的判斷嗎?
不會,它是後盾。agent 自己拒絕了 merge 之前的部署;hook 則在 14 s 內以 exit 2 擋下了 merge 之後的嘗試。