天猫数字员工（效能篇）- 多角色场景下的 AI 研发流转效能分析

本文分析了天猫技术数字员工在多角色 AI 研发场景下的流转效能。数据表明，尽管 AI 已大幅减少编码环节的人工介入，但交付周期的缩短幅度有限，主要瓶颈在于各轮次交接间的等待耗时。为此，文章提出通过“产物驱动”与“协作调度”双管齐下提升流动效率：一方面推进产物标准化与质量门禁以实现自动接续；另一方面针对仍需人工判断的环节，通过卡点私聊跟进、群内上下文提醒及个人日报聚合等主动推进机制，精准诊断并消除交接缺口，从而将局部执行提速转化为团队整体交付能力的提升。

前言

天猫技术正在建设统一的 AI 端到端交付架构：数字员工提供统一入口与运行时，驻进需求群承接交付；各业务域按需装配并持续沉淀自己的知识、技能与子 Agent。它与产品、前端、后端、测试共享上下文，接需求、写方案、调度 Agent、跟进交付，像一位全程在场的同事。目前已经在天猫技术的所有业务线进行落地推广，月均活跃需求交付100+。

导读｜本文基于天猫真实业务需求的交付数据，分析 AI 研发效能的影响因素，并针对协作中的交接等待，给出提升流动效率的数字员工实践方案。

我们先从交付记录分析周期差异，再区分可自动衔接的环节与必须保留的人工判断。本文重点是后者：怎样诊断交接缺口，通过卡点跟进、群内提醒和个人日报组织协作，并验证是否带来有效推进。产物标准化与自动质量门禁可以减少重复交接；本文关注当前尚未自动贯通、以及仍需业务判断的部分。

本文为此系列第三篇内容。

第一篇：《天猫数字员工（协作篇）- 研发的暗物质与 AI Native 组织协作》

第二篇：《天猫数字员工（实践篇）- 接管全链路：交付能力与技术拆解》

数字员工以钉钉为协作入口。每条需求对应一个场景群，产品、设计、开发、测试与它共享同一份需求上下文；从 PRD、设计稿和技术方案，到编码、测试、发布与复盘，产物都回到群里。团队不用更换协作工具，@ 它即可发起任务，私聊也能使用同一套能力。

找到入口 → 提出需求 → 确认方案 → 执行验证 → 验收交付 → 状态回写；

六个节点均取自真实需求场景

周期要重新算：从阶段到轮

▐  2.1 研发模式变了，评估单元也要变

传统研发按阶段接力，需求、开发、测试各有负责人。数字员工承接方案到部署后，人通过"提要求—AI 交付—验收或纠偏"让结果逐轮收敛，接手方可以是任何角色。人又并行参与多条需求：AI 做完时，接手人可能正在别处工作。评估因此要从"阶段"细化到"轮"，看清每次交付后的等待。

左：按阶段观察角色交接；右：细化到每轮执行 a 与接手等待 w；

底：沿需求关键路径拆解周期，并行分支不重复相加

沿需求的关键路径，分别记录每轮执行与接手的时间：

周期 = 每一轮里（AI 做的时间 + 人回来的时间）的总和 + 外部等待

一轮从人的输入开始，到 AI 交付、人接手给出下一步输入。旁听纪要、日批等自发活动不计入；轮外的外部等待单独记录，避免重复。并行任务只沿决定完结时刻的关键路径计算，不能把各分支耗时直接相加。

▐  2.2 模型：通过 Harness 缩短轮数，通过协作缩短等待

式子里的时间分两半。AI 做的时间和轮数归 Harness 与业务知识：一轮做得准不准、要来回几轮、人还要不要下到编码层，取决于模型、工具链、技能和沉淀的业务知识，实践篇、资产篇讲的都是这一侧。人回来的时间和外部等待归协作：产物交付之后需要谁判断、何时接手、是否值得此刻推进，取决于组织怎么安排接手。两个方向都决定周期，具体怎么做放在第 2 节。要比较两边各占多少、哪个因子真正起作用，先得能把它量出来。

