AI 审查噪声正在淹没有效反馈

AI reviewer 最初抓出了遗漏的空值检查和未关闭的文件句柄，后来却让每个 PR 多出十五到二十条评论。原文提醒的是一个容易被忽略的代价：当开发者习惯批量关闭机器评论，人工留下的关键提醒也可能一起被跳过。

作者的结论是保留 AI 初筛，同时收紧评论范围、明确处理规则，让人工判断重新显眼。对已经接入自动审查的团队，值得检查的不只是它找出了多少问题，还有大家是否仍在认真阅读反馈。

评论太多，为什么会伤到人工审查

原文用一个团队场景说明问题：启用 AI reviewer 三个月后，评论逐渐集中在命名、小幅重构，以及其他地方已经处理的问题上。开发者开始不读内容，直接批量标记为已解决。

随后，一位同事认真指出的竞态条件（race condition）问题，也和另外十二条评论一起，在不到一分钟内被关闭。

这里的风险不只是多花几分钟。低价值评论反复出现，会训练读者忽略整条反馈通道。 人工评论与机器评论混在一起，最终可能得到同样草率的处理。

不过，原文没有交代团队、仓库或统计方法。这些数字构成了文章的叙述场景，不能当成 AI 审查工具普遍表现的实测结果。

先看评论有没有促成修改，再调整规则

作者建议，把讨论落在团队注意力上，并带上真实例子。一个可操作的起点是：粗略统计过去一个月，机器人留下的评论有多少最终促成了代码修改。

这能让讨论从「我觉得它很吵」转向具体反馈：哪些类别反复出现，却几乎没有人采纳？

接下来再调整配置。例如，formatter 已经强制执行的风格要求，就没有必要让 AI 重复提醒。原文认为多数此类工具可以配置，但没有列出具体产品、配置项或命令，实际能关闭到什么粒度，还得检查团队使用的工具。

评论的处理规则也要明确。作者给出的例子是：AI 评论可以要求作者回复或作出反应，但只有作者认可建议时才修改代码；人工评论则应得到更充分的处理。文章没有进一步规定人工意见的统一处理流程，这部分需要团队自行约定。

人工意见要显眼，人工审查也要保留

作者提出了两种让人工判断更容易被看见的做法：

• 对阻止合并的评论添加清晰标签，让作者知道哪些问题必须先处理。
• 在审查顶部写一段短摘要，交代审查者检查了什么、担心什么。

这些做法的共同作用，是让开发者快速识别需要认真回应的判断，而不是逐条猜测评论的重要程度。

AI 仍然可以做第一轮检查。但作者强调，它不知道改动为什么存在、谁依赖这段代码，也不了解团队去年尝试过什么。这些信息可能决定一段代码是否适合合并。

机器人没有发现问题，不能直接成为批准 PR 的理由。 没有人工判断的绿色勾选，只能说明自动检查没有提出异议。

我的判断

我认同作者把注意力当作有限资源。审查工具的价值不能只看评论数量，还要看它是否帮助团队发现并处理了重要问题。让 formatter 负责明确的格式规则，也比反复阅读同类 AI 建议更省事。

但「促成修改的比例」只能作为讨论入口。低采纳率可能来自误报，也可能来自建议缺少上下文；少数没有立即促成修改的评论，仍可能帮助作者确认实现。反过来，开发者照单全收，也不代表建议质量高。

原文没有给出调整前后的对照数据，也没有比较关闭评论类别、增加标签等措施的效果。这是一组合理的流程建议，属于经验之谈。

作者对 AI 缺少上下文的判断也有前提。如果工具能读取关联需求、历史讨论和仓库约定，部分信息缺口可能缩小。但上下文是否充分，仍需核查，不能从一次没有报错的审查中推断出来。

能拿来做什么

• 从最近一个月的 PR 中抽取一批 AI 评论，记录是否促成修改、为何未采纳，再据此决定关闭哪些评论类别。
• 检查 AI 是否重复提出 formatter 已覆盖的风格要求，把这部分反馈从审查评论中移除。
• 在团队约定中写清 AI 建议如何回应、人工阻塞意见如何处理，避免批量关闭评论成为默认动作。
• 保留人工审查，并要求审查者简短说明检查范围与主要顾虑，让批准合并有可追溯的判断依据。