研发AI试点结束后，团队常听到两种说法：写代码、写文档确实快了；但评审、返工和确认也变多了。要判断试点是否值得继续，需要把执行环节的节省与复核环节的新增成本分开计量，再相减得到净时间收益。本文给出一套可复算的口径：指标怎么定义、数据从哪里取、公式和分母怎么设，并用一个需求任务算完整的时间账。
要点总览（TL;DR）
- 把AI试点的时间变化拆成两笔账：执行环节的节省时间，以及复核环节新增的检查、返工、澄清与等待时间，两者相减才是净时间收益。
- 核心公式为净节省时间＝人工基线执行耗时－AI辅助执行耗时－复核增量耗时；单位化时按任务数、人天或需求条目选一种主口径，不混用。
- 取数优先用任务状态流转、评审与提交记录，并单独留痕复核人、复核轮次和返工原因；工时缺失的任务不进入均值，单独统计数量。
- 算例显示执行快2小时、复核多1.5小时时净收益只剩0.5小时；复核成本更高的场景净收益可能为负，需按任务类型分组判断。
- 净收益为正只说明该任务类型在该时间窗内整体省时，样本量小、任务难度差异和学习期效应都会影响可比性，结论要写明适用范围与复评时点。
评估目标：要回答的是净时间收益还是环节变化
评估开始前先写清要回答的问题，否则容易只报一个笼统的“提效百分比”。研发AI试点通常需要同时回答两类问题：第一类是整体判断，AI参与的任务在试点周期内是否净省时间；第二类是结构判断，节省发生在哪些环节、复核成本集中在哪些环节。前者决定试点去留，后者决定下一步怎么调整用法。
评估对象要具体到任务类型、团队和时间窗。例如“2025年第三季度，A团队使用AI辅助的需求分析、编码和测试用例编写任务”，比“研发团队AI试点”更容易取数和复算。任务类型不同，复核强度差异很大，混在一起算平均值会掩盖问题。
结论用途也要提前约定，常见有三种：净收益为正且分布稳定，考虑扩大范围；净收益接近零但复核成本集中在少数场景，调整用法后再评；净收益为负且返工比例高，暂停或缩小试点。把用途写进一页评估目标说明，包含评估对象、时间窗、结论用途和负责人，后续指标设计才有依据。
指标与范围：节省时间与复核成本各算什么
建议把时间拆成四类动作分别记录：执行耗时、复核耗时、返工耗时和等待时间。执行耗时指任务从开始处理到首次提交的时间；复核耗时指他人检查、评审、确认所花的时间；返工耗时指因AI输出问题而重新修改的时间；等待时间指提交后排队等待评审或澄清的时长。四类动作的边界要在评估前写死，避免同一段时间被重复计入。
核心公式有两个。净节省时间＝人工基线执行耗时－AI辅助执行耗时－复核增量耗时，其中复核增量耗时＝AI辅助下的复核耗时＋返工耗时＋因AI输出引发的澄清等待时间－人工基线下的对应耗时。单位任务净收益＝净节省时间÷任务数，也可以按人天或需求条目做分母，三种口径不要混用。
| 指标 | 定义 | 单位 | 分母口径 | 时间窗 |
|---|---|---|---|---|
| 执行节省时间 | 人工基线执行耗时－AI辅助执行耗时 | 小时 | 按任务数 | 任务开始至首次提交 |
| 复核增量耗时 | AI辅助下复核、返工、澄清等待合计－基线对应合计 | 小时 | 按任务数 | 首次提交至验收通过 |
| 净节省时间 | 执行节省时间－复核增量耗时 | 小时 | 按任务数 | 任务全周期 |
| 单位任务净收益 | 净节省时间÷任务数 | 小时/任务 | 按任务数 | 试点周期 |
| 单位人天净收益 | 净节省时间÷投入人天 | 小时/人天 | 按人天 | 试点周期 |
纳入范围建议只统计AI实际参与的任务，并保留“AI参与”的判定记录，例如使用了AI生成初稿、AI补全测试用例等。未使用AI的任务可作为人工基线来源，但要与试点任务在难度、类型上可比。排除范围要写明，例如紧急线上故障修复、探索性预研任务，这类任务耗时波动大，混入会拉偏结果。分母选择上，按任务数适合比较同类任务的单件收益，按人天适合评估团队整体投入产出，按需求条目适合向业务方汇报。选定一种作为主口径，其余作为辅助口径。
数据口径与证据：时间从哪来、复核成本怎么留痕
时间数据优先取自系统记录，减少人工填报误差。执行耗时可以从任务状态流转中取“开始处理”到“首次提交”的时间戳；复核耗时从评审记录、提交记录中取；返工耗时从任务被退回或重新打开的次数与停留时长推算；等待时间从提交到首次被评审的时间差取。工时记录可以作为补充，但要求填报颗粒度与指标定义一致，否则只用于校验。
AI使用记录要与任务关联。至少记录三项：该任务是否使用AI、用于哪个环节、使用的日期。关联方式可以是在任务上打标签或填写字段，也可以由工具自动记录。ONES Assistant 能够理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，基于相关项目数据和团队知识回答问题并执行后续操作，结果可保存为工作项、Wiki 页面等内容；如果试点在ONES中进行，这类工作项和页面可以作为AI参与记录与任务关联的承载位置。具体字段设置需按团队实际配置确定。
复核动作要留痕到可归因的程度，建议字段包括：复核人、复核轮次、复核结论、返工原因分类（如事实错误、逻辑遗漏、格式问题、需求理解偏差）、返工耗时。返工原因是后续分组分析的关键，没有它只能看到复核变慢，无法判断问题出在提示词、任务选择还是模型能力。
缺失值处理规则提前约定：工时未记录的任务不进入均值计算，单独列出数量；只有开始时间没有提交时间的任务按未完成处理，不计入净收益；同一任务多次返工按累计耗时计算，不取最后一次。缺失比例超过约定阈值（例如两成）时，该任务类型的结论标注为证据不足。
计算与评估步骤：从原始记录到净收益
第一步建立人工基线。优先使用试点前同一团队、同类任务的历史耗时；历史数据不足时，设置对照任务组，由未使用AI的成员完成同类任务，或同一成员在部分任务上不使用AI。基线样本要与试点样本在任务难度上大致匹配，难度差异大的任务单独分组。
第二步逐任务计算。对每个任务分别算出执行节省时间和复核增量耗时，记录计算所用的原始时间戳，保证任何人可以复算。第三步汇总，把任务级净节省时间加总，除以任务数或人天得到单位口径，同时给出中位数和分布，避免均值被少数极端任务拉偏。
第四步按任务类型分组比较，例如需求分析、编码、测试用例编写、文档撰写分别汇总。复核成本往往集中在需要严格评审的任务类型上，分组后才能看出哪类任务适合继续用AI、哪类需要调整复核方式。第五步处理边界情况：分母为零时该组不计算单位收益，只报告绝对时间；样本量少于约定下限（例如每组不足十个任务）时只做描述性统计，不下扩大结论。
汇总表建议包含这些列：任务类型、任务数、基线执行耗时合计、AI辅助执行耗时合计、执行节省合计、复核增量合计、净节省合计、单位任务净收益、缺失任务数、备注。这张表既是计算底稿，也是评审时的证据。
例子：一个需求任务的净时间账
以下为演示情景，数值用于说明计算方法，不代表任何团队的实际水平。某需求分析任务，人工基线为：撰写需求文档4小时，评审与确认1小时，返工0.5小时，合计5.5小时。使用AI辅助后：AI生成初稿并人工修改用时2小时，评审发现需求边界描述不清、补充确认1.5小时，返工修改1小时，等待评审0.5小时，合计5小时。
按公式计算：执行节省时间＝4－2＝2小时；复核增量耗时＝（1.5＋1＋0.5）－（1＋0.5）＝1.5小时；净节省时间＝2－1.5＝0.5小时。这个任务执行环节快了2小时，复核环节多花了1.5小时，净收益只有0.5小时。如果只看执行耗时，会得出提效50%的结论；把复核算进来，实际净收益约9%。
换一个复核成本更高的场景：同一任务AI初稿用时1.5小时，但评审发现多处事实性错误，复核与澄清3小时，返工2小时，等待0.5小时。执行节省2.5小时，复核增量＝（3＋2＋0.5）－1.5＝4小时，净节省为负1.5小时。此时试点在该任务类型上不省时间，需要检查是提示词缺少上下文、任务本身不适合AI初稿，还是复核标准过严。
| 项目 | 场景一（小时） | 场景二（小时） |
|---|---|---|
| 基线执行耗时 | 4 | 4 |
| AI辅助执行耗时 | 2 | 1.5 |
| 执行节省 | 2 | 2.5 |
| 复核增量 | 1.5 | 4 |
| 净节省 | 0.5 | -1.5 |
两个场景的差别主要来自复核与返工，而不是执行速度。评估报告应把这类对比放在一起，说明同一任务类型在不同用法下净收益可能反向，避免用单个场景的平均值代表整体。
解读与限制：哪些结论能下、哪些不能
净收益为正说明试点在该任务类型、该时间窗内整体省了时间，不说明每个任务都省时间，也不说明质量提升或团队绩效改善。解读时要同时看分布：如果少数任务贡献了大部分净节省，其余任务接近零或为负，扩大试点前应先弄清差异来源。
样本量小和任务难度差异是常见偏差来源。十几个任务的平均值容易受个别复杂任务影响；试点任务如果恰好比基线任务简单，净收益会被高估。学习期效应同样影响前后对比：试点初期成员不熟悉AI用法，执行耗时偏高、复核问题偏多，直接用初期数据与成熟期基线比较会低估或高估效果。建议把试点周期分成前后两段分别统计，观察趋势是否稳定。
复核成本被低估的情形要特别留意：评审意见只记录结论不记录耗时；澄清通过即时消息完成，没有进入任务记录；返工被合并进正常修改，无法区分；等待时间因为评审人兼职而拉长，却被算作执行环节的问题。这些情况会让净收益看起来比实际更好。评估时可以把复核耗时与评审记录条数交叉核对，发现明显缺口就标注数据质量说明。
结论要写明适用范围和复评时点，例如“本结论适用于A团队需求分析类任务，样本32个，建议两个月后按同一口径复评”。单指标不能代表整体绩效，净时间收益需要与质量指标（如评审一次通过率、缺陷密度）一起看，才能判断试点是否值得继续。ONES TestCase 支持测试用例与需求、任务关联，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，还提供质量统计报表；如果试点涉及测试环节，这些记录可以作为复核与返工留痕的补充证据，帮助把时间账和质量结果放在同一套工作项体系里核对。
常见问题
试点期间AI工具或提示词中途升级，前后数据还能放在一起算吗？
建议按用法版本分段统计，而不是把整个试点周期合成一个平均值。可以在任务记录里增加一个“AI用法版本”或“提示词版本”字段，升级前后分别计算执行节省与复核增量，再比较两段的净收益趋势。如果升级后样本太少，只做描述性说明，不据此下扩大结论。
团队没有试点前的历史工时，人工基线怎么建立？
可以设置对照任务组：由未使用AI的成员完成同类任务，或同一成员在部分任务上不使用AI。关键是让基线任务与试点任务在任务类型、难度和验收标准上大致匹配，难度差异大的任务单独分组。对照组的记录方式要与试点组一致，否则两类数据无法同口径相减。
复核耗时分散在即时消息和口头确认里，怎么留痕？
把关键确认动作回写到任务记录中，至少记录复核人、复核轮次、结论和返工原因分类，耗时可以按轮次估算后填入。即时消息里的澄清如果影响任务范围，应在任务上补一条说明并记录时间。评估时把复核耗时与评审记录条数交叉核对，发现明显缺口就在报告中标注数据质量说明，避免净收益被高估。
净收益接近零时，试点应该继续还是暂停？
先看分布和集中度。如果多数任务净收益接近零，但复核成本集中在少数任务类型，可以调整这些场景的用法，例如补充上下文、缩小AI生成范围或改变复核方式，再按同一口径复评。如果返工比例高且分散在多个任务类型，暂停或缩小试点更稳妥。判断依据是分组结果，整体均值不足以支撑决定。
净时间收益要不要和质量指标一起看？
需要。净时间收益回答的是时间账，评审一次通过率、缺陷密度等指标回答的是质量变化，两者结合才能判断试点是否值得继续。如果试点涉及测试环节，测试用例与需求、任务的关联记录、未通过用例转缺陷的流转记录以及质量统计报表，可以作为复核与返工的补充证据。ONES TestCase 支持测试用例与需求、任务关联，未通过的用例可快速创建缺陷任务，并提供质量统计报表，便于把时间账与质量结果放在同一套工作项体系里核对。
