别被 AI 评审带偏：给 AI 代码评审结论做二次验证的方法

先划界：这篇不讲评审流程，也不讲检查项

这篇的前提是：你已经有 AI 评审了，不管是模型审你的 PR，还是审 AI 自己写出来的代码。这篇不教你怎么搭建评审流程，也不罗列评审要查哪些项——流程和检查项都有现成的指南。这篇只解决流程之后的问题：评审给了一堆结论，你怎么判断哪些该改、哪些该扔、哪些看起来很专业其实是错的。

换句话说，这篇讲的是“评审的评审”。AI 评审最大的风险不是它漏掉了问题，而是它说得太像回事，让你不知不觉照单全收。被带偏的方式很少是低级错误，多半是：把风格当缺陷、把猜测当事实、把小问题说成高危、把真正的高危淹没在一堆正确的废话里。

为什么人会被 AI 评审带偏：四种心理陷阱

第一，流畅即正确。评审意见写得越完整、术语越准确，你越倾向于相信它，哪怕它指向的代码根本不存在。先问一句：它引用的函数名、文件名、行号，在你的仓库里真实存在吗？不存在的引用，整条意见直接作废，不需要再读下去。

第二，数量即严重。评审一次抛出二十条意见，你会本能地觉得代码问题很大。实际上二十条里可能十九条是风格偏好，一条是真问题，而真问题藏在第十七条。先分类再行动，不要按意见的顺序改，更不要按意见的数量焦虑。

第三，严重度通胀。AI 评审喜欢把问题标成严重、高危、必须修复，因为它不知道你的上下文：这段代码是不是只跑在内部工具里、这个接口是不是根本不对外、这个“注入风险”是不是已经被上层过滤掉了。严重度必须由你根据真实暴露面重新定，评审标的严重度只作参考。

第四，权威幻觉。当评审意见引用了某个设计模式、某条安全规范、某个“最佳实践”，你会下意识地不敢质疑。质疑的方法很简单：让它说出可验证的东西——复现步骤、失败输入、真实调用链。说不出来的规范引用，等于没有证据的指控。

二次验证四步法：每条意见都过一遍

第一步，验存在。核对意见引用的代码是否真实存在、是否在本次改动范围内。评审经常对着旧版本、别的分支、甚至自己脑补的代码提意见。引用不存在、或者与本次 PR 无关的意见，直接关闭，附一句“引用代码不在本次改动中”。

第二步，验复现。对每条声称是缺陷的意见，要求一个最小复现：什么输入、走哪条路径、会产生什么可观测的坏结果。能复现的才是缺陷；只能描述、不能复现的先放进“待证实”清单，不进本次修复。反例：评审说“这里可能有竞态条件”，却给不出两个并发执行的路径和交错顺序——这不是结论，这是一个需要你自己去证实或证伪的猜想。

第三步，验暴露面。问三个问题：这段代码谁能触发？触发需要什么权限？最坏结果影响谁的数据？只跑在本地脚本里的“注入风险”，和对外接口的“注入风险”，根本不是同一个级别。暴露面决定修复优先级，脱离暴露面谈严重度没有意义。

第四步，验代价。修复本身有没有代价？改动会不会引入新风险、破坏现有行为、拖垮性能？有些评审建议在技术上正确，但在你的项目里不值得做：比如给一个内部一次性脚本加完整的权限体系。正确的处理不是照做，而是写下“已知风险、接受理由、复查条件”，留给以后。

三类意见，三种处理：照单全收是最差策略

把评审意见先分进三类，再决定动作。分类本身只要十分钟，却能省掉一整天被带偏的返工。

必须修：能复现、暴露面真实、修复代价可控。这类意见直接进修复清单，修完要回归验证。注意，回归验证的对象是复现步骤本身，不是评审意见的文字：按复现步骤再走一遍，坏结果消失才算修好。

先证实再修：听起来合理，但复现或暴露面还没确认。这类意见不要立刻改代码，先做最小验证：写一个测试、构造一次输入、查一次调用链。验证失败就关闭意见并记录原因；验证成功就升级为必须修。最浪费时间的模式，恰恰是跳过验证直接改代码，改完才发现原来问题不存在。

