一個 bug 被記進追蹤系統之後，往往要躺上好幾天，才有人真的去打開它對應的那個檔案。而真正花在改動程式碼上的時間，通常是整個流程裡最短的一段。把行事曆吃掉的是改動周邊的那些事：建分支、寫一條講得清楚為什麼要改的提交訊息、推上去、開拉取請求、把差異描述到審查者不必反推你的意圖、等回覆、按意見再改一輪。每一件都不難，疊起來卻把一個工作日切成碎得沒法思考的小塊。

GitHub Copilot 的編碼智能體，瞄準的正是這段被切碎的中間環節。官方對它的定位值得照字面理解，因為這決定了期待放在哪裡：它不是編輯器裡那個等你提出下一個問題的對話框，而是一個接過任務、在背景自己走到終點的角色，你可以同時去做別的事。

把一個 issue 交出去，等一個 PR 回來

運作方式很樸素。把某個 issue 指派給 Copilot，或者在任意頁面的智能體面板發起一個任務。它會帶著 issue 的標題、正文與已經存在的評論開工，在自己專屬的臨時開發環境裡摸索儲存庫、擬出計畫、動手改動，最後開出一個拉取請求。完成之後它把你加為審查者並發出通知，交接因此落在你真的會看到的地方。

那個環境由持續整合能力驅動，也就是說專案的測試與靜態檢查可以在你還沒看結果之前先跑一遍，而工作區也能依照儲存庫裡已經寫明的準備步驟先搭好。如果某個測試非得有資料庫加上幾個背景服務才會過，這一步不必靠猜。

需求變動時有一個細節容易踩到：指派之後才補上的評論，它並不會感知。後續的要求應該寫在它開出的那個拉取請求裡。在 PR 裡留話，它會新開一個會話接著處理；而同一條 PR 上過往會話的上下文是有保留的，所以追加請求通常比第一次更快、也更少誤讀。持續整合的工作流跑掛了，走的也是同一條路：把失敗交給它，它去查，然後把修復推上來。

交出去之前，先自己讀一遍

審查機器寫出來的改動，累人的地方不在於它明顯壞掉，而在於它看起來跑得起來，但團隊裡沒有人會那樣寫。官方的做法是在打開拉取請求之前，先讓編碼智能體用程式碼審查能力把自己的補丁讀一遍，收到回饋之後再迭代改進。等你被指派為審查者時，前面已經有人過了一輪。

同一套工作流裡還會跑程式碼掃描、金鑰掃描與相依套件漏洞檢查。某個相依套件有已知問題，或者差異裡出現一段看起來像是有人誤提交的憑證，都會在拉取請求被看見之前先被標出來，而不是等審查者自己撞上。

把團隊的做法寫進設定檔

一句簡短的提示詞會留下大量需要臨場判斷的空間，而臨場判斷未必總跟團隊的實際做法一致。自訂智能體就是用來把這部分固定下來的。在儲存庫裡加一個設定檔，就能指定某一類任務該按什麼順序做。比如一個效能優化智能體可以先量基準，再改程式碼，改完重新量一次證明改動真的有用，最後才開 PR。這份設定還能在組織或企業範圍內共用，讓不同團隊收斂到同一套流程，而不是各自養一份私房做法。

桌面端：把會話並排擺開

任務一多，難處就轉移到怎麼把它們分開。Copilot 桌面端可以從一個問題、一個拉取請求、一句話或上一次會話發起工作，也可以同時並行好幾個智能體會話。每個會話各自擁有獨立的工作樹與分支，檔案、對話與任務狀態彼此隔離，不會互相污染。它提供 Windows、macOS 與 Linux 版本，改動可以在整合終端與瀏覽器裡驗證，而它開出的 PR 依然要走團隊既有的審查、檢查與合併規則。

編碼智能體在背景接過任務，自己建分支、提交、開拉取請求，不必一步一步有人在旁邊推。

交付前自查先用程式碼審查迭代改進，再跑程式碼掃描、金鑰掃描與相依套件檢查。

並行會話讓桌面端每個會話各佔獨立工作樹與分支，不會同時改到同一批檔案。

費用怎麼算

個人方案自 2026 年 6 月起改為按用量計費，產品線從免費的 Free 檔一路鋪到 Pro、Pro+ 與 Max。Free 檔包含有限的補全額度，以及有限的對話與智能體用量，同時也帶上了命令列工具與 agent 模式，想先試水不必先掏錢。付費檔的基礎額度與訂閱價格一比一對應，在此之上還有一份會隨成本變動的彈性額度；補全與下一步編輯建議在付費檔不限量，也不消耗額度。具體檔位與數字，以官方定價頁為準。

把程式碼寫出來只是整件事的一半，另一半是讓改動穿過審查、檢查與合併。這套東西把後一半也接了過去，人因此只需要在真正需要判斷的地方出現。