腾讯工程师反思 AI 编程提交量暴涨数十倍
腾讯 Agent 开发工程师 maple 观察到，团队代码提交量因 AI 编程暴涨数十倍，但可控性同步下滑：AI 缺乏人类在需求评审中隐性裁剪边界的知识，倾向保守展开全部异常路径，导致协调状态膨胀、review 退化为“看着像不像”。作者认为瓶颈不在生成能力而在收敛能力，应在生成前写入显式约束并保留人工中断点。
报道正文
说个最近越想越不对劲的事......
《AI 编程的加速陷阱》
我是maple，目前主要在腾讯做Agent 相关的一些开发业务。
我们团队现在代码提交量大概是以前的几十倍。一开始大家挺兴奋，觉得效率上来了。但慢慢我发现，量上来了，可控性反而下去了，而且是整条链一起往下掉。
需求评审完，产品随口说了句，「这个边界先不用管，实际业务里不会这么用。」程序员点点头，测试也没为这个场景开单。这句话没进 PRD，没进纪要，也没变成用例，但它实实在在把系统复杂度降下来了。
现在换成 AI 编程。这句「先不用管」没人写进需求。AI 很认真地把边界展开成十几个状态、一堆异常路径和兼容分支。代码提交量上去了，测试单也上去了，所有人就被拖进了循环。
问题不是 AI 不努力，是它不知道人类本来会妥协。
传统手工编程时，我们从来没把所有状态全实现过。真正让东西能交付的，是产品、开发、测试在磨合里一次次把边界裁掉。哪些异常不会发生，哪些兼容可以放弃，哪些测试细节不值得开单。这些大多不在文档里，是组织里的隐性知识。
AI 没有这套隐性知识。没有显式约束时，它倾向于保守展开，所有边界都当有效，所有异常都当要覆盖。结果就是协调状态急剧膨胀，AI 处理不完，人也 review 不过来。
以前复杂度在进代码前就被人类裁掉了。现在复杂度先被展开，再想靠 review 和测试收回来。但人的带宽有限，变更一旦超过某个量级，review 就会从「判断对不对」退化成「看着像不像」。
上周我翻了一个中等需求的提交记录。以前类似需求大概二三十次提交，这次是六百多次。测试刚跑完一轮，第二天又多了八十多个 commit。他追不上，只能用 AI 批量生成用例、批量开单。开发收到一堆细节单，也只能继续用 AI 批量改。
这就陷入了恶性循环。
关键不是「AI 太快」，是加速链里没有中断点。软件工程本来需要一些减速带，需求裁剪、验收标准、测试取舍、发布门禁、人工否决。这些减速带被冲掉后，速度不会自动变成吞吐，反而会变成噪声和返工。
所以方向不是「事后 review 更多」，而是「生成前约束更多」。把不处理场景、可接受异常、兼容范围和人工兜底写清楚，让 AI 能读到、能执行。组织上也得保留人类说「停」的权力。
AI 编程缺的可能不是生成能力，是收敛能力。
没有中断的加速，不是吞吐，是噪声。