各組織已開始以一年前難以想像的速度使用 AI 來撰寫程式碼，然而圍繞程式碼的流程卻未能以同樣的速度改變。
軟體開發生命週期（SDLC）是將軟體從構想推進到生產環境的流程。大多數組織都運行著某種版本的相同六個階段，涵蓋規劃、設計、建置、測試、部署與維護軟體。
轉變
下表突顯了傳統 SDLC 與由 Claude 支援的 AI 原生 SDLC 之間的光譜兩端。大多數組織的位置介於這兩欄之間。
| 階段 | 傳統 SDLC | AI 原生 SDLC |
|---|---|---|
| 規劃 | 需求由委員會收集，經由工作坊與簽核提煉，再以人工方式撰寫 | Claude 直接從來源彙整痛點，並將其記錄於 intent.md 中，該檔案兼具人類可讀性與機器可執行性 |
| 設計 | 規格由分析師撰寫，再由設計師解析 | 需求與設計在與代理人（agent）的一次工作會議中壓縮完成，並由編碼為技能（skills）的標準引導，並在 Git 中進行版本控管 |
| 建置 | 測試與程式碼皆為手寫，文件則在主要開發完成後才撰寫 | 測試與程式碼由 AI 生成，組織知識則以版本化、機器可讀的 CLAUDE.md 檔案與技能形式維護 |
| 測試 | QA 關卡設於各階段邊界 | 持續性評估（evals）貫穿整個實作過程 |
| 部署 | 人類審查每一行程式碼，治理則在審查週期中進行，且往往不一致 | 多層代理式審查，人類審查僅保留給受監管與關鍵程式碼。治理在 AI 執行動作時即被強制執行，並以 hooks 作為核准關卡 |
| 維護 | 人類監看生產環境中的錯誤 | 代理人監控即時部署。任何違反控制範圍的情況都會被診斷，並以新的 intent.md 寫回循環中 |
對於任何需要判斷力的決策，人類仍須負責。
各項實踐（play）如何運作
這些實踐是本手冊的核心，分為六個非線性階段（規劃、設計、建置、測試、部署、維護），合起來涵蓋了完整的生命週期。
每項實踐涵蓋：
- 有哪些改變
- 如何開始
- 具體的實作步驟
- 治理考量
- 如何衡量是否成功
每項實踐都在「先決條件」下列出其依賴項，依賴關係圖進一步說明了這一點。
這張實踐依賴關係圖。位於最上方一列的實踐沒有先決條件；實線箭頭指向以其為基礎的實踐，虛線箭頭則表示有助益但非必需。
選擇您的第一項實踐
這些實踐是模組化的，各組織可根據自身獨特需求，選擇在不同時間優先轉型不同的階段。
上圖最上方一列的六項實踐沒有先決條件：
- 規劃：以 intent.md 捕捉意圖
- 建置：以 Claude Code 的規劃模式（plan mode）作為預設起點
- 建置：CLAUDE.md
- 建置：將技能作為組織知識
- 測試：為 Claude 提供回饋循環
- 部署：以 hooks 作為核准關卡