绿箭头指向 AI 做的时间与轮数，橙箭头指向人回来的时间与外部等待；

两侧都是周期的组成部分，图内比例为示意

一条需求的十四天长什么样。每一天，只要有人发言、数字员工回复或工具调用，就算这条需求在动；连续没有，就是停下来了，停的时候在等谁，从数字员工最后说的那句话里读出来：

14天中7天有可见活动，流动效率为0.50；系统拼接的合成轮不计入。

它衡量活动连续性，不是有效工时或任务完成比例

这条需求十四天里动了七天，流动效率 = 流动天 ÷ 流逝天 = 0.5。它回答的只是"需求在不在动"，不是有效工时，也不是完成比例；但它零填报、每天可算，是后面所有分析的起点。

一条需求这样算清楚之后，就可以放到一批需求上去问：什么决定周期？先猜——把可能影响周期的量都列出来，从数字员工沿交付过程留下的记录里能提取七个候选因子：

左：数字员工沿交付过程自动留下的记录；中：七个候选因子各自怎么算、回答什么问题；

右侧标签是可能的改进方向，不是责任划分或投入排序

▐  2.3 数据验证：等待占据周期主体，流动效率是关键因子

模型到此给出两个待验证的判断：协作一侧占据周期主体，流动效率是关键因子。下面用真实数据分别检验。

验证一：周期的主要构成落在协作一侧。 先看 Harness 这一侧。在成熟业务场景、Harness 工程较完善的条件下，编码层平均约 0.5 轮人工介入，人几乎不再需要下到代码里改。按这个投入，如果周期主要由执行决定，交付应该快出好几倍。

实际快了多少？下图把数字员工参与的需求和历史基线放在同一把尺子下比：从首次代码提交到上线，按复杂度分层。看点是两句话：整体确实快了，这组样本里四档都缩短；但幅度只有一到三成，离"数倍"的量级差得远。 交付仍然以天、周计。执行层几乎不需要人了，周期却只快了这么一点，省下的时间去哪了？

历史样本对照：数字员工组39个已上线需求，部分层样本较少，且使用并非随机分配。图内降幅只描述这组样本，不外推为普遍提效；日历周期也不等于模型执行时间，不能与人工介入次数直接换算

从活动记录中寻找等待线索。 把已完结需求验证期的每一天按活动归类，返工与验证只占一小部分，沟通与静默占比较高，提示交接等待值得进一步关注。这个分类用于寻找线索，不能直接测量 AI 执行耗时，也不能量化执行提速后有多少时间转为等待：

保留早期天粒度归类图，不是 AI 运行耗时的直接测量；图中9%/91%不能用来精确拆分执行与等待。下方为另一批静默记录的主要归因，与后文261段样本口径不同，不可拼算；模型分类未经人工抽检

验证二：控制变量后，流动效率与较短交付周期的关联较强。 控制复杂度、改动规模与建群时机后，流动效率在图示因子中的偏相关绝对值最大；交付深度和纠错返工轮的区间也不跨零。把已完结需求按流动效率分成低、中、高三组，交付周期中位数分别约 22 天、14.5 天、8 天。流动效率与交付深度的偏相关分别约为 −0.55、−0.42，其他因子的结果见图：

n=29；左侧为控制变量后的偏相关与90%重采样区间，右侧为同一样本按流动效率分组的周期中位数，不是控制变量后的收益。两侧均为观察性结果：样本非随机，流动效率与周期共享时间信息，不能据此认定因果关系，也不能把组间差异解释为提醒效果。纠错负相关不等于多返工会更快

多角色协作里，一次关键接手的延迟，可能把等待传到整条依赖链上。 这就是本文余下篇幅要处理的那一半：Harness 方向的产物标准化与质量门禁在 2.1 简述，协作方向从 2.2 起展开。

除了继续提升 AI 的交付能力，我们把优化落到交接上：减少重复核对，让必要的评审、验收和发布判断及时接上。

怎么让需求转起来

