AIDive沒人實測過的 playbook
Anthropic 發布了一份給 Claude Code 的 AI-native SDLC playbook:六個階段,每個階段都以一份已提交的檔案收尾,並做成免費課程開放學習。它的核心主張是,程式碼已經不再是瓶頸,真正管理瓶頸的是這條已提交產出物串成的鏈。但這份文件本身沒有任何量測,沒有時間、沒有成本、沒有基準測試。我們在一個真實的程式庫上做了第一次計時測試:十六次計時的 Claude Code 工作階段,每一道關卡都標上價格,最後的結論把這條鏈從中間劈成兩半。過程中,一個兩分鐘就能修好的 bug 走完整條鏈,讓我們量出了這套儀式的代價;而我們自己的部署也被擋了兩次,其中一次只靠四行 shell。
Playbook 與測試環境
測試環境:十六次計時的 Claude Code 工作階段、約 12 美元的運算費用、一個真實的程式庫。這份 playbook 分六個階段:規劃、設計、建置、測試、部署、維運。每個階段都以一份已提交的檔案收尾,下一個階段再讀這份檔案:intent、spec、plan、pull request、事故紀錄。這些 commit 就是稽核軌跡。Anthropic 把它做成免費的 14 堂課程,大約一小時,是為有審查關卡的企業寫的;我們測的是,當它遇上單一開發者時還剩下什麼。
這個程式庫是 RealWorld 示範應用(Express、TypeScript、Prisma、Postgres),是一個有真實測試的真實專案,而且全新 clone 下來就有一組測試是壞的(四組通過的測試、14 個綠燈測試、執行兩秒)。這個 bug 之後會成為我們的對照組。計分規則是:一道關卡的產出若能改變最終交付的內容,而且成本比它帶來的價值低,這道關卡就值得。
入場門票是放在儲存庫根目錄的一份記憶檔案:指令、慣例、架構、模型一再犯的錯,篇幅控制在一頁以內。我們的這份在 63 秒內寫好並提交,花費 $0.44。方法上有一個誠實的但書:headless 執行會把 playbook 裡的訪談壓縮成單一 prompt。
規劃:29 秒產出 intent.md
第一道關卡在任何人開始設計之前,先把想法記錄下來。我們的功能需求是:讀者想要靜音那些洗版灌爆動態的作者。playbook 把產出稱為 proto-spec,由你和模型一起寫,但由你負責擁有,並允許三種來源:一個想法、一張已開立的工單,或一則事故警報。範本有五個段落,標題本身就在替你思考:問題、預期成果、受影響的使用者與系統、限制條件、未解問題。工作流程是五個動作:描述、腦力激盪、依範本產生、修正、提交。
| intent.md | 時間 | 成本 |
|---|---|---|
| 靜音作者功能 | 29 s | $0.18 |
| 壞掉的測試組 | 39 s | — |
價值藏在最底下的未解問題裡:被靜音作者的收藏會怎麼處理?他們的頁面還能被連到嗎?這些決定如果沒寫下來,coding agent 會默默替你做掉,現在則被寫下並標上日期。這份檔案會被提交,所以作者與時間戳記不會隨聊天紀錄消失,產品負責人也會在接受之前先修正草稿。Anthropic 為這個階段設定的目標是「以小時而非以週」完成需求釐清;單人作業的話,不到一分鐘。
設計:spec 自己標出了它的前提
第二道關卡用課程裡的一個 prompt,把 intent 變成 spec:讀取 intent、產出需求與設計 spec、套用可用的 skills,而這些 skills 本來應該承載你的品牌、安全與 UX 政策。兩分鐘後,我們拿到約 2,300 字、品質稱職的 spec:端點、資料模型、動態行為、邊界情況。它甚至如 prompt 所要求的,記錄下自己無法滿足的部分。
轉折出現在它標出的疑慮裡,那是模型自己寫的:「C0. No org skills available. This spec has not been checked against any policy.」這個階段的整個前提,假設了大多數環境裡根本不存在的檔案。講解影片都略過了這個前提,而 agent 把它白紙黑字寫了出來。第二個標記則平淡得多:未解問題的預設值需要產品端簽核才能進入建置。
這堂課對配對要求很嚴格(spec 與 intent 一起提交,由人核准進入建置的轉換),而且還有一筆閱讀成本:每份 spec 約 12 分鐘的產品負責人時間。playbook 甚至會追蹤返工:建置開始後才標上日期的 spec commit,都會算在你頭上。在已經把政策編碼好的團隊裡,這道關卡就是這些政策被執行的地方。單人作業時,你付錢買的是一個目前的環境還兌現不了的承諾。
建置:Plan Mode、TDD,以及迴圈真正檢查的東西
第三道關卡是 Plan Mode,而它設的門檻既嚴苛又實用:一位從沒看過那段對話的工程師,光靠這份 plan 就能完成實作。Plan Mode 自己強制執行「閱讀」這一半:在 plan 被接受之前,模型不能編輯任何檔案。我們的 plan 約 4,000 字,花了四分鐘,列出會改動的檔案、工作順序、風險與驗證方式,並記下三項與 spec 不同、且都有標註的偏離,這些偏離之後在審查時會再出現。
建置跑在一個迴圈上:先寫失敗的測試,讓它通過,只有一個目標,全部變綠,否則任務就沒完成。這個迴圈受到保護(修程式碼的 agent 不能削弱針對該程式碼的檢查),並搭配一個 verifier,也就是在全新 context 中進行的第二次檢查,不受寫出那段程式碼的工作階段所影響。
| 建置結果 | 數值 |
|---|---|
| Agent 時間 | ~9 min, 91 turns |
| 成本 | ~$2 |
| 變更 | 15 個檔案、Mutes 資料表、兩個端點、兩個動態都加上過濾 |
| 測試 | 5 組、50 個測試,獨立重跑後全數通過 |
| 首次通過即合併 | 是 |
要加上的星號是:綠燈只證明迴圈裡包含的東西,沒有更多。端對端從未被執行,因為那需要一台運作中的伺服器和有種子資料的資料庫,而一個對準過時假資料的迴圈,同樣會亮得一片綠。團隊規模下還可以在 worktree 中平行跑工作階段(上限據說是兩到三個);這部分我們沒有測試。
部署:審查,以及說不的那道關卡
部署關卡有兩層,而且兩層都對我們說了不。第一層依照儲存庫根目錄的一份書面政策閱讀 diff:三輪檢查(bug、安全性、對照 spec 與 plan 的合規性),「Important」只保留給壞掉的行為、洩漏的資料或違反政策,nit 最多五項,其餘只以數量彙總,這份政策連自己的雜訊都設了上限。審查花了兩分鐘、$0.80,而且跑了真正的檢查:測試、建置、對照 plan 中記錄的基準線做 lint,以及涵蓋九個檔案的格式檢查。結論:零個 Important 發現、六個 nit,其中一個超出上限而被彙總。它最後說了一句我們沒有要求的話:這個 agent 不負責核准,核准仍由分支保護機制背後的人類 code owner 決定。
第二層就是關卡本身。我們要求部署,模型自己拒絕了,因為該功能不在要出貨的分支上。那是判斷,不是強制執行。所以我們先合併再問一次:四行 shell 在 14 秒內回應:已封鎖,需要發布授權。Exit code 2 會中止這次工具呼叫,理由則回到模型手上。管線端也得到同樣的處理:一個壞掉的 build 以 headless 方式在 11 秒內完成分診,花費 $0.13,它讀了 log、點出確切原因,並在沒有動任何檔案的情況下提出 diff。確定性勝過客氣;hook 的能力只取決於它的 pattern,而我們的只比對到一支腳本。
關卡稅
同一個 bug、同樣壞掉的起點、兩條路,這就是對照實驗。第一條路:直接修。第二條路:走完整條鏈,從 intent 到 build。
| 直接修 | 完整鏈 | 倍數 | |
|---|---|---|---|
| 實際耗時 | 2:13 | 11:31 | ×5.2 |
| 成本 | $0.70 | $3.46 | ×4.9 |
| Turns | 40 | 169 | — |
| 結果 | 測試組全綠 | 測試組全綠 | 相同 |
機器的帳單只是小的那一半。為了一個一行的修正,這條鏈寫出了約 5,500 字的產出物,大約需要 27 分鐘的人工閱讀,而那個 diff 你一眼就能掃完。這條鏈把寫作時間轉換成閱讀時間,這就是關卡稅。
playbook 還加上了一筆經常性費用:持續評測。二十到五十個真實任務,每次設定變更都重跑,每個案例都是一個真實的過往任務,prompt 維持原樣,從變更前的 commit 開始跑,並附帶可檢查的驗收條件。從歷史紀錄寫出五個案例花了五分鐘,但要把它們跑對就沒那麼容易:我們第一版的測試框架把兩個案例對準了錯的 commit,而兩個 agent 都抓到了這件事,而不是假裝通過。以每個案例約一分鐘計算,完整的一套每跑一次最多要花一小時的 agent 時間,而且每一次正式環境事故都應該作為永久的回歸評測加入這套案例。在受監管的團隊裡,這份閱讀本身就是交付物;單人作業時,它就是額外負擔。
結論:六道關卡有三道值回票價
六道關卡中有三道自己就值回票價:
| 階段 | 結論 | 證據 |
|---|---|---|
| 規劃 | 保留 | 40 s 買到沒人問過的問題 |
| 建置 | 保留 | plan mode + 測試迴圈交出 50 個綠燈測試 |
| 部署 | 保留 | $0.80 的審查加上真正的檢查,以及 14 s 的確定性封鎖 |
| 設計 | 單人可跳過 | 為你還沒編碼的政策向你收費 |
| 測試(持續評測) | 可以等 | 每跑一次最多一小時,而且容易對錯目標 |
| 維運 | 尚未證實 | 需要數週的正式環境遙測資料 |
維運在紙面上很優雅:確定性的腳本監看控制區間,一旦越界就寫出一份新的 intent 檔案;但要證明它,需要我們沒有的正式環境遙測資料。如一位分析師所說,Anthropic 自己的文件通篇沒有任何量測;這些是第一批數字,限制也很明顯:一個程式庫、一位開發者、一天。
外部資料顯示這份壓力是真實的。Faros 追蹤了 1,200 多個團隊、超過 10,000 名開發者:高採用率的團隊合併的 pull request 多了 98%,審查時間增加 91%,平均每個 pull request 的大小成長超過一倍。最新的 DORA 報告也有類似的訊號:有了 AI,吞吐量上升,穩定性下降。審查正在成為瓶頸,而這份 playbook 瞄準的正是這個位置。社群的變體已經把這條鏈砍到只剩兩個由人做的決定:一個提供範本與一份關卡帳本,另一個只讓人留在設計與測試兩個環節。採用那三道值回票價的關卡,等你的團隊長大了,再慢慢接上其餘的。Anthropic 自己的結尾那句話,正是最恰當的墓誌銘:迴圈持續運轉,人的判斷力始終在它之上。
