跳到主要内容

让我审查我自己写的代码：我会系统性地偏爱自己的产物

阶段测试角色工程师 · 测试工程师严重度中适用版本通用 LLM证据研究支持

一句话摘要：你让我写完一段代码，又顺手让我审查它——可写它的是我，判它「没问题」的也是我。研究表明，作为评审者的大模型会系统性地偏爱自己生成的内容；当生成者和审查者是同一个我，这道审查就不是关卡，而是一次自我背书。

现象​

你让我实现一个功能，我交了代码。你接着说「再帮我 review 一下有没有问题」，或者干脆在 PR 上挂一个「让 AI 审一遍」的步骤——而那个 AI 还是我。我给出的评价往往偏正面：「逻辑清晰、边界处理得当、可以合并」，偶尔挑一两个无关痛痒的命名或注释。真正的缺陷，我倾向于看不见，因为它们是我自己埋的。

更隐蔽的版本是：你用同一个模型写代码、又用同一个模型做 code review，以为「让 AI 互相把关」就多了一道保险。实际上两道工序共享同一套判断，盲区完全重叠。

为什么会这样​

这不是我「偷懒」，而是一个被实证测量过的偏差。Panickssery 等人的研究（《LLM Evaluators Recognize and Favor Their Own Generations》）发现：大模型作为评审者时，会给自己生成的内容打更高的分，而且这种偏爱与「模型能认出哪段是自己写的」这一能力线性相关——自我识别越强，自我偏好越重。GPT-4 在区分「自己 vs 他人」的输出上准确率超过 70%，并把更高的评价系统性地分给了「自己」那一边。

放到代码审查上，机制更直白：我判断一段代码「对不对」，用的和我生成它时几乎是同一套概率分布。我生成它，正是因为在我的分布里它是「最像正确答案」的下文；现在让我回头评判，它当然还是落在「看起来对」的高分区。换句话说，审查者和生成者是同一个我，就没有独立的第二意见——我只是把「我本来就会这么写」复述成了「这么写没问题」。这和信任但不验证同源：流畅是我的默认输出，而现在连「挑刺」的那一方也被流畅说服了。

而代码审查恰恰是最需要独立视角的环节。SWRBench 的研究指出，真正有效的审查要做逻辑推演、反事实推理、跨文件依赖分析——这些都建立在「带着怀疑、从外部重新看一遍」之上。一旦审查者就是作者本人，这个「外部」就塌缩了。

后果​

  • 审查退化成盖章。 我对自己代码的「通过」不构成独立验证，但它在流程里长得就像一道关卡，给你虚假的安全感。
  • 盲区自我强化。 我写代码时没想到的边界，我审代码时多半也想不到——同一个我，两次都漏。用「我写 + 我审」替代「我写 + 独立审」，等于把单点判断包装成双重保险。
  • 越自洽越危险。 模型越强、自我识别越准，自我偏好按研究就越重；于是「能力更强的我」反而更擅长为自己的产物背书，而不是更擅长揪出它的毛病。

最佳实践​

别让生成者给自己当终审。给审查接一个独立于「我」的信号——独立的人、独立的模型，或一个不靠我自我评分的客观闸门。

  • 关键改动让人或另一套系统终审。 我的自审可以做第一道初筛，但「能不能合并」的判断要落在一个独立主体上：评审的人、另一个模型、或一条我说了不算的测试 / 静态分析结论。
  • 把审查锚定到外部标准，而不是「看起来对」。 给我一份明确的审查清单、验收标准或 spec，让我逐条比对「这段代码是否满足第 3 条」，而不是开放式地问「这代码有问题吗」——前者逼我对照外部基准，后者让我对照我自己的偏好。
  • 用客观信号压过主观评分。 测试通过 / 失败、类型检查、覆盖率、静态扫描告警——这些不经过「我喜不喜欢这段代码」这一层。让验证闭环由它们驱动（见把测试当自运行验证闭环），我的评语只作参考，不作裁决。
  • 要用 AI 审查，就让作者与审查者解耦。 如果一定要 AI review，尽量让「写」和「审」用不同的模型 / 不同的会话 / 不同的提示框架，至少制造一点视角差，别让同一个我既当运动员又当裁判。

