Claude Academy
載入中

Claude Code 計劃模式作為預設起點

第 4 課6 分鐘

工程師以計劃模式啟動 Claude Code 工作階段，將第 2 階段：設計中已核准的 spec.md 提供給 Claude，並讓它對他們進行訪談，反覆修改計劃直到他們滿意為止。

有何改變

傳統方式AI 原生方式
工程師閱讀設計後就開始撰寫程式碼。變更將如何進行，細到哪些檔案、哪些測試，都只存在於工程師的腦中，頂多寫在工單留言裡。沒有其他人可以審查它。審查者第一眼看到的就是完成的差異（diff），到那時再重做就很慢了。工作從 Claude 在計劃模式下產生的書面計劃開始，在此模式下它可以讀取程式碼庫而不做任何變更。工程師在撰寫程式碼之前修正計劃，核准後的版本會以 plan.md 提交，供後續階段核對。

開始使用

  • 先決條件：若存在意圖產物（intent.md 或 spec.md），以及 CLAUDE.md 檔案會有所幫助。
  • 基礎設施：具有儲存庫存取權限的 Claude Code。

如何執行

  1. 工程師與 Claude 以計劃模式啟動工作階段。
  2. 工程師將 intent.md 和 spec.md 提供給 Claude，並要求提供一份實作計劃，列出會變更的檔案、工作順序，以及用來證明的測試。
  3. 透過詢問這項變更可能破壞什麼、哪個步驟風險最高，以及 Claude 選擇不採用的其他方案，來質詢這份計劃。
  4. 反覆修改，直到一位從未看過這段對話的工程師，僅憑這份計劃就能實作這項變更。
  5. 將核准的計劃以 plan.md 提交。該計劃會加入稽核軌跡，而 PR 審查流程（第 5 階段：部署）會依此核對最終的差異。
  6. 接受計劃並讓 Claude 進行實作。有了完善的計劃，實作通常只需一次就能完成。
  7. 當實作偏離計劃時，在同一次提交中更新 plan.md。可考慮使用 hook 來強制兩者保持同步。

實際樣貌

以下計劃是針對某保險公司的一項變更：客戶入口網站中顯示理賠狀態的面板。該面板會呼叫入口網站的後端 claims-api，而後者會從較舊的內部系統 claims-core 讀取資料。

plan.md：

markdown
# Plan: claims status self-service (from intent.md and spec.md)

## 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 (R1, R2, R3).
2. Panel against the endpoint, with the 60-second cache (R1, R4).
3. Wire into the portal nav.

## Risks

The claims-core API rate-limits at 50 rps; the panel must cache (spec concern 3).

## Proof

test_status.py covers the four claim states (R2) and fails on any extra field (R3); screenshot matches the approved mock.

R1 到 R4 是 spec.md 中編號的需求，而 concern 3 是 spec.md 標記出的一項風險。由於計劃引用了這些項目，審查者可以逐行核對計劃與規格。

治理考量

設計審查發生在產生任何程式碼之前，此時改變方向仍只是編輯文件的問題。計劃模式本身就強制執行這一點，因為在工程師接受計劃之前，Claude 無法編輯檔案。計劃及其修訂版本會連同核准者一起被記錄下來。常規變更由工程師核准，而組織歸類為較高風險的任何事項則交由技術主管或架構師處理。

如何衡量

  • 領先指標：第一次實作就合併的變更比例，以及從計劃核准到 PR 合併所需的時間，所需資料皆來自 PR 元資料。
  • 落後指標：每項變更的重做週期數，同樣來自 PR 元資料，以及合併後的差異與已提交的 plan.md 相符的頻率。

自動模式下的 Claude Code

Claude Code 也可以在自動模式下執行，工程師反覆修改並核准計劃，然後 Claude 會套用每項變更，而不需要逐次編輯的提示。隨著後續流程中的防護機制逐漸成熟（經過調校的 CLAUDE.md、將政策編碼的技能、阻止不安全操作的 hook，以及 Claude 可以執行的測試套件），自動模式會成為常規工作的預設方式：精簡的 spec.md、小範圍的影響半徑，以及測試已經涵蓋的程式碼。

這種轉變是從使用者觀看代理進行編輯並審查操作，轉向在較長的自主工作階段之後審查產物。當與 worktree 搭配使用時，自動模式能進一步實現個人與團隊之間的平行作業，並且是自主執行 SDLC 以及如第 6 階段：維護中所述完成閉環的基礎。

舊有系統與真實來源

現有的 SDLC 流程可能已經在追蹤產物，只是不是以 Markdown 檔案的形式。工作項目可能在 Jira 中，需求可能在內建法規可追溯性的工具中，設計可能在 Figma 中，而變更核准則透過變更委員會進行。這些系統很難被取代，因為稽核人員和監管機構已經接受它們，而其他團隊也依賴它們，因此 AI 原生的 SDLC 必須配合現有的系統運作。對於流程產生的每一項產物，應指定一個系統作為真實來源，其他系統則保留副本或連結。

以下配置可以設定為擁有一個真實來源，而選擇會因產物而異：

  • 以儲存庫作為真實來源。 Markdown 產物是權威記錄，而舊有系統則參照提交中的檔案。對於以工程為主導的組織而言，這可能是最簡潔的配置之一，因為所有記錄都存在於一個工具中，並由單一時間戳記權威管理。
  • 舊有系統即為真實來源。 Jira、ServiceNow 或需求工具持有權威記錄，而 Markdown 產物則是工作副本。Claude 在工作階段開始時讀取該記錄，並在產生規格或計劃的同一個工作階段中，透過 Model Context Protocol（MCP）連接器將結果寫回。
  • 以連結作為最低標準。 所有產物都會記錄該記錄的 ID，而所有舊有記錄都包含 Markdown 檔案的提交 SHA。在轉換至 AI 原生 SDLC 時，連結選項是一個很好的起點，因為此時存在兩個真實來源。

只要兩者之間存在連結，或其中一方被宣告為真實來源，舊有系統與 AI 原生的 Markdown 優先系統就可以共存。