已提交產物鏈

資料來源#

• The AI-Native SDLC playbook | Claude by Anthropic

摘要#

Anthropic 的 Applied AI 團隊發布了 The AI-Native SDLC playbook（claude.com，2026-08-21），逐階段說明如何以代理程式重建六階段的軟體開發生命週期。十一項做法背後有一個結構性構想，文章只陳述一次，之後便處處以此為基礎：每個階段結束時，都將一份產物寫入版本控制；下一階段則從讀取該產物開始。 團隊自己的說法是 — 「貫穿右欄的主線是已提交的產物……提交鏈同時也是稽核軌跡：誰提出了什麼要求、代理程式產出了什麼，以及誰核准了它。」

這裡綁在一起的是兩項可以分開討論的主張；本文將它們分開處理，因為兩者的失敗模式不同：

1. 以提交完成交接。 SDLC 階段之間的介面不再是工單、會議或簽核，而是一個檔案。合併成為觸發下一階段的事件，而不只是記錄上一階段已完成。
2. 以提交紀錄作為稽核紀錄。 每份產物都自然帶有作者、時間戳記和修訂歷史，因此 git 被宣稱能滿足過去由流程中的核准閘門達成的控制目標。

全文的證據等級都是 vendor-claim：這是 Anthropic 說明如何使用 Anthropic 產品的文件，內容取自其 Applied AI 團隊的客戶工作，但全文沒有任何測量。以下的歸屬標示都是刻意的 — 說的是「playbook 建議」，而不是「這樣做的團隊會得到什麼成果」。

產物鏈#

階段	提交的產物	起草者	核准者	合併後觸發的事項
Plan	intent.md — 問題、預期成果、受影響的使用者／系統、限制條件、待解問題，以發起者自己的措辭撰寫	Claude，根據與發起者的腦力激盪起草	Product owner	需求與設計檢視
Design	spec.md — 在一次流程中完成需求與設計，並受組織技能限制，同時標示疑慮	Claude，根據 intent.md 起草	Product owner（較高風險類別由技術主管核准）	Plan mode
Build	plan.md — 變更檔案、工作順序、風險、證明	Claude 在 plan mode 中起草，由工程師提問檢視	工程師	實作
Build/Test	差異與其測試	Claude	feedback loop（tests/build/screenshot），在人類看到之前執行	PR
Deploy	附有檢視結果的 PR，依 REVIEW.md 標記嚴重程度	Claude review passes	透過 branch protection 指定的 Code owner	pipeline
Maintain	事故紀錄，另寫回一份新的 intent.md	由確定性偵測器呼叫的 Claude	Service owner 分流處理	再次進入循環

這些做法明確採用非線性設計 — 每項做法都列出前置條件，而 playbook 的相依關係圖安排的是採用順序，不是執行順序。沒有其他項目指向的階段，可以先行採用。

為什麼特別採用 markdown#

明確提出的限制是要同時供兩種讀者閱讀：早期階段使用 「.md 檔案作為主要產物，因為產品負責人和代理程式都能閱讀同一份檔案並據以行動。」 這是語料中對 Agent Context Files 前提最清晰的陳述，並將其應用在產品產物，而非代理程式設定上 — 同一套由 repo 版本控制的純文字控制平面，向左延伸到過去由非工程人員負責的階段。playbook 也清楚說明界線在哪裡：從 Build 開始，產物就是程式碼及其紀錄，而不是散文。只有在人類無法閱讀差異、卻仍必須檢視內容時，markdown 才是介面。

接著就有一個存取設計問題，playbook 直接給出答案，沒有含糊帶過：沒有 git 的貢獻者預期會透過版本控制連接器進入 intent 專用首頁，因此 Claude 會代表他們從 claude.ai 或 Cowork 提交內容。文件將架設該首頁列為平台團隊的一次性任務，並指出必須審慎決定寫入權限，因為 「許多貢獻者會來自組織各處。」

以提交作為觸發，而非紀錄的交接方式#

playbook 規定的逐步導入方式明確分階段：「首先，手動提示每一步，最終形成一個循環：每份獲核准的產物都會觸發下一道閘門。」 Design 做法進一步說明中間步驟 — 手動執行需求檢視、將流程編成組織層級的 slash command，接著讓 intent.md 獲核准成為非互動式工作的觸發條件，由工作將 spec.md 作為 PR 提交。這是 Loop Engineering 中「讓自己不再擔任提示者」的做法，套用在組織流程邊界，而非單一工程師的終端機內；Maintain 階段則完成這個循環：確定性偵測器在呼叫流程中不需任何人介入便會呼叫 Claude，而偵測結果會回到 Plan 階段。

當合併成為觸發條件時，改變的是人類注意力所在之處。主張是，人們不再負責啟動各階段，而只負責檢視：「人類注意力會集中在各道閘門，檢視代理程式標記的內容，而不是每次都從頭啟動階段。」

