AI-native SDLC 要解決什麼？當 agent 加快 code 產出後，真正的瓶頸會移到規劃、審查、測試與部署；這堂課用 intent.md → spec.md → plan.md → diff/test → PR/review → incident 的 committed artifact 鏈，搭配 Skills、continuous evals、AI review 與 hooks，把線性流程改成有人守 gate 的治理迴圈。課程視角偏 engineering、platform、security lead，實作細節仍依版本、平台與組織設定而異。

前一篇 Subagents 入門 還在討論怎麼把探索工作交給獨立的 context，這次的 The AI-Native SDLC Playbook 把視角拉到整個組織：當 agent 已經能快速產生大量 code，需求、設計、審查、測試和部署要怎麼跟上？

這堂課比較像 engineering、platform、security lead 的組織治理指南，讀者不會拿到一串照著貼就能完成的單人操作步驟。以下依照官方 Course outline 整理；官方頁面目前以英文顯示，中文是口語化筆記，功能標示和可用性仍可能隨版本、平台與帳號方案變動。

課程資訊一覽

Introduction

1. Introduction

Software Development Lifecycle（SDLC，軟體開發生命週期）通常被切成 Plan、Design、Build、Test、Deploy、Maintain 六個階段。每個階段由不同角色負責，靠需求文件、ticket、簽核和交接維持共識。這套設計很適合「寫 code 要花幾週到幾季」的時代。

當 agent 開始大量產生 code，瓶頸會移到 code 的前後：plan、review、test 和 deploy 還是照人的速度走；人可以逐行審少量手寫 diff，卻很難用同樣方式審查 agent 產生的大量變更；資安與合規的例外也仍然等待每週或每月一次的會議。

AI-native SDLC 保留原本的控制目標，改變它們的執行方式。流程從線性階段變成迴圈，AI 嵌在每個節點，上一階段提交的產物觸發下一階段，人則站在 gate 上負責發起、指揮和治理。

串起整條鏈的是 committed artifact。每個階段都把產物寫進版控，從 intent.md、spec.md、plan.md，一路到 diff 與測試、PR 與 review findings、incident 紀錄。下一個階段從上一份產物開始，commit 鏈也就成為稽核軌跡：誰要求什麼、agent 產出什麼、誰核准了什麼。需要判斷的決策仍由人負責。

課程裡的 plays 是六個可以模組化組合的 stage，不要求每個組織一次完成全部自動化。最初可以手動下 prompt，成熟後再讓「接受 intent.md」觸發 requirements/design、「核准 spec.md」觸發 plan mode、「merge PR」觸發 pipeline，production 超出 control band 時則產生下一份 intent.md。人的注意力會集中在 gate，而非每個階段都從零開始。

Stage 1: Plan

2. Capture as intent.md

傳統需求會經過 backlog、user story、story point 和 refinement 會議，每次交接都可能離發起人的原意更遠。這個 play 把入口改成 intent.md：發起人用自己的話說明要什麼、為什麼要做，以及有哪些限制，再和 Claude 一起把內容整理成可以進版控的 proto-spec。

Getting started 不需要工程技能。團隊先準備 intent.md 模板和一個共同的版控位置：單一產品可以放在 repo 的 intent/ 資料夾，跨多個 repo 才考慮獨立的 intent repo，monorepo 則可以放在既有目錄。沒有 Git 經驗的發起人，也可以透過 GitHub 這類版控 connector 讓 Claude 代為提交 Markdown。

執行流程可以濃縮成五步：

1. 發起人用自己的話描述目前做不到什麼、誰受影響、更好的結果長什麼樣，以及明確不做什麼。
2. 和 Claude 腦力激盪，把範圍、使用者、限制和成功條件問清楚。
3. 依組織模板寫成 intent.md；模板也可以做成由技術人員維護的 Skill。
4. 發起人修正 Claude 的誤解。
5. Commit 到共同位置，留下作者與時間戳，交給 PO 接手。

官方範例是 claims status self-service：

治理證據是已提交的 intent.md、作者、時間戳和完整修訂史；PO 的接受或拒絕，則記錄成 merge 或關閉 review。可以觀察的指標包括從第一次對話到 intent.md commit 的時間、進入 Design 的比例，以及第一份 spec.md commit 之後 intent.md 被修改的次數。

