Copilot impact dashboard 按表面统计采用

GitHub 在 2026 年 9 月 17 日给 Copilot impact dashboard 加上了功能采用统计：它不再只告诉你“有多少人用过 Copilot”，而是按表面拆开，看 28 天滚动窗口里有多少活跃用户经常使用补全、Agent 编辑、代码审查、Cloud Agent、CLI 和 Copilot 应用。同一套数字也进了企业和组织的 28 天聚合报表 API。

GitHub Copilot impact dashboard 展示各 Copilot 表面的功能采用人数 — 官方截图：Copilot impact dashboard 上的 feature engagement。来源：GitHub Changelog，2026-09-17。

企业管理员原先最容易被日活、周活和“采用阶段”带着走：报表说组织已经进入 Agent 阶段，培训却还在讲补全快捷键；预算在涨，却说不清钱是补全烧掉的，还是 Cloud Agent 烧掉的。本文只回答一件事：这套新计数怎么改你看采用率的方式，以及它明确不覆盖什么。

AI Coding 交流群

如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。

发生了什么

这是一条 Improvement，不是新 SKU。打开路径仍然是：进入企业 → Insights → Copilot impact。能看的人还是企业所有者、billing manager、组织所有者，以及带 View Copilot Metrics 的自定义角色。前提没变：必须打开 Copilot usage metrics 策略。GitHub 文档写得很硬：没开这项策略，就拿不到 Copilot 用量指标。

新视图统计的是：在 28 天窗口内，对某个列入清单的功能至少使用了两天的活跃用户数。GitHub 的原话是 “how many active users engaged with each included feature on at least two days during the 28-day period”。两天门槛把“点开一次就算采用”滤掉了。它和 impact dashboard 里原有的采用阶段是两套尺子：阶段回答“这个人被分到哪一档”，功能采用回答“这个表面有没有变成习惯”。

API 侧，企业和组织的 28 天聚合报表多了三块：

copilot_feature_engagement：仪表盘上的活跃用户总数，加上各功能采用人数。
totals_by_feature：按表面拆开，当前列出 code completion、agent edit、passive Copilot code review、active Copilot code review、Copilot cloud agent、Copilot CLI、Copilot app。
users_in_phase_28d：每个 AI 采用阶段在该报告日的完整 28 天人群。原来的 total_engaged_users 仍只计当天活跃、且落在该阶段里的人。

代码审查被拆成两条，这是这次更新里最容易误读的地方。主动：用户手动请求 Copilot 审查，或应用了审查建议。被动：Copilot 被自动指派到该用户的 PR，而用户没有与审查互动。一个人可以同时出现在多个表面里。把七个表面的人数相加，一定会大于去重后的总人数。

一个真实的看数场景

假设你负责 800 人工程组织的 Copilot 落地。月初报表说采用阶段已经到了 Phase 2（用过一种 GitHub 侧 Agent 表面），你据此排了 Cloud Agent 培训。打开新视图后，你可能看到完全不同的结构：补全和 Agent 编辑人数很高，主动审查很少，被动审查却不低，CLI 接近空。

接下来的动作不再是“再推一轮 Copilot”，而是按表面改配置。被动审查高、主动审查低，说明规则把 Copilot 自动挂上了 PR，但开发者既没点开评论，也没应用建议——该查的是审查噪音、自动指派范围和评论是否可执行，而不是许可证覆盖率。CLI 接近空，该查的是终端安装、组织模型策略和沙箱，而不是再发一篇 IDE 入门。

报表拉取也要换字段。以前用 28 天聚合里的阶段人数做周报，会把“当天活跃”和“窗口内属于该阶段”混在一起。现在应同时看 users_in_phase_28d（窗口内的阶段存量）和 totals_by_feature（窗口内经常使用某个表面的人）。两者对不上不是 bug：一个人可以处在 Multi-agent 阶段，却没有“经常”使用 CLI；也可以天天在 IDE 里补全，却从未跨过 Agent 阶段的门槛。

数据仓库的接入点也要改。企业和组织的 28 天报表走 /latest，没有按天回放参数；1 天报表才带 day=YYYY-MM-DD。功能采用这次只写进 28 天聚合，不写用户级报表。如果你的管道是按用户明细做采用漏斗，这次更新帮不上忙，继续用原有用户级字段即可，不要空等 totals_by_feature 出现在 users 报表里。

编辑绘制：Copilot 功能采用的七个表面、两天门槛以及主动与被动审查的区别 — 编辑绘制：计入规则。依据 GitHub Changelog 2026-09-17 的字段定义，不是产品截图。

为什么这会改变工作流

采用率以前是一个数，现在是一组可追责的表面。培训、许可证、预算申请和“Agent 已经普及”这类结论，第一次能对上同一种计数：28 天里至少两天。GitHub 把这项数据放进企业和组织 28 天聚合，而不是用户级报表，方向也很清楚——给管理员做启用决策，不给经理做个人考核表。

它也修正了阶段报表的时间口径。过去 AI 采用阶段拆分只显示“当天活跃且落在该阶段”的人数，周末或假日会把阶段看起来变空。users_in_phase_28d 给出报告日那一档的完整滚动人群，阶段迁移终于能按周对比，而不是跟着日历抖。

同一天 GitHub 还把 Copilot CLI 的技能、自定义 Agent、MCP、斜杠命令和插件用量写进了 usage metrics API。那是另一条独立事件，本文不展开。只提醒一句：impact dashboard 上的 CLI 功能采用，和 CLI 自定义项的 top-5 活动数组，不是同一张表。前者问“有多少人经常用 CLI”，后者问“CLI 里哪些自定义项被点到”。

限制和人必须接管的地方

功能采用只出现在企业和组织的 28 天聚合，不进用户级报表。计数是聚合，不点名个人。一人可跨多个表面，把各表面人数相加会大于总人数。GitHub 没有在这篇 changelog 里给出仪表盘的具体 URL 路径，也没有写数据延迟小时数；你只能按 Insights 导航和字段是否为 null 来判断数据是否就绪。

copilot_feature_engagement 在计算不可用时会缺失或为 null，这不等于零。某个采用阶段若未被测量，users_in_phase_28d 会被省略；写 0 才表示测过且为空。没开 Copilot usage metrics 策略，仪表盘和 API 都看不到这些数。调用 REST 时，企业侧需要 manage_billing:copilot 或 read:enterprise，组织侧需要 read:org，外加对应的 View Copilot Metrics 权限。

它也不回答“这段代码是谁写的”或“这笔 credits 花在哪个模型上”。质量、成本和安全仍要另接用量、预算和审计。ROI 区块在 impact dashboard 里本来就是方向性估算，GitHub 文档写了不要当成精确财务结果。

人接管点很具体：看到被动审查远高于主动审查时，先抽 10 条自动审查评论，判断是建议没用，还是自动指派范围太大。看到 CLI 为空时，先确认组织有没有禁止 CLI、有没有托管沙箱策略，再决定要不要培训。看到 Cloud Agent 人数高、合并吞吐却没动，先查会话是否卡在等待审批，而不是继续加席位。

如何试用

确认企业或组织已启用 Copilot usage metrics 策略。
用企业所有者、billing manager、组织所有者或带 View Copilot Metrics 的角色，打开 Insights → Copilot impact。
看各表面“28 天内至少两天”的人数，并对照主动/被动审查，不要把七个数字加总当覆盖率。
若要进周报或数据仓库，拉企业和组织 28 天聚合，读取 copilot_feature_engagement、totals_by_feature、users_in_phase_28d。字段缺失时按“计算不可用”处理，不要当 0。