代码生成基准测试跑分再高，放到真实代码评审场景可能直接翻车。这是AI代码工具领域长期被忽视的盲区——直到有人把54个真实Pull Request摆到台面上。
一个反直觉的发现：会写代码的模型，未必会审代码。
代码生成与代码评审是两种认知任务。前者像闭卷考试，模型凭记忆和模式匹配输出答案；后者像侦探工作，需要在他人思路的残骸里找出逻辑裂缝、安全暗门和性能陷阱。现有基准测试HumanEval、MBPP、SWE-bench全部聚焦前者，评审能力的评估长期处于真空状态。
测试团队从GitHub开源仓库筛选了54个已合并PR，覆盖Python、JavaScript/TypeScript、Go、Rust、Java五种语言。这些不是LeetCode式玩具题，而是真实开发者提交的真实变更，附带完整的人类评审历史作为参照系。
PR规模刻意拉开梯度：小到单行修改变更，大到跨文件重构。测试维度拆解为四类——功能性bug、安全隐患、性能瓶颈、代码可维护性。最终人工复核确认247个真实问题：89个bug、43个安全问题、52个性能问题、63个代码质量问题。
评审能力的五个测量维度
模型输入统一标准化：完整diff、PR标题描述、相关文件上下文（最多8000 token）。输出则被严格打分：
召回率（Recall）：在247个确认问题中，模型找出了多少。
精确率（Precision）：模型指出的问题中，有多少是真实存在的。
误报率：模型报的"问题"实际没问题，这类噪音占比多少。
安全分析深度：能否识别设计层面的安全影响，而非只抓表面漏洞。
可执行性：评审意见是否具体、可操作，还是泛泛而谈"这里可以优化"。
双人工标注+91%一致性校验，争议项讨论裁决。测试方声明独立身份：无厂商 affiliation，API自费购买，标准定价。
参战模型六款，代表2026年初第一梯队：Claude Sonnet 4.5、GPT-4o、Gemini 2.0 Pro、o3-mini、DeepSeek-V3、Llama 3.3 70B。全部使用2026年2月最新可用版本。
Sonnet 4.5的评审表现拆解
Anthropic在这代模型中强化了"批判性阅读"能力。测试数据显示，Sonnet 4.5在跨文件依赖分析上显著优于前代——当PR的bug根因不在变更行本身、而在被变更代码的调用方时，模型能追踪到因果链。
一个典型case：某Python PR修改了工具函数的错误处理逻辑，表面看是防御性编程。Sonnet 4.5指出，调用该函数的 upstream 代码依赖原有抛异常行为做分支判断，新逻辑会导致静默失败。这种"副作用盲区"被人类评审者遗漏，却在合并后引发线上故障。
安全评审维度，模型对注入类漏洞的识别率提升，但对业务逻辑缺陷（如权限检查顺序错误）仍显吃力。性能分析方面，Sonnet 4.5能识别明显的复杂度退化，但对数据库查询模式、缓存失效策略等领域特定问题，输出趋于模板化。
误报控制是另一块试金石。部分模型为追求召回率，倾向于"宁可错杀"——把风格偏好、过度工程化猜测都报成问题。Sonnet 4.5的误报率在六款模型中处于中游，但"可执行性"评分领先：它的评审意见更少出现"考虑重构"这类正确的废话，更多给出具体行号、具体修改建议。
基准测试的诚实局限
测试方公开了方法论的全部粗糙边缘。247个确认问题依赖人工复核，存在主观判断空间；五语言覆盖不代表全栈场景；已合并PR的筛选机制可能引入"幸存者偏差"——未被合并的PR或许包含更隐蔽的问题类型。
更根本的约束：代码评审是社交过程，不是单人任务。人类评审者的价值不仅在于找bug，还在于知识传递、设计共识建立、团队规范强化。这些维度当前无法被量化捕获。
测试团队将完整数据集和评分细则开源，接受社区审计。他们的定位很明确：不做模型排名榜单，而是提供工程团队的选型参考——如果你的团队代码评审积压严重，哪款模型的辅助最值得接入？如果你的核心风险是安全漏洞，应该优先看哪个指标？
Sonnet 4.5的测试窗口恰逢其发布初期。后续模型迭代、提示工程优化、领域微调都可能改写具体数字。但这项测试确立了一个有价值的锚点：代码评审能力可以被系统性测量，且当前顶尖模型与人类专家之间仍有显著差距——特别是在需要跨文件上下文、领域知识、设计权衡的复杂场景。
当AI辅助评审从"玩具演示"进入"生产工具"阶段，这类压力测试会变得比跑分排行榜更关键。你的团队愿意把多少代码评审权重交给模型？当模型给出的修改建议与资深工程师冲突时，决策流程如何设计？
热门跟贴