點出既有事實來源問題，而非寄望問題消失#

playbook 最務實、最坦誠的一節，是其中討論既有產物的側欄。這些產物可能已存在 Jira、ServiceNow、受監管的需求工具或 Figma 裡 — 這些系統 「很難取代，因為稽核人員和監管機關已經接受它們。」 規則是：每份產物都要明確指定唯一一個系統作為事實來源，其餘系統只保存副本或連結。以下三種設定須依產物選擇，而非依組織選擇：

• Repo 為權威來源 — markdown 是正式紀錄，舊系統則引用提交。對工程主導的組織而言最簡潔：一個工具、一個時間戳記權威來源。
• 舊系統為權威來源 — Jira 或需求工具保存正式紀錄；Claude 在工作階段開始時讀取該紀錄，並在產出 spec 或 plan 的同一個工作階段中，透過 MCP 連接器寫回結果。markdown 檔案是工作副本。
• 只建立連結 — 每份產物都註明紀錄 ID，每筆舊系統紀錄都附上提交 SHA。文件將此列為起點，也明言其代價：兩個事實來源。

這是附上遷移路徑的 Code as Source of Truth，也是最不依賴 Anthropic 產品的 playbook 內容。

產物鏈的完整性問題：三份代理程式草稿、三次人類修正#

文件一貫強調人類的責任 — 「人類仍須為每個需要判斷的決策負責」 — 並只在一個接合點落實職責分離，也就是 PR：「撰寫程式碼的代理程式無法核准自己的程式碼」，branch protection 會要求 Code owner 核准。但產物鏈中的前三份文件都是由代理程式起草，再由人類修正：發起者修正 intent.md，產品負責人檢視（明確表示 「但不負責撰寫」）spec.md，工程師則透過提問檢視 plan.md。playbook 對 plan 品質提出的檢查方法很實用，而且將它描述成標準，而非儀式 — 「反覆修訂，直到一位從未看過對話的工程師能單憑 plan 實作變更」 — 但設計中沒有任何機制能偵測修正者已停止修正。

在這裡，這比單一閘門設計更重要，因為產物彼此相連：spec.md 是從 intent.md 產生，而 PR review 會依據 plan.md 檢查差異，因此若早期草稿未受質疑，就會成為後續每道閘門衡量的標準。這是 rubber-stamp question 加上累積效應；稽核軌跡的主張也在此面臨考驗：提交紀錄能記下人類接受了內容，卻無法證明人類讀過內容。Git 提供來源資訊和時間戳記，但不會提供注意力。playbook 自己的 tiering instinct 是現有的解答 — 它會在 spec 和 plan 兩道閘門將高風險類別交由技術主管處理 — 但分級由組織自行決定，也沒有提供校準方法。

尚未提供的測量#

每項做法都以一項領先指標和一項落後指標結尾，所選用的工具有明確且合理的原因：它們都取自組織已在使用的系統。Git 時間戳記（intent→spec 經過時間、spec.md 的提交日期晚於第一份 plan.md）、PR 中繼資料（返工週期、首次通過合併的比例、檢視時間）、OpenTelemetry 匯出資料（含時間戳記的 hook 允許／封鎖判定、每位工程師的並行工作階段數）、CI（首次通過成功率、eval 通過率）、事故追蹤系統、DORA。

這些指標一項也沒有報告。 這份文件是儀表化設計，不是研究 — 約 10k 字全文沒有基準、沒有群組，也沒有前後比較；唯一提出的量化預期（誘發工作 「從數週……的週期縮短到數小時」）也只是預測。這對 wiki 如何收錄這份文件有兩個影響：

• 所有結果主張都屬於 vendor-claim，每個引用此來源的頁面都應如此標示。
• 不過，指標集合是可重複運用的部分。其中幾項正是語料中的實證來源所測量、且彼此看法不同的數值 — 每個 PR 的檢視時間、返工率、變更失敗率 — 這表示原則上可用既有工具驗證或推翻 playbook。這比多數廠商指引更有價值，也因此下方的待解問題標為 #oq/source，而非無從作答。

對照遙測資料：診斷相同，證據狀態相反#

playbook 一開頭就提出了 Acceleration Whiplash 所測量的發現 — 建置時間縮短至數小時，但前後階段仍由人類依原有速度處理，控制措施與實際情況脫節，治理成本上升 — 只是它用斷言得出診斷，而 Faros 是根據企業遙測資料得出相同結論。兩者對解方看法不同，而此處 wiki 自身的證據比 playbook 更有力：