规则与授权明确的交接，尽量由产物直接触发；仍需人判断的交接，把材料与接手安排组织清楚。 例如 PR 合入后可以触发流水线，而报告中的风险是否接受、何时发布，仍可能需要相应角色确认。同一条需求中，这些做法可以配合使用。

目标机制与当前边界示意：标准化产物经质量门禁后，在明确规则与授权内接续；未自动覆盖的检查与必要业务判断仍需组织接手，不代表已全量实现。

▐  3.1 产物驱动：减少不必要的人工交接

产物标准化要解决的，是下一环节能否直接使用这份产物。 以代码变更接预发验证为例，仅有一句“测试通过”还不够：要知道测的是哪个提交、哪个环境，覆盖了什么，失败项与执行证据在哪里。信息没有约定清楚，接手人就只能重新询问和核对。

Harness 向交付流程延伸，需要把这些约定变成可执行的契约：

• 产物契约：关联需求、代码版本与目标环境，保留验证范围、结果、失败项和证据入口。标准化的不只是格式，还包括可追溯性与下一步所需的信息。

• 质量门禁：校验产物完整性、版本一致性及约定的质量条件。检查失败或证据不足时返回补齐、修复与重验，不把“报告已生成”当成“可以继续”。

• 接续规则：明确门禁通过后能触发什么动作、由谁执行、需要什么权限，以及成功终态。质量合格不等于获得发布授权；超出规则的判断仍交给对应角色。

把这三项约定连起来，产物的下一步才不需要靠人反复转述：

接预发验证的设计示意：校验失败先补齐、修复与重验；规则或授权未明确先找责任人确认，结果回写后仍须校验。质量达标不等于获得发布授权，不表示全链路已经自动化

当标准、门禁与授权能在覆盖范围内稳定执行，重复追问材料、人工搬运结果和重新发起任务，就有机会从流程中消除。产物既是本轮的交付，也是下一环节可消费的输入。“PR 合入触发流水线”就是一个例子；这类以版本化产物衔接流程的机制，也见于 Anthropic 的 AI 原生软件开发手册。

当前的限制是覆盖与贯通还不完整，不是这些方向不重要。 我们已有业务知识与技能装载的实践，但不同业务的产物约定、质量规则、验证环境和操作授权，尚未连成一条稳定的自动交付链。不能把门禁未通过的产物往后推，也不能假设一次技术检查已经替业务作出了验收或发布决定。

因此，减少交接等待有一条更根本的路径：把可重复检查的条件前置进 Harness，让合格产物在授权内自动接续。协作机制则承接当前尚未覆盖的检查，以及不能由既定规则代替的业务判断。

▐  3.2 协作调度：接续仍需人参与的环节

需要人参与的交接，要区分尚未自动化的检查与需要责任人判断的事项。前者应持续沉淀为标准和门禁；后者如业务口径、风险接受、发布窗口，仍需相应角色给出结论。数字员工负责准备材料、保留待处理事项并读取后续回应，让接手人不必重新寻找上下文，而不是代替他作出决定。

需要人判断时，产物、问题和回答沿同一条需求接续：

协作时序示意，沿用实践篇的主子 Agent 与共享会话视角。图中展示信息怎样回到执行上下文，不表示收到回复就自动验收，也不预设固定角色流水线。

本文重点展开这部分协作工程。 我们把这种持续核对进展、组织必要接手的工作方式称为“主动推进”。它与产物驱动配合：能按规则继续的环节直接衔接，需要人判断的环节保留判断权，协作系统负责把依据与待办送到合适的位置。

要组织接手，先得知道等待是否真实：是缺少某项条件、尚未有人接续，还是已经有了新的安排？只凭群里多久没人说话，还不足以选择动作。

主动推进前，

先确认需求在等什么

只凭群里多久没人说话，还不足以选择动作，原因有两个。一是群聊看不到全部工作：测试可能在群外进行，发布可能另有排期，几天没动静不等于没人在做。二是静默的原因不同，该做的动作也不同：缺一份材料和忘了验收，不该用同一句话去催。

