永无止境的AI代码审查：为何一次审查远远不够

一句话看懂：来自 dev.to 的一篇深度实验指出，使用大语言模型（LLM）进行代码审查时，单次运行远不够可靠——同一项目连续审查 6 次会得到 6 份不同的漏洞报告。这并非提示词写错，而是 LLM 的非确定性和“锚定效应”导致的内在结构缺陷。研究数据表明，单次审查可能漏掉超过一半的关健漏洞。

事件核心：发生了什么

作者运行了大语言模型对同一真实项目进行多次代码审查。第一次，模型将锚定在“架构”上，发现了 WebSocket Hub 伸缩性问题；第二次转向“性能”，揪出 Redis N+1 查询与缺失的 TTL；第三次才注意到“安全”，发现了认证令牌日志泄漏和敏感文件提交。6 次审查之后，模型总计发现了大量不同问题，但任何一个单次运行都无法覆盖全部风险。2025 年的三项研究呼应了这一观察：Semgrep 的研究发现，对相同代码与提示的 3 次运行可能分别产出 3、6 与 11 条不同结果；SWR-Bench 的研究指出，将审查运行 10 次并合并结果后，召回率可提升 118%；Ericsson 的工程师则验证，一次性大规模提示策略会在实践中失效。在作者的对比测试中，6 次传统（整包）审查的综合结果依然漏掉了两个关健跨文件逻辑漏洞，而这些洞在切换到“结构化分模块审查”后，第一轮就被捕获。

为什么重要

这个现象揭示了大语言模型在自动化代码审查场景中的核心局限：其非确定性输出天然无法替代确定性工具（如 linter 与静态分析）的完备性检查。对开发团队而言，这直接冲击了“用大模型跑一次审查就等于安全通过”的信任假设。对企业级应用而言，单次审查可能将关健的架构缺陷、安全漏洞或数据泄露风险隐藏在看似“已审查”的假相中，带来严重合规与部署隐患。同时，这一发现促使业界重新思考 AI 代码审查工具的产品设计——从“一次全面接析”转向“多次、小步、模板化、合并结果”的结构化策略，这可能是提升代码审查准确率的可行路径。

对用户/开发者/创作者的影响

对于使用大语言模型进行代码审查的开发者与 Tech Lead：

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。

1. 不要信任单次审查结果。如果只跑一次就合并代码，可能遗漏超过一半的真实缺陷。建议至少运行 3-5 次主题不同的审查（如安全、性能、逻辑、设计），并手动合并输出。2. 优先采用“分模块+专门提示词”的方法，而不是一次性喂入整个项目。这能减少 LLM 的上下文压缩问题，显著提升每个轮次的精确度与覆盖率。3. 对于生产环境的变更，任何由大模型标记为“高优先级”的问题都应被当作真实威胁处理，但“低优先级”警告也值得回归工程确认，以避免被模型“忽视”。

值得关注的后续

1. 代码审查工具产品（如 GitHub Copilot、GitLab Code Review、开源项目）是否会在产品层面支持自动多轮、合并结果或模板化审查？2. 大模型本身是否会出现更稳定的“确定性审查”模式，或开发者社区的对抗策略是否会催生更可靠的提示词模式？3. 2025 年的 SWR-Bench 和 Semgrep 研究是否为更大规模 DevOps 工具链集成（如 CI/CD 管道中的多轮 LLM 审查）提供了数据支撑，并将推动相关合规标准更新。

来源：dev.to

永无止境的AI代码审查：为何一次审查远远不够