想象一个熟悉的场景：团队全面用上AI写代码，提交量涨到以前的几十倍，群里一片欢腾。三个月后，项目反而越来越不可控了。
这不是段子。腾讯AI Agent开发程序员maple在11月10日分享了他称之为「AI编程的加速陷阱」的亲身经历：以前一个中等需求，二三十次提交就收工，最近一个差不多体量的需求，提交了六百多次。测试团队好不容易跑完一轮，第二天又冒出八十多个新提交。测试追不上，就用AI批量生成用例、批量开单；开发收到一堆单子，又用AI批量去改。AI给AI擦屁股，人在中间已经完全跟不上。微博
这也不只是一个团队的问题。GitHub最新年度报告里，过去12个月全球发生了179亿次代码推送、343亿次代码提交，差不多是两年前的三倍。今年9月，超过40%的PR初稿已由AI智能体起草，而3月这个数字还只有17%。微博
陷阱的根子：没人告诉AI「这个不用管」
maple举的例子特别扎心。以前需求评审，产品经理随口一句「这个边界情况先别管，实际业务里碰不到」——这句话永远不上文档，却实打实砍掉了一大块系统复杂度。换成AI之后，没人把「先别管」写进需求，AI看到需求就老老实实把所有边界全展开，十几个状态、一堆异常处理、各种兼容分支，全给你安排上。微博
说白了：AI只会做加法，不会做减法。 评论区的高赞吐槽看得很透——以前那些默契「长在团队脑子里」，AI没有默契，只能按最保守的方式来。更麻烦的是，需求评审、验收标准、测试取舍、发布前人工审核这些「减速带」，本来会把多余的东西挡在门外，现在全被速度冲掉了。量大到一定程度，review就从「判断对不对」变成了「看着像不像」。连地基都在被冲垮：今年8月17日GitHub出现过大规模宕机，官方复盘的结论就一句——基础设施容量没能跟上平台使用量的暴涨。微博微博微博
组织层面把油门踩到底的样本也有了。隐私安全公司Proton今年10月约90%的代码已经由AI编写，还在员工电脑上装软件统计AI代码量。有安全团队员工建议新代码上线前多花几天做渗透测试，CEO当场回怼「这是胡说八道，是失败者的思维」。随后曝出的「全员重新面试证明你会用AI」引发用户抗议，10月30日全员会议上复试被正式取消，CTO也承认「我们搞砸了」，但11月1日这位CTO又在官网发布软件工程AI宣言：「编程已经死了，但工程没有」。踩油门容易，丢的方向盘是回不来的。36氪
怎么破：把刹车装回去
综合maple和一线从业者的实践，破法出奇一致——在AI动手之前，先把「不做」定下来：
把「先别管」写进需求：哪些场景不处理、哪些异常可接受、兼容做到什么程度，写清楚了再让AI去生成；maple同时强调，团队里必须保留人喊停的权力。微博
控制单次变更规模：首席架构师Carlos Kelkboom的建议很直接——代码太多，为什么不让Agent少写一些？他的Agent曾因反复打补丁把同一功能实现了五次，所以他的原则是看不懂就扔掉，宁可回退重来，不在错误结构上续命。36氪
先搭骨架再放AI干活：Carlos动手前先花20分钟到1小时定好目录、关键文件和函数签名。美团的做法更进一步：31万行的业务系统90%以上代码由AI生成，团队把工程规范转成AI可执行的规则，提交前先让AI自查规范、缺陷和异常处理，人再重点审业务逻辑。连Claude Code团队自己也搭起了从PR前、PR中到合并时、合并后的全流程审核，没人靠肉眼硬扛。36氪哔哩哔哩
maple的总结值得裱起来：AI编程可能缺的，是收住的能力；没有中断的加速，最后跑出来的全是噪音。工具会越来越快，但下一个拉开差距的，是谁先学会让AI做减法。微博