• 解方方向。 Faros 的論點是，問題出在撰寫，而不是檢視：擴大檢視規模是在處理症狀。playbook 大致是一套檢視與閘門方案 — 代理程式檢視流程、hooks、控制範圍 — 只有兩項做法真正著眼於撰寫端（用 CLAUDE.md／skills 限制生成，以及讓工作階段在人類看到內容前先完成驗證的 feedback loop）。Acceleration Whiplash 也屬於 vendor-claim，但它是有測量結果的廠商遙測資料，與本文未經測量的規範性指引不同；兩者若有衝突，遙測資料的證據較充分。
• 檢視時間主張。 playbook 預期首次檢視時間會*「降至幾分鐘」*，而每個 PR 的檢視時間也會在測試捕捉到過去由檢視者發現的問題後下降。Faros 測得 PR 檢視中位時間上升 441.5%，Tran et al.（empirical，含人類對照組）測得阻擋性檢視討論串是人類基準的 1.92 倍。首次檢視所需時間與總檢視時間是不同的數值，而且兩者可能各自變動 — 代理程式檢視者能在幾分鐘內留言，卻不一定縮短人類閱讀的時間 — 因此這是可以釐清的歧見，而非直接矛盾；只有 playbook 這一方尚未測量自身主張。
• playbook 提供了遙測資料沒有的內容。 Faros 記錄了流程卡住的情況；本文則是廠商對於完整、順暢流程的端到端樣貌所做的最完整公開說明，包括無人測量的部分（誰管理 intent 首頁、政策負責人核准什麼、受監管企業的 managed-settings 設定檔會拒絕什麼）。應將其視為待驗證的假設，而非研究發現。

延伸閱讀#

• Code as Source of Truth — 直接的先驅，並向左延伸兩個階段。該頁主張 spec 和 skills 應放在 repo 中，因為高吞吐量下文件會過時；這條產物鏈則加入工程開始前的產物（intent.md、spec.md），以及說明正式紀錄已在 Jira 的組織如何遷移的規則。這也首次在語料中為「為什麼」指定明確位置 — intent.md 被指定用來記錄*「想要什麼、為什麼，以及受哪些限制」* — 但這仍是規範，而非證明原因能經得起產物鏈考驗的證據
• Prototype Over PRD — 執行相同工作的競爭性產物。Carey 刪除 PRD，因為原型本身就是 spec；此 playbook 則保留文件鏈，並使其可供機器採取行動。這不是風格上的差異：原型表面呈現的內容決定了它就是 spec，因此它涵蓋可觀察的行為，卻不涵蓋跨領域限制；而 intent.md 的限制區塊，正是原型無法呈現的部分
• Planning / Execution Division of Labor — 這條產物鏈明確化的實測基準。Anthropic 自身涵蓋 400K 個工作階段的遙測資料發現，人類做出約 70% 的規劃決策，Claude 做出約 80% 的執行決策；playbook 的 plan.md 閘門就是將這種分工寫下來並提交，而 plan mode 會以機制強制落實（plan 獲核准前，Claude 無法編輯）。矛盾之處在於，遙測描述人們實際怎麼做，playbook 卻建議讓代理程式起草規劃，人類降為修正者 — 這正是「AI as primary author」對該頁的解讀所擔心的方向，只是這裡的變化發生在程式碼上游
• Agent Context Files — 基礎層。CLAUDE.md 和 skills 是產物鏈中的持續性產物（它們限制每個階段，而非觸發下一階段），playbook 則為該頁提供兩項紀律：重犯兩次才記錄的規則（Claude 第二次重複錯誤時，才將修正寫入 CLAUDE.md，並在檢視時標示），以及「控制在一頁以內」的篇幅原則
• Deterministic Pre-Execution Gates — 產物鏈仰賴的執行層，也是 playbook 最明確的技術貢獻：skill 是建議性控制，hook 是背後的確定性層，PR 階段重新檢查則是第三道防線 — 「skill 讓違規變得罕見，而 hook 讓違規幾乎不可能發生。」 受監管企業使用的 managed-settings 設定檔，則是對該頁所述最嚴重實際失敗的解答：代理程式刪除了封鎖用 hook 的觸發條件
• Deterministic Engineering for Agent Code Review — Deploy 階段的機制；playbook 的 REVIEW.md 正是一種該頁的 rule-guided dispatch 可加以操作的政策產物：列出檢視步驟、明確區分 Important 與 Nit、設置 nit 上限，並排除生成路徑和 CI 已強制執行的內容
• Evals as Product Spec — Test 階段的做法；playbook 將其描述為 「evals 是 AI 原生的階段閘門 QA。」 它的貢獻在於指定測試套件的檢查對象：將代理程式設定（CLAUDE.md、skills、hooks）納入回歸測試，並以合併檢查作為閘門；每起正式環境事故都必須由負責團隊永久加入 eval
• Risk-Tiered Auto-Approval — 產物鏈在三道閘門（spec、plan、merge）需要、但都未具體說明的分級方式；PostHog 已部署的技術堆疊是經過校準的實例
• Loop Engineering — 循環的終點：獲核准的產物觸發下一道閘門，形成以合併事件為提示者的循環；Maintain 階段則完全將人類從呼叫流程中移除
• Claude Code Auto Mode — 讓產物鏈的 Build 階段便宜到值得採用的做法：防護措施成熟後，自動接受會成為例行工作的預設選項，而檢視工作也會從監看編輯過程，轉為在較長的自主工作階段結束後閱讀產物
• Verification as the New Bottleneck — 產物鏈藉由在每份產物交由人類閱讀前附上機械產生的證據，試圖避開的限制
• Acceleration Whiplash — 本文開頭診斷的實測版本，也討論應該修正 SDLC 哪一端的歧見
• AI-Native Organization — Tan 從營運角度將 markdown 對應為組織基礎原語，指向相同的基礎層；這條產物鏈則是軟體生命週期中的實例。兩者都認為負責承載工作的核心是由版本控制的純文字，但對於頂層內容看法不同 — 前者視 skill 檔案為員工，後者視產物為階段邊界
• Engineer PM Convergence — 角色上的影響：產品負責人檢視自己未撰寫的 spec，並處理標記出的政策疑慮；這是將檢視工程師的職務說明套用到產品職務
• The PRD-Replacement Spectrum at AI-Native Speed — 說明本文位於光譜何處：不是刪除 PRD，而是將 PRD 拆成三份較小、已提交且各有指定核准者的產物
• Is Human Review of AI-Authored Code Still a Real Control, or Already Rubber-Stamping? — 上文提到的累積性修正者問題
• Is Persistence the Line Between Prompting and Spec-Driven Development? — 將本文「PR 依據 plan.md 檢視」視為語料中對 spec 定義最清晰的陳述：關鍵在權威性，而非儲存方式。這也縮小了與 Martin 的歧見 — 他保留由檢查器強制執行的限制，只捨棄未受強制執行的 plan，因此爭論在於可強制執行性，而非是否提交檔案
• Spec-Driven Development as the New Waterfall — 針對產物鏈核心做法的實務報告。Martin 在受訪那週採用 plan-first 代理程式工作，並稱之為「總是一場災難」：代理程式會照著漂亮的 plan 繼續執行，超過人類原本會停下來的時點，因此他讓 spec 保持短暫存在，從不提交。Martin 針對的是可執行的 plan.md，而非 intent.md，因此產物鏈上游部分不受影響 — 雙方都沒有測量任何結果
• AI as Primary Author — 產物鏈 Plan 階段所推動的方向：由代理程式起草 spec.md 和 plan.md，再由人類修正，將作者身分移交給代理程式；這個移交發生在 Faros 測量的程式碼上游一個階段

