AI 写代码不可怕，可怕的是工程师把审查权交出去

最近很多工程师都有同一个隐约焦虑：天天让 AI 补代码、写函数、起测试，我是不是在退化？

这篇面向工程师的文章给了一个更准确的切口。AI 编程工具真正危险的地方，不是让人变懒，而是让人把判断权交出去。

这两件事差别很大。

用 AI，不等于放弃工程能力。真正的分水岭，是你把生成结果当“答案”，还是当“待审查的初稿”。

争议很短：AI 输出能用，但不能直接信

文章里最有用的比喻是：AI 输出像一个聪明但过度自信的 junior engineer。

这句话很工程。

一个聪明的初级工程师可以写出不错的第一版，也可能漏掉权限边界、异常路径、输入假设和安全面。你不会因为他写得快，就取消 code review。

对 AI 也一样。

未经审查的认证中间件，看起来只是少几行判断。默认成立的输入格式，看起来只是少补几个测试。没覆盖的异常状态，看起来只是暂时没人触发。

短期都很安静。

进了生产环境，它们就会变成延迟偿还的技术债。凌晨两点暴露的问题，通常白天已经埋好了。

《论语》说，“学而不思则罔”。放到今天的工程现场，就是：生成而不审，则罔。AI 给你材料，但不会替你承担上线后的后果。

真正有效的用法，是对抗式使用 AI

我不太买账“少用 AI 才能保住基本功”这种说法。它太像上一代人面对搜索引擎、IDE、Stack Overflow 时的焦虑。

历史不完全一样，但结构相似：新工具降低了获取答案的成本，也放大了偷懒流程的代价。

编译器没有消灭程序员，搜索没有消灭工程判断。它们淘汰的是一部分记忆负担，同时暴露了另一种能力差距：谁能判断答案在当前系统里是否成立。

AI 编程工具也是这条线上的新一轮放大器。

更好的用法不是少问，而是逼它多暴露问题：

• 让 AI 给出初版方案或代码；
• 把输出贴回去，让它反驳自己的方案；
• 追问没覆盖的边界条件；
• 检查它默认了哪些生产环境假设；
• 换成安全审计视角再看一遍；
• 根据这些质疑修正代码、测试和设计。

关键不在这几句提示词。

关键在循环：生成、反驳、找边界、查假设、再修正。判断力就长在这个循环里。

这里有一个现实约束也要说清：AI 不知道你们线上系统的全部上下文。它可能不知道历史包袱、灰度策略、鉴权链路、日志规范，也不知道某个看似奇怪的判断其实是在保护老用户路径。

所以它越自信，工程师越不能省 review。

工具给的是速度，不是责任转移凭证。

受影响最大的是两类人：写代码的人，管质量的人

对正在用 AI 编程工具的软件工程师来说，动作很具体：别把 AI 输出直接并进分支。至少补三类问题。

输入假设是什么？失败路径在哪里？安全边界有没有被默认跳过？

如果这三问答不上来，代码还没准备好上线。

对技术负责人来说，问题更硬一点：不能只采购工具、鼓励提效，然后把审查流程留在原地。

团队需要调整的是工程制度，而不是只培训提示词。

接下来最该观察的变量，不是哪个工具又多会写代码。

我更在意两件事。

一是团队有没有把 AI 生成代码纳入正式 review 规则。比如提交说明里是否标注关键假设，测试是否覆盖异常路径，安全敏感代码是否需要额外审查。

二是工程师有没有形成反向审问的习惯。会不会让 AI 找漏洞、拆方案、列边界，而不是只让它继续补全下一段。

这决定了 AI 到底是答案机器，还是判断力训练器。

现在很多讨论喜欢滑向两个极端。一边说 AI 会毁掉工程师基本功，一边说 AI 会让人人十倍效率。都太省事。

更接近现实的判断是：AI 会放大工程师原本的工作方式。

习惯追问的人，会拿它当陪练。习惯复制粘贴的人，会拿它当挡箭牌。

未来稀缺的不是提示词模板，而是能在任何生成物面前问出硬问题的人：这里的权限边界是什么？这个异常状态怎么处理？测试覆盖的是常态，还是也覆盖失败？如果交给资深工程师做安全审计，第一刀会砍在哪里？

这不是反 AI。

恰恰相反，这是更认真地用 AI。

把 AI 当答案机器，工程师会越来越像审核缺席的流水线工人。把 AI 当判断力训练器，它会逼你更快暴露盲区。

我的判断很简单：AI 不会自动削弱工程能力，但会无情奖励偷懒的流程。工具越强，审查越不能弱。否则速度只是幻觉，债务才是真的。