夜雨聆风前两天深夜，一个做创业的朋友跟我吐槽，说他要被AI编程搞疯了。
他们团队一直在用Cursor和Copilot赶进度，早期确实爽，一天能出5000行代码，老板看了直呼高效。但项目代码量过了8万行之后，画风突变——跑得越来越慢，改一个bug冒出三个新的，AI写的那些模块他自己都没仔细看过，更别提理解了。他试了改数据库、调线程、清资源竞争，全部没用。
最后他说了句让我印象很深的话："我感觉不是在维护项目，是项目在维护我。"
这不是个例。我最近跟不少开发者聊，发现类似的吐槽越来越多。AI编程的"反噬"，正在变成一个行业级的真问题。
快是有代价的
说实话，AI编程在起步阶段（几千行代码的小项目）确实像开挂。但项目一大，情况就完全不同了。
代码量到了5万、8万行，每次修改都可能引发连锁反应。更要命的是调试——AI写的代码，依赖关系藏得深，边界条件想不全，异常处理能省就省。有时候为了修一个小bug，你得把AI那堆混乱的调用链从头到尾啃一遍，花的时间比自己重写还长。
这事不是我一个人觉得。Stack Overflow 2025年的调查里，45%的开发者说修AI代码比自己从头写还费劲。还有个团队的实践更夸张：AI确实把单模块开发从3天压到了8小时，但上线后架构一团糟，维护成本直接涨了3倍。甚至有一份研究说，AI工具反而让资深开发者的效率降低了19%——本来以为能快，结果更慢了。
技术债这笔账，迟早要还
AI生成的每一行代码，将来都可能变成债。
GitClear去年的报告有个数据挺吓人的：用了AI辅助编程之后，代码克隆量涨了4倍。大量短期拼凑的代码涌进来，原来那点复用文化基本瓦解了。
而且说实话，大家审AI代码的认真程度，远不如审同事的代码。很多人心里清楚AI写的东西有坑，但测试先拖着吧，适配以后再说吧，反正"能跑就行"。81%的开发者承认，花在审查AI代码上的时间明显变多了，差不多占了工作日的三分之一。
cURL的作者Stenberg今年在FOSDEM上讲了个事：他们项目收到的安全报告里，有效比例从六分之一下降到了二十分之一甚至三十分之一。他直接把这叫"对开源的DDoS攻击"。大量低质量的AI生成报告淹没了真正有价值的问题。
归根到底就一句话：AI会写代码，但它不负责。它不知道几万行代码迭代完之后性能会变成什么样，它只管帮你改掉眼前这个bug，至于会不会引入更多问题——那不归它管。
一个永远教不会的实习生
我觉得AI编程最坑的地方，不是代码质量差，而是它在架构层面有先天缺陷。
第一个问题是，AI没法保持架构上的一致性。每次让它写个功能，单看都没毛病，但迭代几十次下来，因为根本没有统一的设计思路，项目就成了"屎山"。比如你让它先加串口通信，再加TCP，再加UDP，三个模块各自跑起来都挺好，但接口设计思路完全不同，整合在一起又慢又难维护。
第二个问题更隐蔽：项目里总有一些没写在代码里的"铁律"，比如某个函数必须在主线程调用，某个缓存上限是1000条。AI在生成一小段代码的时候，根本预见不到这些约束。经典的翻车场景是在工作线程里直接操作Qt的GUI控件——编译能过，测试能过，上线之后随机崩溃。
最让人崩溃的是，它没有成长性。你跟它反复强调命名规范和架构约束，它每次都"好的好的我理解了"，下次照样我行我素。就像一个永远带不出来的实习生。
怎么办？
其实行业里已经有比较清晰的方向了。
谷歌内部现在75%的新代码是AI生成的，工程师的工作重心已经从"写代码"转到了"审代码"和"做架构"。这不是选不选的问题，是必须走的路。以后真正值钱的能力不是敲代码有多快，而是你能不能做出正确的技术决策、设计稳固的架构、快速判断哪里会出问题。
具体怎么落地？几个我觉得比较实在的做法：
先用架构约束框住AI。模块怎么分层、哪些可以调用哪些不行，这些要在AI动手之前就定好，不能让它自由发挥。
然后严格审查。不是看"能不能编译"，而是看架构有没有被破坏、有没有踩到那些隐藏的系统约束。
还有分阶段验证。每次加一点就测一轮，别攒着。有数据显示，加上这些约束之后，代码规范达标率能从58%拉到92%，关键缺陷密度降了40%。
另外"代码熵管理"这个概念也值得关注——用系统化的手段量化代码质量，让混乱程度始终可控。
最后说两句
现在AI编程工具正在从"代码助手"往"自主执行Agent"进化，权限只会越来越大。这意味着失控的代价也在同步放大。
我个人的体会是：该交给AI的重复劳动尽管交，但决策权和掌控权必须留在自己手里。"Vibe Coding"听上去很美，但AI最大的问题不是不会做，而是做事缺乏完整性——你让它归档文件，它不会想到本地也要同步；你让它部署代码，它不会想到数据也得迁移。每次都是你提一个它补一个，永远差一步。
在这个时代，能驾驭AI的人值钱，被AI驾驭的人危险。
