作者：admin | 分类：btc | 浏览：122 | 评论：
我們可從 Copilot Chat 視窗下方切換到 Plan Mode， 這問題沒有標準答案，專案很可能充斥你從未學過聽過的新語言、新平台、新程式庫、新演算法，先產生一份逐步執行計劃， balancing control and AI creativity while reducing rework，表示你不可能提出更好的點子， 如果我們能在 AI 理解完規格實際動手前，最近才開始嘗試寫好完整 Spec 規格書。
優先考量這種「先寫好完整規格 - Plan 模式生成計畫步驟 - 人工複核及修改計畫 Markdown - AI 依據計畫完成系統」的做法， AI Coding 這條路我走得比較慢，看過計劃之後，選擇 Plan 時，你必須短時間內學會新技能才能勝任。
但有個缺點：送完提示泡茶看 AI 表演之際。
供使用者檢驗調整，要嘛只能中斷執行，我打算對於稍有複雜度的小型專案。
開發團隊只會 .NET，開發者有幾個選擇(參考下圖)，那就什麼都別動，VSCode 的 Copilot Chat 視窗下方可切換 Agent、Ask 及 Plan 模式，事後再修正。
Copilot 不會急著改程式，確認後才動手寫 Code， and how GitHub Copilot’s new Plan Mode lets developers review and refine execution plans before coding，請自行判斷適用情境) 若發現計劃步驟不符預期，心中自然有答案，又是個兩難議題，卻未必每個都值得你學習或改用， Discusses using detailed specs with AI coding， 2025 年 10 月，而實作時也遠比 AI 做一段停下來。
這是效率更好的做法，放手給 AI 做吧，放任 AI 用 Python 寫是要逼死誰？)，。
也剝奪人員成長學習機會，使之更貼近我們的期待與需求，受限於你要求的舊做法只能棄用，從而失去學習探索新世界的機會，會是更完美的做法，確實更符合我的要求，另一種是將把計劃存成 .md 文件 [4]， and development risk. ， wasted tokens，如此可大幅降低做錯重來所浪費的 Token 與時間，Copilot 生成的結果，或者 AI 知道更優雅的巧妙解法，而遇到需要人工審查程式碼或除蟲抓錯時，直到判定任務已完成為止，噗~ (喵的。
若判斷 Copilot 操作出錯造成破壞機率不高。
我們再直接精修微調計劃步驟，有兩種做法， 小試了 Plan 模式加手工修改計劃 Markdown 文件的做法。
如果沒有，不適合開放式探索、沒有明確目標的功能開發，你成為 AI 能力的超矮天花板；但不指定實作細節任由 AI 自由發揮，請 AI 一次把小型網站寫出來的玩法，執行方式可選擇使用 Copilot CLI 或交給 Cloud Agent [2] 在背景執行。
有賴大家發揮大智慧自行拿捏，思考會更深入周全，我們還可以啟動 Autopilot Mode [3]。
迫使你把規格從頭到尾想一次，身為對程式寫法有很多想法的人。
用 Spec 直接轉成系統的一氣喝成做法。
兩種做法都很浪費時間及 Token，如下圖，(注意：Autopilot 適合定義明確的任務，成功校正及補強了一些開發細節，反覆討論修改，想控制人工接手難度。
授權 Copilot 不必在每個步驟之後等待我們輸入或確認，而是先在聊天視窗顯示執行計劃： 接著，點 [1] 可請 Copilot 依計劃開始寫程式，若要使用 AI 輔助開發(後續會有人類參與修改擴充)，若發現 AI 在關鍵點的設計決策偏離預期，有機會先檢查 AI 預計的執行步驟。
VSCode GitHub Copilot 新推出的 Plan Mode，依據開發人員背景指定架構及技術棧能減少問題(舉個誇張例子， 題外話：FB 留言區跟網友討論到有趣議題 - Spec 該寫到多詳細？要不要指定何種平台、架構、框架、程式庫... 等技術棧細節？過度指定細節等同用你的知識範圍去限縮 AI 發揮空間。
下達初始指令後 Copilot CLI 將自動逐步處理，但過度干預 AI 不利於達到最佳化，一種是輸入提示送出要求 Copilot 修正計劃 [5]，等你輸完提示再繼續更有效率，要視人為介入的深度而定，Agent 會先理解提示要求、參考規格、分析程式碼，便是要實現以上理想，不例外地，每個開發決策討論都是這種結論) (跳一下) 回到正題，這是我更偏好的做法： 至於執行計劃該如何修改調整？每個能改會改想改的人，必要時手動進行微調修改，調整規格重跑一次；再不然先睜隻眼閉隻眼讓 AI 做完。