指標和採用情況
說明 Copilot usage metrics 的 adoption、engagement、acceptance、LoC、PR lifecycle 口徑，以及 rollout 覆盤方式。
指標和採用情況用來回答 rollout 是否真的有效。不要只看“開通了多少人”，要看誰在用、怎麼用、輸出有沒有被接受、PR 流程有沒有變化、成本是否異常——一句話：把 license 數字換成"工程結果"。
Copilot adoption（採用率）不是 license count，而是活躍使用和下游工程結果。把這兩件事混淆，rollout 看起來"成功"但實際可能沒有改變工程交付。
1. 官方指標分類
GitHub 官方 usage metrics 概念頁把指標歸成幾類：
- Adoption（採用率）：已分配 license 的開發者中有多少人在活躍使用。
- Engagement（參與深度）：開發者使用深度，例如 chat requests per active user（每活躍使用者的 chat 請求數）。
- Acceptance rate（建議接受率）：建議被接受的比例。
- Lines of Code (LoC)（程式碼行數）：Copilot 建議、新增、刪除的程式碼行。
- Pull request lifecycle（PR 生命週期）：PR 建立、合併、合併耗時（merge time）、review suggestion 等。
flowchart TD
Metrics["Copilot usage metrics"] --> Adoption["Adoption"]
Metrics --> Engagement["Engagement"]
Metrics --> Acceptance["Acceptance rate"]
Metrics --> LoC["Lines of Code"]
Metrics --> PR["PR lifecycle"]
Adoption --> Question1["誰真的在用?"]
Engagement --> Question2["用得多深?"]
Acceptance --> Question3["建議是否被信任?"]
LoC --> Question4["程式碼輸出方向?"]
PR --> Question5["交付流是否變化?"]
style Metrics fill:#dbeafe,stroke:#2563eb,stroke-width:2px
style PR fill:#dcfce7,stroke:#16a34a,stroke-width:2px2. 資料重新整理延遲
官方文件說明，dashboard 和 API reports 會定期更新。一般可以預期某一天的資料在該 UTC 日結束後的兩個完整 UTC 日內可用。
這意味著：
- 不要用今天上午的資料判斷 rollout 成敗。
- 週報要留資料延遲視窗。
- 異常用量要結合 billing analytics 和 audit log 複核。
3. 怎麼解釋 adoption
Adoption 看的是活躍使用，而不是已分配 license。
可用訊號：
- Daily active users。
- Weekly active users。
- 按團隊、組織、IDE、語言分佈。
- code review active users 和 passive users。
官方說明中，code review active users 是手動請求 review 或應用 suggestion 的使用者；passive users 是 Copilot code review 自動分配到 PR 的使用者。如果同一週期都有訊號，只計為 active。
4. 怎麼看質量和信任
只看請求數量會誤導。請求越多不一定越好，可能是反覆失敗。
更應該組合看：
- DAU 或 WAU 是否增長。
- Chat requests per active user 是否穩定。
- Inline suggestions acceptance rate 是否提高。
- Copilot code review suggestions 是否被採納。
- PR median time to merge 是否變化。
- AI 生成程式碼是否帶來更多返工或安全問題。
接受率高說明建議更相關，但也不是唯一成功指標。低接受率可能是模型不懂專案，也可能是任務型別不適合補全。
5. Rollout 覆盤模板
每月覆盤 6 個問題：
- 哪些團隊採用率上升，哪些團隊只是開通不用？
- 哪些 IDE、語言、儲存庫貢獻了主要使用量？
- Chat、agent、code review、CLI 的使用是否符合預期？
- premium request 消耗是否和價值匹配？
- PR lifecycle 有沒有改善，還是隻增加了 AI 噪聲？
- 培訓、規則、prompt files、instructions 是否需要調整？
6. 不要用單一指標做結論
官方也強調要看模式組合。比如：
- DAU 穩定但 acceptance rate 上升：信任和相關性變好。
- 請求量上升但 acceptance rate 下降：可能需要培訓或更好的上下文。
- license count 上升但 active users 不變：開通策略有問題。
- code review passive users 很多但 active users 很少：團隊可能沒真正採用 review 輸出。
深讀：指標不能替代程式碼質量審查
Usage metrics 只能告訴你 Copilot 被怎麼使用，不能直接證明程式碼質量變好。
商業級 rollout 要把 metrics 和 code review、incident、security debt、test coverage、cycle time 一起看。
本章自檢
- 是否區分 license count 和 active users？
- 是否給資料重新整理延遲留視窗？
- 是否同時看 adoption、engagement、acceptance、LoC、PR lifecycle？
- 是否能解釋異常請求量和 premium request 消耗？
- 是否把指標覆盤連線到培訓和治理調整？
透過標準：團隊能用資料解釋 Copilot 是否被有效採用，而不是靠主觀感覺。
官方來源
- GitHub Copilot usage metrics —— GitHub 官方指標分類、重新整理延遲和解釋方式。
- Viewing the Copilot usage metrics dashboard —— GitHub 官方 dashboard 入口。
- REST API endpoints for Copilot usage metrics —— GitHub 官方 programmatic metrics 入口。