AI编程提效现在已经变成了个笑话

寂静回声

AI 生成的代码，风格往往和团队现有代码不一致。变量命名习惯不同，抽象方式不同，错误处理模式不同。你团队用 Strategy 模式处理多态，AI 给你写一堆 if-else；你团队用 Result 类型处理错误，AI 给你 try-catch 然后 return null。
这种不一致，首次生成时还能接受。但当代码量积累起来，维护成本就开始指数级上升。就像那个相亲 App 里的命名混乱：UserHandler、MatchProcessor、ChatManagerV2——为什么有个 V2？V1 去哪了？为什么不叫 UserService、MatchingService、ChatService 保持统一？这些命名背后没有规范、没有约束，完全是 AI“想到哪写到哪”。三个月后你自己再看，都得愣半天。
你想在 AI 生成的模块上加个功能，几个本应分离的职责被揉在一个函数里。你试图重构，改了一处，另外两处就坏了。
这时候你会意识到，AI 生成的代码缺少“可维护性”。它不会主动想“这段代码三个月后还有人能看懂吗”，它的目标是“让这段代码在当前测试用例下通过”，而不是“让这段代码在长期演进中保持健康”。

AI 有时候会生成一些看起来有用、但实际没被调用的代码。
多余的抽象层、过度的设计模式、冗余的中间转换。你知道没必要，但不敢删，因为不确定删了会不会影响隐藏的依赖。
于是代码就这么臃肿下去，直到某天新人接手，对着这堆代码骂娘。


从AI 生成的代码缺少“可维护性”就知道AI没有系统观，这种“系统观”不是写几行代码能获得的，它是长期参与项目、读文档、参加评审、处理线上问题积累出来的。AI 没有这个过程。它每次生成代码，都是从零开始理解你的需求，而不是在你的系统上下文里“生长”出一段代码。
举个更工程化的例子：一次线上故障排查。一个有系统观的工程师看到报错，能顺着调用链、结合最近的发布记录、想到某个历史遗留的“临时方案”，很快定位根因。而让 AI 帮你修这个 bug，它只能在当前文件的上下文里做局部修补。它不知道上周那次“临时加的开关”，也不知道隔壁团队刚改过的接口契约。补完这边，那边又裂了。
所以 AI 写代码的方式，本质上是局部最优的。它在每个函数、每个模块的层面做得不错，但跨模块的协调、跨时间的演进、跨团队的协作，它顾不了。


很多文章喜欢说“AI 编程提效 50%”“开发效率翻倍”，这些数字怎么来的？多数是“首版代码生成时间”的对比。以前写个 CRUD 要两小时，现在 AI 十分钟生成，于是“提效 12 倍”。但 CRUD 只是开发工作的一小部分。调试、联调、评审、处理边界情况、写单测、处理线上告警、重构老代码，这些占据开发者大部分时间的工作，AI 提效非常有限。
其次，“生成快”不等于“交付快”。你花十分钟让 AI 生成代码，但你花两小时 review、修改、补全、测试。总时间比自己写还长。特别是有经验的开发者，对代码质量要求更高，改 AI 代码的时间更多。


这种“首版快、后续慢”的节奏，和软件开发本身的规律相悖。
正常项目，前期设计评审花时间多，编码阶段相对稳定。
AI 介入后，前期编码被压缩，后期维护、调试、重构时间反而被拉长。
总时间未必减少，只是成本转移了，从“写代码”转移到了“改代码”。


行业里有一种叙事，暗示 AI 正在“取代程序员”“让开发变简单”。这种叙事制造了过高的期望，然后让很多人在实际使用后产生落差。
但软件开发从来不是一个“写代码”的问题。需求理解、架构设计、系统演进、团队协作、质量保障、运维监控，这些才是软件工程的主体。AI 目前能做的，只是“写代码”环节里的部分工作。

正确的做法是把 AI 当“打字员”，不当“架构师”。你已经想清楚要写什么了，让 AI 帮你快速敲出来。但设计决策、架构选择、模块划分，还是得你自己来。
首版生成后，花足够时间 review。不要因为它“能跑通”就直接提交。逐行看，理解每一行的意图，检查边界条件，确认和现有系统的一致性。这个时间不能省。
维护阶段谨慎使用 AI，老代码修改、跨模块重构、涉及业务逻辑的调整，AI 容易引入新问题。这些场景，自己写可能更可控。
保持自己的编码能力，不要因为有了 AI 就放弃练习。你需要保持对代码的敏感度和判断力，否则连 AI 写的代码好不好都看不出来。