Copilot 影响仪表盘现已展示功能参与度

Copilot 影响仪表盘现在显示有多少活跃用户定期使用关键 Copilot 功能。企业管理员可以快速看到哪些体验被广泛采用，哪些可能需要更多启用支持。

企业和组织报告 API 现在包含相同的 28 天功能参与度细分，以及一项 AI 采用阶段报告改进，该改进添加每个阶段截至每个报告日的完整滚动 28 天人群。

Copilot 影响仪表盘：显示在 28 天期间至少有两天参与每个包含功能的活跃用户数。

copilot_feature_engagement：将仪表盘的活跃用户总数和功能参与度计数添加到企业和组织 28 天聚合报告中。

totals_by_feature：按代码补全、代理编辑、被动 Copilot 代码审查、主动 Copilot 代码审查、Copilot 云代理、Copilot CLI 和 Copilot 应用细分参与度。

users_in_phase_28d：报告截至当天分类到每个 AI 采用阶段的完整滚动 28 天人群。

现有的 total_engaged_users 字段继续只报告当天活跃的阶段用户。

企业领导者可以看到哪些 Copilot 功能正在成为开发者常规工作流的一部分，并将培训或配置更改集中在采用率较低的地方。

以前，AI 采用阶段细分只显示在给定日期活跃的每个阶段用户数。它们现在还包括截至当天的完整滚动 28 天阶段人群。

功能参与度可在企业和组织 28 天聚合报告中获得，且不会添加到用户级报告中。

一个用户可以在多个功能下被计数。

主动 Copilot 代码审查意味着用户手动请求 Copilot 审查或应用了 Copilot 审查建议。

被动 Copilot 代码审查意味着 Copilot 被自动分配审查用户的拉取请求，而用户没有主动参与审查。

users_in_phase_28d 和 total_engaged_users 是聚合计数，不识别单个用户。

当阶段人群未被测量时，users_in_phase_28d 被省略。值为 0 表示该阶段被测量且没有用户。

当计算不可用时，copilot_feature_engagement 对象可以缺失或为 null。

数据可供企业所有者和账单管理者、组织所有者，以及任何拥有授予查看 Copilot 指标权限的自定义组织或企业角色的人使用。必须启用 Copilot 使用指标策略。

GitHub Copilot 影响仪表盘新增功能参与度视图，并同步到企业和组织 28 天聚合报告 API，企业管理员可查看哪些 Copilot 功能被活跃用户定期使用。

• GitHub Copilot 影响仪表盘新增功能参与度视图，并同步到企业和组织 28 天聚合报告 API，企业管理员可查看哪些 Copilot 功能被活跃用户定期使用。
• 原贴提到：The Copilot impact dashboard now shows how many active users regularly u
• 来源：github.blog

这是什么信号

GitHub 在 Copilot 影响仪表盘中新增功能参与度视图，并把同一套 28 天功能参与度数据接入企业和组织聚合报告 API。信号的核心不是“Copilot 有多少活跃用户”，而是“活跃用户具体在用哪些 Copilot 能力，以及是否形成至少两天以上的重复使用”。同时，AI 采用阶段报告新增 users_in_phase_28d，用滚动 28 天人群替代只看当天活跃用户的旧口径。

为什么重要

企业级 AI 编码工具的评估正在从总量指标走向功能级采用指标。过去管理者容易看到 licenses、活跃人数或阶段分布，但很难判断代码补全、代理编辑、主动/被动代码审查、云代理、CLI、应用等具体能力是否真正进入开发者日常工作流。功能参与度把“是否采用”拆到功能维度，并允许一个用户被多个功能计数，这更接近实际工作流组合，而不是单一活跃标签。

另一个重要变化是 AI 采用阶段的人口口径。users_in_phase_28d 报告截至报告日完整滚动 28 天中处于每个阶段的用户数，而 total_engaged_users 仍只报告当天活跃的阶段用户。前者更适合看阶段人群规模，后者更适合看当日参与。两者结合，能减少只用“当日活跃”判断阶段进展带来的偏差。

对谁有价值

直接使用者包括企业所有者、账单管理者、组织所有者，以及拥有 View Copilot Metrics 权限的自定义组织或企业角色。对开发体验、平台工程、工程效率、DevOps 和内部 AI 赋能团队而言，这些字段可以用于内部采用看板、培训优先级排序和配置调整。对采购与财务相关角色，功能参与度可以作为续费、扩席或调整投入的参考，但它本身不提供个人级明细。

可以怎么行动

第一，先确认 Copilot 使用指标策略已启用，并核对哪些角色拥有 View Copilot Metrics 权限。第二，在企业和组织 28 天聚合报告中读取 copilot_feature_engagement 和 totals_by_feature，按功能查看活跃用户总数与细分参与度。第三，把低采用功能与培训、文档、IDE 配置、代码审查流程结合起来，而不是只做统一宣导。第四，用 users_in_phase_28d 观察各 AI 采用阶段的滚动 28 天人群规模，用 total_engaged_users 观察当日活跃，避免混用口径。第五，把 API 数据接入内部报表，形成按周期追踪的功能采用趋势。

风险或限制

功能参与度只在企业和组织 28 天聚合报告中提供，不加入用户级报告，因此不能用来识别个人。一个用户可以在多个功能下被计数，所以功能参与度之和不能简单等同于独立用户数。主动与被动 Copilot 代码审查有不同的行为定义，解读时需要区分。users_in_phase_28d 在阶段人群未被测量时会被省略，值为 0 才表示已测量且没有用户；copilot_feature_engagement 对象在计算不可用时可能缺失或为 null。此外，数据访问依赖权限与 Copilot 使用指标策略，企业需要先完成治理配置。

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《Copilot 影响仪表盘现已展示功能参与度》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。

• Allison 原帖