Anthropic 釋出一份題為「AI 原生軟體開發生命週期」的手冊，把公司內部圍繞 Claude 重新排列的開發流程拆成六個階段公開。文件的出發點寫得直白：程式碼生成已經不再是瓶頸，傳統流程按照人工打字寫程式碼的速度設計，卡關的位置因此換了地方。
六個階段依序是規劃、設計、建置、測試、部署、維運，每個階段的做法都被重寫過一遍。規劃從需求會議加手寫文件，改成與 Claude 對話後產出 intent.md，文件給出的說法是週期從數週壓縮到數小時；設計在一次會話裡產出 spec.md 並跑政策檢查；建置先出 plan.md 再進入實作；測試不再只守在階段邊界，持續評估被併入實作過程；部署換成分層自動審查加上 Hook 把關；維運則從被動回應告警，改成自動偵測後生成新的 intent.md 回到起點。
串起這六段的是檔案，不是會議。intent.md 交給 spec.md，spec.md 交給 plan.md，再往下是 PR 與審查結果，最後事件紀錄繞回 intent.md。文件把這條鏈概括成一句承諾：每個階段都要交付一項可供下一階段讀取的產出物。
四項治理產出物
Skills 負責制度化知識。API 安全標準、品牌規範這類東西被寫進 .claude/skills/，政策一改，中央改一次，工程師下次會話就自動拿到新版。文件舉的例子是一個叫 secure-api-review 的 skill，負責盯身分驗證、輸入參數檢查與稽核日誌。
Hooks 負責確定性的管控，沒有人工繞道的路徑。建置階段擋下對凍結相依套件的修改、強制跑格式化；部署階段的正式環境發布需要發布經理授權，未經授權直接以 exit code 2 阻斷。
CLAUDE.md 是團隊的記憶，篇幅控制在一頁：建置指令、慣例、架構、常犯的錯誤。文件給的維護原則很務實——同一個錯誤犯到第二次，就寫進去。
evals 當回歸測試用。20 到 50 個真實任務組成評估集，設定一改就跑，另外每晚也定時跑一輪；每一次正式環境事故都被固化成一條永久 eval，通過率直接作為合併的條件。
一個理賠查詢功能怎麼走完整個流程
文件舉的案例是理賠狀態自助查詢。營運端先寫 intent.md，說明問題、使用者與限制，產品負責人審查核准後進入設計階段；Claude 套用 UX 與安全 skills 產出 spec.md；工程師進入 plan 模式拿到 plan.md，接著由 Claude Code 實作，PR 通過審查 Hook 後才合併。
限制條件被明確寫進計畫裡：claims-core 介面限制 50 rps，所以 plan.md 標注了需要快取；會話過程中不得新增個人身分資訊；驗證走既有方案。另一個支付服務團隊的 CLAUDE.md 則寫著 Java 21、Spring Boot 3、禁用 Lombok、金額必須用 BigDecimal 而非 double、相依版本由平台團隊管理不許自行變動。
指標清單洩露了讀者是誰
領先指標包括從第一次對話到提交 intent.md 的時間、提交到第一次審查的時間、並行 agent 工作階段數、CI 通過率；落後指標包括 intent.md 的通過率、首次實作的成功率、PR 審查發現問題數的趨勢、正式環境事件重複率、每位工程師每週合併的 PR 數。
搭配的還有兩條合規路徑：一條以 Jira 或 ServiceNow 為權威紀錄、markdown 當工作副本，透過 MCP 連接器同步回舊系統；另一條以儲存庫為唯一真實來源，舊系統只引用 commit SHA。稽核軌跡靠 Git 歷史、PR 討論串、OpenTelemetry 匯出的 agent 行為紀錄，以及 Hook 的放行／阻擋日誌四路拼齊。
這套東西不是為個人開發者準備的。粗略估算一下，一個兩三百人的工程組織若照文件的說法把評估集全面鋪開，每次設定變更加上每日定時各跑一輪，光是推論成本就是一筆長年的固定開銷，再加上 skills 與 hooks 需要專人維護——治理產出物本身要花錢要花人力，效益卻往往要等好幾季才看得出來。這也是這類流程改造在中型公司通常推不動的地方。願意為稽核軌跡付這筆錢的組織，才是這份手冊真正瞄準的客戶。
參考來源：Anthropic 官方工程文件、CocoLoop、Claude Code 產品文件；核實六階段產出物命名、三級門檻設定與評估集數量的說法。