AI Coding 也該謀定而後動 - Github Copilot Plan 模式

AI Coding 這條路我走得比較慢，最近才開始嘗試寫好完整 Spec 規格書，請 AI 一次把小型網站寫出來的玩法。

題外話：FB 留言區跟網友討論到有趣議題 - Spec 該寫到多詳細？要不要指定何種平台、架構、框架、程式庫... 等技術棧細節？過度指定細節等同用你的知識範圍去限縮 AI 發揮空間，或者 AI 知道更優雅的巧妙解法，受限於你要求的舊做法只能棄用，從而失去學習探索新世界的機會，你成為 AI 能力的超矮天花板；但不指定實作細節任由 AI 自由發揮，專案很可能充斥你從未學過聽過的新語言、新平台、新程式庫、新演算法，卻未必每個都值得你學習或改用。而遇到需要人工審查程式碼或除蟲抓錯時，你必須短時間內學會新技能才能勝任。
這問題沒有標準答案，要視人為介入的深度而定，想控制人工接手難度，依據開發人員背景指定架構及技術棧能減少問題(舉個誇張例子，開發團隊只會 .NET，放任 AI 用 Python 寫是要逼死誰？)，但過度干預 AI 不利於達到最佳化，也剝奪人員成長學習機會。不例外地，又是個兩難議題，有賴大家發揮大智慧自行拿捏，噗~ (喵的，每個開發決策討論都是這種結論)

(跳一下) 回到正題，用 Spec 直接轉成系統的一氣喝成做法，迫使你把規格從頭到尾想一次，思考會更深入周全，而實作時也遠比 AI 做一段停下來，等你輸完提示再繼續更有效率。但有個缺點：送完提示泡茶看 AI 表演之際，若發現 AI 在關鍵點的設計決策偏離預期，要嘛只能中斷執行，調整規格重跑一次；再不然先睜隻眼閉隻眼讓 AI 做完，事後再修正，兩種做法都很浪費時間及 Token。

如果我們能在 AI 理解完規格實際動手前，有機會先檢查 AI 預計的執行步驟，反覆討論修改，必要時手動進行微調修改，使之更貼近我們的期待與需求，會是更完美的做法。

2025 年 10 月，VSCode GitHub Copilot 新推出的 Plan Mode，便是要實現以上理想。我們可從 Copilot Chat 視窗下方切換到 Plan Mode，Agent 會先理解提示要求、參考規格、分析程式碼，先產生一份逐步執行計劃，供使用者檢驗調整，確認後才動手寫 Code，如此可大幅降低做錯重來所浪費的 Token 與時間。如下圖，VSCode 的 Copilot Chat 視窗下方可切換 Agent、Ask 及 Plan 模式，選擇 Plan 時，Copilot 不會急著改程式，而是先在聊天視窗顯示執行計劃：

接著，開發者有幾個選擇(參考下圖)。看過計劃之後，點 [1] 可請 Copilot 依計劃開始寫程式，執行方式可選擇使用 Copilot CLI 或交給 Cloud Agent [2] 在背景執行。若判斷 Copilot 操作出錯造成破壞機率不高，我們還可以啟動 Autopilot Mode [3]，授權 Copilot 不必在每個步驟之後等待我們輸入或確認，下達初始指令後 Copilot CLI 將自動逐步處理，直到判定任務已完成為止，這是效率更好的做法。(注意：Autopilot 適合定義明確的任務，不適合開放式探索、沒有明確目標的功能開發，請自行判斷適用情境)

若發現計劃步驟不符預期，有兩種做法，一種是輸入提示送出要求 Copilot 修正計劃 [5]，另一種是將把計劃存成 .md 文件 [4]，我們再直接精修微調計劃步驟，身為對程式寫法有很多想法的人，這是我更偏好的做法：

至於執行計劃該如何修改調整？每個能改會改想改的人，心中自然有答案。如果沒有，表示你不可能提出更好的點子，那就什麼都別動，放手給 AI 做吧。

小試了 Plan 模式加手工修改計劃 Markdown 文件的做法，成功校正及補強了一些開發細節，Copilot 生成的結果，確實更符合我的要求。我打算對於稍有複雜度的小型專案，若要使用 AI 輔助開發(後續會有人類參與修改擴充)，優先考量這種「先寫好完整規格 -> Plan 模式生成計畫步驟 -> 人工複核及修改計畫 Markdown -> AI 依據計畫完成系統」的做法。

Discusses using detailed specs with AI coding, and how GitHub Copilot’s new Plan Mode lets developers review and refine execution plans before coding, balancing control and AI creativity while reducing rework, wasted tokens, and development risk.