過去一年，組織用 AI 寫程式的速度已經到了「一年前無法想像」的程度，但圍繞程式碼的流程幾乎沒有同步改變。多數工程團隊手上還是同一套審核閘門、同一套 review 流程、同一套交接與政策，結果就是：導入 Claude Code 這類 agentic coding 工具帶來的生產力，被流程本身吃掉。
Anthropic 的 Applied AI 團隊把他們對客戶做這件事的實務做法整理成一份公開課程：《The AI-native SDLC playbook》。整份教材共 14 課、約一小時，依軟體開發生命週期分成六個階段，每一課的結構都一樣——先講傳統做法與 AI 原生做法的差別，再給「怎麼開始」「怎麼執行」「長什麼樣子」「治理考量」「怎麼量測」。這篇文章把它完整拆開。
當程式碼不再是瓶頸：三個推論
課程開頭先立一個前提：傳統 SDLC 是為了「寫程式最耗時、最貴」的時代設計的。當 build 階段的產出速度被 agent 拉高，原本的流程設計反而變成阻礙。此時有三件事會同時成立：
- 瓶頸搬家。 它從 build 移到兩側的階段：主要是規劃（plan）、審查與測試（review／test）、部署（deploy）——這幾段還是用人類速度在跑。
- 控制手段開始失真。 逐行人工審查在「程式碼是人寫的」前提下才合理；一旦大部分 diff 是 agent 產生的，人工逐行審查就追不上，也失去原本的保證效果。
- 治理成本上升。 例外還是走會議與委員會，而委員會每週或每月才開一次，等於把整條流水線的節奏綁在最慢的那個環節上。
課程用資安團隊當例子：資安團隊的人力是為人類產出速度配置的。當 agent 把程式碼產出放大數倍，結果只有兩種——審查佇列堆積，或是程式碼在審查不足的情況下上線。對受監管的組織來說，這兩個選項都不能接受。
這份 Playbook 是什麼？誰適合讀
這不是「怎麼用 AI 寫程式」的入門課，而是怎麼改流程的手冊。課程明講它的目標讀者：
- 工程、平台與資安主管
- 組織已經在用 Claude Code
- 但審核閘門、review 與交接仍然以人類速度在跑
- 主要針對大型企業，尤其是受監管產業
課程的立場很清楚：這些 play 假設你有能力改變組織「規劃、審查、測試、部署」的方式，而不是只改變「寫程式」的方式。如果只能動到工程師的個人習慣，這套方法大概落地不了。
傳統 SDLC 與 AI 原生 SDLC 的差別
傳統 SDLC 的六個階段，每一階段由不同角色擁有，工作靠文件、票券與簽核在階段之間移動。它是「流程重」的設計，目的是在每一步確保問責與控制——而且在「寫程式最貴」的年代，這個設計是划算的。
AI 原生 SDLC 的改動，是把每個階段的產出換成版本控制裡的機器可讀檔案，並讓 agent 直接接手階段之間的轉換。以下六個階段的對照，是整份課程的主幹：
| 階段 | 傳統做法 | AI 原生做法 | 關鍵產出檔案 |
|---|---|---|---|
| 1. Plan | 想法經過 backlog、user story、story point、refinement 會議才有人能動 | 提出者直接跟 Claude 腦力激盪，寫成 proto-spec | intent.md |
| 2. Design | 分析師寫需求、設計師再把需求翻成設計，兩個階段分開、慢且有損耗 | 同一個 session 內，由 intent.md 生出需求＋設計規格，並標記疑慮 | spec.md |
| 3. Build | 工程師讀設計就開始寫程式，怎麼改只留在腦中或票券留言 | 先在 plan mode 產出書面計畫，人類修正後才開始寫程式 | plan.md、CLAUDE.md、skills |
| 4. Test | 訊號來得很晚：CI 幾分鐘後、測試人員幾天後、production 幾週後 | 讓 session 自己驗證（測試／build／截圖比對），通過了才給人看 | 測試套件、eval 套件 |
| 5. Deploy | PR 等人讀完、review 品質隨負載起伏、作者追著 reviewer 跑 | 所有 PR 跑同一套 review pass，人類注意力上移到意圖與風險 | REVIEW.md、hooks、CI/CD |
| 6. Maintain | 維護是被動階段，票券與事故都等人啟動 | 觸發器（指標越界、票券、訊息、排程）直接喚起 agent，人只做分類與審查 | 新一輪 intent.md |
Stage 1：Plan — 把想法寫成 intent.md
流程的起點是 intent.md。它可以從三種路徑進來：有人有想法、有人開了票、或系統發出告警（第三條會在 Stage 6 接回來）。不論哪一種，步驟都一樣，最後由 product owner 審閱並修正 agent 寫的 intent.md，才 commit。
執行步驟
- 提出者用自己的話把問題講給 Claude 聽。可以講「今天做不到什麼」「誰受影響」「更好的樣子是什麼」「什麼不在範圍內」，不需要任何正式格式。
- 一路腦力激盪到具體為止。Claude 會問分析師會問的問題：範圍、使用者、限制、成功的定義。
- 請 Claude 依組織範本寫成
intent.md。範本本身可以寫成 skill，由技術人員建置、主管簽核。 - 提出者修正 Claude 誤解的地方。
- commit 到共用的 intent 家目錄，作者與時間戳一併進入紀錄。
課程給的範例檔長這樣（理賠狀態自助查詢）：
# Intent: claims status self-service
Author: J. Ortiz (claims operations). Status: draft.
## Problem
Customers phone the contact center to ask where their claim is.
Handlers spend roughly a third of call time on status-only queries.
## Proposed outcome
Customers see claim status, next step and expected date in the portal.
## Affected users and systems
Claims handlers, portal team, claims-core API.
## Constraints
No new PII in the portal session. Existing authentication only.
## Open questions
Do third-party loss adjusters need access too?
基礎設施：非工程師也要有 Claude 存取權（claude.ai 或 Cowork）；一個議定的 intent.md 範本；一個共用且版本控制的 intent 存放位置。單一產品最簡單的做法，就是在產品 repo 底下開一個 intent/ 目錄，讓產出檔案緊貼著由它衍生的程式碼。沒有 Git 經驗的貢獻者不需要碰 Git——接上 GitHub 之類的 connector，讓 Claude 代為 commit。
量測
- 領先指標：從第一次對話到
intent.md被 commit 的時間（讀 Git 歷史）。課程的期待是從「數週的引導與 refinement 循環」壓到「數小時」。 - 落後指標：
intent.md的存活率——被 product owner 接受進入 Stage 2 的比例，而不是被關閉的比例；另外可以統計同一變更在spec.md首次 commit 之後，intent.md還被改了幾次。
Stage 2：Design — 一個 session 生出 spec.md
intent.md 被接受後，Claude 接手產出需求與設計規格，並且受組織的 skills（品牌、資安、合規、UX）約束。這裡有個容易被誤解的分工：product owner 審查規格，但不寫規格。
課程給的 prompt 幾乎可以直接抄：
Read the attached intent.md and produce a requirements and design spec for
integrating it into our existing codebase. Apply the skills available to you
so the plan conforms to our brand guidelines, security policies and UX
standards. Document the spec fully as spec.md, ready to hand to the
engineering team. Describe clearly any areas of concern, especially where you
cannot satisfy contradicting policies.
執行步驟
- product owner 開啟 session（組織 skills 已載入），附上
intent.md。 - prompt 指向 intent、點名限制、要求標出疑慮。一開始手動跑，之後把它固定成組織層級的 slash command；成熟後可以把「intent 被 merge」當觸發器，用非互動式任務自動跑完並把
spec.md開成 PR。 - product owner 對照原始想法審規格：這份規格有沒有解決原本的問題？
intent.md的未解問題是被回答了還是被帶下來？ - 先處理被標記的疑慮。 這些就是分析師會往上呈報的點；在工程看到規格之前，product owner 要先跟對應的政策負責人解決。
spec.md與intent.md一起 commit。這對檔案記錄了「要求了什麼」與「決定了什麼」。- 由人類（必要時諮詢技術主管）決定是否進入 build。接受規格，就是啟動 Stage 3 的 plan mode play。
量測：領先指標是 intent.md commit 到 spec.md commit 的兩個 Git 時間戳差距；落後指標是 build 開始後的需求返工量——統計同一變更在 plan.md 首次 commit 之後才出現的 spec.md commit。
Stage 3：Build — plan.md、CLAUDE.md、Skills、平行 session
Stage 3 是課程裡最厚的一段，共四課：plan mode、CLAUDE.md、skills、平行 session 與 subagent。
plan mode 當預設起點
工程師用 plan mode 開 session，把 Stage 2 通過的 spec.md 交給 Claude，讓它反問、迭代，直到計畫可接受。plan mode 本身就是一種設計審查閘門：Claude 在計畫被接受前不能改檔案。
課程建議第 3 步是「審問計畫」——問它這個變更可能弄壞什麼、哪一步最危險、它放棄了哪些其他選項。第 4 步的驗收標準很具體：一個完全沒看過對話的工程師，光看計畫就能實作。 通過後把計畫 commit 成 plan.md。
# Plan: claims status self-service (from intent.md 2026-06-02)
## Files that change
portal/src/claims/StatusPanel.tsx (new), claims-api/routes/status.py,
claims-api/tests/test_status.py
## Order of work
1. Add the status endpoint behind existing auth.
2. Panel against the endpoint.
3. Wire into the portal nav.
## Risks
The claims-core API rate-limits at 50 rps; the panel must cache.
## Proof
test_status.py covers the four claim states; screenshot matches the approved mock.
課程也提到 auto mode：工程師仍然審計畫，但 Claude 之後不必每一次編輯都確認。當護欄成熟（調好的 CLAUDE.md、把政策寫成 skills、會阻擋危險動作的 hooks、可執行測試），auto mode 就會變成日常工作預設——前提是 spec.md 夠緊、影響半徑夠小、且測試已覆蓋。課程把這個轉變講得很直白：使用者角色從「盯著 agent 每一次編輯」變成「在較長的自動 session 之後審查產出檔案」。
CLAUDE.md：給 agent 的新人上手包
CLAUDE.md 要放的是「一個新人第一天需要知道的事」：慣例、指令、架構、以及團隊最常看到的錯誤。做法是 claude-code 的 /init 產生初稿，然後砍到剩真正必要的內容，commit 進 repo 根目錄，讓全隊共用一份。
課程給了一條很好用的工作規則：當 Claude 同一個錯誤犯第二次，就把修正寫進 CLAUDE.md。 另一個實務限制是長度——Claude 每次開 session 都會讀完整份，所以最好控制在一頁以內，過期內容只是白白佔 context。
# Payments service
## Commands
- Build: make build
- Test: make test (unit), make itest (integration, needs docker)
- Lint: make lint (runs in CI; fix before pushing)
## Conventions
- Java 21, Spring Boot 3. No new Lombok.
- Money is always BigDecimal, never double.
- Every endpoint needs an integration test in src/itest.
## Architecture
- api/ holds REST controllers, core/ holds domain logic,
adapters/ talks to external systems.
- Kafka events are defined in schemas/; never edit generated classes.
## Things Claude gets wrong
- Do not bump dependency versions; the platform team owns them.
- The legacy v1/ package is frozen; changes go in v2/.
Skills：把制度知識變成可執行檔
Skills 是組織把「制度知識」變成可操作資產的方式：顯式、版本控制、廣泛套用，政策改了就在中央更新。判斷標準很簡單——必須被一致套用的制度知識才寫成 skill；屬於 CLAUDE.md 或單次 prompt 的東西就不要寫成 skill。
skill 的實體是一個資料夾，內含 SKILL.md：frontmatter 說明何時觸發，body 說明要做什麼。放在 repo 的 .claude/skills/<name>/ 就跟著程式碼出貨；要全組織散佈就走 plugin。
---
name: secure-api-review
description: Apply the API security standard. Use whenever creating or
modifying an external-facing endpoint, reviewing API code, or
generating an OpenAPI spec.
---
# Secure API review
When you create or change an API endpoint:
1. Authentication: every endpoint requires the gateway JWT;
no anonymous routes outside /health.
2. Input validation: validate request bodies against the OpenAPI
schema and reject unknown fields.
3. Audit: every state-changing endpoint emits an audit event with
actor, action, entity and timestamp.
4. Data classification: fields tagged pii in the schema must never
appear in logs or error messages.
Run scripts/check-endpoints.sh and include its output in your summary.
課程對 skills 的定位講得很誠實：skill 是一種控制，但是「諮詢性」的控制。 它讓 Claude 在寫程式的當下比較可能套用政策，但沒有任何機制強制 session 遵守。所以真正必須成立的規定，背後要有確定性的東西——一個會擋掉動作的 hook，或是在 PR 再檢查一次政策的 review pass。skill 讓違規變少，hook 讓違規近乎不可能。
平行 session 與 subagent
一個工程師可以同時推動好幾條工作流：
- 平行 session：另一個完整的 Claude Code 實例，在自己的 Git worktree 上做另一個任務。每個獨立 session 彼此不知道對方存在，唯一的共享資源是操作它們的工程師。
- subagent：跑在單一 session 內的範圍化幫手，有自己的 context window 與工具限制，適合在多個任務中重複出現的工作。
課程建議從兩到三個 session 起步，實際上限定義在天花板——取決於一個人能好好審查幾條流，審查跟不上就不要再開。重複性的工作則包成 subagent，定義放 .claude/agents/：
---
name: verifier
description: Runs the app and checks the change works before the session reports done
tools: Bash, Read
---
Start the app with make run. Exercise the changed behavior and the two
nearest neighboring flows. Report what you ran, what you saw, and any
behavior that does not match plan.md. Do not fix anything; report only.
Stage 4：Test — 給 Claude 一個回饋迴圈
核心原則只有一句：永遠給 Claude 一個能自己驗證工作的方式——測試、build，或截圖比對。session 在自己修錯，人看到的已經是「通過驗證」的結果。
課程特別澄清一個容易混淆的地方：回饋迴圈不等於 verifier subagent。回饋迴圈在整個任務中會跑很多次；verifier subagent 是在 session 自認完成後，用一個乾淨的 context window 做最後檢查，避免結論被「產出程式碼時的那些假設」污染。
執行步驟
- 如果驗證今天要跑一串指令加上環境知識，把它包成單一目標（
make test、npm test），失敗時回傳非零。 - 在
CLAUDE.md的 Commands 段落列出每個指令，並附上「健康輸出」的樣子。 - 把目標寫成可量化，讓 Claude 不必問你就能判斷，例如「
test_status.py全部通過」「截圖與附上的 mock 一致」「端點回 200 且帶新欄位」。 - 修 bug 時先寫失敗的測試：請 Claude 用測試重現 bug、確認它以預期原因失敗、commit 這個測試，然後才請它修到通過，且不准改測試。課程的說法是：一個在修復前就存在、agent 又改不動的測試，就是 bug 已經消失的證據。
- UI 工作要收在視覺檢查上：給 Claude 瀏覽器或截圖工具、給它 mock，讓它實作—截圖—比對—調整，兩三輪是正常的。
- 把驗證寫進「完成」的定義，放在
CLAUDE.md：回報任務完成前必須跑測試，並貼出輸出。 - 最後要保護迴圈本身：修程式的 agent 不能夠削弱檢查它的那個測試。用 hook 在修復任務中封鎖測試檔的編輯，或在 review 階段檢查 diff、拒絕任何動到測試的變更。
把評估放進 CI：continuous evals
Evals 是 AI 原生版的「階段閘門 QA」。實務上就是一套在 agent 設定變更時就跑的測試套件：換模型、改 prompt、動 skills 或 hooks 時，eval 套件回答一個問題——agent 還能不能做到同樣標準？
做法是：平台工程師從近期工作收集 20 到 50 個真實任務（各附可接受的結果），每個任務寫成一個 eval（prompt 加上判定「可接受」的檢查），在 CI 中非互動執行，並且把設定變更也納入閘門——skill 改動若讓通過率下降，就要先被 review 才能 merge。課程另外補了一條很有價值的規則：每一次 production 事故都要變成一條 eval，永久留在套件裡當回歸測試。
name: Agent evals
on:
pull_request:
paths: ['CLAUDE.md', '.claude/**']
schedule:
- cron: '0 2 * * *'
jobs:
evals:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm install -g @anthropic-ai/claude-code
- name: Run eval suite
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
run: |
for eval in evals/*.json; do
claude -p "$(jq -r '.prompt' $eval)" \
--allowedTools "Read,Edit,Bash(make test)" \
--output-format json > result.json
./evals/check.sh "$eval" result.json
done
Stage 5：Deploy — PR 審查、Hooks 閘門與 CI/CD
AI 進到 PR review 迴圈
課程的設定是 Claude 兩邊都做：審別人的 PR，也回應自己 PR 上的 review 留言。人類的注意力因此上移到一個層級——判斷意圖與風險，而不是逐行讀 diff。
實作上，讓技術主管在 repo 根目錄寫一份 REVIEW.md，把關心的審查分成幾個 pass：bug 與邏輯錯誤、資安與漏洞、以及對照 spec.md、plan.md 與設計原則的合規檢查。同時定義什麼算 Important、什麼只是 nit。
# Review instructions
## Passes
Run three passes and tag each finding with its pass:
- Bugs: logic errors, broken edge cases, subtle regressions
- Security: injection risks, authentication gaps, PII in logs
- Compliance: the change matches spec.md, plan.md and our design principles
## What Important means here
Reserve Important for findings that would break behavior, leak data
or breach a policy. Style and naming are nits.
## Cap the nits
Report at most five nits per review; summarize the rest as a count.
## Do not report
Generated files under src/gen/ and anything CI already enforces.
兩個關鍵的治理設計：findings 本身不會批准也不會阻止 PR（branch protection 仍然要求 code owner 核准），以及職責分離被保住——寫程式的 agent 沒有任何途徑可以核准它自己寫的程式碼。另外，課程強調 review finding 要回流到 CLAUDE.md：同一個錯誤被 review 抓到第二次，就把修正寫進去，因為 review 會讀 CLAUDE.md，下一次 PR 就自動被擋掉。
Hooks 當審核閘門
Build 階段的 hook 是「護欄」（允許或阻擋，沒有人參與）；到了 Deploy 階段，hook 可以變成 ask——暫停動作，等特定的人核准。課程給的範例是 production 部署授權：
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{ "type": "command",
"command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/production-gate.sh" }
]
}
]
}
}
#!/bin/bash
# Production deploys require a named release authorization
cmd=$(jq -r '.tool_input.command' < /dev/stdin)
if [[ "$cmd" == *"deploy"* && "$cmd" == *"production"* ]]; then
if [ -z "$RELEASE_APPROVAL" ]; then
echo "Production deploys need a release authorization." >&2
exit 2 # exit 2 blocks the action; the message goes to Claude
fi
fi
exit 0
團隊的 hooks 放 .claude/settings.json 進版控；不可協商的 hooks 放 managed settings，由平台或 IT 管理，個別工程師無法關掉。課程提醒：阻擋要能自我說明——hook 擋下動作時，原因與取得授權的路徑必須出現在 Claude 的輸出裡。
CI/CD 整合與部署
這一段的順序原則值得抄下來：先把閘門做出來，再讓自動化加速穿過它。 具體做法是：
- 從唯讀的判斷步驟開始：用
claude -p在 pipeline job 裡分流失敗的 build、整理 flaky test、草擬 changelog。 - 寫入型步驟放在既有閘門後面（修 lint、更新產生的文件、處理
@claude留言）。agent 寫的任何東西都以 PR 形式進來，沒有任何路徑能直接 push 到 main。 - 執行要沙箱化：agent job 跑在容器裡，搭配網路政策與短效範圍憑證，預設不持有 production 憑證。
- 部署透過 MCP 暴露成工具（deploy、status、rollback），每個環境各自授權——讓 agent 的部署權限是一份 allowlist，而不是一支帶著憑證的 shell script。
- 依環境分級自主權：開發環境 agent 自由部署；production 由 agent 準備、release manager 授權，並由 hook 強制這個閘門。
- Rollback 應該是整條 pipeline 裡最熟練的路徑，一條 agent 能執行、且定期在 staging 演練的指令——因為 Stage 6 會在控制頻段被突破時呼叫它。
Stage 6：Maintain — 讓指標自己把流程跑起來
前五個階段都還需要人啟動，Stage 6 的重點是讓 Claude 自主運行、把迴圈閉起來。課程給的圖像是：一個持續運行的監控 agent 從 bug ticket 出發，自己產生 intent.md，然後流經需求、計畫、build、test、review。這個階段是 headless 運行，階段之間有一個獨立的信心閘門（確定性檢查或一個對抗式審查 agent）決定要繼續還是升級給人類。
做法是：
- 選一個有穩定滾動基線的指標（CI 測試失敗率、部署後 5xx 率、PR cycle time）。
- 寫偵測腳本——滾動視窗的均值與標準差，加上 Western Electric 之類的規則，才抓得到緩慢漂移。偵測完全確定性，不涉及模型。
- 回應分級寫在版本控制的設定裡：1σ 只記錄、2σ 喚起 Claude 做唯讀診斷、3σ 允許 Claude 行動，但只能開 PR 進 review 閘門，或觸發事先核准的 runbook。
- 觸發層可以是 GitHub 排程 workflow、webhook，或 Agent SDK 寫的服務。
課程對這個階段的定位很務實：監控越界只是「迴圈自主運行」這個模式的其中一個例子，重點是人不再需要啟動工作，只需要分類與審查工作。
產出檔案總表：誰簽核、留在哪一層
把六個階段串起來，會得到一條以 Git 為骨幹的檔案鏈。這條鏈同時是流程紀錄，也是稽核軌跡：
| 檔案 | 出現在 | 用途 | 誰簽核 |
|---|---|---|---|
intent.md | Stage 1 | 用提出者自己的話記錄「要什麼、為什麼、受什麼限制」 | product owner |
spec.md | Stage 2 | 需求與設計規格，受品牌／資安／合規／UX skills 約束 | product owner（疑慮轉給政策負責人） |
plan.md | Stage 3 | 會動到哪些檔案、工作順序、風險、驗證方式 | 工程師（高風險變更升級給技術主管） |
CLAUDE.md | Stage 3 | agent 的常駐上下文：指令、慣例、架構、常見錯誤 | code owner（像程式碼一樣 review） |
.claude/skills/ | Stage 3 | 必須一致套用的制度知識 | 政策負責人 |
.claude/agents/ | Stage 3 | 重複性工作的 subagent 定義 | 進版控、全隊共用 |
| eval 套件 | Stage 4 | agent 設定變更的回歸測試 | 擁有該設定的團隊 |
REVIEW.md | Stage 5 | PR 審查的 pass 定義與嚴重度標準 | 技術主管 |
| hooks／managed settings | Stage 3、5 | 護欄與審核閘門 | 平台或 IT 管理員 |
bands.yaml 等分級設定 | Stage 6 | 指標越界的回應層級 | 服務負責人 |
治理重點：受監管企業的 managed settings
課程對受監管企業另外給了一組 managed settings 範例，由平台團隊透過 MDM 或管理主控台部署，工程師無法編輯或覆寫。它的設計邏輯值得理解，因為它示範了「多層防護」怎麼疊：
{
"permissions": {
"deny": [
"Read(.env*)", "Read(./secrets/**)",
"WebFetch", "Bash(curl *)", "Bash(wget *)"
],
"allow": [
"Bash(git *)", "Bash(make build)",
"Bash(make test)", "Bash(make lint)"
],
"disableBypassPermissionsMode": "disable"
},
"allowManagedPermissionRulesOnly": true,
"sandbox": {
"enabled": true,
"failIfUnavailable": true,
"allowUnsandboxedCommands": false,
"network": { "allowedDomains": ["git.internal.example.com", "registry.npmjs.org"] },
"credentials": {
"files": [
{ "path": "~/.ssh", "mode": "deny" },
{ "path": "~/.aws/credentials", "mode": "deny" }
],
"envVars": [ { "name": "GITHUB_TOKEN", "mode": "deny" } ]
}
},
"allowManagedHooksOnly": true,
"disableSideloadFlags": true,
"allowManagedMcpServersOnly": true,
"strictKnownMarketplaces": [
{ "source": "github", "repo": "example-corp/approved-plugins" }
],
"requiredMinimumVersion": "2.1.193"
}
課程把每個欄位翻成控制語言，這段是全文最值得細讀的地方之一：
permissions.deny把機密擋在 agent 的 context 之外，同時阻斷工具層的任意網路出口；permissions.allow預先核准安全的內圈指令，避免 deny 清單變成「審核疲勞」。disableBypassPermissionsMode加上allowManagedPermissionRulesOnly，代表沒有任何工程師、專案檔或命令列參數可以放寬規則。sandbox處理權限管不到的部分：工具層的 WebFetch 禁令擋不住 shell 指令連外，OS 層的網域 allowlist 才是真正阻斷出口的地方——兩個層次在執行同一個目標。failIfUnavailable與allowUnsandboxedCommands把沙箱變成前置條件：沙箱起不來 Claude Code 就拒絕啟動，沙箱內失敗的指令不能拿到外面重試。credentials補上 deny 規則漏掉的情境：permissions.deny管的是 Claude 的檔案工具，但沙箱內的 shell 指令預設還是讀得到~/.ssh或~/.aws/credentials。allowManagedHooksOnly代表只有 managed settings 裡定義的 hooks 會執行。disableSideloadFlags與strictKnownMarketplaces保證工程師機器上的每一個 skill、agent、hook 或 MCP server 都來自組織核准的 marketplace。requiredMinimumVersion拒絕在低於核准版本時啟動——控制是由「組織真的評估過的那個 build」在執行的。
這套方法的限制與批判
課程本身寫得相當自覺，但作為一份「官方 playbook」，它談的是成功路徑。以下幾點是第三方分析與業界研究普遍提出的保留，值得在導入前先想清楚：
- LLM 自我評分不能取代確定性檢查。 有研究觀察到多個獨立的 LLM 評審可能一致通過一個實際上不存在、或根本沒被真正檢查的問題；agent 之間的共識不等於編譯器、linter、或真實測試執行的結果。這正好呼應課程自己的立場——skill 是諮詢性的，必須有 hook 或確定性檢查在背後。反過來說，如果一個組織只抄了 skill 而沒有補 hook，就等於只拿到一半的控制。
- 誤差會沿著鏈條累積。 多 agent 串接下，上游一個小幻覺（例如誤判權限邏輯）會被下游繼承並放大，後續 agent 花大量 token 修一個不存在的問題，最後被人退回，成本是非線性累積的。
- 自動化偏誤會讓閘門失效。 當產出格式看起來很專業，人類容易降低警覺。課程自己給了兩個偵測這種「治理假象」的訊號：
intent.md接受率接近 100%，代表沒有人在審；product owner 每份檔案審不到一分鐘，代表只是蓋章。課程甚至說，「幾乎正確」的 intent 檔比沒有更危險，因為下游的規格、程式碼與測試會自信地繼承那個錯誤。 - 對小團隊可能過重。 這套流程明確是為「審查佇列不能堆積、程式碼不能審查不足」的大型與受監管組織設計的。對兩三個人的團隊來說，完整的檔案鏈與閘門可能比它省下的時間更貴——比較合理的做法是只取其中幾塊（例如
CLAUDE.md、回饋迴圈、hooks）。 - Legacy 系統不會消失。 課程自己花了一段談源頭唯一性：Jira、ServiceNow、有法規追溯性的需求工具、Figma、變更委員會都還在，而且稽核與法規已經接受它們。務實的配置有三種——以 repo 為唯一真相、以 legacy 系統為唯一真相（Claude 用 MCP 讀寫）、或以「互相連結」為最低標準（兩邊都記對方的 ID 與 commit SHA）。課程也建議轉型期先從第三種開始。
- 成熟度有前置條件。 Stage 6 的自主迴圈要求
intent.md、PR review、hooks 與可用的 rollback 路徑都已經到位。少了這些，自動化只是把錯誤跑得更快。
實務落地順序建議
如果把課程的六個階段攤成一條導入路線，先後順序其實是內建的：先把閘門做出來，再加速穿過閘門。對照課程的依賴關係，一個合理的順序是：
CLAUDE.md（成本最低、立刻影響所有 session）- 回饋迴圈：可一鍵執行的 build／test／lint，並寫進「完成的定義」
- plan mode 當預設起點，產出
plan.md - 把一項必須一致套用的政策寫成 skill，並補上對應的 hook
- PR review pass（
REVIEW.md） - eval 套件進 CI，設定變更納入閘門
- hooks 作為審核閘門 ＋ managed settings（受監管組織必做）
- 最後才是 Stage 6 的指標迴圈
站上另外兩篇可以搭配著讀：Claude Skills 最佳實務 2026 補齊 skills 的寫法細節，Vibe Coding 2.0 實戰指南 談規格驅動的個人工作流。如果想要對照「規格驅動」的開源實作，OpenSpec 是另一個路線；要把多個 agent 的協調問題拆開看，可以延伸讀 Google AX 完整教學。
結語
這份 playbook 真正想講的，其實不是「AI 會寫程式」這件事，而是流程的哪一段還卡在人類速度上。當 build 階段被 agent 壓縮之後，原本為了「確保每一步都被檢查」而存在的流程設計，會從保障變成枷鎖；解法不是拆掉檢查，而是把檢查換成另一個形式——寫成檔案、寫成 skill、寫成 hook，並且讓它們都進版控。
課程最後的立場也很清楚：轉型的目標是把人類判斷留在流程中心，同時滿足大型企業的治理與法規要求。對台灣的工程團隊來說，這份教材最實用的地方不是架構本身，而是它把每個階段都給了「怎麼量測」——領先指標與落後指標各是什麼。因為沒有量測，就分不出「真的把瓶頸移開了」與「只是把工作換了個地方堆著」。
資料來源
- The AI-native SDLC playbook（Claude Academy，14 課）
- Introduction｜Capture as intent.md｜Requirements and design｜Plan mode｜The CLAUDE.md｜Skills as institutional knowledge｜Parallel sessions and subagents｜Give Claude a feedback loop｜Continuous evals in CI｜AI in the PR review loop｜Hooks as approval gates｜CI/CD integration and deployment｜Closing the loop on metrics｜Closing thoughts and resources
- Complete guide to building skills for Claude（Anthropic 官方部落格）
- Claude Code subagents 文件｜Code Review 文件｜Claude Code auto mode
- Agent Skills overview（Claude Platform Docs）
- Give Claude context: CLAUDE.md and better prompts（Claude Help Center）