Day20_什麼是 Codex 的規劃模式？

前言

Day19 已經用 Docker 準備好 SQL Server，前面的文章也陸續整理了 User Story、流程圖、資料庫 Schema、API 契約與測試方式。工具和規格都有了，照理說可以開始寫程式，但我還不想立刻對 Codex 說：「整套網站交給你了。」

這就像裝潢前已經備妥材料，也畫好了格局。若工班一進門就開始敲牆，做到一半才發現屋主只是想換門，前面做得越快，後面拆得越累。Codex 寫程式也一樣。它可以很快修改許多檔案，卻不會自動知道哪些規則不能動、哪一份文件才是目前的準則。

所以我會先開啟規劃模式（Plan mode），讓 Codex 讀懂現有內容、排出實作順序，等方向確認後再動手。

規劃模式在做什麼？

OpenAI 將 /plan 說明為「切換多步驟規劃模式」。進入這個模式後，Codex 會先整理一份可以討論的實作方案，而不是立刻修改程式碼。

以「替 Task 加入優先級」為例，畫面上可能只是多一個下拉選單，背後卻會牽動資料庫欄位、API 傳輸格式、前端表單、排序規則與測試。如果只說「幫我加入優先級」，Codex 可能自行設計五個等級；但原本的需求其實只有高、中、低三種。

規劃模式會把這些藏在一句需求後面的工作攤開來。Codex 可以先閱讀現有檔案，找出受影響的範圍，再整理修改順序與驗證方式。遇到無法從專案判斷的業務規則，也應該先提出問題，例如：「舊資料的預設優先級是什麼？」

規劃模式不會保證內容一定正確。Codex 仍可能漏看檔案或誤解規格，所以產出的方案需要由人審查；若希望這個階段完全不修改檔案，也要在 Prompt 裡明確寫出來。

什麼時候值得先規劃？

改一個錯字、調整一個已知的 CSS 樣式，通常直接處理比較快。下面這些情況，我才會先使用規劃模式：

• 需求會同時影響前端、後端、資料庫或多個模組。
• 資料遷移、權限或公開 API 一旦改錯，不容易回復。
• 專案裡已經有許多規格，必須先確認哪一份是實作依據。
• 自己還沒想清楚做法，想先比較影響範圍與風險。

簡單判斷方式是：如果做錯後會影響許多檔案、資料或既有使用者，那就值得先停下來規劃。

如何開啟規劃模式？

在 Codex 桌面版的輸入框輸入 /，再從清單選擇 /plan；也可以繼續輸入完整指令來篩選。官方文件提醒，可用的 Slash command 會依執行環境與帳號權限而不同，因此看不到 /plan 時，應先確認目前的執行環境與帳號權限。

輸入 /plan 後，畫面上方會出現「規劃模式」選項。點選它，這次對話就會先以整理方案為主，不會一收到需求就立刻開工。

開啟後，不要只丟一句「請規劃 ProjectManagementWeb」。專案名稱不是需求，Codex 還是不知道要做到哪裡。OpenAI 的 Prompting 指南建議，大型任務可以交代目標、背景、輸出與界線。這不是固定格式，而是把會影響結果的資訊說清楚。

以下用 ProjectManagementWeb 的後端開發做示範：

請先閱讀目前專案的 AGENTS.md，以及 ProjectManagementWeb_Spec 內的規格文件。
這一輪只做規劃，不要修改任何檔案。

目標：規劃 ProjectManagementWeb 第一版的 ASP.NET Core Web API。
背景：Vue 3 負責前端畫面；後端負責 API、權限、業務規則與資料存取。
      本機 SQL Server 已依 compose.yaml 建立。
範圍：帳號登入、專案、成員、Task Item 與留言。
界線：以現有 User Story、流程圖、Schema 與 API 契約為準；
      規格沒有寫的業務規則先提出問題，不要自行補完。
輸出：整理實作階段、相依順序、預計異動的區域、風險與驗證方式。

送出前，可以從輸入框下方確認目前使用的是「方案」模式。這段 Prompt 不需要塞滿技術名詞，只要說清楚要做什麼、參考哪些資料、這次做到哪裡，以及哪些事情要先詢問。

收到方案後，先別急著說「可以」

Codex 讀完規格後，可能會碰到文件沒有定義的業務規則。這時它會暫停規劃，請我們從選項中做決定。

畫面中的「推薦」只是 Codex 根據目前資料提出的建議，不代表一定符合需求。若選項都不適合，可以直接補充自己的答案，避免 Codex 自行決定功能範圍。

問題確認完後，Codex 會整理出完整方案，並詢問是否開始執行：

先不要急著選擇「是，執行此計畫」。右側方案會列出基準、實作範圍、延後項目與執行順序。方案寫得詳細，不代表每項安排都符合需求；現在修正幾段文字，會比實作後重改一批檔案省事。正式執行前，我會逐項確認：

• 每個步驟能不能對回現有規格，而不是 Codex 自己想像的需求？
• 前後步驟的相依關係是否合理，例如先確定資料模型與 API 契約，再做依賴它們的功能？
• 權限、資料遷移、錯誤處理與舊資料相容性有沒有被漏掉？
• 驗證方式是否具體，能說出要執行哪些測試、觀察什麼結果？

如果方案只寫「建立後端、加入資料庫、完成測試」，它只是待辦事項，不足以拿來開發。可以直接在同一個對話補充：

請把計畫中的「完成測試」拆開，分別列出單元測試、API 整合測試與權限測試。
每個階段都要寫出完成條件；若規格互相衝突，先列出衝突，不要替我選擇。

第一版方案不用完美。看過後補資料、調整順序、追問風險，本來就是規劃的一部分。

確認方案後，怎麼繼續？

如果方案還有問題，先不要離開規劃模式。直接告訴 Codex 哪個步驟需要調整，例如補上權限測試、縮小這次的實作範圍，或把尚未決定的規格列出來。它會根據新條件更新方案，不必重新開一個對話。

內容確認無誤後，可以在畫面中選擇「是，執行此計畫」。Codex 會沿用剛才整理好的方案開始實作，不需要再貼一次相同的 Prompt。實作期間若發現程式與規格不一致，應先停下來確認，不要為了照表操課而硬把計畫做完。

如果這次只想取得方案，還不準備修改程式，可以選擇「跳過」，或再次輸入 /plan 關閉規劃模式。回到一般模式後，仍然可以保留這份方案，等準備好再請 Codex 繼續。

實作完成後，還要查看 Git diff、確認測試真的有執行，並手動走過重要操作。規劃模式能減少走錯方向的機會，但程式碼審查與驗收仍要由人完成。

小結

規劃模式很像開工前把圖紙攤在桌上。這時改一條線，只需要幾分鐘；等牆砌好才發現位置不對，就得付出更多時間重做。

前面的文章已經準備好規格、測試觀念、Git 與 Docker 環境。現在再用 /plan 把實作順序談清楚，下一篇就會把確認過的規格交給 Agent，分別展開 Vue 前端與 ASP.NET Core Web API 的開發。

參考資料

• OpenAI：Slash commands（/plan 指令）
• OpenAI：Prompting（目標、背景、輸出與界線）