AI 辅助编程实测：Bug 率增加 41%，安全缺陷增 2.74 倍

AI 辅助编程实测：Bug 率增加 41%，安全缺陷增 2.74 倍 | 前端进阶之旅

Full translation

完整中文译文

Vibe Coding 现状核查：Bug 增加 41%，缺陷扩大 2.74 倍

在编辑器里放一个模型，你确实能更快地交付代码。但同时你也在交付更多缺陷，而且这个差距比大多数团队预估的要大：一项研究指出，团队采用 AI 编码工具后，Bug 率上升了 41%；AI 辅助代码中出现安全缺陷的频率大约是人工代码的 2.74 倍。

这不是让你关掉这些工具的理由。现在进入生产环境的代码约有 95% 包含 AI 辅助内容，所以真正的问题早已不再是"你用不用 AI"，而是"如何在享受速度的同时阻止质量悄悄流失"。

以下是你需要了解的真实数据、背后的原因，以及在不回到慢车道的前提下守住质量的五个做法。

Vibe Coding 时刻：到底发生了什么

Vibe Coding 是一种习惯模式：描述你想要什么，接受模型输出的任何内容，用"能不能跑通"来判断结果对不对。提示、运行、再提示。不逐行阅读 Diff。

这种感觉难以置信地好。一个原本要花一下午的功能，二十分钟就落地了。Cursor、Copilot 和 Claude Code 同时变得足够好用，以至于写代码的摩擦力降到了review的摩擦力之下——而这个反转就是事情的全部。

因为当写代码变得便宜，而 Review 依然昂贵时，人们会写得更多、Review 更少。不是因为懒惰，是因为数学。一款工具一次生成 300 行代码，并不会同时产出 300 行的 Review 注意力量，而没有人给这个差额做过预算。

Uplevel 研究：采用 AI 后 Bug 率上升 41%

那个被反复引用的数字来自 Uplevel：采用 AI 编码工具的团队，Bug 率上升了 41%。其机制被定性为过度依赖——开发者接受建议，但没有在背后做足够的 Review。

CodeRabbit 的研究从另一个角度指向了相同的方向。AI 辅助的代码库，每个 Pull Request 的问题数量比纯人工代码多 1.7 倍。不是按行计，而是按 PR 计——而你的团队实际 Review 的单位就是 PR，所以额外负担准确地落在了做 Review 的人身上。

仔细琢磨第二个数字，因为它解释第一个数字。如果现在每个 PR 都背负着接近两倍的问题量，而你的 Review 流程没有改变，那你的 Review 流程现在捕获问题的比例就变小了。Bug 不是凭空出现的，它们是通过一个为不同容量设计的关卡走进来的。

这件事难以察觉的原因是，失败都很无聊。不是离谱的模型幻觉。而是吞掉异常的错误路径、一段看起来正确但放错位置（晚了一行）的空值检查、通过 Review 的代码因为它看起来像你会写的代码——而这正是这些模型被优化生成的东西。

安全漏洞：AI 辅助代码库中缺陷增加 2.74 倍

对企业代码仓库的静态分析发现，AI 辅助代码中安全漏洞的流行程度大约是人工编写代码的 2.74 倍。这个乘数值得你带给你的 Lead 看，因为安全缺陷的成本曲线是列表中其他指标无法比拟的。

为什么安全问题是特殊的？一个模型写的是围绕周围上下文的统计上典型的代码。互联网上公开代码中的典型代码包含大量教程级的捷径：字符串拼接进查询、宽松的 CORS、从字面量直接读取密钥、信任对象形状的验证（因为类型注解这么说了）。没有任何一部分看起来有问题，但全部在真实部署中是一把擦枪。

模型也不知道你的信任边界在哪里。它无法知道这个特定的处理器在没有认证的情况下是否可达，或者这个输入在两个帧之前是否已经跨过了网络。这些上下文活在你的脑子里和你的架构里，而这恰恰是决定一段代码是正常的还是一个漏洞的关键。

类型系统在这里也救不了你。类型安全的代码可以完全是类型安全的，但仍然授权给了错误的用户。

为什么开发者仍然信任 AI，尽管数据不支持（以及这种信任何时会破裂）

问一屋子工程师 AI 工具是否让他们更快，几乎每个人都会举手。问代码是否更好，手就放下了。两个答案都是真实的，它们并不矛盾。

信任得以维持是因为失败模式被延迟了。你在同一个会话中立刻感受到速度，而缺陷三周后在事件频道里才感受到，通常被归因于其他完全不相干的东西。在那个循环中没有任何东西把这两件事连接起来，所以本该校准你信任的反馈永远不会到达。

