用AI写代码反而慢了19%？我折腾半年后终于信了

半年前我第一次认真用AI写代码的时候，感受就两个字：真香。

那时候在写一个内部管理系统的后端接口，搁以前得查文档、翻Stack Overflow，一个分页查询的CRUD可能要磨蹭半小时。现在呢，把需求往AI助手对话框一丢，几秒钟代码就出来了，还带了注释和单元测试。我当时拍了张截图发到技术群里，配文："以后程序员只需要会打字就行。"

直到我看到了一个数据，整个人都不好了。

这个数据来自一家叫METR的研究机构，他们搞了个挺有意思的实验：找了一帮资深开发者，用自己熟悉的代码库做真实开发任务，一半人开AI编程工具，一半人不开。结果发现——开了AI工具的人，任务完成速度不但没快，反而慢了19%。

但这还不是最离谱的。最离谱的是，这些被测的开发者事后被问到"你觉得AI帮你提速了多少"，他们普遍认为提速了20%左右。实际慢了19%，自己觉得快了20%，认知偏差将近40个百分点。

我当时第一反应是：这研究肯定有问题吧？我自己用着明明快了很多啊。但仔细翻了翻自己的Git提交记录和时间分配，突然有点说不出话了。

那些被忽略的"隐形成本"

仔细想想，AI帮我"快"的那些时间，到底花到哪去了？

代码确实是秒出的，这个没水分。但出了之后，我得读吧？AI生成的代码有个特点：看起来很完整，注释也齐，逻辑乍一看也通顺。但"看起来对"和"真的对"之间，有时候隔着一整个线上事故。

我有次让AI写一个优惠计算函数，需求是"满1000减50"。AI几秒钟就给出了代码，单元测试都帮你写好了，跑一下全绿。当时挺满意，直接合了。上线第二天运营找过来了——怎么每个用户都减了50，不管满没满1000？

翻出来一看，AI把"满1000减50"理解成了"每满1000减50"。就差一个字。单元测试为什么全绿呢？因为AI自己写的测试用例只覆盖了正好满1000的情况，没测不满1000的边界。它既是运动员又是裁判，当然全过。

这种"看起来对"的代码最坑人。如果是自己手写的，你会下意识去怀疑边界条件。但AI给你的代码，带着注释和测试，心理上就会放松警惕。这种信任本身就是一种成本——你在不知不觉中降低了对代码的审查标准。

后来我开始留意自己用AI编程的时间分配，大致是这样的：

写代码本身确实快了不少，大概省了30%到40%的编码时间。但读代码和验证代码的时间翻倍了——以前自己写的代码心里有数，扫一眼就行；AI生成的代码，你得逐行读，因为它可能用了一种你没预期的实现方式。再加上修AI产生的那些微妙bug，一来二去，省下来的时间基本又赔回去了。

更别说有时候AI会"自作聪明"。有次我让它把一个变量重命名，它顺手帮我改了6个文件113行代码，连Webpack配置和README都给我动了。有些改动是合理的，有些根本没必要。但你得花时间逐一审查，因为不审查你不敢合。

写代码只占开发周期的四分之一

METR那个19%的数据出来后，有人专门做了更细的拆解。结论挺扎心的：写代码这个动作，在整个开发周期里只占25%到35%。

剩下的时间花在哪了？需求理解、方案设计、技术选型、联调测试、部署运维、写文档。这些环节AI基本帮不上太多忙，有些甚至帮倒忙。

举个具体的例子。需求评审的时候，产品说要做个"积分兑换"功能。你脑子里得想：积分过期策略是什么？并发兑换怎么锁库存？退款了积分退不退？这些是业务逻辑，不是代码语法，AI再聪明也猜不到你公司的业务规则。

而恰恰是这些"想"的时间，决定了一个功能做得对不对。AI帮你把"写"的环节加速了，但"想"的环节它加速不了。如果你因为代码写得快了就压缩思考的时间，那结果就是——代码产出快了，但返工更多了。