我们在这里踩过坑。第一版群内提醒只看静默天数，到点就发模板消息，上线十五分钟就撤了：对方昨天刚说"下周再看"，系统今天仍会照常催促。从那以后，静默只当排查的入口；发消息之前，先把最近一次交接还原出来：上一份产物交给了谁，对方还缺什么，有没有新的安排。 这一节讲怎么还原：先看在等什么，再看停在哪个阶段，最后落到缺的到底是什么。

▐  4.1 在等什么：静默记录里的交接线索

先看等待长什么样。下面是一批需求的十四天活动矩阵：每一格是当天有没有活动，空格连成一段就是一次中断；中断从哪一天开始、当时交付到了哪一步，是核对的起点：

从原图对应的2026年8月29日历史快照选取6条需求，名称泛化；每格仅表示当日有无活动记录，距图末按最后活动日期计算。交付状态单列，“等人回应”为待核验线索，不能直接判定卡点或弃用。

每一段中断，取静默前数字员工最后说的那句话来判断在等谁。最常见的是"等人回应"，占 66%：数字员工已经提交了方案、代码或测试报告，后面需要一次评审、验收或新的指令。其余是补材料、评审或排期，以及权限、环境等不同线索：

n=261，剔除按静默超过十天推断为弃用的记录；按段数而非时长统计，沿用原图显示比例。归因与弃用均为自动判定，尚未人工核验

但最后一句话只保留了发起交接的现场，未必包含接手的结果，测试可能已经在群外进行，发布也可能另有排期。所以"等人回应"是待核对的线索，要连同交付物和后续对话一起看，不能直接变成发给某个人的催办。

▐  4.2 停在哪个阶段：按阶段核对交接材料

知道了在等什么，还要知道停在哪个阶段。同样是"等人回应"，停在需求讨论阶段和停在测试阶段，要核对的材料完全不同。把静默开始时的需求状态和等待分类交叉起来，排查方向就具体了：

261 段过滤后静默中，156 段有状态记录，另有 105 段未纳入此图。单元格为段数，着色按行内占比；状态与分类用于缩小核对范围，不能直接决定推进动作。模型分类未经人工抽检

需求讨论阶段，25% 被归为等需求侧。此时先查 PRD 中的业务口径和约束是否明确，待确认的问题有没有得到回答。若方案还依赖一次业务决策，继续催开发进度就找错了对象。

进入开发和预发后，要看代码、执行记录及验证条件。预发验证阶段，21% 被归为等权限和环境。一份实际日报就记录过这样的情况：需求已在开发，但缺少 Arthas 权限，无法完成预发验证。需要补的是权限；只问"开发完了吗"，无法解除这个障碍。

测试产物已经交付时，检查对象又变了：报告里的失败项是否仍待处理，验收结论是否已给出，后续对话有没有约定发布时间。"报告已提交"只确认了交付动作，接手情况要从后续记录中找。 同一个"等人回应"标签，到这里才被还原成具体问题。

▐  4.3 缺的到底是什么：卡点与待接手

分类和阶段都只是线索，最后要落到一个能核对的问题上：这条需求现在缺的到底是什么。 按"对下一步的阻碍知道多少"，等待分成两种：已经知道缺什么的，是卡点；还不知道接下来怎么安排的，是待接手。区别不在哪条需求沉默得更久：

结构示意：锁表示已确认的条件缺口，问号表示接续安排尚待核对；虚线表示尚未衔接，不表示等待时长。两种情况都需保留交接依据，已有明确排期不能判成无人接手。

• 卡点：已经确认具体障碍。例如缺少权限使验证无法执行，缺少业务结论使方案无法定稿。诊断需要把障碍与受影响的动作对应起来，并核对谁有能力解除它。

• 悬置（待接手）：已有交付物，但记录中尚未看到接续，也未确认具体障碍。此时缺的是对当前安排的了解：是否有人在群外处理、是否另有排期，或确实还没有人接手。

