夜雨聆风上周五下午，我正准备把一段 Claude Code 生成的数据库查询逻辑提交上去。代码看着挺干净，逻辑也说得通，我都准备写 commit message 了。但不知道哪根弦拨了一下，我还是多看了一眼，发现一个边界条件被吃掉了：如果传入空列表，整条查询会静默返回全量数据。
没有报错，没有异常，就是结果不对。
这种"看着对、实际错"的代码，过去半年我遇到太多次了。更让我后怕的是，我差点就没看那一眼。
太长不看版
1. 2026 年初，90% 的开发者日常使用 AI 编程工具，但只有 29% 的人信任 AI 输出的代码 2. 信任度从 2024 年的 40% 降到了 29%，用得越多反而越不信，踩过的坑在积累 3. AI 代码最危险的不是明显的报错，而是"看着对、跑着也对、但逻辑有坑" 4. 66% 的开发者说最大的痛点是 AI 代码"差一点点就对了"，修起来比自己写还累 5. AI 辅助的 PR 引入的 bug 数量比纯人写的高出 1.7 倍，安全漏洞多 15%-18% 6. 资深工程师的角色正在从"写代码"变成"看代码"，审查 AI 输出成了日常 7. 我的经验：把 AI 当一个手快但不稳定的新人，每一行产出都要过目 8. 真正的效率提升不在生成速度，在于你能多快地验证结果
数据说了什么：90% 在用，29% 在信
翻 JetBrains 的 AI Pulse 调查，一万多人的样本，里面有个数字很扎眼：90% 的开发者说自己日常至少在用一种 AI 工具。我又去看了 Stack Overflow 和 Google 的 DORA 报告，数字都差不多，DORA 原文写的是 "adoption has reached 90%, a 14-percentage-point increase year over year"。
但让我真正停下来的是后面那个数字。
同一批调查里，说自己信任 AI 输出代码的开发者，只有 29%。2024 年这个数字还有 40%。用的人越来越多，信的人反而越来越少了。
听着矛盾，其实不是。恰恰是因为用得够多，大家才摸清了 AI 代码的脾气。蜜月期过了。现在大部分人的态度是：能帮忙，但不能闭着眼睛收。
"差一点就对了"，比错更可怕
如果 AI 给你一段语法跑不通的代码，反而简单，编译器替你拦着。真正麻烦的是另一种：语法没问题，测试也能过，就是藏着一个你一时半会儿发现不了的逻辑缺陷。
我管这叫"看着对"陷阱。
有一次我让 AI 写一个文件去重逻辑，按 MD5 比较文件内容。代码跑得挺好，但我后来发现它比较完之后，直接把"重复"的那一份删了。没有确认步骤，没有回收站。两个文件名字不同但内容一样，有一个就这么没了。
这段代码在 code review 里很容易放行。结构清晰，命名规范，还有注释。它不像新人写的那种一眼就知道有问题的代码，更像一个有经验但偶尔犯糊涂的同事交出来的东西。
Sonar 的 State of Code 报告里有句话我印象很深："almost right, but not quite"，66% 的开发者说这就是他们跟 AI 代码打交道时最大的痛点。修补那差的一点点，成本有时候比从头写还高。因为你得先理解 AI 的思路，在它的框架里改，而不是按自己的习惯来。
AI 代码进了生产环境，bug 确实更多
这不只是我的个人感觉。我看到一篇分析，里面引了好几份研究数据，有一个数字让我有点吃惊：AI 辅助生成的 Pull Request 引入的 bug 数量，大约是纯人工代码的 1.7 倍。安全漏洞那边更夸张，高出 15%-18%，而且集中在 SQL 注入、密码处理不当、跨站脚本这几类老问题上。不是什么新花样，就是 AI 不知道该防的地方。
我自己的体感也印证了这个数据。AI 处理"局部正确性"很强，但"全局一致性"很弱。它能写出一个漂亮的函数，但不一定理解这个函数在整个系统里的位置。它不知道你三个月前为了避免竞态条件，特意把某个操作改成了同步的。更不知道你们团队有个不成文的规矩：涉及金额的计算一律用 BigDecimal。
这种上下文盲区，才是 AI 代码出问题的根子。
Sonar 那份报告里还造了一个词，我觉得特别准确：Verification Tax，验证税。意思是 AI 帮你省下的写代码时间，有相当一部分被花在了审查和修复上。经验不够的开发者，这个税率可能超过 100%，也就是说用 AI 反而比自己写更慢。
资深工程师的新活儿：从写代码到看代码
半年前我觉得 AI 编程会让资深工程师更轻松，把脏活累活丢给 AI，自己专注架构就行。
实际情况反过来了。
审查负担明显加重。以前 code review 看的是同事的代码，风格和思路大体了解。现在要看 AI 生成的代码，每一段都得从零建立信任。我在一份开发者调查里看到，超过 38% 的人觉得审查 AI 的代码比审查同事的更费劲。这跟我的感受完全一样。
而且 AI 产出速度太快了。以前一天几个 PR，现在有些团队一天十几个，大部分有 AI 参与。审查的工作量不是线性涨的，是翻着倍涨的。
我自己摸索出了一套分级审查的习惯：UI 文案、简单配置这类低风险的，扫一眼结构就行。业务逻辑、数据转换这类，逐行看，盯边界条件和错误处理。涉及金钱、权限、数据删除的，不管 AI 写得多好看，我都会重写关键部分。
不是跟 AI 过不去，是对生产环境有敬畏心。
DORA 报告里一个有意思的发现
翻 Google 的 DORA 报告，有一段话我反复读了两遍。大意是说：AI is an amplifier, not a fixer。AI 是放大器，不是修复器。
团队本来就有完善的测试、清晰的架构、高效的 CI/CD 流程，AI 会让你更快。但如果本来就缺代码审查、测试覆盖率低、部署流程乱，AI 只会帮你更快地生产出更多没人审查的代码。问题还是那些问题，只是速度快了。
我自己的项目里效率提升很明显，因为验证流程比较完善：写完跑测试、审查、分阶段部署。但听过不少团队吐槽，说引入 AI 之后交付确实快了，线上故障率也跟着涨了。
根子不在 AI，在于有没有配套的刹车系统。
踩坑之后留下的几条原则
用了半年 AI 编程，我逐渐形成了一些跟 AI 代码相处的习惯。没什么方法论，就是踩够了坑之后的本能反应。
把 AI 当新人看，别当专家看。AI 代码的特征很像一个聪明但经验不够的新人：基本功扎实，代码风格整洁，但不太理解上下文和业务约束。用这个心态审查，不容易过度信任，也不会因为偶尔出错就否定它的价值。
别追求一次生成完美代码。更值得投入的是怎么更快地验证 AI 的输出。自动化测试、类型检查、lint 规则、pre-commit hook，这些"刹车系统"的投入回报远高于在 prompt 上反复调试。
越是看着没问题的代码，越要多看一眼。AI 不会写出新手那种一眼就有问题的代码。所以反直觉地，越是看着舒服的 AI 代码，越需要你刻意停下来想：空值处理了吗？并发考虑了吗？业务规则遵守了吗？
写在最后
回到开头那个差点提交上去的数据库查询。
如果我没多看那一眼，测试环境大概率也不会出问题，因为测试数据里没有空列表的场景。它会安静地上线，安静地运行，直到某天一个用户触发了那个边界条件，返回了整张表的数据。
我现在对 AI 编程工具的态度大概是"依赖但验证"。离不开它的效率，但不会放弃自己最终拍板的权力。说到底，问题不是信不信 AI，是你愿不愿意在验证上花功夫。
