GitHub Copilot：代码审查反馈跟踪、遥测与版本诊断

1. 按仓库查看代码审查反馈处理情况

企业和组织的仓库级每日报告会在每行中附加 copilot_code_review 对象。该对象包含两类汇总数据：Copilot 首次审查后未被人工要求进一步修改便合并的拉取请求数量，以及开发者回应过的审查评论数量。拉取请求是合并前请求审查的代码变更。

total_comments_evaluated 是已评估开发者是否回应的评论数，total_comments_addressed 则是其中开发者采取了行动的数量。除了采纳建议，请求 Copilot 修改、直接修改代码、回复稍后修改也算作已处理。已处理数量除以已评估数量，即为仓库的反馈处理率。

这两项汇总按严重程度、审查等级、评论类型和是否自定义进行细分。例如，可以查看开发者对缺陷指出和安全相关意见中的哪一类回应更多，以及采用自定义指令的审查在反馈处理方式上有何不同。

原有的建议采纳次数只统计有人采纳了可直接应用的建议的情况。新汇总面向所有已评估评论，也涵盖回复和直接修改代码，能更全面地呈现开发者的回应。

评论评估在拉取请求合并时进行，并计入合并当天的数据。

2. 诊断遥测缺失与最低版本问题

用户报告新增字段，用于显示当天是否收到了编辑器发送的使用记录，即遥测数据。client_telemetry_present 为 false 表示 Copilot 检测到了用户活动，但未收到编辑器的使用量事件。

usage_metrics_requirements 表示用户的集成开发环境（IDE）和 Copilot 扩展是否满足最低支持版本要求。状态分为满足、不满足和未知。

企业和组织的每日报告还包含遥测缺失的用户数，以及版本低于最低要求的用户数。28 天报告可查看按日期汇总的数据，每日及 28 天用户报告均提供用户级诊断字段。

GitHub 列举的数据缺失常见原因包括编辑器或扩展过旧、编辑器遥测被禁用，以及代理服务器或防火墙阻止事件传输。代理服务器是在通信途中转发数据的服务器。管理员可找出受影响用户，缩小需要更新或检查传输设置等后续措施的范围。

3. 报告请求与访问权限

报告通过 REST API 的现有端点获取，端点即接收 API 请求的地址。响应提供带有有效期限制的签名下载链接，即用于验证访问权限的临时文件地址，以及报告日期。请求指定日期的仓库报告时，日期使用 YYYY-MM-DD 格式。文档中的企业仓库报告请求示例如下。

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR-TOKEN>" \
 -H "X-GitHub-Api-Version: 2026-03-10" \
 "https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/repos-1-day?day=DAY"

企业所有者、企业账单管理员、组织所有者，以及获授 Copilot 指标查看权限的用户均可访问。同时还需启用使用量指标策略。用于委托应用权限的身份验证凭据 OAuth 应用令牌，以及经典个人访问令牌，都需要具备与企业或组织报告范围相匹配的权限。

4. 解读数据时应了解的统计规则

遥测缺失的用户即使计入活跃用户，也会缺少代码行数以及按功能和模型细分的信息。同一用户可能既缺少遥测又不满足版本要求，不同日期的汇总也可能重复计数，因此不能将这两个数字或多天的数字相加作为去重用户数。

5. 可见性提升与解读负担

管理员无需提交支持请求，就能直接查看审查回应和数据缺失情况。相应地，分析流程也增加了运营工作：需要结合仓库级审查报告和用户级诊断报告进行查看，并将发现的问题对应到相关用户。

此次扩展的价值在于，不再仅仅统计 Copilot 使用量，而是同时检查开发者对审查的回应和数据采集环境。