這一 stage 的核心理解很簡單：先讓想法成為一份保留原意、可以被後續流程讀取的產物，需求就不必在多次交接後才第一次被看見。

Stage 2: Design

3. Requirements and design

傳統流程把 requirements 和 design 分給不同團隊，分析師先正式化需求，設計師再重新解讀。這樣可以分工，卻也會增加等待與資訊損耗。AI-native 的做法是讓 Claude 讀取 intent.md，在一次 prompt 工作階段內產出 requirements 與 design spec，並把疑慮區（flagged concerns）一起標出來。

前置條件是已有 intent.md，以及把品牌、資安、合規和 UX 政策寫成 Skills。PO 開啟載入組織 Skills 的 session，附上 intent.md，要求 Claude 指向原始 intent、套用限制、產出完整的 spec.md，並特別標示互相衝突、無法同時滿足的政策。

一開始可以手動執行，之後再做成組織層級的 slash command。更進一步，當 intent.md 在 intent home 被 merge，就由非互動 job 載入 Skills，產生 spec.md 並以 PR 提交；PO 的第一次介入變成 review，而不是從頭撰寫文件。

PO 仍然要逐項對照：spec 有沒有解決原本的問題？open questions 有得到回答或被明確延續嗎？flagged concerns 要先交給政策負責人處理，spec.md 與 intent.md 一起 commit，最後是否進入 Build 永遠由人決定，高風險變更再交給 technical lead。

前端工作可以套用同樣的想法：intent 被接受後，PO 用 Claude Design 依 intent.md 做 mock、迭代，再 export 給 Claude Code 實作。這類 beta 功能的可用性仍以實際帳號與平台狀態為準。

這一 stage 的治理重點是把政策套用時機往前移。spec、產生它的 prompt 和當時生效的 Skill 版本都進版控，PO 負責簽核，疑慮交給指定的政策負責人。衡量方式則是比較 intent.md 到 spec.md 的時間，以及第一次 plan.md commit 之後是否仍頻繁修改 spec。

Stage 3: Build

4. Claude Code plan mode as the default starting point

工程師讀完設計就開始寫 code 時，「哪些檔案要改、工作順序和怎麼證明可行」通常只存在腦中。reviewer 第一次看到的是完整 diff，方向錯了才發現，rework 會變得昂貴。

這個 play 把 plan mode 設成預設起點：Claude 可以讀取 codebase，但在計畫被接受前不能改檔。工程師先提供 intent.md、spec.md，要求 Claude 產出包含以下內容的書面計畫：

• 哪些檔案要改。
• 工作順序。
• 可能弄壞什麼，以及風險最高的步驟。
• 能證明結果可行的測試或截圖。
• Claude 沒有選擇的替代方案。

計畫要迭代到「沒有看過對話的工程師，只看 plan.md 就能開始實作」。核准後把它 commit 成 plan.md，再交給 Claude 執行；如果實作偏離計畫，就在同一個 commit 更新 plan.md，也可以用 hook 強制兩者同步。官方範例的區塊是 Files that change、Order of work、Risks 和 Proof，例如 API 有 50 rps 限流時，panel 必須加入 cache，測試要涵蓋四種 claim state。

當 CLAUDE.md、編碼政策 Skills、阻擋不安全動作的 hooks 和可執行測試都成熟後，auto mode 才適合用在例行工作。工程師的工作會從逐次觀看 agent 修改，轉成讓它長時間工作，再審查最後的 artifact；worktree 則提供個人或團隊平行工作的隔離空間。

既有系統的 artifact 也要先指定 source of truth。工程主導的團隊可以讓 repo 為真；舊系統不可移除時，可以讓舊系統為真、Markdown 作為工作副本，透過 MCP connector 讀寫；至少也要讓兩邊互相記錄 record ID 與 commit SHA，作為過渡方案。

plan mode 的價值在於把方向審查移到 code 產生之前。這時改方向只需要改文件，工程師核准計畫後才讓 agent 進入實作。

