指标和采用情况
说明 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 入口。