---
title: "指標和採用情況"
description: "說明 Copilot usage metrics 的 adoption、engagement、acceptance、LoC、PR lifecycle 口徑，以及 rollout 覆盤方式。"
verifiedAt: "2026-05-06"
---

指標和採用情況用來回答 rollout 是否真的有效。不要只看“開通了多少人”，要看誰在用、怎麼用、輸出有沒有被接受、PR 流程有沒有變化、成本是否異常——一句話：把 license 數字換成"工程結果"。

> [!IMPORTANT]
> 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 等。

```mermaid
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:2px
```

## 2. 資料重新整理延遲

官方文件說明，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 個問題：

1. 哪些團隊採用率上升，哪些團隊只是開通不用？
2. 哪些 IDE、語言、儲存庫貢獻了主要使用量？
3. Chat、agent、code review、CLI 的使用是否符合預期？
4. premium request 消耗是否和價值匹配？
5. PR lifecycle 有沒有改善，還是隻增加了 AI 噪聲？
6. 培訓、規則、prompt files、instructions 是否需要調整？

## 6. 不要用單一指標做結論

官方也強調要看模式組合。比如：

- DAU 穩定但 acceptance rate 上升：信任和相關性變好。
- 請求量上升但 acceptance rate 下降：可能需要培訓或更好的上下文。
- license count 上升但 active users 不變：開通策略有問題。
- code review passive users 很多但 active users 很少：團隊可能沒真正採用 review 輸出。

<details>
<summary>深讀：指標不能替代程式碼質量審查</summary>

Usage metrics 只能告訴你 Copilot 被怎麼使用，不能直接證明程式碼質量變好。

商業級 rollout 要把 metrics 和 code review、incident、security debt、test coverage、cycle time 一起看。
</details>

## 本章自檢

1. 是否區分 license count 和 active users？
2. 是否給資料重新整理延遲留視窗？
3. 是否同時看 adoption、engagement、acceptance、LoC、PR lifecycle？
4. 是否能解釋異常請求量和 premium request 消耗？
5. 是否把指標覆盤連線到培訓和治理調整？

透過標準：團隊能用資料解釋 Copilot 是否被有效採用，而不是靠主觀感覺。

## 官方來源

- [GitHub Copilot usage metrics](https://docs.github.com/en/copilot/concepts/copilot-usage-metrics/copilot-metrics) —— GitHub 官方指標分類、重新整理延遲和解釋方式。
- [Viewing the Copilot usage metrics dashboard](https://docs.github.com/en/copilot/how-tos/administer-copilot/view-usage-and-adoption) —— GitHub 官方 dashboard 入口。
- [REST API endpoints for Copilot usage metrics](https://docs.github.com/en/rest/copilot/copilot-usage) —— GitHub 官方 programmatic metrics 入口。

## 接下來去哪

<Cards>
  <Card title="用量和計費" description="把採用情況和 premium request 消耗連起來看。" href="/zh-Hant/docs/github-copilot/official/08-security-governance/usage-billing" />
  <Card title="SDK 與自定義 Agent" description="進入更高風險能力前，先確認指標和治理能跟上。" href="/zh-Hant/docs/github-copilot/official/09-sdk-and-custom-agents" />
</Cards>
