GitHub Copilot impact dashboard 上線：別只看活躍人數，先看採用階段

impact dashboard 實際多了什麼#

Dashboard 以最近 28 天的 Copilot 產品使用情況分群，並把已授權、但未符合互動條件的使用者獨立列為 Passive。對有互動的使用者，GitHub 顯示三個採用階段：

每張群組卡會顯示每位使用者每月平均 merge 的 PR、PR merge velocity 中位數、群組人數與占比，以及每天平均程式碼行數；趨勢圖可看六個月的群組與 PR throughput 變化。這些是「同一群組在一段時間內的活動訊號」，不是個別工程師的績效排名，也不能單獨推出程式碼品質或商業成果。

先確認你的帳號看得到資料#

GitHub 將這個 dashboard 限給可存取 Copilot usage metrics 的 enterprise administrator 和 organization owner。分類也不是即時狀態：官方說明以滾動 28 天的產品使用情況計算，且採用階段有版本欄位，分類邏輯日後可以調整。

所以遇到「明明剛開始用 agent，為什麼還沒進 Phase 2」時，先不要把它當成 dashboard 壞掉。應先確認：

1. 使用者是否在該 28 天窗口中符合互動條件。
2. 管理者是否有 usage metrics 的存取權。
3. 你比較的是同一個階段定義與同一個時間窗口，而非把不同版本的分類混在一起。

若要匯出或串自己的報表，usage metrics API 的 ai_adoption_phase 位於使用者層級資料；organization 與 enterprise 層級則有依階段彙總的 totals_by_ai_adoption_phase。彙總值是該階段的每人平均，不是整個階段的加總，做內部簡報前要先標清楚。

把指標變成一個可審核的啟用順序#

我會把 dashboard 當成找問題的位置，而不是 KPI 終點。可以用下面的順序把觀察變成小範圍的改善：

1. Passive 比例高：先抽樣問三件事：是否已完成 IDE／CLI 登入、是否知道允許的使用情境、是否被網路或組織政策擋住。先排除入口問題，不要直接要求增加提示詞次數。
2. Phase 1 很多、Phase 2 很少：挑一個低風險任務做團隊範例，例如「為指定 PR 提供 review 建議」，並明訂資料範圍與人工 merge 規則。
3. Phase 2 或 3 成長：回頭檢查 agent 的權限、可用模型、外部工具與輸出審查是否仍符合預期。這時的問題通常不是使用率，而是高權限流程有沒有留下可查紀錄。
4. PR 活動變動：把 dashboard 的群組趨勢與 release、團隊人力、PR 大小、review 規則一起看。不要因為兩條線同時上升，就宣稱 Copilot 造成產能提升。

對會在 GitHub Actions 使用 agent 的團隊，還要把「採用」和「可寫入權限」分開。像 GITHUB_TOKEN、copilot-requests: write 與 Safe Outputs 的角色不同，可搭配 GitHub Agentic Workflows 不用 PAT 後：權限、費用與寫入邊界怎麼設 一起盤點。

不要把 adoption phase 當個人考核分數#

採用階段描述的是 Copilot 產品 surface 的使用型態，不是工程能力等級。Phase 3 也不必然比 Phase 1「更好」：如果團隊還沒有可審核的 agent 任務邊界，把更多人推進較深階段，反而可能擴大權限與成本的不確定性。

比較實用的作法是每次只改一個因素，例如新增一份 code review 使用規則，或替一個特定團隊完成 CLI onboarding；隔一個完整觀察窗口後，再把採用分群、PR 資訊和人工回饋放在一起檢視。這樣能把 dashboard 留在它擅長的地方：指出下一個該驗證的假設。

Copilot impact dashboard 讓管理者更容易看見「誰從哪種使用方式開始」，但它不會替你定義好流程或風險邊界。先用分群找出卡點，再以小範圍、可審核的啟用實驗改善，比把活躍人數當成唯一目標更有用。

常見問題#