省下的时间卡在轮与轮之间

编码层的人工介入已经压到每个需求半轮，交付周期却只快了一到三成。省下的时间没有消失，它停在「产物已交付、接手还没发生」的那段空档里。

一个业务需求，把编码交给 AI 之后会发生什么：AI 在一小时内交出一版代码，然后就没有然后了。评审在开另一个会，PM 在跟另一条需求，这份代码在群里躺了三天。三天里 AI 随时可以继续干活，但它不知道可以开始——因为还没人看过上一版。

读完你能回答：

• 为什么编码提速没能转化成交付提速？
• 怎么把「等待」量出来，而不是靠感觉？
• 静默了几天的需求，什么时候该催、什么时候不该催？

编码已经不是瓶颈了

先看一组实测。某团队在 Harness 工程较完善的业务场景里，编码层的人工介入已经压到平均每个需求约 0.5 轮——人几乎不需要下到代码里去改。按这个投入，如果交付周期主要由执行决定，交付应该快出好几倍。

实际只快了一到三成。39 个已上线需求，按复杂度分四档，四档都有缩短，但幅度离「数倍」差得很远，交付仍然以天、周计 tmall-efficiency。

省下的时间去哪了？答案在评估单元里。过去按「阶段」看研发——需求、开发、测试各有负责人；AI 承接方案到部署之后，人通过「提要求 → AI 交付 → 验收或纠偏」让结果逐轮收敛，接手方可以是任何角色。人还并行参与多条需求：AI 做完的时候，接手人可能正在别处。

所以评估要从「阶段」细化到「轮」。一轮从人的输入开始，到 AI 交付、人接手给出下一步输入为止：

周期 = Σ(每一轮：AI 做的时间 + 人回来的时间) + 外部等待

这个式子的两半分属两类工作。AI 做的时间和轮数归 Harness 与业务知识——一轮做得准不准、要来回几轮，取决于模型、工具链、技能和沉淀的业务知识。人回来的时间和外部等待归协作——产物交付之后需要谁判断、何时接手、是否值得此刻推进，取决于组织怎么安排接手。

两半都决定周期。只优化前一半，就是上面那组数据的样子。

把等待量出来：流动效率

没有一个数字，讨论就会停在「感觉最近挺忙的」。这里给一个零填报、每天可算的指标：

流动效率 = 流动天 ÷ 流逝天。 一天里只要有人发言、AI 回复或工具调用，这条需求就算「在动」；连续没有，就是停下来了。

一条需求十四天里动了七天，流动效率就是 0.5。要小心它回答的问题：它衡量活动连续性，不是有效工时，也不是任务完成比例——但它不需要任何人填报，每天都能算，是后面所有分析的起点。

有了这个数，就能问「什么决定周期」。实测把已完结需求按流动效率分成低、中、高三组，交付周期中位数分别约 22 天、14.5 天、8 天；控制复杂度、改动规模与建群时机后，流动效率在若干候选因子中偏相关绝对值最大 tmall-efficiency。

这些是观察性结果，样本非随机，流动效率与周期还共享时间信息，所以不能据此认定因果，也不能把组间差异解释成「提醒带来的收益」。但它足以支撑一个动作层面上的判断：在编码已经不怎么需要人的场景里，继续压执行侧的收益远小于去压缩接手等待。

静默只是线索，不是判据

知道了等待是瓶颈，最直觉的做法是「等太久就催」。这里有个踩过的坑值得说：某团队的第一版群内提醒只看静默天数，到点就发模板消息，上线十五分钟就撤了——因为对方昨天刚说「下周再看」，系统今天照常来催。

所以静默只能当排查入口。发消息之前，先把最近一次交接还原出来：上一份产物交给了谁、对方还缺什么、有没有新的安排。

还原分三步，每一步都在缩小范围：

第一步，在等谁。 看静默前 AI 最后说的那句话。261 段静默里最常见的是「等人回应」，占 66%——AI 已经提交了方案、代码或测试报告，后面需要一次评审、验收或新指令；其余是补材料、评审或排期、权限与环境 tmall-efficiency。但最后一句话只保留了发起交接的现场，未必包含接手的结果，所以它只是待核对的线索，不能直接变成发给某个人的催办。