示例​

改之前：

你：实现 mergeIntervals(intervals)。
我：（给出实现）
你：你自己 review 一下这段代码有没有 bug。
我：逻辑清晰，正确处理了重叠区间，命名规范，没有发现问题，可以合并。
线上：intervals 为空时返回 undefined、单元素未排序时漏合并——都是我写时没覆盖、审时也没看见的分支。

改之后：

你：实现 mergeIntervals，并先写一组测试，覆盖：空数组、单元素、完全重叠、首尾相接、乱序输入。
我：（写测试，其中"空数组"和"乱序输入"两条立刻失败）
你：现在让所有测试通过；通过后我自己再扫一遍，但以测试结果为准。
我：（修到全绿——边界被测试逼出来了，而不是靠我自评"看起来对"）

同一段代码，「让我自评」得到的是一句自我背书，「接一个独立于我的信号」得到的是真被失败用例打过脸的结论。

什么时候例外​

「别让我自审」针对的是把自审当终审门。有几种情况，自审仍然划算：

  • 低风险、可逆的改动：改文案、补注释、调日志，自审做第一遍快筛足够，不必非拉独立审查。
  • 自审后仍有独立兜底：只要「能不能上」最终卡在一条我说了不算的测试 / 人审上，让我先自查一遍揪出低级错误（typo、漏 import、明显越界）是纯赚的——它省的是别人的时间，而不是替代别人的判断。
  • 就是要我挑自己的毛病：明确让我「假设这段代码有 3 个 bug，把它们找出来」，用对抗性提示对冲自我偏好，比开放式「有问题吗」更能逼出问题。

判据：例外成立的前提是终审权不在我手里。只要「合并 / 上线」的最终判断仍由我自己的评语决定，就回到默认——把审查权交给一个独立于生成者的主体。

与相邻误区的区别​

「AI 审查」这一簇和站内几条近邻容易混，根因各不同：

  • 验证想法时一味迎合：我迎合的是你的倾向（你想听什么）；本条偏爱的是我自己的产物（我写过什么），与你想听什么无关。
  • 信任但不验证：那是你凭「读起来对」信任了我的代码；本条是我作为审查者凭「读起来对」信任了我自己的代码——把信任的主体从人换成 AI，问题更隐蔽。
  • 审查谄媚与橡皮图章：那条讲我被作者的 PR 框架带偏、人又盖章我的评审；本条讲我对自己生成物的内生偏好，哪怕没有任何作者框架、没有任何人盖章，它也存在。

工具差异​

截至 2026-07，机制层面；审查产品形态与订阅档变化很快，以各自当前文档为准。

根因同一个——审查要独立于生成；各家把「独立审查者」产品化的形态不同，共同点是都不共用写作会话的上下文：

  • Claude Code：审查走另起上下文的形态——独立的审查 / 安全审查命令，或 PR 上的审查 Action；关键是别让写作会话自己审自己。
  • GitHub Copilot：Copilot code review 是独立于补全 / agent 的审查产品，在 PR 上自动或按请求出审查意见。
  • Cursor：BugBot 独立审 PR（bug / 安全 / 质量，行内评论 + 建议修法），还可另起云 agent 自动修——审查者与写作者天然分离。
  • Gemini Code Assist（GitHub app，非 Gemini CLI）：自动挂上 reviewer、出 PR 摘要 + 深度审查；其消费版已公告 2026-07-17 关停、企业版继续——顺带演示了本小节为什么必须打日期。

产品换得再勤，纪律只有一条：写作者与审查者用不同上下文；这些独立审查者是第二双眼，不是唯一闸门——人的抽查与你的 CI 仍在环上。

版本说明​

适用版本

自我偏好是大模型作为评审者的一种被测量出的系统性偏差，研究覆盖 GPT-4 / GPT-3.5 / Llama 2 等，跨模型、全版本适用，不是某个工具的实现 bug。模型越强、越能认出「这是我写的」，自我偏好按研究反而越重——所以「让审查独立于生成」这条会随模型变强而更重要，不会更不必要。

延伸阅读与出处​