统计AI流程执行确认平均耗时，起算点应定在AI完成执行、把待确认结果提交到确认环节并产生待确认记录的时刻，终点定在确认人给出明确结论并写入系统的时刻。平均耗时等于统计窗口内各次确认耗时之和除以有效确认次数。若从AI任务发起或执行开始计时，执行时长会混入确认耗时，指标就失去解释力。本文给出可直接复算的口径、字段与算例，并说明结果解读的限制。
要点总览（TL;DR）
- 计时起算点定在AI执行完成、待确认结果提交到确认环节并产生待确认记录的时刻；终点定在确认人给出明确结论并写入系统的时刻。
- 平均确认耗时 = Σ单次确认耗时 ÷ 有效确认次数，单次确认耗时 = 结论时间 − 提交确认时间，单位在统计窗口内保持一致。
- 有效确认次数需事先约定：超时未确认单列不混入平均值，撤回未形成结论的剔除，退回重提按最终结论计一条。
- 平均值受长尾影响，应同时看中位数与分位数；样本过少、跨流程版本或确认复杂度差异大时不宜直接比较。
- 确认耗时短不代表确认质量高，需结合驳回率、退回率等指标一起解读，不宜单独作为个人绩效依据。
这个指标要回答什么问题
这个指标回答一个具体的管理问题：AI把结果交出来之后，确认环节是否拖慢了流程整体流转。它衡量的是人工确认这一段的时间成本，用来判断确认环节是否成为瓶颈，以及瓶颈出现在哪类结论、哪类任务或哪个确认人身上。
指标边界需要先划清。它只覆盖确认环节，从待确认结果提交开始，到结论写入系统结束；AI执行本身的时长、确认之后的落地动作（如发布、合并、归档）都不计入。这样切分的好处是，确认耗时可以和执行耗时分开观察，改进动作也更容易落到具体环节。
指标用途主要有三类：定位瓶颈，看确认环节在整体流转中占多大比重；设定改进目标，例如缩短某类任务的确认等待；对比不同流程版本或不同团队在同一口径下的确认效率。用途决定了统计粒度，如果只想看整体趋势，按周汇总即可；如果要定位到人，就需要保留确认人字段并控制样本量。
计时起算点与终点怎么定
推荐起算点：AI执行完成、待确认结果提交到确认环节，并且系统产生一条待确认记录的时刻。这个时刻的标志是状态从“执行中”变为“待确认”，同时生成可追溯的记录。推荐终点：确认人给出明确结论——通过、驳回或要求修改——并且结论被写入系统的时刻。结论类型要一并记录，否则后续无法区分不同结论下的耗时差异。
常见错误起算点是从AI任务发起或执行开始计时。这样算出来的数值包含模型生成、工具调用、结果整理等执行时间，确认环节的真实等待被稀释或放大，跨任务比较时失真尤其明显。另一个容易忽略的错误是把“结果已生成但尚未提交确认”的时间算进去，这段属于执行侧收尾，不属于确认等待。
挂起与退回需要事先约定。建议规则是：退回修改后重新提交，视为一次新的确认，计时从重新提交时刻重新起算，原记录标记为“退回”并保留，不参与平均耗时计算；确认人挂起（如等待补充信息）期间，若系统能记录挂起状态，可单独统计挂起时长，主指标仍按提交到结论的完整区间计算，并在口径说明中注明。两种做法都可行，关键是同一统计窗口内保持一致。
| 节点 | 判定规则 | 记录要求 |
|---|---|---|
| 起算点 | AI执行完成，待确认结果提交到确认环节，产生待确认记录 | 记录提交确认时间、任务ID、流程版本 |
| 终点 | 确认人给出明确结论并写入系统 | 记录结论时间、结论类型、确认人 |
| 退回重提 | 重新提交视为新一次确认，重新起算 | 原记录保留并标记退回，不进入平均计算 |
| 挂起 | 主指标按完整区间计算，挂起时长可另设辅助指标 | 如系统支持，记录挂起开始与结束时间 |
| 超时未确认 | 按口径约定处理，建议单列，不混入平均值 | 记录超时标记与最后状态 |
指标口径、公式与数据字段
公式分两层。单次确认耗时 = 确认结论时间 − 待确认提交时间，单位用分钟或小时，同一统计窗口内单位保持一致。平均确认耗时 = Σ单次确认耗时 ÷ 有效确认次数。分子是有效记录的单次耗时之和，分母是有效确认次数，两者必须来自同一批记录，不能一边剔除记录一边保留其耗时。
时间窗按自然周或自然月切分，也可以按流程版本切分。按版本切分适合比较改版前后的确认效率，但要注意版本切换期可能存在记录归属模糊，建议在切换日附近留出观察期。统计区间要在报表上写明起止日期，避免不同人取数时口径漂移。
所需字段至少包括：任务ID、提交确认时间、结论时间、结论类型、确认人、流程版本。若要做分组分析，再加任务类型、优先级、所属团队。字段缺失的记录不能靠估算补齐，应单独列出缺失数量，作为数据质量说明的一部分。
有效确认次数的口径要事先写清楚。建议默认规则：包含正常给出结论的记录；超时未确认的记录单列，不进入平均值；被撤回且未形成结论的记录剔除；退回后重新提交的记录，以最后一次提交到最终结论为一条有效记录，中间过程记录保留但不重复计数。若业务上关心“首次确认”的效率，也可以另设一个只统计首次提交的指标，两个指标分开报告，不混用。
| 项目 | 口径 |
|---|---|
| 单次确认耗时 | 确认结论时间 − 待确认提交时间，单位分钟或小时 |
| 平均确认耗时 | Σ单次确认耗时 ÷ 有效确认次数 |
| 时间窗 | 自然周、自然月或按流程版本切分，报表注明起止日期 |
| 有效确认次数 | 形成明确结论的记录；超时未确认单列；撤回未形成结论的剔除；退回重提按最终结论计一条 |
| 必填字段 | 任务ID、提交确认时间、结论时间、结论类型、确认人、流程版本 |
| 缺失值处理 | 不估算补齐，单列缺失数量并在报表中说明 |
统计步骤：从取数到出结果
第一步，从流程系统导出统计窗口内的待确认记录与确认记录。导出时带上任务ID、状态变更时间、操作人和流程版本，尽量保留原始时间戳，不在导出环节做格式转换。
第二步，按任务ID配对提交与结论时间。配对后剔除结论时间为空的记录，这些记录要么仍在等待确认，要么已超时，应单独统计数量，不能当作零耗时计入平均值。
第三步，计算每条记录的单次耗时，检查是否存在负值或异常大的值。负值通常来自时间戳记录错误或时区问题，需要回到原始记录核对；异常大的值先保留，在解读阶段用分位数观察其影响，不直接删除。
第四步，按流程版本、确认人、结论类型分组汇总，计算各组平均值与记录数。分组后记录数过少的组只展示不比较，避免用小样本得出方向性结论。
第五步，抽样复核。随机抽取若干条记录，对照系统操作日志核对提交时间与结论时间是否与实际操作一致，重点检查批量确认、代确认和系统自动关闭的情况。复核发现的问题要回写到口径说明中，作为下一期统计的修正依据。
在ONES中，AI执行结果可以保存为工作项，状态流转和操作记录随工作项留存，确认动作对应到具体工作项的状态变更与操作人。ONES Assistant基于ONES权限体系执行任务，输出过程可追踪、结果可审计，这为按任务ID回溯提交与结论时间提供了记录基础。具体到确认环节的时间戳字段与耗时报表，需要按团队实际配置的流程状态来取数。
算例：一组确认记录的平均耗时
假设某流程版本在一个自然周内产生6条待确认记录，其中1条超时未确认、1条退回后重新提交并最终通过。按前述口径，有效确认次数为5条（超时记录单列，退回记录按最终结论计一条）。
| 任务ID | 提交确认时间 | 结论时间 | 单次耗时（小时） | 结论类型 | 确认人 |
|---|---|---|---|---|---|
| T-01 | 周一 09:20 | 周一 10:05 | 0.75 | 通过 | 甲 |
| T-02 | 周一 14:00 | 周一 17:30 | 3.50 | 要求修改 | 乙 |
| T-03 | 周二 09:10 | 周二 09:40 | 0.50 | 通过 | 甲 |
| T-04 | 周三 11:00 | 周三 15:20 | 4.33 | 驳回 | 丙 |
| T-05 | 周四 10:15 | 周四 11:00 | 0.75 | 通过 | 乙 |
| T-06 | 周五 09:00 | — | 超时未确认，单列 | — | 丙 |
5条有效记录耗时之和为0.75 + 3.50 + 0.50 + 4.33 + 0.75 = 9.83小时，平均确认耗时 = 9.83 ÷ 5 ≈ 1.97小时。若把超时记录按零耗时计入，平均值会被拉低到约1.64小时，掩盖了确认环节的真实等待，这正是分母口径必须写清楚的原因。
按结论类型分组：通过类3条，平均约0.67小时；要求修改1条，3.50小时；驳回1条，4.33小时。按确认人分组：甲2条平均约0.63小时，乙2条平均约2.13小时，丙1条4.33小时。分组结果提示，非通过类结论的确认耗时明显更长，后续可以进一步看是信息补充耗时还是判断耗时。
结果怎么解读，哪些情况不能直接比
平均值容易受长尾影响。上例中一条4.33小时的记录就把平均值从不足1小时拉到接近2小时，因此报告平均值时应同时给出中位数和分位数（如75分位、90分位），让读者看到分布形态。若90分位远高于中位数，说明少数记录等待很久，改进重点在长尾而非整体提速。
分母为零或样本过少时不下结论。某个确认人一周只有一两条记录，平均值波动很大，只能作为观察线索，不能据此评价个人效率。跨流程版本比较时，要确认两版的确认复杂度、任务类型分布相近，否则差异可能来自任务本身而非流程改进。
确认耗时短不等于确认质量高。确认过快可能意味着核对不充分，需要结合驳回率、退回率、确认后缺陷率等指标一起看。这个指标只反映时间，不宜单独作为个人绩效依据；把它用于流程改进的定位和验证更合适，用于考核时需要配套质量指标和样本量控制。
最后，指标本身不提供因果解释。确认耗时上升可能是任务变复杂、确认人负荷变化或提交时间集中在非工作时段，解读时应结合任务类型分布和提交时段一起分析，再决定改流程、调分工还是改提交节奏。
常见问题
AI执行结果提交确认后一直没人处理，超时记录要不要算进平均耗时？
建议单列，不混入平均值。超时未确认的记录没有结论时间，无法计算单次确认耗时；若按零耗时计入，会把平均值拉低，掩盖确认环节的真实等待。更合适的做法是单独统计超时记录的数量和占比，作为确认环节负荷或提醒机制是否有效的观察指标，与平均确认耗时并列报告。
确认人要求修改、AI重新执行后再次提交，计时怎么处理？
建议把重新提交视为一次新的确认，计时从重新提交时刻重新起算，原记录保留并标记为退回，不参与平均耗时计算。这样每次有效确认都对应一段完整的提交到结论区间，口径清晰。如果团队更关心从首次提交到最终结论的总时长，可以另设一个指标单独统计，两个指标分开报告，避免混用导致口径漂移。
确认人中途挂起等待补充信息，这段时间算不算确认耗时？
两种做法都可行，关键是同一统计窗口内保持一致。主指标按提交到结论的完整区间计算，挂起时长包含在内；若系统能记录挂起开始与结束时间，可另设辅助指标单独统计挂起时长，用于判断等待信息补充占多大比重。无论选哪种，都应在口径说明中写明，避免不同期报表之间无法比较。
统计结果能不能直接用来评价确认人的工作效率？
不建议单独使用。确认耗时受任务复杂度、提交时段、确认人同时承担的其他工作影响，样本量小时波动尤其大。把它用于流程改进的定位和验证更合适，例如发现某类非通过结论耗时明显偏长，再去看是信息补充环节还是判断环节的问题。若用于考核，需要配套质量指标（如驳回率、确认后缺陷率）和最小样本量控制。
在ONES中做这项统计，数据从哪里取？
ONES Assistant基于ONES权限体系执行任务，输出过程可追踪、结果可审计，AI执行结果可以保存为工作项，状态流转和操作记录随工作项留存，确认动作对应到具体工作项的状态变更与操作人，这为按任务ID回溯提交与结论时间提供了记录基础。具体到确认环节的时间戳字段与耗时报表，需要按团队实际配置的流程状态来取数，并核对导出记录中的时间戳是否与实际操作一致。