两种情况的诊断都要留下最近的产物、未完成的动作、相关角色和已有约定。查到明确排期，说明这段等待已有安排；查到具体障碍，才有依据提出补齐条件的动作；尚不清楚的部分保留为待确认问题，不能用模型的分类标签补成事实。

诊断的产出，是一份带依据的交接记录。 下一节讲怎么把它送到合适的人手里，并让之后的回应、排期和处理结果持续更新同一条记录。

需求流转优化实践

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

交接记录提供共同依据：具体问题定向到人并持续跟进，需求安排回到群里共同确认，多条需求按个人聚合；回应与新约定回写原记录。三种方式并行，不是逐级加压的催促链

这些方式可以并行：群内确认验收安排，私聊跟进一个权限问题，日报汇总与本人有关的进展。日报提供跨需求视野，不是催办的前置步骤。

触达范围与执行授权分开判断。 数字员工可以整理材料、提示待处理事项；代办具体操作需要委托与确认，验收和业务取舍仍由相应角色决定。权限、环境问题的申请与处理遵循平台流程，材料补齐和责任接手仍可纳入协作跟进。

呈现、提醒、催办与代办分别约束触达和授权；更强的动作需要独立依据，不是上一种方式无效就自动升级。

▐  5.1 卡点推进：把具体问题私聊给能解决的人

先讲一条需求。数字员工接到需求群里的交接，准备开始出方案，发现 PRD 还没有给到：群里只有一句口头描述，业务口径、边界和验收条件都在那份没到的文档里。它在群里询问后没有人回应：不是没人看见，是这份材料只有提需求的那位同学能补，而他当时正在别的群里忙。需求就停在了这里。

这种停和"忘了"不一样：缺什么、缺在谁那里、为什么缺，群里的上下文已经说清楚了。 数字员工在工作时段里等了十二个小时没有回应，就把这件事记成一条卡点：问题是什么（交接缺少 PRD），需要谁做什么（对应处理人补齐交接材料），依据是群里的哪句话。然后它不在群里重复提醒，直接私聊那位同学一条消息：这件事卡在你这里，缺 PRD，补上就能继续。

私聊卡片如下。待处理事项、谁提出的、已经挂了多久放在一起；接收人可以点「我已知晓」，也可以直接反馈这不是他的事：

私聊卡片为独立测试截图，人员与群名已打码；“我已知晓”只记回执，不能作为问题已解决的证据。

私聊发出之后，跟进并没有结束。这条卡点同时挂在需求群的协作看板上，谁都能看到它在等谁；后面群里的对话数字员工继续读——材料补上了、有人明确处理了、或者负责人说一句"这个我来跟"，它就相应更新状态，处理完的自动消失，不用人手动关。看板与后续回应的样子如下（示意，非同一条实录）：

另一个真实事项的看板、回应与概要记录，人员和内部标识已打码；不与前图 PRD 私聊测试串成同一条实录。这里记录的是责任交接，不是开关已经打开。

这里有三个判断要分开：知晓只是回执，自行跟进是责任交接，问题真正解除才算解决。 三者对后续的处理不一样：点了"知晓"的还要继续看，接手了的停止催促，解除了的才关闭。关闭要有证据：材料补齐、明确处理，或者后续动作证明障碍已经不在；误判和过期单独记，不算解决。回放里还见过另一种漏法：同一个问题被反复提出、被转派的人一直没接，群里其他话题却聊得很热闹。只看最后发言时间会把它漏掉，所以计时的对象是这个问题，不是这个群。

产品设计示意：知晓、接手和解决分别影响后续跟进，不把所有回复都当作问题已解决。

私聊是定向触达，不是加压：有提出来源，遵守免打扰、去重和个人频次上限；不向主管升级，不做催办排行；需要数字员工代办时，先取得委托和确认。处理人看完应当知道该做哪件事，而不是只知道有人在催促。

▐  5.2 群内提醒：让相关成员接上这条需求

另一种停没有任何障碍。数字员工做完了一个动作，比如跑完测试、交了报告，接下来该有人验收、给下一步。但评审在忙别的，PM 在跟另一条需求，群主也没注意到，几天过去，这件事便停留在群里，没有人再想起。

