AI 写代码更快，为什么交付反而排起了队？

上午把需求交给 AI，午饭前已经多出好几个补丁。看上去进度不错。到了下班，功能还没上线：有的等审查，有的等测试，有的刚解决完冲突，又得重新验证。

这是一种很容易想象的反差。写代码的那一段确实快了，可用户等到功能的时间，没有按同样的比例缩短。我觉得理解它，要先把“写完”和“交付”放回各自的位置。代码只是经过生产线的一件半成品；只有需求被正确实现、变化被看懂、风险被验证，最后真的交到用户手里，这件事才算走完。

下面用一个假设的小团队来算账。所有任务数量和时间都是解释机制的示意，不代表某家公司，也不是 AI 工具的实测成绩。

一天写八份，不等于一天交八份

假设这个团队原来每天能完成四份大小相近的补丁，审查与验证合起来也能处理四份，暂且忽略偶发故障。一天结束，前面做出的东西，大致能被后面接住。

现在生成代码的能力提高了，每天能写八份，后面仍然只能处理四份。第一天留下四份，第二天又留下四份，第三天队列就有十二份。如果持续这样投入，队列会一直长下去。换一个更快的模型，可能只是更快地把半成品送到同一个等待区。

这里的“处理四份”，也不是说审查者整天只能读四个文件。它包括理解需求、读变化、确认边界、追问缺失信息、等待作者修改，以及检查测试是否真的证明了目标。不同补丁的难度当然不同，所以实际观察不能只数提交个数；这个简化例子只是把入口与出口的速度差露出来。

排队还会反过来增加工作量。一个补丁放了几天，相关代码已经变了，需要重新合并。审查意见终于回来时，作者正在处理另一项任务，得重新恢复当时的上下文。最初只差一次确认的修改，后来可能多出几轮沟通。

于是，“大家一直很忙”和“东西交得很快”完全可以不是同一回事。忙碌描述的是人有没有被占满，交付速度描述的是成果多久能离开系统。让每个人手里永远都有新任务，有时恰好会把后一件事拖慢。

先看时间花在哪里，再决定加速哪一段

如果一个补丁写了两小时，随后等审查一天、等测试一天，只把写代码压到二十分钟，省掉的依然只是那一小时四十分钟。等待没有变化，总时间就不可能跟着缩成原来的六分之一。

这不是说 AI 没价值。省下来的时间可以用来澄清需求、补充验证、帮助别人审查，甚至让原本不值得做的小改善变得可行。问题在于：如果省下的时间全部变成更多新补丁，后面的压力也会一起增加。

我会先给一项任务标出几个实际时刻：开始做、提出审查、收到第一次有效反馈、通过必要检查、真正可供用户使用。再看其中哪些时段在处理，哪些时段只是等待。无需一开始就建复杂的指标平台，拿最近几项任务画出来，常常已经能看见最显眼的空档。

还要把退回修改算进去。一次审查只花十分钟，但来回五轮、每轮间隔半天，它的影响并不小。只统计审查者点开页面的时间，会把大部分延迟藏起来。排队发生在需求澄清、测试环境或发布窗口时，同样不能把责任都推到审查者身上。

DORA 对在途工作限制的说明也强调，要把从想法到用户的整段过程看见，否则很容易优化了一个局部，却没有动到真正的约束。

来源：DORA 的在途工作说明

小补丁的“小”，是能独立讲清一件事

看到队列以后，常见反应是让审查者更快点。但有些等待，是补丁本身制造的。

假设要给一个资料列表加“按名称查找”。AI 可以顺手加上模糊匹配、历史记录、快捷键、筛选面板，还把原来难看的组件重写一遍。每一项看起来都有用，合在一个补丁里，审查者就得同时判断产品行为、数据处理和旧功能是否被破坏。

我更愿意先把第一步说得窄一点：用户输入名称后，列表只展示符合约定规则的项目；清空输入后恢复；空结果有明确提示。实现这件事所需的代码和验证一起提交。历史记录或布局重做，留给后面的独立变化。

这不是按文件数量硬切。把实现放一份、相关测试放另一份，第一份反而缺少证明。把一个无法单独使用的功能拆成十份，也不意味着交付变快。好的切分单位，是审查者能说明“这一份改变了什么”，合并之后系统仍然处于可工作的状态。

Google 的工程实践把小变更的核心写成一项自洽的改变，而不是固定行数。它也提醒，审查者并没有作者从开工开始积累的全部背景。

来源：Google Small CLs

对 AI，我会把这个要求放进任务边界：先完成一个可验收的行为，遇到顺手优化先列出来，暂不一起实现。这里没有神奇提示词，关键是把“多做了多少”改成“这一份是否足够完整，又是否只围绕一个目标”。

还有一个例外要保留：有些整体替换确实很难安全拆开。强行拆分可能需要临时兼容层，增加读者和维护者的负担。此时应该比较两边的真实成本，提前约定审查时间、验证范围和回退办法，不把“小”当作压倒一切的教条。