5. The CLAUDE.md

課程把 CLAUDE.md 比喻成給 Claude 的新人 onboarding 資訊：專案慣例、指令、架構，以及團隊最常犯的錯。它原本散落在人腦與 wiki 裡，現在變成 agent 每個 session 開頭會讀取、全隊共同維護的檔案。

建立方式是先在 repo 執行 /init，再把內容砍到只剩新成員第一天需要知道的資訊：build、test、lint 指令，重要慣例，以及 Claude 一再做錯的事。檔案放在 repo root 並提交到 Git，變更像 code 一樣經過 review。

官方 Payments service 範例分成四區：

• Commands：make build、make test、make itest、make lint。
• Conventions：Java 21、Money 一律用 BigDecimal、每個 endpoint 都要有 integration test。
• Architecture：api/、core/、adapters/，Kafka schema 不改 generated classes。
• Things Claude gets wrong：不要升級依賴版本，legacy v1/ 已經凍結。

一條實用的維護規則是：Claude 同一個錯犯兩次，修正就補進 CLAUDE.md。檔案也要保持在一頁以內；每個 session 都會讀它，過時的內容只會占用 context。可以觀察 Claude 重複犯錯的頻率，以及新成員到第一個 merged PR 的時間。

6. Skills as institutional knowledge

需要一致套用的組織知識適合寫成 Skill，單次 prompt 或每個 session 都必須知道的短規則則留在 CLAUDE.md。例如資安標準、API 設計慣例和品牌規則，都可以由政策負責人提供 source of truth，再由工程師寫成 Skill。

一個 Skill 通常放在 repo 的 .claude/skills/<name>/，隨 code 一起出貨；也可以用 plugin 做組織層級分發。SKILL.md 的 frontmatter 說明何時觸發，內文說明具體工作。建立後要用不同說法測試觸發，政策改變時也由政策負責人核准新版。

官方的 secure-api-review 範例會在建立或修改對外 endpoint、review API code、產生 OpenAPI spec 時觸發，並要求檢查 gateway JWT、輸入驗證、稽核事件與資料分級，最後執行 scripts/check-endpoints.sh。

Skill 是 advisory control，能讓違規變少，卻沒有東西強迫 session 一定遵守。永遠成立的政策需要確定性的控制：阻擋動作的 hook，或在 PR 重新執行的 review pass。可以把它記成一句話：Skill 讓違規變罕見，hook 讓違規幾乎不可能。

Build 階段的 hooks 可以擋受保護路徑的編輯、編輯後執行 formatter/linter、避免憑證進 diff，或支撐必須零例外的 Skill。這些 hooks 應該快速且只檢查有變動的檔案；完整測試留給 commit 或 PR。需要人核准的 hook 則放到 Deploy 階段的 gate，避免每個平行 session 都卡在相同的互動提示。

7. Parallel sessions and subagents

平行 session 提升同時進行的任務數，subagent 則讓單一 session 保持專注。拆任務時先依照 plan 分出會碰不同檔案的工作，共用檔案的任務留在同一個 session 依序處理；每個平行任務使用自己的 worktree，例如 claude --worktree feature-auth 或 claude --worktree fix-rate-limit。

實務上可以從 2–3 個 session 起步，上限取決於一個人能好好 review 幾條線。重複出現的工作則定義成 .claude/agents/ 裡的 Markdown，例如 code simplifier、verifier 或 researcher，連同工具限制與輸出格式一起提交到 Git。

官方 verifier 範例只給 Bash 和 Read，用 make run 啟動 app，測試改動的行為與最近兩個相鄰流程，回報執行內容、觀察結果和與 plan.md 不符之處，不能自行修改任何東西。

session 越多，產出也越多，控制必須來自 repo 設定的 hooks 與權限。衡量方式可以看在 review 品質不下降的前提下，每位工程師能維持多少並行 session，以及每週 merge 的變更數和 rework rate。

Stage 4: Test

8. Give Claude a feedback loop

agent 寫完 code 後，最好能在工程師看到之前先自我驗證。測試、build 和截圖比對都可以成為 feedback loop，讓 session 依輸出自行修正，而不是把所有問題延後到 CI、測試人員或 production。