一条真实的需求就是这样：测试报告已经交付，之后几天群里没有任何动静。数字员工在群里提了一句：报告已经完成，是否需要确认验收。需求负责人想起来了，把测试负责人拉进群，明确了核销、top 核销和门店分账三块的测试范围，说会进一步说明测法。一条停了几天的需求，因为这一句重新动了起来：找到了具体接手人，明确了分工：

原始截图摘录与拼接：仅裁剪和遮挡人员信息，消息内容未改写；第二屏保留具体 @ 对象并打码，使用新提供的“等验收5天”截图。素材来自不同时间，不作为连续时间实录；对接测试负责人不等于测试完成或验收通过，单次后续推进也不能直接归因为提醒的效果。

这就是群内提醒要做的事：把最近的交付物、待确认的事项和已有的安排放进一条消息，让相关的人不用翻历史就能回答"现在做到哪了、下一步谁来接"。 它 @ 一个默认的接手人，但发在群里，谁都可以接。

什么时候说，比说什么更难。 静默本身只触发检查，不直接触发发消息：探测先找出连续几个工作日没有可见推进的需求，再把最后的交付物、最近的真实对话、当前状态和今天的日期一起交给数字员工核对。对方已经约了延期、需求已经结束、近期有人接手了，这些情况它都会选择不说。第一版没有这一步，就是第 3 节开头那次十五分钟撤回。试跑时还出过另一种错，一条提醒把五天前纪要里的"任务仍在运行"写成了当前状态。所以提醒必须带上今天的日期，不能把旧纪要里的进行态原样搬过来。

调度规则约束工作时段、范围、冷却期和频次；开不开口、跟谁说、缺什么信息，由数字员工判断。最后发出去的只是一条普通的群消息，大家可以直接用自然语言回。反馈改变的是后续安排：回"过几天再说"或给了排期，就按约定等，到期再看；回"已完结""无需推进"，这条等待结束；补充了进展或换了接手人，更新上下文和处理人；仍然没人回，重新检查需求状态，不能就此断定某个人有问题。

产品设计示意：反馈改变下一次跟进；虚线回到最新情况核对，不表示自动重发。

▐  5.3 日报：让等待先被看见

日报按个人聚合多条需求的进展与等待。 每个工作日固定时刻，每个人收到一份按需求组织的日报，不是群列表，也不是待办清单，组织单位是需求。它分三层。第一层「需要你介入」：读的就是等待项里等你的那些，最多五条，每条必须同时满足新鲜（一天之内）和核验（读过后续上下文，确认这件事确实还没被别人推进）："你没回"不等于"还等你"，别人接手了、聊过去了、已经推进了，规则测不出来，必须让模型读后续对话；无法核验的事项宁可不列，也不放入一条已经过时的事。

第二层「活跃需求进展」：每条活跃需求三行：本期完成了什么、到什么阶段、还差什么，未关闭的等待项在等谁直接列在"还差"里。第三层一句汇总：几个在推进、几个新近停滞、其余无事；没有列出的，就是当前无需处理的。有连续性时多一行回环："昨天说还差的权限，今天解了。"

日报先让人扫过多条需求，再围绕关心的那一条继续追问。以下以订单查询工具的取件码字体调整为例：UAT 已完成，但代码提交、主预发部署和后续验证仍待推进。日报把下一步放到具体需求下面，追问时沿用同一份上下文：

场景化重排：左侧依据真实日报精简进展与下一步，右侧为按编号追问的能力示意，并非原始对话；需求名泛化，人员身份已打码。不表示问题已解决，也不展示全部日报筛选规则。

日报提供个人视野，不据此自动启动催办。某个具体问题是否需要私聊、某条需求是否需要群内提醒，仍分别核对事项与最新安排。免打扰和退订是一等公民，不希望接收的人不会收到任何推送。

▐  5.4 效果怎么看

