我今天上午的时候，看到腾讯的 AI Agent 开发程序员 maple 分享了一件事，他称之为：AI 编程的加速陷阱。我感觉分享的很对，很有道理。

他说，他们团队现在用 AI 写代码，代码提交量涨到了以前的几十倍。一开始大家都挺高兴，效率确实上来了。但过了一段时间，他发现不对劲：代码是多了，可整个项目反而越来越不好控了。

他举了个特别具体的例子。以前做需求评审，产品经理经常随口说一句：“这个边界情况先别管，实际业务里碰不到。”程序员听了点点头，测试也不会为这个场景开单。这句话从来不会出现在任何文档里，但它确实把系统复杂度砍掉了一大块。

换成 AI 编程之后，没人把“先别管”写进需求。AI 看到需求就老老实实把所有边界全展开了，十几个状态、一堆异常处理、各种兼容分支，全给你安排上。代码量暴涨，测试用例也跟着暴涨，所有人就被卷进了一个越转越快的陀螺里。

以前团队里产品、开发、测试磨合久了，有很多“不说大家也知道”的默契。哪些异常不会真出现，哪些兼容可以不做，哪些测试不值得写。这些东西没人整理成文档，就长在团队脑子里。AI 没有这些默契，只能按最保守的方式来，能展开的全展开。

然后他说了一个数字。以前一个中等需求差不多二三十次提交就搞定了。最近一个差不多的需求，提交了六百多次。测试好不容易跑完一轮，第二天又冒出来八十多个新提交。测试追不上，只好用 AI 批量生成用例、批量开单。开发收到一堆单子，也只能继续用 AI 批量改。AI 给 AI 擦屁股，人在中间已经完全跟不上了。

先说一个问题：速度上来了，但没有人在中间踩刹车。软件开发本来有很多“减速带”，需求裁剪、验收标准、测试取舍、发布前的人工审核，这些环节会自然地把多余的东西挡在外面。现在 AI 的速度把这些减速带全冲掉了，代码像洪水一样涌过来，review 的人只能看个大概，“看着像对的”就放过去了。

再说另一个：复杂度一旦铺开了，想收回来就很难。以前还没进代码就被人砍掉了，现在是先全部展开，再指望 review 和测试往回拽。人的精力就那么多，量大到一定程度，审查就从“判断对不对”变成了“看着像不像”。

所以 maple 觉得，得反过来，在 AI 动手之前就把规矩立好：哪些场景不用处理，哪些异常可以接受，兼容做到什么程度，写清楚了再让 AI 去生成。同时团队里也得保留人喊停的权力。

他最后总结说：AI 编程可能缺的，是收住的能力。没有中断的加速，最后跑出来的全是噪音。

#科技先锋官##How I AI#