AI 编程的能力边界

上个月，一个朋友把他们团队最近的两个项目摆在一起给我看。

项目 A 用 AI 生成代码，两个月交付，测试覆盖率 92%。项目 B 全部人工写，四个月交付，测试覆盖率 78%。

他说："你再猜，哪个项目的线上事故更多？"

我猜错了。

项目 A 线上事故比项目 B 多了将近一倍。不是 AI 生成的代码质量差，是人判断不了这些代码什么时候会出问题。

为什么覆盖率更高反而事故更多？这就是 AI 编程最隐蔽的陷阱。

AI 真行的地方

先说清楚 AI 哪些方面确实强。

代码生成速度。 不是一个量级。一个 CRUD 接口，人写 20 分钟，AI 30 秒。不是人慢，是人打字有物理上限。这种差距在所有重复性编码中普遍存在——单元测试、数据迁移脚本、配置代码、样板代码。

规范一致性。 人最大的问题是状态不稳定。周一写的代码工整漂亮，周五赶工写的就随意松散。命名风格、错误处理模式、测试覆盖——同一项目里前后不一致是最常见的代码异味。AI 没有这种波动，给定规范就能稳定输出。

多语言覆盖。 一个后端程序员熟悉 Java 和 Python，前端熟悉 TypeScript。遇到一个冷门语言或者老旧框架——Groovy、COBOL、甚至是公司内部 DSL——绝大多数程序员需要花时间学，而 AI 可以直接上手。

测试生成。 这是最扎心的一项。多个团队的实测结果一致：AI 生成的测试覆盖率和边界 case 覆盖优于人工水平。原因很简单——人会偷懒，"这行没必要测吧"，AI 不会。

AI 在这些领域已经超过初中级工程师的水平。这不是预测，是现状。

再来看另一面。

需求模糊时的理解。 AI 擅长精确指令下的执行，但真实世界的需求从来不是精确的。产品经理说"优化一下用户体验"，这个描述对人类来说是常识理解，对 AI 来说是一个需要大量猜测的黑盒。在模糊需求下，AI 生成的代码可能需要反复修改，最终工作量反而更大。

长期维护的上下文。 AI 没有"六个月前我为什么这么写"的记忆。它每次生成都是基于当前上下文的最优解，但这个最优解可能和系统已有的设计风格冲突，可能引入新的依赖，可能用一种项目中从未出现过的方式解决问题。短期看代码没问题，长期看系统一致性在悄悄退化。

技术债务的判断。 AI 不会说"这个方案虽然写得快但以后维护成本高"。它缺乏对长期代价的感知。一个快速实现但难以扩展的方案，AI 倾向于选择它因为它当前看起来合理。

不确定性处理。 第三方接口变了、需求砍了、数据库 schema 改了——这些变化时刻在发生。AI 不知道这些变化，除非你告诉它。而且即使你告诉它，它也不一定能理解这些变化对整个系统的影响范围。

把上面两部分放在一起，边界就很清楚了。

AI 擅长：有明确输入输出规范的编码任务、测试生成、重构、代码翻译、文档生成、已知模式的实现。

AI 不擅长：需求理解与澄清、架构权衡、跨模块影响分析、长期可维护性判断、非确定性场景处理。

这个边界非常关键。因为误判这个边界带来的后果，比不用 AI 更严重。

那个测试覆盖率 92% 但事故更多的项目，问题出在团队认为"AI 写的代码没问题"——他们把 AI 生成当作终点，而不是起点。

AI 写代码的速度越快，你需要花在审查和理解上的时间就越多。这个比例不是线性的。AI 产出快了 10 倍，审查时间可能需要增加 3 倍——因为你不再是自己写自己懂，而是需要理解别人写的逻辑，再判断它对不对。

一句话概括：AI 搞定怎么写的部分，你搞定为什么写和写得对不对的部分。

把 AI 当作一个极其高效但没有判断力的初级工程师。它能在一小时内完成你一天的工作量，但你需要花时间来检查它做的对不对。

不要让它独立负责重要模块。不要跳过代码审查。不要假设"AI 生成的就是对的"。

当你对"AI 能做什么不能做什么"有了清晰的判断力，你才能真正用好它。

这个判断力本身就是一种新的专业技能。它的价值，比任何一门编程语言都要高。

这是《AI 时代程序员新技能体系》30 篇系列的第 1 篇。

下一篇（第 2 篇）：从 Prompt 到 Loop——工程范式四次跃迁

每天一篇，一个月完成一轮系统升级。关注这个系列，不要错过下一篇。