AI-native SDLC 是什麼？Anthropic 官方 Playbook 重點整理（2026）

AI-native SDLC 是 Anthropic 在 2026 年 8 月提出的開發流程：保留傳統 SDLC 的控制目標，換上新的執行方式。流程從線性變成迴圈，AI 嵌在每個階段，人對每個需要判斷的決策負責。

什麼是 AI-Native SDLC？

Anthropic 在 2026-08-21 發表〈The AI-Native SDLC playbook〉（作者 Louis Claxton），整理 Anthropic Applied AI 團隊幫企業客戶改開發流程的做法。

官方的定義是「combines the old control objectives with new enforcement」，舊的控制目標保留，執行方式換新。

傳統 SDLC 的六個階段（plan、design、build、test、deploy、maintain）各由不同角色負責，工作靠文件、ticket、簽核在階段之間傳遞。這套流程是為了「寫 code 最貴、最久」的年代設計的。

AI 讓 build 縮到小時級之後，官方指出會冒出三個問題。

• 瓶頸移到 build 的左右兩邊，plan、review、test、deploy 還是人的速度。
• 逐行人工 review 跟不上 agent 寫出來的 diff。
• 例外還是走每週或每月一次的委員會，治理成本上升。

AI-native SDLC 的做法是把線性流程改成迴圈，AI 嵌在每個點，階段之間的交接自動觸發。原文最後一句是「The loop keeps running. Human judgement stays above it.」

原理：每個階段交出一份 artifact

每個階段結束時 commit 一個 artifact 到版本控制，commit 本身觸發下一個階段，下一個階段從讀這份 artifact 開始。這條 commit 鏈同時是稽核軌跡：誰要了什麼、agent 產了什麼、誰批准的。

Plan → intent.md

有想法的人和 Claude brainstorm，用自己的話寫成 intent.md：問題、想要的結果、影響的使用者與系統、限制、待解問題。product owner 在 commit 前 review 並修正。

Design → spec.md

Claude 讀已接受的 intent.md，在組織的 brand、security、compliance、UX skills 約束下產出需求與設計 spec，並標出有疑慮的地方。product owner review，但不寫它；進不進 build 由人決定。

Build → plan.md、diff 與測試

工程師用 plan mode 開 session，把 spec.md 交給 Claude 寫實作計畫：改哪些檔、工作順序、用什麼測試證明完成。plan mode 能讀 codebase 但不改任何檔案，工程師批准後 commit 成 plan.md，Claude 才開始寫 code。

Test → 測試結果、evals

每個 session 在人看到之前先自己驗證：跑測試、跑 build、截圖比對。CLAUDE.md、skills、hooks 這些操控 agent 的設定一改，就跑 eval 套件，確認 agent 還是照同樣的標準做事。

Deploy → PR 與 review findings

每個 PR 都跑同一組 AI review（bugs、security、對照 spec.md 與 plan.md），findings 依嚴重度排序。批准還是由人透過 branch protection 給出。官方的原則是 agent 可以做到 production gate 為止，不能越過。

延伸：我的想法

整體架構還是很值得學習，這其實是用 AI 替換人，來處理整個開發流程。

不過現實上沒有這麼簡單，幾乎每一層都要再額外處理。像是業主的意圖可能並不清晰，或是實際上有衝突。

plan.md 用 plan mode 產出，這個做法已經有點過時。Claude Code 團隊的 Thariq 在 2026-09-23 公開表示，他認為模型已經不需要 plan mode，未來可能不再推薦。

這套流程很適合開發新產品。開發新產品重視的是 intent（用戶痛點、需求），整個流程就是以它為核心。如果是一個時常修改的案子，這套流程其實不是很好用，沒有 SDD（Specification-Driven Development，規格驅動開發）來得好用。

FAQ

AI-native SDLC 跟傳統 SDLC 差在哪？

階段一樣是 plan、design、build、test、deploy、maintain。差別是流程從線性變成迴圈，AI 嵌在每個階段，每個階段結束時 commit 一個 artifact，下一個階段從讀它開始。

AI-native SDLC 每個階段要交出什麼？

Plan 交 intent.md，Design 交 spec.md，Build 交 plan.md、diff 與測試，Test 交測試結果與 evals，Deploy 交 PR 與 review findings。

AI-native SDLC 裡人負責什麼？

人對每個需要判斷的決策負責，例如批准 intent.md、決定 spec 能不能進 build、批准 plan、在 branch protection 上批准 PR、授權上 production。

參考資料

• The AI-Native SDLC playbook（Claude blog，Louis Claxton，2026-08-21）