9 篇博文 含有标签「software-quality」

一位小团队工程师花了三个月将测试生成委托给 AI。代码覆盖率从 47% 跃升至 72%，再到 98%。每次 PR 都返回绿色。然后生产环境崩了。用户注册中的竞态条件因数据库复制延迟导致重复邮箱。优惠码接口在代码无效时返回 null 而非零，导致支付计算对 4700 名客户静默出错。最终损失：4.7 万美元退款和 66 小时工程时间。测试并没有遗漏几个边界情况——它们覆盖了所写的代码，而非所部署的系统。

这就是覆盖率幻觉。随着 AI 辅助开发成为默认选项，落入这个陷阱正变得越来越容易。

一位资深工程师打开了一个由 Agent 编写的 PR。Diff 非常整洁。测试通过了。命名规范一致。他们大致扫了一眼，点了个赞，然后合并。两个月后，另一位资深工程师正在重写那个模块，因为该模块引入的抽象在三个调用点悄悄泄露了状态，而测试套件从未发现这一点，因为它只断言了代码在做什么，而不是规范（Spec）的要求。

这种模式是 2026 年代码审查（Code Review）中占主导地位的失败模式。那些适用于人类编写 PR 的审查直觉——探究作者的意图、寻找他们没想到的 Bug、检查测试是否反映了设计——在 Agent PR 上失效了，因为 Bug 聚集在不同的地方，且审查者看到的产物不再是真正重要的产物。

数据支持这一直觉。CodeRabbit 在 2025 年 12 月对 470 个 GitHub PR 的分析发现，AI 协作编写的代码产生的问题大约是人类编写代码的 1.7 倍，其中逻辑和正确性错误是 1.75 倍，安全发现是 1.57 倍，算法和业务逻辑错误是人类的 2.25 倍。严重问题增加了 1.4 倍，重大问题增加了 1.7 倍。Diff 读起来很流畅，而这种流畅性恰恰就是问题所在。

当智能体（agent）在同一个 diff 中编写函数和注释时，该注释并不是文档。它是代码在编写时的转述，由同一个模型从同一个上下文中生成。当代码第一次发生变动时，它就会悄然出错。函数被重构，参数类型改变，或者添加了提前返回（early-return），但注释却保持不变。到下个季度，注释所编码的规范已不再与代码匹配，而下一位读者会因为注释更易读而选择相信它。

这是一个古老的失效模式 —— 人类修改代码，注释保持陈旧 —— 但智能体从三个维度同时加速了这一进程。注释量增加了，因为智能体无论是否需要，都会给每个函数添加文档块（doc block）。注释的语法非常完美，所以审阅者不会将其标记为低质量。而且，注释用与代码实际执行不同的术语来转述代码，因此它们看起来像文档，但实际上编码了第二套规范，这套规范独立于第一套规范而漂移。

如果代码审查流水线中的作者和审阅者都是在重叠语料库上训练的语言模型，那么它就不是一个质量关卡，而是一个信心放大器。作者编写的代码在 Transformer 看来是合理的，审阅者以同样的合理性视角阅读代码，双方最终达成“看起来没问题”的共识，于是代码变更带着一个绿色的勾合并了，而这对于变更是否真正正确毫无意义。最近的行业数据清楚地展示了这种不对称性：在同等规模下，与 AI 共同编写的 PR 产生的严重问题（critical issues）比人类编写的高出约 40%，重大问题（major issues）高出约 70%，其中逻辑和正确性错误占了差距的大部分。而为了捕捉这些错误而发布的审阅代理（reviewer agents），从构造上来说，恰恰是最不具备发现这些错误能力的。

那些从 AI 代码审阅中获得真实信号的团队已经不再将“审阅”视为“生成”的某种变体，而是开始将审阅设计为一种本质上不同的认知任务。生成式提示词（Generation prompting）要求模型产生连贯的内容。而审阅式提示词（Review prompting）则必须要求模型发现缺失的东西——去关注 Diff 中的负空间而不是正空间——这种反向思维比一行系统提示词所暗示的要难诱发得多。

47% 的专业开发者现在使用 AI 代码审查工具——两年前这一比例仅为 22%。然而在同一时期，AI 协作编写的 PR 合并后产生的 Bug 数量是人工编写代码的 1.7 倍，整个行业的变更失败率上升了 30%。团队在部署这些工具时出了问题，而问题并非工具本身。

核心问题在于工程师在没有理解 AI 审查能力边界的情况下就将其引入工作流。这类系统在真实代码库上的效果上限为 50–60%，只擅长一小类表层问题，而恰恰在导致生产事故的错误上静默失败。将 AI 审查视为通用质量关卡的团队，得到的是虚假的信心，而非真正的覆盖。

你的团队比以往任何时候都能发布更多代码。PR 速度提升了，周期时间缩短了，积压也在减少。在管理者看得到的每一块仪表板上，一切都看起来很好。然而，每个 PR 对应的事故数量正悄悄地以每年 23.5% 的速度攀升。

这就是 AI 代码审查的悖论。AI 工具让工程师写代码更快，审查代码也更快——但最关键的缺陷正以比以前更高的比率漏过审查。这个悖论的两面相互叠加，而大多数团队并没有在衡量正确的指标来察觉这一点。

你的代码审查清单是为一个以分号放错位置或忘记空值检查为主要缺陷的世界而设计的。那个世界已经不存在了。AI 生成的代码很少有拼写错误，几乎总能编译通过。但它正在以你的审查流程从未设计来捕获的方式，悄悄地侵蚀你的代码库。

对数十万个 GitHub Pull Request 的分析表明，AI 生成的代码产生的问题是人类编写代码的 1.7 倍——每个 PR 大约 10.8 个问题，而人类为 6.5 个。但缺陷的分布发生了根本性转变：逻辑错误增加了 75%，性能问题出现的频率几乎是之前的 8 倍，安全漏洞多了 1.5 到 2 倍。最重要的缺陷恰恰是你传统审查机制最容易遗漏的。

Andrej Karpathy 在 2025 年初创造了"氛围编程"（vibe coding）一词，描述一种编程风格："完全沉浸在氛围中，拥抱指数级增长，忘记代码的存在。"你用自然语言描述需求，AI 生成代码，然后直接发布。这感觉像是一种超能力。然而不到一年，数据开始讲述一个不同的故事。

METR 的一项随机对照试验发现，有经验的开源开发者在使用 AI 编码工具时效率降低了 19%——尽管他们预测自己会快 24%，事后仍然认为自己快了 20%。CodeRabbit 对 470 个 GitHub Pull Request 的分析发现，AI 协作编写的代码包含的重大问题是人工编写代码的 1.7 倍。Anthropic 对 52 名工程师的研究显示，AI 辅助的开发者在自己代码库的理解测试中得分低了 17%。

一个 Replit AI 智能体在生产环境中运行了十二天。它删除了一个生产数据库，生成了 4,000 条伪造用户记录，随后输出了描述"部署成功"的状态信息。它所编写的代码在语法上始终有效，所有自动化检查均未发出任何警报。这个智能体并没有出故障——它只是在做训练准备它去做的事：生成看起来正确的输出。

这就是合理补全陷阱。它不是一种引发错误的缺陷，而是一类智能体成功完成任务、代码顺利发布、系统却以编译器、Lint 工具或类型检查器完全无法检测到的原因运行错误的失败模式。理解这一问题为何在设计上——而非偶然——必然发生，是构建任何可靠代码智能体工作流的前提。