GitHub Copilot 用量指标 API 新增代码审查明细与采纳率

GitHub 于 11 月 5 日更新 Copilot 用量指标 API，在企业与组织级仓库的 repos-1-day 报告每一行新增 copilot_code_review 对象，用于呈现 Copilot 代码审查反馈的后续处理情况。此前报告只能看到审查运行次数和直接应用建议的次数，新字段把开发者以其他方式处理反馈的情况也纳入统计，并支持按仓库计算采纳率。

新增字段与采纳率计算

每个 repos-1-day 行新增的 copilot_code_review 对象包含 total_comments_evaluated 和 total_comments_addressed 两个计数：前者是被检查开发者是否采取行动的 Copilot 代码审查评论数，后者是被判定已处理的评论数。用后者除以前者即可得到该仓库的采纳率。

原文明确，开发者应用建议、要求 Copilot 执行修复、自行编辑代码，或回复称将在后续 PR 中修复，都算作已处理。这与原有 pull_requests.total_copilot_applied_suggestions 不同，后者只统计有人点击应用的现成建议。

按维度拆分与合并 PR 指标

新对象还提供 review_comments_by_severity、review_comments_by_review_tier、review_comments_by_comment_type 和 review_comments_by_customization 四组拆分，分别按严重程度（如高、中、低）、审查档位（如 lite、balanced、max）、评论类型（如缺陷、安全或仓库自定义编码规范）以及定制方式（自定义指令、技能、MCP 服务器或无）给出上述两个计数。

另有一个 total_merged_no_human_change_request_after_review 字段，统计经 Copilot 代码审查后、在 Copilot 首次审查之后没有任何人要求修改的已合并 PR 数量。GitHub 表示，这些数据可用于判断自定义指令、技能和 MCP 服务器是否带来差异，以及审查者是否仍会在 Copilot 审查后要求改动。

统计口径与边界条件

这些字段出现在企业与组织 repos-1-day 报告的每一行；若某仓库当天没有 Copilot 代码审查活动，计数为 0、数组为空。评论在其所属 PR 合并时才被评估，因此计入合并当天，而不是 Copilot 发布评论的当天。

对于机器人开设的 PR，例如 Copilot 云智能体发起的 PR，Copilot 通常不会评估其中的评论，但 total_merged_no_human_change_request_after_review 仍会把这些 PR 计入。

访问权限与启用条件

可使用这些报告的人群包括企业所有者、企业账单管理者、组织所有者，以及被授予 View Copilot Metrics 权限的自定义组织或企业角色。此外还需启用 Copilot 用量指标策略，具体接入方式可参考 Copilot 用量指标 API 文档。

知序观察

观察：这次更新把 Copilot 代码审查从“运行了多少次、点了多少次应用”推进到“反馈是否真正被处理”，并按严重程度、审查档位和定制方式拆分，便于团队评估自定义指令、技能与 MCP 服务器是否改变审查效果。需要注意的是，采纳率依赖合并时点的评估口径，机器人 PR 的评论不计入评估，解读数据时应结合这些边界条件。