信任在一种情况下会破裂：第一次有人将一个生产事件追溯到团队中没有人能解释的一块代码。不是因为它复杂，而是因为没有人类真正阅读过它。那个时刻的冲击力和任何统计数据都不同，这是大多数团队最终添加关卡的那个时刻。

你不需要等它发生。

在不扼杀速度的前提下保持质量的五个做法

这些做法没有一个要求你少用 AI。它们把成本从你未来的事件频道移到你现在的流水线里，在那里它更便宜。

像对待陌生人提交的 Diff 一样阅读它。不是 Prompt，不是模型给你的解释，是 Diff。如果一个你从未见过的承包商提交了这个，你会把它打回，现在也一样。这条规则的最强版本是个人化的：永远不合并一段你在事故复盘中无法为之辩护的代码。
让静态分析成为阻断性的，而不是建议性的。一个发布评论的 SAST 工具在一周内就会被忽略。一个让构建失败的 SAST 工具会被修复。鉴于 2.74 倍的安全乘数，这是列表中单次杠杆效应最高的改变。

# .github/workflows/security.yml
name: security
on: pull_request

jobs:
  sast:
    runs-on: ubuntu-latest
    container:
      image: semgrep/semgrep
    steps:
      - uses: actions/checkout@v4
      # --error makes findings exit nonzero, which fails the check
      - run: semgrep ci --config auto --error

限制每个 Pull Request 的爆炸半径。Review 质量在超过几百行变更后会断崖式下降，而 AI 使得大 Diff 变得轻而易举地产生。在自己面前设置一个真实的限制：

#!/usr/bin/env bash
# .git/hooks/pre-push  (chmod +x this file)
# Refuse to push a branch that has grown past a reviewable size.
set -euo pipefail

BASE="${BASE_BRANCH:-origin/main}"
LIMIT="${DIFF_LIMIT:-400}"

changed=$(git diff --numstat "$BASE"...HEAD \
  | awk '{ added += $1; removed += $2 } END { print added + removed + 0 }')

if [ "$changed" -gt "$LIMIT" ]; then
  echo "Branch changes ${changed} lines, limit is ${LIMIT}."
  echo "Split it, or push with DIFF_LIMIT=$((changed + 1)) if you have a reason."
  exit 1
fi

测试模型看不到的边界。认证、授权、输入验证、错误路径、资源清理。模型把快乐路径写得非常漂亮，因为快乐路径是大多数公开代码所展示的。那些测试你自己写，或者最低限度你自己写测试名称，这样契约的形状来自你。
每个 Pull Request 追踪一个质量信号。Review 中发现的问题、逃逸的缺陷、你的团队已经在计数的任何指标。你无法管理一个你从未测量的 41% 漂移，而这种失败模式的全部危险在于它在月复一月地隐形。一个单一数字，持续追踪八周，比任何别人发布的基准都更能说明问题。

五个做法背后的共同模式：模型生成，而一个不会疲倦的关卡验证。人类注意力是现在的稀缺资源，所以把它花在机器无法检查的部分。

现在立刻验证的三件事

对你的 main 分支运行 semgrep ci --config auto 并计算发现数量。无论你是否知道，这就是你的当前基线。

检查你的 SAST 任务是设置为失败构建还是仅仅评论。如果是评论，改成失败。

拉取最近十个合并的 Pull Request，用 git diff --numstat 检查 Diff 大小。如果中位数超过 400 行，你的 Review 流程已经在超出其设计容量运行了。

AI 生成的代码是否引入更多 Bug？现有数据说是。一项研究测量到团队采用 AI 编码工具后 Bug 率上升 41%，另一项独立研究发现 AI 辅助代码库中每个 Pull Request 的问题数量是 1.7 倍。两者识别出的原因都是 Review 深度降低，而非模型产生了无稽之谈。

什么是 Vibe Coding？向模型描述你想要什么，接受生成的代码，用运行而非阅读来验证它的正确性。它在原型和一次性脚本上效果很好。一旦代码有了用户，它就严重降级了，因为"它能运行"和"它是正确的"不再是同一个断言。

使用 AI 工具时如何保持代码质量？将验证移入自动化，人类注意力集中在判断上。阻断式静态分析、小而可Review的 Diff、你为模型看不到的边界写的测试，以及一个被追踪的质量指标，将覆盖大部分差距。工具不是问题所在。一套没有改变的 Review 流程以数倍于其设计容量的规模运行着，才是。

如果你想更深入地了解这些关卡如何融入你实际在生产环境中运行的 AI 系统，我在我的网站上更详细地介绍了这一点。

如果你想在自己的代码库端到端地连接这些，那正是我承接的工作类型。

如果你有不同的设置，欢迎留言。我很好奇大家实际在跑哪些关卡，哪些在Deadline压力下活了下来。