---
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="/docs/github-copilot/official/08-security-governance/usage-billing" />
  <Card title="SDK 与自定义 Agent" description="进入更高风险能力前，先确认指标和治理能跟上。" href="/docs/github-copilot/official/09-sdk-and-custom-agents" />
</Cards>
