AI流程执行确认平均耗时怎么统计，从哪个环节计时

2026年11月10日

统计AI流程执行确认平均耗时，关键是先定好计时起点：以AI完成执行、把待确认结果提交给确认人的那一刻开始，到确认人给出通过、驳回或要求重做的动作为止。平均耗时等于统计周期内各次确认耗时之和除以有效确认次数，分母排除挂起未确认和重复提交的记录。如果还要看端到端体验，可以另设一个从AI发起执行到确认完成的辅助指标，两个口径分开报告，避免混在一起解释。

Table of Contents

要点总览（TL;DR）

平均确认耗时 = Σ单次确认耗时 ÷ 有效确认次数，单次耗时 = 确认动作时间 − 提交待确认时间。
计时起点取AI执行完成、待确认结果对确认人可见的时刻；终点取确认人提交通过、驳回或退回修改的时刻。
分母只计有明确确认结论的记录，挂起未确认、重复提交不计入，撤回后重提按新一次确认单独计数。
报告均值时同时给出样本量、中位数和分位数，避免少数跨天长尾记录把均值拉高。
分母为零时报告样本不足而非0耗时；确认耗时需与驳回率、返工率配套解读，不宜直接横向比较。

评估目标：确认耗时到底要回答什么问题

确认耗时这个指标，服务的是确认环节的管理判断，而不是衡量AI跑得快不快。它主要回答三类问题：确认任务是否在某个环节积压、当前确认人力配置是否匹配提交量、AI产出质量变化是否让确认负担变重或变轻。把这三个用途想清楚，后面的口径设计才不会跑偏。

要区分两段时间。第一段是AI执行耗时，从任务触发到AI产出结果；第二段是人工确认耗时，从结果提交待确认到确认人给出结论。两段时间的优化手段完全不同：前者靠模型、规则和任务编排，后者靠确认人安排、信息完整度和流转规则。混成一个“总耗时”，出了问题也定位不到具体环节。

本文讨论的范围限定在AI驱动执行之后的确认环节，也就是AI产出需要人来判断对错、决定是否放行的场景。确定性规则自动化——比如固定校验通过就直接流转、不需要人工介入的流程——不产生确认动作，不在本文统计范围内。这个边界要先和团队对齐，否则取数时会把两类记录混进同一个分母。

指标与范围：平均耗时的定义和统计对象

指标定义可以写成一条公式：平均确认耗时 = Σ单次确认耗时 ÷ 有效确认次数。单次确认耗时 = 确认动作时间 − 提交待确认时间。单位统一用小时或分钟，全篇只选一种，不要一部分记录用小时、一部分用分钟。

统计对象是由AI执行产出、并且需要人工确认的工作项或文档版本。一个工作项如果经历多轮确认，每一轮单独作为一条记录，不合并成一条。文档版本按版本号区分，同一文档的不同版本各自计时。

纳入和排除规则建议明确成清单，取数时逐条对照：

类别	规则	对分母的影响
纳入	已提交确认，且有明确结论（通过、驳回、退回修改）	计入
排除	已提交但一直挂起、统计周期结束时仍无确认动作	不计入
排除	同一结果因系统原因重复提交产生的重复记录	只保留一条，其余不计入
单独计数	被撤回后重新提交的记录	撤回那次不计入，重提按新一次确认单独计数

这里最容易出错的是“撤回后重提”。如果撤回和重提都算进分母，同一份结果会被计两次，均值被稀释；如果只算第一次，又会漏掉重提后实际等待的时间。比较稳妥的做法是撤回记录作废，重提作为一条新的确认记录从新的提交时间起算。

数据口径：起算点、终点和字段来源

起算点取AI执行完成、把待确认结果提交给确认人的时刻。这个时刻的标志是状态从“执行中”变为“待确认”，并且确认人已经能实际看到结果。如果系统先落库、后通知确认人，起算点应取确认人可见的时间，否则会把通知延迟算进确认人的头上。

终点取确认人提交通过、驳回或退回修改的时刻。三种结论都算一次有效确认动作，都作为终点。确认人打开页面查看但未提交结论，不构成终点，这条记录继续处于待确认状态。

节点	定义	典型字段来源
起算点	AI执行完成并提交待确认	工作项状态变更日志中“待确认”状态的进入时间
中间状态	待确认、确认中、已确认、退回	状态流转记录，含每次变更的操作人与时间戳
终点	确认人提交通过、驳回或退回修改	确认记录中的结论字段与提交时间
辅助字段	确认人、流程类型、AI任务类型	工作项属性、确认记录操作人

取数前要统一时区和精度。跨时区团队的时间戳先换算到同一时区再相减，精度统一到分钟或秒，不要一条记录精确到秒、另一条只到天。缺失时间戳的记录单独列出，能通过状态日志补全的补全，补不全的标记为无效记录并从分母剔除，同时在报告里注明剔除条数，避免均值看起来干净但样本被悄悄缩小。

