前陣子一直在挖 AI coding 相關的框架跟工具，這次回到 GitHub Copilot，為了可以讓 AI 開發導入團隊中，首先就必需讓自己也熟悉 AI 工具的使用跟開發，最近就常常用政府的 OpenData 進行各種串接開發。目前大概也串接了40筆資料。在基本的API串接跟後台介面開發的情境，加上公司所提供github copilot的工具限制，最後得出了使用 copilot 的 plan agent，非常適合在小步快跑中的開發方式。

最近看到一些除了做用 AI 很溜的工程師，其他的工程師在開發上，有部分都還在把 AI 當成詢問問題的工具，並沒有好好的把 AI 變成協助開發的幫手，這樣一來很可惜。我也大概跟工程師們聊了一下，有些人是怕 AI 亂改程式甚至是刪除資料，造成更多的問題。其實這樣的疑慮也可以用 plan agent 在開發前跟 AI 討論擬好要開發的項目跟內容，再讓 AI 進行開發，減少 AI 所帶來的不確定因素。

copilot-plan-agent-flow

以下是核心流程：先建立計畫書，人確認過了才准動手

唯讀掃描 ➔ 產出計畫書（Plan Markdown）(可以產出.md檔) ➔ 人工審查 ➔ 本機執行

跟傳統模式最大的差異在於第一步不是改檔案，是讀檔案。AI 先用工具掃過相關檔案、理解依賴關係，接著在聊天面板或獨立 Markdown 視窗裡列出詳細的修改步驟、預期影響的檔案清單、函式變更、還有潛在風險。工程師針對這份計畫書 Review、提修正意見或核准，確認無誤後 AI 才啟動 Agent Mode，在隔離環境中依序執行所有修改。

  1. 全域程式掃描——不會改了 A 壞 B

這是 Plan Agent 拿來對付「經典翻車現場」的招數。以目前 copilot 的上下文處理能力，它擬計畫的時候能同時考量跨模組的影響，不會發生改動只顧眼前那支檔案、卻漏掉呼叫端的窘境，來避免視野太窄造成的程式調整錯誤。

  1. 把幻覺攔在寫程式之前

過去如果 AI 理解錯需求，往往要花很多時間還原一團亂的 Diff——這種事故成本很高,因為你要先搞懂它到底改了哪些地方,再一個個判斷要留還是要砍。有了計畫書這一關,錯誤的架構方向在「寫程式前」就能被攔下來,溝通跟試錯的成本直接砍掉一大塊。

  1. 驗證步驟直接寫進計畫裡

好的計畫通常會把「跑單元測試」或「補測試案例」也列進去,等於是把驗證這件事寫進流程裡,而不是等改完才回頭想是否要測試測一下。這個設計思路其實跟之前介紹過的 agent-skills 裡的 /test 階段是同一套邏輯——先講清楚怎麼證明改動是對的,再放行。

以前「Vibe Coding」,速度快但在企業級、多人協作的架構下風險很高。Plan Agent 這套做法,其實是往 Agentic Engineering 轉型——工程師不再是第一線逐行敲程式碼的人,而是變成「AI 團隊的架構師跟審查員」,核心價值轉移到定義清楚的邊界條件、寫規範文件（像 .copilot/instructions）、審核 AI 交出來的 Plan 合不合系統架構跟需求開發的最佳實踐。這份 Plan Markdown 本身也順便可以變成一份技術溝通文件跟歷史紀錄。

跟之前介紹的 agent-skills 擺在一起看,兩者其實在解同一個問題,只是切入點不同：agent-skills 是靠一整套 Prompt 流程（/spec ➔ /plan ➔ /build）去說服 AI 照規矩來,Plan Agent 則是把「先計畫後執行」這件事直接寫進需求開發機制,不用你自己裝一套 Skill 才能有這個把關動作。AI 開始學會先立計畫書再動手,工程師的力氣就能省下來,轉去顧真正燒腦的業務邏輯跟系統設計。

所以透過 github copilot 現有的 plan agent 可以在開發前先看 AI 實際要做的項目，來避免許多不確定性，增加工程師在開發上的效率跟品質。

最後，plan agent的使用也很簡單，在 CLI 上打「/plan」再加上說明跟需求資訊，這樣子就可以直接執行了。而在規劃完後，也可以直接用auto pilot的方式依照規畫進行開發。