让审查者收到证据，而不只收到一堆变化

还是刚才的列表搜索。作者提交时写“已经实现，测试通过”，审查者仍然不知道：通过的是构建，还是输入搜索词后真的出现了正确结果？空字符串呢？已有的排序会不会被重置？

更有用的交接，是把行为和证据对上：本次约定哪一种匹配规则；用哪组中性样例检查正常结果；清空输入怎样恢复；没有匹配项怎样显示；哪些原有行为需要保持。若某项还没验证，就直接写尚未验证。

这几句话不是替审查者下结论，而是减少他重新搜集上下文的时间。截图能说明页面外观，不能证明所有交互；构建成功能说明代码经过了某些静态检查，也不能证明产品规则正确。证据和主张之间差一层，交接时就要把那一层留出来。

AI 当然也可以帮忙检查代码，但让它再说一次“看起来没问题”，不等于多了一份独立证据。如果实现和检查都沿用了同一个错误理解，两遍回答会非常一致。一个更具体的检查问题是：当输入为空时，旧行为应当怎样；这个用例失败时，现有测试是否真的会报错？

Google 的审查指南要求审查测试本身是否有用、代码坏掉时测试会不会失败。这提醒我，测试数量和绿色标记都不能代替对测试目标的理解。

来源：Google 代码审查指南

因此，AI 节省的实现时间，很适合拿一部分来做反例：不仅演示正常情况，还尝试推翻自己的实现。与再生成一个附加功能相比，这往往更能帮助当前任务离开队列。

限制在途任务，限制的是同时欠着多少事

当等待审查的补丁越来越多，可以给团队试一个简单规则：某个阶段达到约定上限，就先帮助已有任务向前走，再启动新的任务。上限要按实际能力试，不存在适合所有团队的固定数字。

假设审查区已满，作者不一定只能闲等。他可以补齐复现步骤，整理测试证据，回应已有意见，协助准备验证环境，或把一个过大的补丁重新拆清楚。只有具备相应知识和权限的人才适合替别人审查；无法直接接手时，也能先消除那些让审查者分神的小障碍。

这里最容易作弊的办法，是把卡片挪到一个叫“待补充”的新栏，于是审查区又空了。实际工作并没有消失。限制在途任务的用意，就是暴露这些尚未完成的承诺，不能靠换个状态名把它们藏起来。

还有一种常见混淆：把优先级高的任务不断插到最前面。偶尔处理紧急问题很正常，但如果每件新事都能插队，原来的任务就会越来越老，承诺的日期也越来越不可信。最好让紧急任务的代价可见：它占用了谁的时间，哪一项原有工作因此后移。否则团队会误以为自己只是多做了一件事，忽略了正在被延迟的另一件。

也别把它变成“不许并行”。互不依赖的工作、有明确交接契约的组件，仍然可以并行推进。需要限制的是超过后续消化能力的投入，以及让人频繁切换、让反馈越来越迟的在途库存。某一段暂时空闲，有时是在为整个过程留出处理意外的余量。

DORA 的小批量实践强调尽早取得反馈，并让每个工作单元可以被验证。我理解它的实际价值是：方向错的时候，桌上只有一小份待修改的东西，而不是已经沿着错误前提写出的整个功能。

来源：DORA 的小批量交付说明

怎样判断调整真的有效

我不会拿“今天生成多少行代码”来验收这类改进，也不会只看合并数量。把一项工作拆成更多提交，就能轻易让数量变漂亮，用户却未必更早拿到东西。

观察时也要避免把不同工作混在一起。改一个文案和重做一段核心逻辑，本来就不该期待相同的完成时间。一个团队本周接了更多难题，平均耗时上涨，并不能直接证明工具变差了。反过来，只挑最容易完成的小修改，也能让看板显得很顺畅，却掩盖了真正重要的任务仍在原地。比较应当围绕相近的任务类型，并保留异常情况的说明。

比较有用的观察是：相似难度的需求，从开始到可用的时间有没有缩短；等待最久的一批任务是否变少；退回修改和上线返工有没有增加。把质量放在同一张桌上，才能避免用仓促放行换一个好看的速度。

可以先挑一类边界清楚的日常修改，试着限制同时进行的数量、缩小单份变化，并在交接时附上与行为对应的验证。过一段时间，看等待究竟少在什么地方。如果只看到写代码更快，而审查和测试仍在排长队，就继续处理后面的约束。

独立开发者也有同样的问题，只是队列里等待的是未来的自己。今天让 AI 同时开五个分支，明天仍然要亲自理解五组改动、判断能否合并。把任务停在“代码已写好”，并不会免掉这份责任。

AI 能把实现这一步变得便宜，这已经很有价值。我更在意的是，省下来的时间有没有换成更早的反馈、更清楚的变化和真正可用的结果。一天开始多少事不难看见；一天少欠了多少事，才更接近交付。