Copilot 代码评审按生命周期分类：把“未解决、已解决、此前漏看”分开

小猫跳舞 技术创作者 2026-09-22 127 阅读

先说结论

  • GitHub 官方在 2026-09-18 的 Copilot code review: An improved review experience 中，把评审 overview 评论按生命周期分组为 Open、Resolved since last review、Previously missed；其中 Open 组内的问题可能带 new 标签，表示由新提交引入。
  • 这次更新不是“Copilot 能审出更多问题”，而是把“当前还值不值得看”前置，减少已经修复、重复出现、状态不清带来的噪音。
  • 自动解决自己评论的能力更谨慎：当有人回复要求保持打开时，Copilot 尊重回复；根据后续提交解决时，会给出 Won't Fix 或 Incorrect 原因。
  • 批量接受完整建议时，Copilot 可以生成相关 commit title 和可选 description；批次中即使夹着非 Copilot 评论，也能生成智能提交消息。
  • 本文所有产品行为来自官方 changelog；官方没有给出准确率、误报率、解决率等数字。文中的优先级排序和示例场景是作者自己的判断/推演，不是官方建议。

证据与过程

官方更新落在“评审进度”和“提交可读性”两条线上

官方 changelog 原句写得很直接：

Copilot code review now gives you a clearer view of how a review changes over time, more intelligently auto-resolves its own suggestions, and generates useful commit messages when you accept eligible suggestions in a batch.

这句话包含了三个能力点：更清晰地展示评审随提交变化的进度、更智能地自动解决自己的评论、为批量接受的建议生成提交消息。这里“generates useful commit messages when you accept eligible suggestions in a batch”是官方定义的能力边界，但 eligible 和 complete batch 的判定条件，changelog 没有展开，应归入“这次没核实的”。

如果把这次更新放进 GitHub Changelog 汇总页 看，9 月 Copilot 代码评审相关更新不止一条。这种连续迭代说明，产品重点正在从“让 AI 写出更多评论”转向“让评论可以被管理”。

分组字段不能简化成 new / resolved / previously missed

很多地方会把这次更新简化成“new / resolved / previously missed”三类，但官方原始分组不是这样。官方原文把 findings 分组为：

  • Open：尚未解决的问题，可能带 new 标签，表示由新提交引入。
  • Resolved since last review：Copilot 已验证你修复了此前发现的问题。
  • Previously missed：不是由新提交引入，而是 Copilot 在后续评审中，在你已有的改动里新发现的问题。

所以 new 并不是与 Open 并列的第三类，而是 Open 组内的一个可选标签。这个区别很重要：官方实际上先按“是否已解决”切一刀，再在未解决里面区分“是否本轮新引入”。如果把 new 当成独立分类，容易误解成三组完全独立。

需要显式标注：以上字段名和含义来自官方 changelog 原文，不是社区二手信息，也不是作者推测。

官方还写明，每条 finding 包含 severity 和对应 inline comment 链接，因此可以从 overview 快速跳到相关代码。对 Previously missed，官方特别说明：因为这些问题没有在 PR 上的其他地方评论过，所以 overview 里保留了这些评论的 exact details。这可以理解为，Previously missed 不是简单重复，而是为了避免这些后发现的旧问题没有行内入口，审查者只能从 overview 里看到详情。

评论标题降低扫读成本

官方说明，每条 Copilot code review comment 现在包含一个标题，用简洁语言描述发现了什么。这些标题会用在 overview 的 issue list 中，也作为 Copilot findings 的快速描述。

字段名 title 是官方 changelog 提到的。官方没有给出标题格式、长度限制或枚举值，因此这些是本篇未能核实的内容。工程上可以这样用：先在 overview 里按标题和 severity 扫一遍，再决定要不要点开某条行内评论。这是常见做法，不是官方推荐流程。

自动解析变得更有边界

在 9 月 11 日的 auto-resolution and analysis updates 中，GitHub 已经发布过自动解析已处理评论的能力。本次 9 月 18 日 changelog 进一步写明了两个改善：

  • 当 Copilot 评论收到要求保持打开的回复时，Copilot 尊重该回复。
  • Copilot 根据后续提交解决评论时，使用 Won't Fix 或 Incorrect 作为 resolution reason。

这里 Won't Fix 和 Incorrect 是官方原文中出现的关闭原因。理解其用途时要注意，官方并没有说“开发者应如何审计这些原因”。实践中常用的一种做法是：如果某个 AI 评论是误报，但暂时不打算改，可以回复让它保持打开，避免被自动关闭；事后定期过滤 Won't Fix 和 Incorrect 评论，检查是否有真实问题被错误关闭。这是作者建议，不是官方要求。

