【2026 最新】Claude Code 大專案規劃怎麼做？Session 級規格、驗收與回寫教學

你想用 Claude Code 做一個大功能，打開文件卻看見十幾個 epic、幾百張待辦卡。每張都寫得像已經確定，程式碼一改，後面的卡又得重寫。Claude Code 大專案規劃到底要先寫多細，才不會把時間花在維護過期計畫？

這篇寫給第一次帶 Coding Agent 做跨多個 Session 專案的讀者。你不用先懂專案管理術語；我們用一個「活動報名頁加上候補名單」的小功能，帶你寫一頁方向、下一輪任務卡、可觀察的驗收條件，以及做完後的規格回寫。

以下是依Claude Code 官方最佳實務與跨 Session 記憶文件整理的編輯方法，查核日期為 2026 年 10 月 5 日。本文的候補名單是教學範例；維護量比較是示範如何記錄，並非 AlphaLab 的實測數據。

先說結論：只把下一個 Session 寫到能驗收

一句話記住：大專案規劃＝長期方向寫清楚＋下一輪寫到可驗收＋每輪依現況回寫。把它想成開車：先知道目的地與不能走的路；只替眼前一段設導航，走完再看路況。不是每一個未來轉彎都要先畫到公尺。

• 長期層：一頁寫清楚目標、不能違反的條件、未知問題和成功畫面。
• Session 層：只為下一輪選一件能完成的改動，附可由人或程式觀察的驗收條件。
• 回寫層：結束前對照程式與測試，改動後續卡片的假設，留下「現在有效的是什麼」。

Claude Code 大專案規劃，先停在哪裡？

停止規則很簡單：下一輪可以開始做，而且做完知道如何判斷成敗，就先停止細化。之後的任務只需保留順序、依賴與風險；如果它依賴尚未決定的介面或資料模型，今天把細節寫滿，只會把猜測包裝成承諾。

Anthropic 在官方最佳實務把探索、規劃、實作和驗證分開，也建議大型功能先訪談需求，將自足規格寫入 SPEC.md，再用乾淨 Session 執行。這支持「先留下可用規格」，卻沒有替每個團隊規定要提前拆幾張卡。下文的三層停止規則是本文的操作建議。

第一層：一頁方向，不預寫每個檔案

在專案根目錄建立 SPEC.md。先寫「誰要完成什麼」「哪些行為不能退步」「還不知道什麼」；每一句都能在後續更新。以活動報名頁為例：目標是名額滿時可加入候補；既有報名確認信仍照常發送；未知的是候補順位與取消後補位的產品規則。未知事項寫成問題，不讓 Agent 自行補成事實。

第二層：下一個 Session 才拆到動作

把下一輪命名為「新增候補登記，不處理自動補位」。任務卡列出可能涉及的畫面、API、資料欄位、禁改範圍和驗收。這是一次工作約定，不是保證每個檔案最後都照預測修改。先請 Claude 探索相關程式，再確認卡片中的路徑和依賴是否真的存在。

第三層：遠期只留地圖

例如後續可能有「取消後補位」「管理員匯出」。先記依賴與未決問題，不寫固定 API 名稱、資料表欄位或測試檔名。當前一輪真的決定資料模型後，再細化下一張卡。這就是「逐 Session 細化」：詳細程度跟證據一起前進。

一個完整例子：把候補名單拆成可交付的一輪

以下文字可以直接複製到 SPEC.md。先以自己的專案檔案與測試指令替換方括號內容。把規格視為工程合約草稿：它描述要看到的結果，也誠實保留還沒決定的部分。

1. 目標。名額滿時，使用者可提交候補資料，看到「已加入候補」確認；一般報名流程仍可用。
2. 邊界。本輪只做候補登記與重複提交提示；自動補位、付款、通知信列為後續工作。
3. 未知。同一電郵是否可跨活動候補？產品負責人尚未決定；本輪先讓 Claude 找出目前報名唯一性規則，回報選項。
4. 驗收 A。名額未滿時仍走原本報名流程，既有相關測試通過。
5. 驗收 B。名額已滿時提交有效資料，畫面顯示候補確認；再次提交同一活動與電郵，畫面顯示可理解的結果，不重複建立紀錄。
6. 驗收 C。錯誤輸入與伺服器失敗可在畫面辨識；測試或手動操作留下實際結果、指令與截圖位置。

驗收條件最好寫成「條件 → 行為 → 證據」。例如「名額已滿」是條件，「看到候補確認」是行為，「自動測試名稱或操作截圖」是證據。只寫「候補功能完成」不能讓人判斷是否漏了重複提交和失敗狀態。

啟動 Claude Code 時先進入專案目錄執行 claude，再用自然語言貼上：「先閱讀 SPEC.md 與現有報名流程。列出本輪需要確認的假設與受影響檔案；在改檔前給我最小實作計畫。只做候補登記與上述驗收，完成後執行相關測試並逐條回報證據。」若想先只讀探索，可依官方 Plan Mode 說明用 claude --permission-mode plan 啟動；切換回可實作模式後再執行計畫。

做完後怎麼回寫規格，才不會留下過期任務？

