AI 写代码越快，越该限制同时开的任务

三个 Agent 都说改完了，你还没审完第一个 PR。

如果你正在几个终端、分支和需求之间来回切，这个画面大概很熟悉。模型一直有产出，人一直在忙，到了下班却说不清今天到底合进去了什么。我的判断是，当审查已经积压，减少同时开的任务，比继续催模型更值得试。

这几天，一篇叫 《One month without AI》 的开发者自述被社区重新讨论。原文发表于 9 月 25 日。作者写到，多任务并行让他频繁切换上下文，生成的改动仍要自己理解、审查和修正，后来选择停用 AI。

这是个人经历，不是对照实验，不能拿来证明 AI 编程普遍低效。本文也没有做生产项目实测。它值得拿来问一个更具体的问题，你现在开的并发，究竟有没有超过自己审代码的能力？

我不准备建议所有人把工具卸了。把使用范围收窄，可能就足够改变局面。下面这套一周记录方法，是我基于交付流程给出的建议，不是原作者的实验结论。

忙碌从终端搬到了脑子里

假设一个常见场景，你把三个相互独立的小需求分给三个 Agent。它们各自在独立工作目录里干活，看起来互不打扰。

代码文件确实隔开了。可负责验收的还是同一个你。

审第一个改动，你得想起接口原来的约定。审第二个，需要切换到页面状态。第三个又涉及数据库字段。即使每份改动都能编译，你也得重新装载三套背景，确认它们没有把不同需求的边界混在一起。

好家伙，终端上的进度条都满了，脑子里的加载条还在转。

这里容易漏算的是等待。模型提交补丁之后，到你真正读懂、验证并决定接受，中间经过的时间，也属于交付周期。它不会因为 Agent 宣布完成而消失。

待审改动就是尚未兑现的工作。 它可能有价值，也可能需要推倒重来。只数新建了多少 PR，无法分清这两种情况。

更麻烦的是，等待会让原本简单的任务变贵。

你刚提完需求时，还记得为什么只改这个函数。隔一段时间再看，需求的前提、上一次讨论的取舍、哪些行为必须保留，都得重新找。Agent 的说明写得再流畅，也不能自动补回你当时没有写下来的判断。

你想想看，如果一个队列已经开始积压，再往里面塞任务，至少不会让现有待审项自行消失。加并发能不能提高最终产出，要看后面的审查能力是否也能跟上。

当然，多个任务并行有它的好处。一个在等依赖下载，另一个可以跑测试。边界清楚、验证办法成熟的独立工作，也可能一起完成。这里要限制的是超过验收能力的在途任务，不是追求终端永远只开一个。

把一周的账记在同一张纸上

别急着找一个行业通用的最佳并发数。我也给不出这个数字。

同样一个人，改文案和改支付状态机，能承担的并发就可能完全不同。我们可以做一个小范围观察，让决定有点依据。

挑一类重复出现、规模相近的任务。比如给现有接口补一项明确的参数校验。实验期间尽量使用同一套模型配置和验收要求，避免这边同时换模型，那边又把任务难度翻了一倍，最后分不清是谁造成变化。

前半周照原来的方式工作，后半周降低同时在做的实现任务数。周内任务太少，就延长观察，不要为了填表硬造工作。这个做法只能提供团队内的线索，不能据此宣布某种模式快了多少。

下面这张记录单可以直接放进团队文档。每个任务写一份，空着的地方填实际记录。

任务名称与范围
原本要改变的行为——
必须保持的行为——
开始处理的时间——
首个可审补丁到达时间——
开始人工审查时间——
人工阅读、验证、返修的累计用时——
最终接受或放弃的时间——
返修原因——
遗留问题与观察期限——

为什么把「首个可审补丁」单独记下来？因为它能帮你分辨生成慢和排队慢。