直接关闭：引用不存在、纯风格偏好、脱离项目约束的“最佳实践”。关闭时写一句话理由，不要默默忽略。理由写下来有两个好处：下次同一个评审再提同样意见，你可以直接引用上次的结论；团队其他人看到关闭记录，也知道这不是疏忽，而是判断。

反例值得单独说一个：评审指出“这个函数太长，应该拆成三个”，并给出了一套拆分方案。拆分本身没错，但这次 PR 的目标是修复一个线上故障，拆分会扩大改动面、增加回归风险。正确的处理是：承认建议合理，拒绝本次执行，记进重构清单。评审意见正确，不等于现在就要执行。

反向质问评审：四句可以直接复制的话

当你怀疑一条意见时，不要凭感觉争论，用固定的问题逼它拿出证据。下面四句可以直接粘贴进评审对话：

• “请给出最小复现输入和可观测的坏结果，不要只描述可能性。”这句话能过滤掉一大半猜测型意见。
• “这段代码的真实调用方是谁？请列出调用链，不要假设调用方。”用来对付脱离暴露面的严重度判断。
• “如果按你的建议改，现有哪个测试会失败、哪个行为会变化？”用来评估修复代价，防止以修代坏。
• “请指出你引用的规范原文适用于本项目的哪一条约束。”用来对付搬运来的最佳实践。

如果评审在反问之后修正了自己的结论，这不是评审失败，这是二次验证在起作用。好的评审流程应该奖励这种修正，而不是把第一次结论当成不可挑战的判决。一个从不被挑战的评审，不论是人还是 AI，都会越来越自信、越来越不准。

评审意见的去重与合并：别让同一问题改五次

AI 评审还有一个隐蔽的带偏方式：同一个根因，用五种说法提五次。你按顺序改，会改出五处互不兼容的补丁。处理办法是先合并再动手：把指向同一函数、同一数据流、同一假设的意见归成一组，只修根因一次。

举个具体例子：评审分别指出“这里没校验长度”“那里没校验类型”“下游没处理空值”。三条意见的根因可能是同一个：入口处缺少统一的输入校验。只在入口修一次，比在三个地方各打一个补丁更干净，也更容易回归验证。合并之后再看：如果三条意见其实指向三个独立问题，再分开处理也不迟。

合并的另一个好处是暴露评审的盲区。当你把意见归组之后，常常会发现某一类问题完全没有被提到——比如评审盯着代码风格，却没看错误处理；或者盯着性能，却没看权限。归组之后留白的地方，就是你需要人工补看的地方。评审没提，不等于没问题。

给团队的评审复核清单：每次 PR 花十分钟

把下面这张清单贴进 PR 模板，评审意见处理完之后逐项打勾。它不增加流程，它只是把二次验证变成习惯。

• 引用核对：每条意见引用的代码真实存在且在本次改动范围内。
• 复现确认：每条缺陷类意见都有最小复现，或已明确标记为待证实。
• 暴露面定级：严重度已按真实调用方和权限重定，不是照抄评审标注。
• 代价评估：每项修复的回归范围已确认，纯风格建议已决定本次做还是不做。
• 关闭有理由：每条关闭的意见都写了一句话理由，可供以后引用。
• 合并已完成：同一根因的意见已合并，只修一次。
• 留白已补看：评审没覆盖的维度（权限、错误处理、数据兼容）已人工扫一遍。

最后记住一条原则：AI 评审是帮你发现问题的眼睛，不是替你做判断的大脑。眼睛可以看得比你多、比你快，但该不该改、什么时候改、改到什么程度，永远是人的决定。守住这个分工，评审才会越用越准；放弃这个分工，评审只会让你越来越不敢质疑它——而那正是被带偏的开始。

评审带偏的五种话术：听到就要警惕

AI 评审带偏 rarely 靠明显的错误，更多靠话术。话术的特点是：听起来无法反驳，但仔细一问，证据是空的。下面五种话术出现时，先停下来，不要直接动手改。

话术一：“最佳实践建议……”最佳实践前面没有项目约束，就等于没有信息。追问：这个最佳实践解决的是本项目的哪个具体问题？如果评审答不上来，或者答的是一个你项目里不存在的问题，这条意见就是搬运。搬运来的建议即使正确，也可能不适用于你的规模、你的用户、你的阶段。小项目照搬大厂实践，是最常见的过度设计来源。

