AI 生成代码会被低看吗？447 名工程师的评审实验给了一个意外答案

AI 生成代码会被低看吗？447 名工程师的评审实验给了一个意外答案

Microsoft Research 9 月 1 日公布一项代码评审实验：447 名软件工程师分别审阅相同的四段代码，提交信息中加入 AI 使用披露，同时改变作者资历标签。研究所在组织已经普遍接受 AI 编程工具。结果没有检测到 AI 披露对代码有效性或作者能力评价的负面影响，资深或初级标签却显著改变了两项判断。

这个结论与“评审者看到 AI 生成就会扣分”的直觉不同，也不能解释成 AI 代码已获得普遍信任。实验测量的是一个 AI 使用常态化组织中的主观评价，并非代码缺陷率；参与者看到的是研究设计提供的标签，不是由检测器猜测代码来源。样本环境、公司文化和四段代码的范围都会影响外推。

披露没有显著惩罚，组织背景可能是关键

过去一些研究发现，即使内容完全相同，只要标明使用 AI，评审者也会降低对作者能力的评价，边缘群体受到的影响更明显。新研究把实验放进一个 AI 已被组织接受的环境，得到不同结果。一个合理解释是，当 Codex、Claude Code 或 Copilot 已成为日常工具，使用 AI 不再被视为异常信号，评审注意力更容易回到变更本身。

不过，“没有检测到偏差”不等于证明偏差为零。统计结果受样本量、效应大小和实验材料限制，也没有覆盖所有语言、仓库风险和团队。安全补丁、核心交易逻辑与普通界面代码的心理门槛可能不同。团队若想验证自身情况，可以在不影响上线的历史 PR 上做匿名对照，让不同评审者比较相同 diff，再观察缺陷发现、评审时间和修改建议，而非只问大家是否接受 AI。

研究也不支持隐瞒 AI 使用或设计文本去躲避检测。检测器判断的是风格或概率，代码评审关心的是可执行行为、测试证据和责任归属。把来源检测当质量门槛，可能同时放过危险的人写代码并误伤正常变更。更稳妥的策略，是披露使用了哪些工具、保留关键提示和验证过程，同时让所有代码通过同一套测试与安全检查。

初级标签仍在影响对相同代码的判断

实验更清楚地检测到资历标签效应：同样的代码，因为作者被标成初级或资深，评审者对代码有效性和作者能力的看法会变化。这个结果提醒团队，AI 工具普及并不会自动消除传统层级偏见。自动生成内容也可能强化它：资深开发者的改动被快速相信，初级开发者则被要求提供更多证明，即使两者的 diff 相同。

代码评审界面可以减少无关身份线索，先展示测试、风险范围和差异，再显示作者信息；模板则要求所有人填写复现步骤、边界条件和回滚方式。对 AI 辅助变更，附加模型名称和对话长度帮助有限，更有价值的是指出哪些文件由工具修改、哪些测试由人补充、哪里仍存在不确定性。责任人必须能解释并维护最终代码。

如果团队通过 [统一模型网关](/) 使用多种编程模型，还可以把模型版本、调用任务和结果链接到 PR，但不要用“某模型生成”代替审查。相同需求可以抽样交给另一个模型做静态分析或测试建议，再由人判断冲突；这种交叉复核用于发现盲点，不负责替作者背书。

评审制度应围绕证据，而不是写作者猜测

企业引入 AI 编程后，最有用的规则通常很朴素：高风险目录需要指定 reviewer，生成测试不能作为唯一验收，依赖和许可证必须扫描，生产事故仍由明确的人员和团队负责。是否披露 AI 可以纳入流程，但不应成为降低技术标准或增加羞辱性审问的理由。

这项研究更像一面镜子。AI 标签的影响会随组织规范改变，资历标签的影响却可能在工具升级后继续存在。管理者需要跟踪不同资历开发者的评审等待时间、被要求返工的原因和缺陷发现率，才能看见制度是否公平。对于准备大规模采购 Codex、Claude 等 AI 编程服务的团队，评审质量与成长机会应和生成速度一起进入验收指标。

来源：[Microsoft Research：AI 披露与代码评审偏差实验](https://www.microsoft.com/en-us/research/publication/after-organizational-ai-acceptance-ai-bias-fades-but-a-junior-penalty-persists-in-code-review/)