如果补丁早就到了，但很久没人开始审，继续优化提示词让它更早到，收益恐怕有限。如果你马上开始审，却一直看不明白改动为什么扩大了，那就该缩小任务范围，或者要求模型先解释方案。两者处理办法不同。

有一点需要说清，自然经过的时间和人的投入时间要分开记。 晚上没人审，不等于有人连续投入了一整晚；模型在后台运行，也不等于开发者完全没有切换成本。把这两笔账揉成一个数，很容易各说各话。

再补一条，放弃的补丁也要留下。只统计最终合并的任务，会把失败尝试花掉的时间藏起来。某个任务重开了三次，那三次都属于这次交付，不能只留下最后看起来最漂亮的一轮。

坦率讲，这种记录不怎么酷，也不会在演示里显得模型很厉害。但它能让你在下周讨论时，拿出一个具体卡点，而不是一句「最近感觉更累」。

接受补丁之前，把理由拿回来

减少并发以后，多出来的注意力放在哪里？我会优先放在看懂改动与验证失败场景上。

假设 Agent 给一个接口加了输入校验，又顺手移动了几个公共方法。测试全部通过。你真正需要确认的，是这些移动是否必要，旧调用方的行为有没有变，以及新增测试究竟覆盖了哪个风险。

光让模型再总结一遍，可能只会得到另一份更顺畅的说明。更有用的是要求它把主张对应到代码和可运行的检查上。

这段提示词可以复制。把其中的任务目标、基线分支和允许改动范围替换成自己的项目内容，再交给当前编码助手。

审查当前补丁，暂不继续扩写功能。
任务目标为［填写目标行为］。
比较基线为［填写分支或提交］。
允许改动范围为［填写模块边界］。

说明每组改动与目标行为的对应关系。
指出超出目标的改动，以及保留它的理由。
为最重要的失败场景列出输入和预期结果。
说明现有测试是否真正覆盖该场景。
列出实际运行的检查、结果与未运行项。
区分你已验证的事实和仍需人工判断的推测。
输出后等待审查，不提交、不合并。

这段话本身没有证明能力。模型说测过了，你仍要看实际命令与结果；它说没有影响旧行为，你仍要检查关键调用方。它的作用是把需要核对的东西摆出来，省掉一轮含糊的来回。

厉害了，这时 AI 依然在帮忙，只是工作重点从继续堆代码，转到了把已有改动说明白。

要是你发现，自己无法说明这个模块原本应该怎样工作，那就把实现任务暂停在这里。

可以请模型帮助定位入口、画出调用关系，再由你对照实际代码和需求核实。也可以直接找了解业务的同事确认。反正别让下一份补丁盖住上一份尚未理解的补丁，越叠越难拆。

什么时候可以把并发加回来

观察一段时间后，如果待审项减少，任务从开始到接受的周期也缩短，而返修与遗漏没有明显变多，降低并发就值得继续。任务数量少时，保留原始记录和具体案例，比给一个精确百分比更诚实。

如果没改善，就顺着记录往下找。也许瓶颈是测试环境，也许是需求一直变化，也许关键审批人不在。此时只限制 Agent 数量，当然治不好别的环节。

我更愿意用一个很朴素的条件恢复并发，眼前这批改动能及时审完，而且每份改动都有独立的验收办法。 增加后继续观察，队列又开始堆，就退回去。这是一条操作建议，不是经过验证的通用阈值。

还有一类任务值得单独看待，探索性原型。为了比较方向，同时做几个可丢弃版本，可能比排队做更有价值。但你得提前说清楚，哪些是探索结果，哪些准备进入正式代码库。原型跑得起来，离维护它还有一段路。

说真的，我希望 AI 编程省下来的时间，最后能落在人身上。少开几个终端不是退步，只要它让你更早交付一份自己解释得清的改动。

下一次 Agent 说完成时，可以顺手记下时间。真正该画句号的地方，是你决定接受这份改动的那一刻。

你现在最常卡在哪一步，等模型写完、自己审不完，还是测试一直排队？