话术二：“可能存在……”“可能存在注入风险”“可能存在竞态”“可能存在内存泄漏”，可能性本身不是结论。评审的职责不是列出所有可能性，而是给出可验证的判断。处理方法是把“可能”翻译成验证任务：构造什么输入可以证实它，构造不出来就先关闭。无限列举可能性，等于把验证成本全部转嫁给你，而验证成本才是评审流程里最贵的部分。

话术三：“从安全角度看，必须……”安全这个词自带道德压力，让人不敢拒绝。但安全也有优先级：对外接口的未授权访问，和内部脚本的日志里多打了一个字段，根本不是一个级别。追问暴露面：谁能触发、需要什么权限、最坏结果是什么。答不上暴露面的安全意见，先降级，再验证，不要被“安全”两个字直接推到必须修复。

话术四：“这段代码难以维护。”难以维护是一个判断，不是事实。判断需要标准：是函数太长、职责不清、还是命名误导？如果评审只给判断不给标准，你无法验证它，也无法确认改完之后是不是真的变好了。要求它指出具体的维护成本：下次改需求时，哪一步会因为这段代码而变难。说不出来的维护问题，先放进重构清单，不进本次修复。

话术五：“建议重构为……”重构建议常常附带一套看起来很优雅的新结构，但新结构的代价被藏起来了：调用方要不要改、测试要不要重写、性能会不会变化。评估重构建议时，先看代价再看优雅。优雅但代价大的重构，在修复故障的 PR 里一律拒绝，在专门的重构 PR 里再讨论。

不同场景，复核强度不一样：别用同一标准审所有 PR

二次验证不是要对所有 PR 用同一套重型流程。复核强度应该跟着风险走，风险来自三个维度：改动范围、暴露面、回滚难度。三个维度都低的 PR，快速过一遍引用和复现就够了；任何一个维度高的 PR，才值得走完整四步法。

举三个档位。第一档是纯内部改动：内部脚本、文档生成、开发工具。这类 PR 的评审意见，重点看引用是否真实，其他可以放宽，因为最坏结果也只影响开发者自己。第二档是常规产品改动：界面、普通接口、非核心数据流。这类 PR 走标准四步法，重点是复现和暴露面。第三档是高风险改动：鉴权、支付、数据迁移、对外接口。这类 PR 除了四步法，还要人工补看评审没提到的维度，并且修复之后必须回归验证，验证步骤要写进 PR 描述里。

档位划分的意义，是防止两种极端：对低风险 PR 过度复核，浪费时间；对高风险 PR 轻信评审，酿成事故。很多团队的问题不是没有复核，而是复核强度平均分配，结果该严的地方不严，不该严的地方又卡住了进度。先定档位，再定强度，复核才可持续。

还有一种特殊场景值得单独提醒：评审意见和你自己的判断冲突时，不要用“评审说得有道理”来压倒自己的判断，也不要用“我比 AI 懂”来压倒评审。正确的做法是回到证据：复现、调用链、测试结果。证据支持谁，就听谁的。证据不支持任何一方，就先做最小验证，验证结果出来之前，代码不动。把争论从“谁更可信”变成“证据说什么”，是二次验证最核心的心态转变。

关闭理由的写法：三句模板，留给未来的自己

关闭意见时写的理由，不是写给评审看的，是写给三个月后的自己和团队看的。理由要回答三个问题：为什么关闭、依据是什么、什么条件下重新打开。模板只有三句，但缺一句，记录就失去价值。

• 关闭示例一：引用代码不在本次改动中，相关函数属于旧分支；若该分支重新合入，需重新评审。
• 关闭示例二：已构造复现输入，未观测到所述坏结果，调用链显示上层已过滤；若上层过滤逻辑变更，需重新打开。
• 关闭示例三：建议合理但属于重构范畴，本次 PR 只修线上故障；已记入重构清单，不在本次执行。

养成这个习惯之后，你会发现一个副产品：团队对评审的信任度反而上升了。因为每一次关闭都有理由，每一次修复都有复现，评审不再是一个不可质疑的黑箱，而是一个可以讨论、可以纠错、可以积累结论的协作过程。信任不是来自照单全收，而是来自每一次判断都有据可查。