智能提交消息补上批量接受的最后一环

官方原文写道：

When you commit an eligible, complete batch of Copilot code review suggestions, Copilot now generates a relevant commit title and an optional description based on the selected changes. Batches can also contain non-Copilot comments and will still receive smart commit messages.

这段说明两点：批量提交 Copilot 建议时，会生成 commit title 和可选 description；批次里即使包含非 Copilot 评论，也可以生成智能提交消息。这里的行为描述是官方说法。工程上的做法是：把自动生成的 commit message 当草稿，而不是直接无脑合入。尤其是混合了非 Copilot 评论的批次，自动摘要可能突出了某类建议，却忽略了另一类，提交前需要人工验证。

自己的判断：这不是“审得更准”，而是“状态收敛”

Copilot 代码评审最让人烦躁的，往往不是“报错问题”，而是“同一个问题被反复报”。如果一个 PR 有多次提交，而评审工具没有状态追踪，已修复的问题会继续显示为未处理；开发者必须靠自己判断哪些评论已经过时。这次 GitHub 把“是否已解决”作为第一层分类，相当于把评论列表从时间线视图改成了状态视图。

举一个假设场景（非官方数据，仅用于说明状态流转）：

  • 第一轮 Copilot 报了 5 个问题。
  • 第二次提交修复了其中 2 个。
  • 有一个问题被人工回复“保持打开”。
  • 第三次提交又引入 1 个新问题。
  • 第三轮评审还在旧改动里发现了 1 个此前漏看的问题。

如果没有生命周期分类，这些评论会混在 PR 时间线里。新的 overview 则把 2 个已修复的问题放进 Resolved since last review，把 1 个新提交引入的问题放进 Open 并打上 new，把 1 个第三轮才发现的问题放进 Previously missed。人工复核时，视线会先落在 Open 和 Previously missed，而不是逐条翻历史。

下面是我根据官方分组字段整理的评论生命周期示意。这个结构示意不是官方 JSON schema，官方只给了分组名和含义，没有给出返回格式。

# Copilot 评论生命周期示意（分组含义依据官方 changelog，格式为作者整理）
state: Open
  meaning: 尚未解决
  new_label: true | false   # true 表示由新提交引入；官方原文为 new label

state: Resolved since last review
  meaning: Copilot 已验证此前问题已修复

state: Previously missed
  meaning: 非新提交引入，但后续评审在老改动中新发现
  detail_in_overview: true   # 官方说明这些详情保留在 overview，因为别处没有行内评论

可以带走的人工复核清单

以下清单是作者基于这次更新给出的实践建议，不是 GitHub 官方推荐，也没有官方阈值：

  1. 先看 Open 中带 new 标签的问题：它们和当前提交相关性最高，适合优先处理。
  2. 次看 Previously missed：它很容易被当成历史噪音，但官方把它单独列出，说明它可能是真实遗漏。
  3. 对不带 new 的 Open 问题，尽量在当轮给出处置：修复、回复保持打开，或等待后续自动解决。
  4. Resolved since last review 不必逐条重看，但建议抽查，确认 Copilot 没有把未修复问题误判成已解决。
  5. 对自动关闭的 Won't Fix 和 Incorrect，不要完全忽略：Incorrect 表示 AI 自认为报错了，需要确认它是不是在掩盖问题。

数据标注说明

  • 官方数据：本次 changelog 没有给出可引用的统计数字，只有字段名和行为描述。
  • 自己推算：文中的“5 个问题、2 个修复”等数字，是作者为说明状态流转假设的场景，不是官方统计。
  • 社区二手：本文没有采用社区二手信息；所有产品行为均来自 GitHub 官方 changelog 或其汇总页。

这次没核实的

  • review effort level 的具体档位和计算方式：官方只提到 overview 会显示它，changelog 没有展开。
  • eligible, complete batch 的判定条件：官方没有说明批次大小、建议类型、排除规则或为什么某些批次 eligible。
  • 自动生成 commit title 和 description 的模型、长度限制、失败兜底策略，官方未在本次 changelog 中写明。
  • 9 月 11 日 auto-resolution 条目的完整正文，本文未逐段核实；本次只依据 9 月 18 日 changelog 确认其能力被继续改善。
  • 不同 Copilot 套餐、IDE、GitHub Mobile/web 环境的可用性矩阵，未能核实。

参考来源

# 教程# 编程

评论区

0 条评论

登录后可评论。

小猫跳舞 127 阅读