效果评估先从交接记录判断是否发生了有效推进，再判断是否由提醒带来。 私聊、群内回应和后续交付会更新这些记录；回执、责任交接和新的排期要与材料补齐、必要决策、验收结论分开记录，不能把所有回复都算作收益。

即使出现了有效推进，也可能只是排期到了、群外工作完成了。提醒是否提前了接手，还需要同期未提醒的需求作对照。

历史记录中，261 段过滤后静默有 53% 持续两三天、32% 持续四到七天；其中被标为“等人回应”的记录，64% 后来自行恢复活动。在已恢复的记录中，恢复时长中位数为 3 天，四分之三在 5 天内。这些记录提供了等待时长的参照，不能替代同期未提醒的对照组。

左：261 段静默的时长分布，已剔除按静默超十天推断为弃用的记录；右：仅统计其中被标为“等人回应”的记录。分类未经人工抽检，恢复活动不等于需求完成；历史比例不是提醒的因果效果

当前已经形成等待项的判定、触发与收口机制，但还没有证据说明它缩短了多少交付周期。 后续将通过同期对照，检查提醒是否促成更早的材料补齐、决策或验收，同时记录误报、重复提醒与退订，判断收益是否值得新增的打扰。

AI 的产出，怎样成为团队的交付

回到开头的落差：编码层的人工介入压到每个需求半轮，周期却只快了一成六。省下的时间没有变成周期，是留在了轮之间，产物已经交付，接手还没有发生。 本文走的就是这一半：把等待还原成可核对的交接缺口，再用卡点推进、群内提醒和日报，把它送到该接手的人眼前。

Harness 工程在改变交接的另一半。产物有统一契约，质量门禁能自动校验，授权范围内的下一步就有机会直接执行。但"测试通过"与"今天发布"仍是不同的判断。Harness 让产物可靠、可自动接续；协作机制让产物及时进入验收、决策与后续执行。 两者共同减少交付中的断点，业务时机与风险取舍仍由人决定。

回头看，三个产品依赖的是同一份东西：每条需求此刻停在哪、缺什么、谁来接、有过什么约定。维护这份记录、按它推进，原本是项目经理的工作；现在它从执行里长出来：提交、部署、测试的回执是系统给的，进展、障碍和新约定是从对话里读出来的，人不再填账。这就是 AI Native 项目管理的起点：从工作现场取得事实，把有依据的判断送回工作现场。 系统回执与对话陈述要区分来源，每个判断都要能追溯到证据。

演进方向示意：依据项目管理分层设计重绘，保留事实采集、跨时间研判和行动回流的关系，不表示全部能力已实现；业务验收、关键取舍与执行授权仍需相应责任人确认。

再往前一步是跨时间的研判：报告何时交付、哪个条件尚未满足、谁已经接手、排期为什么改变，放在同一条时间线上，对照该业务的历史节奏找异常；管理系统要保留团队作出安排的理由，才能区分正常等待与需要介入的偏离。研判的结果回到协作：缺权限就把依据交给能处理的人，有发布约定就按约定核对，团队给出新结论就更新同一条记录。这是演进方向，跨时间研判与自动接续尚未全部实现，实际周期收益仍待验证。

对准备落地的团队，可以从一条需求试起：把执行回执、人的约定和后续结果串起来，检查每个状态有没有依据、每次跟进是否尊重最新安排；再扩展到跨需求的风险识别与协作调度。

需求的周期由每一轮 AI 做的时间和人回来的时间构成。执行提速之后，剩下的时间在轮之间。局部提速要成为团队的交付能力，需要执行与协作一起改变——让需求不停在任何一个人手里。

团队介绍

本文作者珈文，来自淘天集团-天猫品牌行业前端团队。我们团队负责消费电子、3C数码、运动、家装、汽车、奢品、服务等多个行业的项目。我们定位自身不局限于“传统”的前端团队，在AI、3D、工程化、中后台等领域，我们有着持续的探索和实践。

¤ 拓展阅读 ¤

3DXR技术 | 终端技术 | 音视频技术

服务端技术 | 技术质量 | 数据算法