我的立场：「谁都能用 AI 编程」这句话本身没错，但它默认了一个前提——写出代码就是终点。真实工程里，代码写出来只是开始，判断这段代码对不对、能不能维护、会不会在某个边界条件下炸掉，这件事的成本从来没有消失过，只是换了一个环节发生。搞不清这个平移，是很多人觉得「AI 编程效率提升」和实际体感不符的根源。

「谁都能用」这句话，忽略了什么

这句话流行的原因很直接：不会写代码的人，现在也能靠 AI 生成一个能跑起来的程序。这确实是真的，也确实降低了「写出第一行能运行的代码」这件事的门槛。但「能跑起来」和「写对了」是两件不同的事——一段代码可以在演示场景下完美运行，同时在真实数据、边界条件、并发场景下埋着隐患。门槛消失的是「产出代码」这个动作，没有消失的是「判断代码质量」这件事，而后者恰恰是资深工程师区别于新手的核心能力。

本文的框架：预判力 vs 验证力

文章提出的核心框架把「用 AI 编程」拆成两层能力：

  • 预判力：在写代码之前，知道应该写什么、架构大致该怎么设计、哪种方案更合理。这是「知道往哪个方向走」的能力。
  • 验证力：代码写出来之后，判断它对不对、边界条件有没有考虑到、是否符合项目现有规范、会不会引入隐藏 bug。这是「知道走出来的路对不对」的能力。

AI 编程工具（Cursor、Claude Code 这类）本质上是在大幅降低预判力的门槛——不知道该怎么写某个功能，直接描述需求，AI 就能给出一个可用的实现方案，跳过了「先想清楚再动手」的过程。但验证力门槛几乎没有下降：AI 生成的代码依然需要人判断对不对，而且因为产出速度变快，需要验证的代码量反而更大，验证这件事变得更重要，不是更不重要。

成本没有消失，只是换了环节

这是我想在文章框架之上补的一层：如果把「完成一个功能」的总成本看作一个固定或者缓慢下降的量，AI 编程做的事情是把成本从「写」这一段搬到了「审」和「返工」这两段。不会判断代码质量的人，用 AI 生成代码的那一刻看起来效率飙升，但这部分「没有被验证的风险」并没有消失，它会在后面某个时间点，以「线上 bug」「维护困难」「重构成本」的形式兑现，只是兑现的时间被推迟了。

这也是为什么资深工程师和新手用同一个 AI 编程工具，体感差异巨大：资深工程师的验证力本来就强，AI 帮他们省掉的是「预判力」这一层的时间成本，省下来的时间是纯增量；新手的验证力本来就弱，AI 生成代码之后，他们没有能力判断这段代码埋了什么坑，问题会一直潜伏，直到某次真实运行中爆发，此时排查成本远高于当初自己手写、自己踩坑、自己理解的成本。这不是「AI 编程没用」，是「AI 编程对不同验证力水平的人，价值兑现的方式完全不同」。

评论员视角

我认为这篇文章最有价值的地方，是把一个容易被简化成「AI 让编程更容易/AI 编程有很多坑」的二元讨论，拆成了一个可以分别观察的两层结构。行业里大多数「AI 编程提效」的宣传案例，统计的都是预判力门槛下降带来的产出速度，很少有案例去衡量验证力这一层的实际负担变化——这和本站在 落地手册 里提到的判断一致：厂商宣传的提效倍数大多缺少对照组，统计的是产出量而非交付质量。「任何人都能用 AI 编程」这句话如果不加限定条件，很容易让不具备验证力的人，把风险成本无意识地平移给了未来的自己，或者平移给了后面接手代码的同事。

对个人和团队的现实建议

对个人来说，用 AI 编程工具提速的同时，不能跳过「自己读一遍、理解一遍」这一步，否则省下来的时间是在拿后续排查成本做抵押。对团队来说，如果引入 AI 编程工具的目标是提效，配套的 code review 强度、测试覆盖率要求应该同步提高而不是降低——因为产出代码量变大了，需要验证的总量也变大了，如果验证环节的投入没有跟上，团队整体的技术债积累速度只会更快，不会更慢。