在ONES中，AI助手执行的操作会保存为工作项、Wiki页面等内容，输出过程可追踪、结果可审计，这为从状态变更日志和确认记录中提取起止时间戳提供了基础。具体的状态名称、字段命名和报表取数方式，需要在实施时按团队实际配置核对，不同项目的状态流转配置可能不同。

计算步骤：从原始记录到平均耗时

整个计算可以拆成四步，每一步都留下可复核的中间结果。

按统计周期筛选记录。以确认动作时间落在周期内为准，而不是以提交时间落在周期内为准。跨周期的记录归到确认完成的那一期，避免同一记录在两期重复出现。
计算单次耗时。用确认动作时间减去提交待确认时间，得到每条记录的耗时，单位为小时或分钟。
清洗异常值和无效记录。剔除缺失关键时间戳、时间戳倒挂（终点早于起点）、重复提交的记录。异常值的判定规则要事先写定，比如超过统计周期长度数倍的记录单独标注，是否剔除在报告中说明，不能算完再挑。
求和除以有效次数，输出均值，同时附上中位数、样本量和分位数。只报均值容易被少数长尾记录带偏，配套指标能让读者判断分布形态。

分组口径建议至少保留三个维度：按确认人分组，看人力是否集中；按流程类型分组，看哪类流程确认负担重；按AI任务类型分组，看不同产出类型的确认难度差异。分组后每组样本量可能很小，样本量低于一定条数时只报中位数或直接标注样本不足，不强行给均值。

例子：一组确认记录的平均耗时算给你看

假设某统计周期内有6条AI执行后提交确认的记录，时间戳和单次耗时如下（示例数据，仅用于演示算法）：

记录	提交待确认	确认动作	单次耗时（小时）	结论
A	周一 09:00	周一 10:30	1.5	通过
B	周一 14:00	周一 15:00	1.0	通过
C	周二 10:00	周二 16:00	6.0	退回修改
D	周三 09:30	周三 10:00	0.5	通过
E	周三 11:00	周四 11:00	24.0	驳回
F	周五 16:00	—（周期结束仍挂起）	—	未确认

先看分母。6条记录中，F没有产生确认动作，属于挂起未确认，不计入分母。有效确认次数为5次。分子为1.5 + 1.0 + 6.0 + 0.5 + 24.0 = 33.0小时。平均确认耗时 = 33.0 ÷ 5 = 6.6小时。

如果把F错误地按“截至周期结束已等待时长”计入，分母变成6，均值会被拉低到约5.5小时，看起来更快，实际掩盖了确认环节的真实负担。这就是分母规则必须先定的原因。

再看分布。5条记录排序后为0.5、1.0、1.5、6.0、24.0，中位数为1.5小时。均值6.6小时明显高于中位数，说明E这条24小时的记录把均值拉高了。报告时同时给出“均值6.6小时、中位数1.5小时、样本5条”，读者才能判断多数确认其实很快，慢的是个别长尾。若只报均值，容易得出“确认普遍要六七个小时”的错误印象。

解读与限制：均值能说明什么，不能说明什么

均值适合看整体水位和趋势，不适合描述单条记录的典型体验。确认耗时的分布通常右偏，少数跨天、跨周末的记录会把均值抬高。因此报告均值时应同时给出中位数和分位数，比如75分位、90分位，用分位数判断“大部分确认在多长时间内完成”，用均值观察总量变化。

分母为零时要报告样本不足，不能写成0耗时。统计周期内没有产生任何有效确认，说明这个周期没有可评估的确认活动，0小时会被误读为“确认极快”。同样，某个确认人分组只有一两条记录时，均值不具备比较意义，应标注样本量或直接不给结论。

不同AI任务复杂度、不同确认人数量下的均值不宜直接横向比较。一个需要多人会签的流程和一个单人确认的流程，耗时结构本来就不同；复杂产出需要更长的判断时间，这是合理差异，不是效率问题。做对比时至少控制流程类型和任务类型两个变量。

确认耗时短也不等于确认质量高。快速点通过可能意味着确认人没有认真看，也可能意味着AI产出质量确实稳定。要判断质量，需要把确认耗时和驳回率、返工率、退回后二次确认耗时放在一起看。确认耗时下降而驳回率上升，往往说明确认被草率放行；确认耗时上升而驳回率下降，可能是确认更审慎，也可能是产出质量下降导致判断变难。

最后，这个指标用于定位问题，比如发现某类流程确认积压、某个环节等待过长，再去看人力安排和流转规则。把它直接当作个人绩效的唯一依据，会诱导确认人快速点结论，反而破坏指标本身的可信度。指标的价值在于暴露流程中的等待和返工，推动改进确认环节的协作方式。