Michael Johnson从 11 月 5 日起，使用 GitHub Copilot Code Review 的团队可以在 API 报告中查看开发者是否对评论采取了行动。同一天，GitHub 还新增了相关字段，帮助管理员发现遥测数据缺口和过时的编辑器版本。这些更新为管理者和组织所有者提供了更具体的方法，用来检查 AI 代码评审的效果，以及 Copilot 使用数据是否完整。
如何衡量对 AI 评论的响应
每日仓库报告行 repos-1-day 中新增了 copilot_code_review 对象。其中的字段包括 total_comments_evaluated（已评估的评论数）和 total_comments_addressed（开发者已响应的评论数）。要计算某个仓库中已处理评论的比例，需要用第二个值除以第一个值。新增字段的说明见Copilot usage metrics API 更新。
如果开发者应用了建议的修复、要求 Copilot 实施修复、自己编辑代码，或回复说会在下一个拉取请求中纳入修复，GitHub 就会将其计为已采取行动。报告还会按严重程度、评审级别、评论类型，以及是否提供额外指令或工具，对评论进行细分。团队因此可以分析安全类评论是否比其他评论更容易得到响应，或哪些类别需要更多人工处理。
这项指标反映的是记录到的行动，而不是修复质量已得到验证。因此，最好结合代码检查和拉取请求状态来解读：已处理评论比例较高，说明评论得到了回应，但这本身并不能证明所有更改都正确或必要。另一个重要细节是：评论会计入拉取请求合并当天，而不是 Copilot 发布评论的当天。
为什么行动指标不同于建议采纳率
此前的字段统计 Copilot Code Review 的运行次数，以及用户点击按钮应用现成建议的情况。新指标涵盖更多响应方式：开发者可以自行修复、要求 Copilot 修复，或将更改推迟到下一个拉取请求。因此，total_comments_addressed回答的是开发者对评论采取了哪些行动，而total_copilot_applied_suggestions只统计通过一次操作即可应用的建议。
报告中还包括 total_merged_no_human_change_request_after_review：由 Copilot 评审过、且首次评审后没有任何人要求修改的已合并拉取请求数量。这些指标描述的是工作流程中的不同阶段，适合结合起来解读：前者反映开发者对评论的响应，后者反映评审直至合并的进展。
新增字段揭示报告不完整的原因
11 月 5 日的另一项更新新增了客户端遥测和工具版本信息。字段 client_telemetry_present 表示某一天是否收到该用户编辑器发出的事件；usage_metrics_requirements 则指出 IDE 和扩展是否达到指标所需的最低版本。管理员还可以查看每天缺少遥测数据的用户数量，以及至少有一个组件版本过旧的用户数量。详细内容见Copilot 数据缺口说明。
这些信息有助于区分用户是否活跃与报告数据是否完整。GitHub 解释说，即使没有收到编辑器事件，用户仍可能被计为活跃用户——此时，报告会缺少按功能和模型划分的使用情况等细节。可能的原因包括 IDE 或扩展版本过旧、编辑器遥测功能已关闭，以及代理或网络防火墙阻止了事件传输。
两个缺口计数不能相加来计算不重复用户数，因为同一个人可能同时属于这两类。此外，编辑器版本符合要求，也不代表遥测数据一定能送达，例如网络限制仍可能存在。如果某个值缺失或为 null，GitHub 会将其标记为数据不可用，而不是零或没有问题。
对团队意味着什么
这些新功能让团队能够用两项更具实际意义的检查，取代笼统的 Copilot 活跃度指标：Code Review 评论得到了怎样的处理，以及内部报告所依据的数据有多可靠。工程团队负责人可以比较不同类型的评论和仓库；管理员则可以找出需要更新 IDE 或扩展，或检查网络设置的用户。
拥有相应 Copilot 指标查看权限的用户，可以在组织和企业级别访问报告；同时必须启用 Copilot usage metrics 策略。Code Review 数据位于 repos-1-day 行中，而遥测与版本字段则包含在 1 天和 28 天的用户报告中。因此，这项更新对已集中管理 Copilot 的组织尤其有用：它们现在不仅能了解助手是否被使用，还能查看开发者如何响应其评审，以及测量数据为何不完整。
