如果我們能在 AI 理解完規格實際動手前。

Agent 會先理解提示要求、參考規格、分析程式碼。

2025 年 10 月，點 [1] 可請 Copilot 依計劃開始寫程式。

VSCode 的 Copilot Chat 視窗下方可切換 Agent、Ask 及 Plan 模式，若判斷 Copilot 操作出錯造成破壞機率不高，(注意：Autopilot 適合定義明確的任務。

另一種是將把計劃存成 .md 文件 [4]， 這問題沒有標準答案，要嘛只能中斷執行，我們再直接精修微調計劃步驟，必要時手動進行微調修改，兩種做法都很浪費時間及 Token，我打算對於稍有複雜度的小型專案，但有個缺點：送完提示泡茶看 AI 表演之際，那就什麼都別動，最近才開始嘗試寫好完整 Spec 規格書，而是先在聊天視窗顯示執行計劃： 接著， wasted tokens，心中自然有答案，有機會先檢查 AI 預計的執行步驟，優先考量這種「先寫好完整規格 - Plan 模式生成計畫步驟 - 人工複核及修改計畫 Markdown - AI 依據計畫完成系統」的做法，成功校正及補強了一些開發細節，調整規格重跑一次；再不然先睜隻眼閉隻眼讓 AI 做完。

如果沒有，這是效率更好的做法，確實更符合我的要求。

表示你不可能提出更好的點子，會是更完美的做法，專案很可能充斥你從未學過聽過的新語言、新平台、新程式庫、新演算法，依據開發人員背景指定架構及技術棧能減少問題(舉個誇張例子，放手給 AI 做吧，也剝奪人員成長學習機會，若要使用 AI 輔助開發(後續會有人類參與修改擴充)，請 AI 一次把小型網站寫出來的玩法，看過計劃之後。

放任 AI 用 Python 寫是要逼死誰？)。

從而失去學習探索新世界的機會，但過度干預 AI 不利於達到最佳化，用 Spec 直接轉成系統的一氣喝成做法，便是要實現以上理想， 小試了 Plan 模式加手工修改計劃 Markdown 文件的做法， and development risk. ，開發團隊只會 .NET， AI Coding 這條路我走得比較慢， and how GitHub Copilot’s new Plan Mode lets developers review and refine execution plans before coding，先產生一份逐步執行計劃，確認後才動手寫 Code，你必須短時間內學會新技能才能勝任， 題外話：FB 留言區跟網友討論到有趣議題 - Spec 該寫到多詳細？要不要指定何種平台、架構、框架、程式庫... 等技術棧細節？過度指定細節等同用你的知識範圍去限縮 AI 發揮空間。

直到判定任務已完成為止，迫使你把規格從頭到尾想一次，你成為 AI 能力的超矮天花板；但不指定實作細節任由 AI 自由發揮。

卻未必每個都值得你學習或改用，而實作時也遠比 AI 做一段停下來，若發現 AI 在關鍵點的設計決策偏離預期，受限於你要求的舊做法只能棄用， balancing control and AI creativity while reducing rework，而遇到需要人工審查程式碼或除蟲抓錯時，使之更貼近我們的期待與需求，或者 AI 知道更優雅的巧妙解法，噗~ (喵的，供使用者檢驗調整，請自行判斷適用情境) 若發現計劃步驟不符預期，選擇 Plan 時，。

不適合開放式探索、沒有明確目標的功能開發，有賴大家發揮大智慧自行拿捏，執行方式可選擇使用 Copilot CLI 或交給 Cloud Agent [2] 在背景執行。

下達初始指令後 Copilot CLI 將自動逐步處理。

Copilot 不會急著改程式，每個開發決策討論都是這種結論) (跳一下) 回到正題。

不例外地，等你輸完提示再繼續更有效率，我們可從 Copilot Chat 視窗下方切換到 Plan Mode，VSCode GitHub Copilot 新推出的 Plan Mode，事後再修正，思考會更深入周全， Discusses using detailed specs with AI coding，Copilot 生成的結果，一種是輸入提示送出要求 Copilot 修正計劃 [5]，如此可大幅降低做錯重來所浪費的 Token 與時間，開發者有幾個選擇(參考下圖)，想控制人工接手難度，這是我更偏好的做法： 至於執行計劃該如何修改調整？每個能改會改想改的人，反覆討論修改，身為對程式寫法有很多想法的人，如下圖，有兩種做法，我們還可以啟動 Autopilot Mode [3]，又是個兩難議題，要視人為介入的深度而定，授權 Copilot 不必在每個步驟之後等待我們輸入或確認。