在把AI编码代理接进日常流程之前，他每次提交的Pull Request平均68行，横跨4个文件。如今同样一个仓库、同样一个人，PR体量膨胀到了873行，文件数也跳升到13个。

光是盯着这两个数字，任何人都会起疑心。审查量翻了十多倍，表面上看就是一个批量制造无人阅读代码的机器——这也正是那些“AI让我快了10倍”的经验贴一遇到有经验的审阅者就翻车的原因：它们停在产出量的数字上，不肯追问多出来的代码到底在做什么。

打开网易新闻 查看精彩图片

于是他干脆算了自己一直不敢面对的那组数据。还是这个仓库，两年全程、2210个已合并的PR，从git和工单API重新拉出来算，结果却彻底扭转了判断：碰过测试文件的PR比例，从5%跳到了88%。过去二十个PR里只有一个顺手写了测试，现在十个里有九个都包着测试一起进来。

这一点直接把“变更量爆炸”从需要忏悔的罪证，变成了值得认真对待的发现。要是多出的代码只是代理在胡乱填充，测试覆盖率应该原地踏步甚至下跌才对。但它涨了17倍，这本身就是质量的一个强信号。

更让他意外的是，工单的吞吐量几乎没动。引入代理前，每月平均关闭43张工单；之后也不过55张。他并没有比以前更快地卸掉更多工单。真正变化的是，在差不多数量的工单里，他开始交付真正“完工”的东西——测试、边界检查、日志埋点已经全在里面。所有增量都发生在单张工单的内部，而这恰恰是按工单数衡量效率的看板永远看不见的细节。

在他重新算出的表格里，最值得注意的一行是：在保持同样工单产出的前提下，每半个小时间歇键盘时间所审阅的源代码行数，是过去的6.3倍。而且这还是一个地板值——因为统计后期有些提交是代理在他煮咖啡时自动完成的，无形中拉大了分母。把时间界限前后稍作浮动，数值始终在5.5倍到7.2倍之间。

再细看中间的演化。只接入一个AI代理时，典型变更行数从68行拔高到210行，大约翻了三倍。从单个代理增加到多个代理并行之后，数字又翻了近四倍，直达873行。第二步的跳跃远比第一步大，而驱动它的并不是单个代理的处理速度，而是并行的天花板被彻底撑开了。

过去，日常同时进行的分支永远在5到8个左右，这点从来没变过。真正被改写的是上限：从最多16个分支并行，直接跳到31个。平时不需要用满，但总会遇到那种六件事齐头并进、光靠线顺序根本推不动的日子——以前正是在这种状态下系统会窒息，而现在不会了。

为了获得这个能力，他的需求很明确：一个地方就能看到所有代理会话的状态，给每个代理分配独立工作树防止文件冲突，每个代理都要清楚标记“工作中/空闲/需要输入”，而且下一步Git操作永远是一键完成。市面上没有完全合用的现成工具，于是他干脆自己造了一个，就叫MindFlock。更重要的是，这一切都跑在自己的笔记本上，而不是丢进某个云服务的虚拟机里。

两年回头看，AI代理没有让他多关掉更多工单。它改变的是每个工单里的完成度。88%的测试覆盖率就是信任的锚点，它让一个873行的PR不再是让人心虚的臃肿怪物，而是一个真正“做完”的提交。当代码变大的同时，那增加出来的部分带着测试一起进来——对开发者的信任而言，这比任何提速宣言都更有分量。