第二步，停在哪个阶段。 同样是「等人回应」，停在需求讨论阶段和停在测试阶段要核对的材料完全不同。需求讨论阶段若被归为等需求侧，先查 PRD 里的业务口径和约束是否明确；进入预发验证阶段，查的可能是权限与环境——有一份真实日报记录过：需求已在开发，但缺 Arthas 权限，预发验证做不了。此时问「开发完了吗」，问不到点上。

第三步，缺的到底是什么。 按「对下一步的阻碍知道多少」分两类：已经确认具体障碍的是卡点（缺权限使验证无法执行、缺业务结论使方案无法定稿）；已有交付物但看不出接续、也没确认障碍的是悬置，此时缺的是对当前安排的了解——是否有人在群外处理、是否另有排期。区别不在哪条需求沉默得更久，而在你知道多少。

这一步的产出不是一句催促，而是一份带依据的交接记录：最近的产物、未完成的动作、相关角色、已有约定。

三种触达并行，不是逐级加压

交接记录进入产品后，要按协作范围组织。一个明确问题可以定向跟进；一条需求的接续信息可能散在多个角色手里；同一个人还需要看到多条需求的整体进展。三种方式并行：

日报里最要紧的是第一层的筛选条件：「需要你介入」最多五条，每条必须同时满足新鲜（一天之内）和核验（读过后续上下文，确认还没被别人推进）。「你没回」不等于「还等你」——别人接手了、聊过去了、已经推进了，规则测不出来，必须读后续对话；无法核验的事项宁可不列。

这里有一条容易被忽略的纪律：知晓只是回执，自行接手是责任交接，问题真正解除才算解决。 三者对后续处理不同——点了「知晓」的还要继续看，接手了的停止催促，解除了的才关闭；关闭要有证据。回放里还见过另一种漏法：同一个问题被反复提出、被转派的人一直没接，群里其他话题却聊得很热闹，所以计时的对象是这个问题，不是这个群。

什么时候算真的有收益

效果评估要分两步走，不能一步跳到位。

先看交接记录是否发生了有效推进：材料补齐、必要决策、验收结论，与回执、责任交接、新排期分开记录，不能把所有回复都算作收益。

再看这个推进是否由提醒带来：即使出现了有效推进，也可能只是排期到了、群外工作完成了。要回答这个问题，需要同期未提醒的需求作对照。

这一步最容易被跳过，而跳过的代价是把运气当成能力。同一个团队给出的参照数据是：261 段静默里 53% 持续两三天、32% 持续四到七天；被标为「等人回应」的记录里，64% 后来自行恢复活动，恢复时长中位数 3 天、四分之三在 5 天内 tmall-efficiency。既然多数等待会自己好，任何「提醒有效」的结论都必须先扣掉这部分自然恢复。

该团队对这一点的表述很克制：已经形成等待项的判定、触发与收口机制，但还没有证据说明它缩短了多少交付周期，后续要靠同期对照来判断收益是否值得新增的打扰。这种自我限定比一个漂亮的百分比更可信。

代价与检查

这套做法要求每条需求有可追溯的活动记录（谁在什么时候说了什么、交付了什么），并且要读后续对话来核验——纯凭规则测不出「别人已经接手了」。对只跑一两次的内部脚本，这套开销完全不划算。

检查方法：挑一条已经交付但还没验收的需求，问三个问题——你能说出它现在是「卡点」还是「悬置」吗？你说得出上一次交接把什么交给了谁吗？如果现在要推进，你知道该找谁、以及他缺什么吗？三个都答不上来，说明你的瓶颈可能已经不在执行侧了，而你还不知道。

判断的落点因此很明确：执行与协作要一起改。 Harness 让产物可靠、可自动接续，协作机制让产物及时进入验收、决策与后续执行。只做前者，局部提速就停在局部；真正的交付能力提升，是需求不停在任何一个人的手里。