有组企业级的数据更直白。一家叫Faros AI的公司分析了大量AI辅助编程的PR记录，发现：AI辅助生成的代码，Bug率比人工高出28%，代码评审时间延长了5倍，事故率提高到3倍，代码改动量更是达到了10倍。

还有一个数字让我印象很深：一家咨询公司的调查发现，企业近44%的AI算力消耗，花在了修复AI自己生成的Bug上。将近一半的资源，在帮AI擦屁股。

但AI也不是没用，关键是别用错地方

说了这么多反面情况，不代表我觉得AI编程没用。我现在每天还在用，只是用法变了。

最开始我是什么都让AI写，核心逻辑、业务代码、接口设计全丢给它。后来发现这条路走不通——越是核心的、跟业务强相关的代码，AI越容易出问题，因为它没有上下文。你的系统架构、数据库设计、业务规则这些信息散落在十几个文件和各种文档里，AI的上下文窗口再大也只是"塞进去"，不是"理解了关系"。

现在我的做法是分场景用。样板代码、CRUD接口、工具函数这些重复性高的东西，放心交给AI，确实快。正则表达式、SQL语句这种记不住语法的，问AI比查文档快。单元测试让AI先出一版，自己再补充边界用例。看不懂的别人的老代码，让AI解释一下，省得自己逐行读。

但核心业务逻辑、系统架构设计、安全相关代码这些，AI只能当参考，不能当答案。关键决策还是得自己想清楚。你让它写个加密函数，语法没问题，但它可能用了三年前就被废弃的加密库，或者没考虑并发场景下的线程安全。

还有一个经验：给AI的指令越具体，输出质量越高。"帮我写个分页查询"和"用MyBatis-Plus写一个分页查询，入参是Page对象，返回IPage，按创建时间倒序"——后者的输出基本能直接用，前者你得改半天。

另外就是控制对话长度。之前我习惯一个对话窗口从头用到尾，后来发现聊到十几轮之后AI就开始"失忆"了，编一些不存在的字段名，引用三周前就被重构掉的旧代码。现在我会定期开新对话，把关键的项目结构、数据库设计、技术栈约定重新喂给它。麻烦是麻烦点，但比修莫名其妙的bug省事。

效率悖论的根源

琢磨了半年，我觉得效率悖论的核心就一句话：AI提高了写代码的速度，但没有提高想代码的速度。

写代码快了，你会不自觉地跳过思考直接动手。以前手写代码的时候，敲键盘的过程本身就是思考的过程——你在打字的同时想这个函数该怎么拆、边界条件有哪些、异常怎么处理。现在AI几秒就把代码给你了，思考的过程被压缩甚至跳过了。

短期来看产出快了，长期来看返工多了。这就像装修的时候赶工期，第一天贴的瓷砖是快了，第三天掉下来重新贴，总时间反而更长。

JetBrains有个调查说，90%的开发者觉得AI帮自己每周省了1小时以上，20%的人说省了8小时以上。但另一边，Bain的报告显示软件企业整体生产率只提升了10%到15%，远低于宣传的"效率翻倍"。

个人感受和企业实际产出之间的差距，就是那个"效率悖论"在起作用。你觉得自己快了，但实际上省下来的时间被审查、修复、返工吃掉了。

信任度也在下降。Sonar的年度调研说，61%的开发者认为"AI代码看起来对但不可靠"。用了两年AI编程工具后，开发者对AI代码的信任度从77%跌到了29%。越用越不信，这个趋势挺说明问题的。

不过话说回来，AI编程工具本身也在快速进化。从最初的代码补全，到现在的Agent模式能自己读代码库、规划任务、跑测试。也许再过一两年，上面说的那些问题会缓解很多。但在那一天到来之前，保持一点清醒没什么坏处。

工具是拿来用的，不是拿来信的。用得好的前提是知道它的边界在哪——在它擅长的领域放手让它干，在不擅长的领域自己把好关。这样AI才是真的帮了你，而不是给你埋了一堆雷。

对了，如果你也在用AI写代码，有没有类似的经历？是觉得真快了还是也踩过效率的坑？聊聊呗，我挺好奇别人是什么感受的。