待解決的問題#

• 產物鏈自身列出的指標正是檢驗它的方法，而 Anthropic 有足夠的樣本可以執行檢驗：在採用這些做法的客戶中，開始建置後的返工（同一項變更的 spec.md 提交日期晚於第一份 plan.md）是否真的減少，還是較早產出、成本較低的產物只是改變了返工發生的位置？如果 intent→spec 延遲下降而返工持平，代表產物鏈只是加快文件產出，沒有改善決策。
• 產物鏈會讓檢視變得更深入，還是只讓檢視時間更早？Faros 測得檢視時間大幅上升，Tran et al. 測得阻擋性討論串達人類基準的 1.92 倍；playbook 則預測，附上機械證據後兩者都會下降。目前沒有研究以相同品質結果比較設有已提交 plan.md 閘門的群組和未設此閘門的群組。
• 修正者疲勞會先讓產物鏈的哪個位置失效？設計中的累積風險是 spec.md 從 intent.md 產生，而 PR 會依據 plan.md 檢查，因此早期產物若未被閱讀，就會成為後續閘門衡量的標準 — 但語料中沒有來源依產物類型測量檢視注意力，只有依差異進行測量。

資料來源#

• The AI-Native SDLC playbook | Claude by Anthropic — Anthropic Applied AI 團隊，claude.com 部落格，發布日期 2026-08-21（匯入摘錄的 frontmatter 記錄為 published: 2000-08-21，這是摘錄工具解析年份時產生的錯誤；此處和匯入紀錄已更正），約 10.2k 字。文中感謝 Jim Blackhurst、Will Steuk 和 Jamal Arif 的貢獻；未列具名作者。vendor-claim — 針對廠商自家產品的第一方 playbook，包含實務者觀點（Applied AI 客戶工作）。沒有任何形式的測量：每個「如何衡量」區塊都指定了要收集的指標。來源中的四張圖是對文中階段與相依結構的示意圖，不含資料