一次實作通常會發現起初不知道的事：例如現有系統已有唯一鍵，或名額判定在伺服器而非前端。Session 結束前，打開原卡和實際 diff，把每項資訊分成「已確認」「與原假設不同」「仍待決策」。這一步比把聊天摘要整段貼回文件更有用。

1. 先驗收。請 Claude 列出每條驗收的結果、測試指令、通過／失敗狀態、人工檢查位置；親自查看 diff 和關鍵畫面。官方也建議給 Claude 可執行的驗證訊號，避免以「看起來完成」當結案。
2. 再記變更。在 SPEC.md 的「目前狀態」寫下已實作行為、所依據的檔案或測試，以及未完成項。不要把「程式已合併」寫成「功能已上線」。
3. 最後掃遠期卡。逐張找出引用舊資料模型、舊介面或已否決規則的內容，標記「需重估」並附上觸發原因；只有下一輪要做的卡才重新寫細。

如果你的團隊已使用決策紀錄，跨 Session 的「為何採此方案」可放在Claude Code Decision Ledger 教學所示的決策簿；SPEC.md則留目前需求、驗收與未決事項。兩者都應連到可查的程式或測試，讓新 Session 不必相信一段沒有證據的摘要。

完整 backlog 與逐 Session 細化，怎麼公平比較？

用同一個候補功能做紙上演練即可理解兩種方法的維護點：若一開始把「登記、補位、通知、匯出」都寫到欄位和測試檔，第一輪發現唯一性規則不同時，每張相關卡都要檢查。若遠期只記目標與依賴，當下主要修改已寫細的卡，再標記受影響的遠期卡。這不是哪種方法必勝的實驗，而是幫你看見「變更傳播」發生在哪裡。

若要在自己的團隊量化，先固定同一功能、同一驗收底線和相近的操作者，再記錄規格撰寫時間、重寫卡片數、返工次數、測試發現問題與人工審閱時間。把完成品質放在前面，不能只比文件張數。想比較 OpenSpec、Claude Code 與 Spec Kit 的規格成本，可接著看三種工作流的規格稅評估；本文只處理「何時停止預寫」。

三個常見坑：規格太粗、太滿，或沒有人回寫

• 規格太粗：任務只寫「做候補」。改成可以觀察的條件、行為與證據，並補上非目標。
• 規格太滿：遠期卡寫死欄位和檔名。改為先保留依賴及待決策事項，等前置工作產生事實後再拆。
• 只回寫聊天：Session 說了「完成」，但沒有 diff、測試和部署證據。把已完成狀態綁到可重查的工件。

還有一個容易誤會的地方：CLAUDE.md能提供跨 Session 的專案慣例，卻不是強制權限機制；官方記憶文件明確把它定位為 context。若「不能碰付款程式」是硬邊界，除了在規格寫出來，還要用權限設定、hook 或隔離環境實際控制。

Claude Code 大專案規劃常見問題

是不是一定要先寫完整 PRD？

不一定。先寫出目標、硬邊界、未知事項與下一輪驗收；多人或高風險專案可以增加產品決策與審核，但不必把猜測偽裝成已定規則。

一個 Session 一定只能做一張卡嗎？

不一定。單位是「這輪能完成並驗收的變更」。若幾張小卡共用同一驗收結果，可以合併；若一張卡跨資料、畫面與部署，可能需要再拆。

Plan Mode 會替我保存規格嗎？

規劃階段的對話和 SPEC.md 是不同工件。要跨 Session 穩定引用的決定，請回寫到檔案並檢查版本。

驗收條件需要先有自動測試嗎？

不一定。能自動測試最好；畫面、API 回應與操作錄影也可作為可觀察證據，但要寫明誰檢查、在哪個環境檢查。

未來工作完全不用規劃嗎？

要規劃順序、依賴、風險與決策點。細節等依賴落定後再寫，才不會反覆維護假設。

規格與程式衝突時信誰？

先查目前程式、測試與產品決策，找出差異原因；規格可能過期，程式也可能是錯誤實作。不要自動把其中一方當真相。

功能做完就能把卡標為上線嗎？

不能直接這樣寫。完成實作、合併與部署是不同狀態；上線要有對應環境與版本的收據。

什麼時候需要更重的規格工具？

當多人審核、變更追蹤或規格版本治理成為主要成本時，再評估工具。先確認它降低了返工或漏驗，而不是只增加文件。

給新手的四步行動

1. 今天先寫一頁 SPEC.md：目標、硬邊界、未知、成功畫面。
2. 只選下一個 Session，把工作縮到一次可驗收的改動，逐條寫「條件 → 行為 → 證據」。
3. 請 Claude 先探索再實作，完成時逐條交付測試與 diff 的證據。
4. 對照實際結果回寫規格，把受影響的遠期卡標記「需重估」，再決定下一輪。

如果你還想先弄懂 Coding Agent 的工作循環，可讀AI Agent Harness 是什麼與最小 Harness 實作；想學如何驗證舊專案規格，可接著看Specification-First Convergence。需要有系統地練習，可從AlphaLab 課程挑一條適合自己的路線。