最基本的 Infrastructure 是一個能用單一指令執行的測試或 build，例如 make test 或 npm test，失敗時回傳 non-zero。接著在 CLAUDE.md 的 Commands 區列出指令，並說明健康輸出長什麼樣；完成條件也要寫成可量化的目標，例如 test_status.py 全部通過、截圖符合核准的 mock，或 endpoint 回傳 200 且包含新欄位。

修 bug 時，課程建議先寫失敗測試：重現 bug、確認測試因預期原因失敗、commit，再要求 Claude 在不修改測試的前提下讓它通過。可以用 hook 在 fix 任務期間阻擋測試檔編輯，或在 review 時只要發現測試被修改就拒收。

UI 工作則形成另一種閉環：實作 → 截圖 → 比對 → 調整，跑 2–3 輪很正常。核心規則是把驗證列為「完成」的一部分，回報任務完成前先跑測試並貼出原始輸出；agent 可以修 code，不能弱化驗收標準。

9. Continuous evals in CI

Evals 可以想成 AI-native 版的 stage-gate QA：當模型、prompt、CLAUDE.md、Skills 或 hooks 改變時，透過真實任務檢查 agent 是否仍然達到同樣水準。它是一套會持續更新的 suite；模型變強後，舊案例可能失去鑑別力，就需要補進新的案例。

Platform engineer 可以從近期工作蒐集 20–50 個真實任務，每個任務附上預期結果和可接受結果的檢查方式，例如測試通過、lint 乾淨、行為不變或遵守政策。Suite 在 CI 以非互動方式執行，排程跑，也在 CLAUDE.md、Skills 或 hooks 變更時跑回歸測試。

