Copilot评审反馈新增处理率统计

GitHub Copilot Changelog#Copilot#代码评审#效能度量

Editor brief · 编辑速览

Copilot企业及组织的仓库级用量报告新增copilot_code_review对象，提供代码评审反馈的处理情况与处理率。团队可据此观察AI评审建议是否进入实际修改流程。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

Copilot 留下了多少条审查意见，不等于开发者处理了多少条。GitHub 这次给使用量指标 API 增加了代码审查明细，让企业和组织能按仓库查看：哪些反馈有人响应，以及 Copilot 审查后，是否仍有人要求修改。

变化不只是多一个比例。新指标补上了「没有点击应用建议，但通过其他方式处理了反馈」的统计缺口。不过，处理率也不能直接当作修复率或代码质量评分。

企业和组织的仓库级 repos-1-day 报告，现在每行都有一个 copilot_code_review 对象。其中两个字段用于计算处理率：

处理率的计算方式是 total_comments_addressed / total_comments_evaluated。

这里的「采取行动」口径比较宽：应用建议、要求 Copilot 修复、手动修改代码，甚至回复「会在后续 pull request 中修复」，都算已处理。

处理率统计的是开发者对反馈的响应，不保证问题已经修好。

原有的 pull_requests.total_copilot_applied_suggestions 只统计有人应用了可直接应用的建议。开发者看完评论后自己改代码，这个旧指标就无法覆盖；新指标则把每条被评估的评论纳入统计。

但公告没有说明系统如何识别这些行动，也没有给出识别准确率。接入报表时，需要保留这层不确定性。

新指标支持同时拆分「评估数」和「处理数」，方便比较不同反馈的响应情况：

review_comments_by_severity：按严重程度拆分，例如 high、medium、low。
review_comments_by_review_tier：按审查档位拆分，例如 lite、balanced、max。
review_comments_by_comment_type：按评论类型拆分，例如 bug、security，以及对应仓库编码规范的 custom。
review_comments_by_customization：按定制方式拆分，例如 custom instructions、skills、MCP servers 或 none。

另一个字段 total_merged_no_human_change_request_after_review，统计经过 Copilot 审查并已合并，且在 Copilot 首次审查后没有人请求修改的 pull request 数量。

读这些数字时，时间和范围尤其容易弄错。评论在 pull request 合并时才被评估，计入合并当天，而不是 Copilot 发出评论的当天。因此，某天处理数上升，可能只是当天合并了更多积压的 pull request。

机器人创建的 pull request 也有不同待遇。Copilot 通常不评估这类请求中的评论，Copilot cloud agent 创建的请求就是例子；但「合并且无人请求修改」的计数仍包含它们。两类指标覆盖的请求范围并不完全一致。

每个仓库每天都会有对应行。当日没有 Copilot 代码审查活动时，计数为 0，数组为空。处理率的分母为 0 时，应显示为无可计算数据。

访问报告还要求启用 Copilot usage metrics policy。可访问者包括企业所有者、企业账单管理员、组织所有者，以及通过自定义企业或组织角色获得 View Copilot Metrics 权限的人。

这次补充很有用。相比只看审查次数和建议应用次数，它更接近开发者实际处理反馈的过程，也给团队检查定制规则是否有帮助提供了数据入口。

但公告没有提供实测案例、对照数据或效果提升数字。它证明的是新增了观测能力，尚不能证明 Copilot 审查更有效。

高处理率不等于高质量，合并后无人请求修改也不等于没有缺陷。

前者可能包含延后修复的回复，后者也可能受到人工审查习惯影响。按 custom instructions、skills 或 MCP servers 分组后出现差异，可以作为排查线索；不同仓库的任务难度、参与者和审查流程也可能不同，不能直接归因为某项定制配置。