官方範例 .github/workflows/agent-evals.yml 會在 CLAUDE.md 和 .claude/** 變更時觸發，也有每日 cron。每個 evals/*.json 透過 claude -p 執行，限制可用工具，再以 ./evals/check.sh 檢查結果。每個 production incident 也應該產生一個 eval，留在 suite 裡成為回歸測試。

治理上，eval 通過率可以成為 merge check；設定變更如果讓通過率下降，就要先 review 才能 merge。可以觀察通過率趨勢、incident 變成永久 eval 的時間，以及 regression 是在 CI 還是 production 才被發現。

Stage 5: Deploy

10. AI in the PR review loop

AI-native review 的目標是讓所有 PR 都先得到同一組 review pass，findings 依嚴重度排序，工程師把注意力放在變更是否符合 plan 的意圖、風險是否可接受。Claude 可以 review 進來的 PR，也可以處理自己 PR 上的 review 意見，但它不能核准自己寫的 code。

Tech lead 在 repo root 建立 REVIEW.md，把 review policy 分成多個 pass，例如 Bugs、Security 和 Compliance。文件還要定義 Important 與 Nit 的差別，以及哪些項目應該略過。官方範例把會破壞行為、洩漏資料或違反政策的問題列為 Important；style 與命名列為 Nit，每次最多回報 5 個 Nit，其餘只做計數摘要，也不檢查 src/gen/ 或 CI 已經強制的項目。

起步可以使用由 admin 啟用的託管 Code Review；需要控制 pipeline 或使用自家雲端合約時，再在 CI 跑 claude-code-action，模型呼叫可以經 Amazon Bedrock、Google Cloud Vertex AI 或 Microsoft Foundry。無論採用哪種方式，branch protection 仍要求 code owner 核准。

Reviewer 或作者可以在 review comment 標記 @claude，讓 Claude 處理意見並 push 修正。Claude 開的 PR 也可以透過自訂 slash command 持續掃描未解決的 comment 與失敗的 check，修完再 push，直到 PR 全綠、只等待 code owner 核准。

Review findings 還要回饋到 CLAUDE.md：同一錯誤被標第二次，修正就寫進專案規則；review 也可以標出變更讓 CLAUDE.md 過時的地方。每月由 tech lead 評分 findings、調整 Nit 數量、排除已由 CI 強制的檢查。

11. Hooks as approval gates

Build 階段的 hook 通常是無需人參與的 allow 或 block；到了 Deploy，hook 也可以 ask，暫停動作直到指定的人核准。Hooks 不只用在 deploy，Claude 的動作到哪裡就可以跑到哪裡，例如 Build 沒有 change ticket 就阻擋 migration，Test 的 fix 任務不允許編輯測試檔。

第一步是由工程領導、change management 和 compliance 列出必須保留的人工核准 gate，例如 change management sign-off、release authorization 和受保護路徑編輯。接著 platform engineer 把每個 gate 寫成 Claude 動作前執行的 script，明確定義 allow、ask 和 block。

團隊 hooks 可以放在 .claude/settings.json 並進 Git；不可協商的 hooks 則放到由 platform 或 IT admin 管理的 managed settings，工程師無法關閉。Block 時要把原因與取得核准的路徑回傳給 Claude，讓被擋下來的動作仍然有可追蹤的下一步。

官方的 production-gate.sh 範例使用 PreToolUse、Bash matcher 和 jq 讀取 .tool_input.command：如果指令同時包含 deploy 與 production，又沒有 RELEASE_APPROVAL 環境變數，就把說明寫到 stderr 並以 exit 2 阻擋動作；符合條件則 exit 0 繼續。

Managed settings 的範例則把控制分成幾層：

這些設定只是起點，需要依資料分級客製；每一條 deny 都會拿走一些能力。衡量方式包括每個 gate 的等待時間，以及 hooks 前後違反 gate 而進入 production 的次數。

12. CI/CD integration and deployment

把 Claude 放進 CI/CD 前，先把 review 與 approval gate 建好。部署相關的 agent job 要在 sandbox 中非互動執行，使用短效且限縮範圍的 token，不帶常駐 production 憑證；deploy、status 和 rollback 則透過 MCP 暴露成 per-environment 的工具。

課程建議循序漸進：

1. 先用 claude -p 做唯讀判斷，例如分流失敗 build、摘要 flaky test、草擬 changelog。
2. 在既有 gate 後加入寫入步驟，例如修 lint、更新產生的文件或處理 review comment；agent 寫出的內容一律走 PR，沒有推到 main 的路。
3. 把 agent job 放進有 network policy 的 container，使用短效 token，預設不帶 production 憑證。
4. 把 deployment 工具透過 MCP 暴露，權力採 allowlist，不把帶憑證的 shell script 直接交給 agent。
5. 依環境分級自主度：development 可以讓 agent 自由部署，staging 介於中間，production 由 agent 準備 release、release manager 授權，hook 強制 gate。
6. 把 rollback 做成單一指令，定期在 staging 演練；Stage 6 的 control band 被突破時，才有一條已證明可行的回復路徑可呼叫。

官方範例是 CI job 在 failure() 時執行 claude -p，讀取 out/build.log，判斷失敗看起來是 flaky 還是真實問題，再把三行摘要寫進 PR thread。這種唯讀判斷很適合成為自動化的第一步。

核心治理原則是：agent 可以一路動作到 production gate，但不能越過它。branch protection 把 agent 寫的東西變成 PR，production deploy hook 等待具名 release manager 授權，pipeline log 也要區分觸發它的工程師與實際執行的 agent。

Stage 6: Maintain

13. Closing the loop on metrics

前面每個 stage 都還需要人來啟動。Stage 6 把維護工作改成可以自主運行的閉環：確定性的 detection script 監看 production，只有指標突破 control band 時才叫醒 Claude；agent 診斷、透過有 gate 的路徑行動，再把發現寫成 intent.md，重新流過前面的 stages。

這裡的關鍵不是讓模型一直盯著 production，而是把偵測和判斷分開。偵測完全由 script 負責，不涉及模型；模型只在符合條件的事件發生時被呼叫。可監看的指標包括 CI 測試失敗率、部署後的 5xx rate 和 PR cycle time。

執行流程如下：

1. 選一個有穩定滾動基線的指標。
2. 寫進版控的 detection script，搭配單元測試，用 rolling window、平均值、標準差和 Western Electric 等規則抓慢慢飄移或突然尖峰。
3. 在 bands.yaml 定義分級回應：1σ 只記錄，2σ 以唯讀工具叫 Claude 診斷，3σ 才能開 PR 或觸發預先核准的 runbook。
4. 用 GitHub/GitLab 排程 workflow、監控系統 webhook 或 cron 觸發非互動的 Claude Code，讓它 stateless 地在 CI runner 或 sandbox container 中執行。
5. 讓 agent 用 Stage 1 的格式寫出 intent.md，包含異常與證據、建議結果、受影響系統和 open questions。
6. 由 service owner 或 on-call 分流：立刻修、排程，或駁回；駁回結果可以拿來調整 control band、降低噪音。
7. 修復上線後，替該 incident 補一個 eval，讓相同問題進入未來的回歸測試。

官方範例把 ci_test_failure_rate 對到 rolling_30d baseline：1σ 只 log，2σ 用 Read、Grep 和 Bash(gh run view *) 做診斷，3σ 才能提出 pull_request 或 runbook:rollback-deploy。

課程列出三個例子：CI 測試失敗率突破 3σ 時隔離 flaky test 或開 revert PR；部署後 5xx rate 突破 3σ 且附近有部署時觸發既有 rollback pipeline；PR cycle time 出現 drift 時寫報告給工程領導層。這表示同一套 harness 也能處理流程指標，不只 production 指標。

另一個例子是 Claude on call with Claude Tag。incident 可能從 Slack 或 Teams 進來，Claude Tag 讓 Claude 以自己的身分成為頻道成員，透過 MCP 驗證指標是否回到基線，並把 post-mortem 寫入版控的 lessons file。小而明確的修復走 PR，大型變更寫成 intent.md 回到 Stage 1，讓 loop 自己餵回自己。課程中這些產品標示屬於當時課程內容，實際可用性仍要以目前服務狀態為準。

Closing

14. Closing thoughts and resources

模型和 harness 持續進步後，組織可以重新設計的範圍不只包含產生 code，還包括整個 SDLC。這份 playbook 建議從組織管理者的決策地圖開始，再依序理解 settings precedence、server-managed settings、permissions、sandboxing、hooks、Skills、plugins、managed MCP、enterprise deployment、OpenTelemetry monitoring、analytics dashboard、Compliance API 和 security model。

整堂課仍然把人的判斷放在核心位置：agent 可以整理需求、產生計畫、修正 code、分流事件和準備 release，但 intent 是否被接受、風險是否可接受、production 是否允許繼續，都要由明確的 gate 和具名的人負責。

從 artifact 到治理 gate

把 14 堂課放在同一張表裡，可以看出每個 play 產生什麼、由誰負責，以及控制強度落在哪裡：

小結

這堂課最關鍵的地方，在於它選擇的視角。它把 agent 放進團隊與企業的 SDLC 裡，討論規劃、審查、測試、部署和維護各階段要怎麼治理。雲端的 Claude、CI 裡的 claude -p、本機的 Claude Code 和 Agent SDK 都只是執行節點，真正讓流程能被治理的是它們之間留下的 artifact、權限和 gate。

它的定位是 playbook，重點放在原理、流程和角色分工。課程沒有附一組內建 Skill、starter kit 或公開的 Skill 套件，讓人照著理論直接實作並產出 intent.md、spec.md、plan.md 等文件；看到內容裡沒有一串可以照貼的指令，其實符合這堂課原本的定位。這是一門偏概念與理念的課，但裡面包含非常多 agent 在團隊和企業裡落地時會遇到的治理概念模型。

在我接觸過的 SDD（Specification-Driven Development）討論裡，重點通常集中在規格、需求、設計和實作之間的關係。這堂課讓我覺得比較不一樣的地方，是它把視線延伸到後面的 Deploy 和 Maintain：流程不在 code merge 後結束，部署後的指標、incident 和 control band 也會重新餵回 intent.md，讓整條 SDLC 形成閉環。這也是我讀完後最想帶走的理解；接下來看到 Skills 課程時，應該會更容易理解它在這條治理鏈裡負責哪一層。

我是 Jasper，從事軟體開發，目前專注打造 AI 工作流程。
本文同步發佈於我的 Blog，和我一起探討更多 AI 議題 🚀