验证AI效率收益，关键是把“用了AI之后效率变好了”拆成一条可核验的证据链：评估对象和目标是什么，用哪些指标衡量，数据从哪里取、口径是否一致，有没有对照或基线，最后如何计算和解释。单看使用率或成员自报的节省时间，很难支撑立项或推广结论。下文给出一套可复算的评估方法，并说明评估任务与结论如何在ONES中留痕。
要点总览（TL;DR）
- 验证AI效率收益要先写清评估目标：对象、周期、用途和收益类型，再选指标，避免指标先行导致数据无法对齐。
- 指标按过程、产出、质量、使用四类各选一到两个，每个指标写明公式、分子分母、单位、时间窗和样本量下限。
- 证明收益与AI有关需要对照或基线，可用历史同期、未使用组或分批试点，并说明学习效应、季节波动等不可比因素。
- 结论按有证据支持、证据不足、无法判断三级表述，约定复评周期；单看使用率或自报节省时间不足以支撑结论。
- 评估任务、指标定义和结论文档可在ONES中留痕，便于沿用口径和复评。
验证AI效率收益要先回答什么问题
在选指标之前，先把评估目标写清楚。目标决定了后面取什么数、和谁比、结论给谁看。建议用一张评估目标说明固定四件事：对象、周期、用途、收益类型。
评估对象要具体到可界定的范围：哪个团队或角色，哪类任务（如需求拆解、代码编写、测试用例设计、缺陷定位），对应哪项AI能力。范围写得越具体，数据越容易对齐；写成“研发团队整体效率”往往无法取数。
结论用途决定证据强度。用于试点验收，需要试点前后的可比数据和明确的通过条件；用于立项决策，需要说明投入与收益的关系以及不确定性；用于推广判断，则需要考虑不同团队、不同任务类型的适用差异。用途不同，样本量和对照设计的要求也不同。
收益类型要分开定义，避免混在一个“效率提升”里：
- 时间节省：同类任务的平均耗时是否下降；
- 返工减少：返工任务数、评审打回次数是否下降；
- 吞吐提升：单位周期内完成的需求或合并的代码量是否增加；
- 质量变化：缺陷密度、逃逸缺陷、回滚次数是否变化。
这几类收益可能同时出现，也可能互相牵制，例如交付变快但缺陷增多。评估时应分别计算，再综合解释。技术模型基准测试（如模型在标准题库上的得分）衡量的是模型能力，与团队实际工作效率是两件事，不纳入本文的评估范围。
指标与范围：选哪些指标、覆盖多大样本
指标不在多，而在每个都能算、能复核。建议按过程、产出、质量、使用四类各选一到两个，并为每个指标写明公式、分子分母、单位、统计时间窗和样本量下限。
| 类别 | 指标示例 | 计算口径 | 单位与时间窗 |
|---|---|---|---|
| 过程 | 平均任务周期 | 任务从进入“进行中”到“已完成”的总耗时 ÷ 完成任务数 | 小时或工作日，按周或按迭代统计 |
| 过程 | 评审等待时长 | 提交评审到首次评审意见的时间总和 ÷ 评审次数 | 小时，按周统计 |
| 过程 | 返工率 | 发生返工的任务数 ÷ 总任务数 | 百分比，按迭代统计 |
| 产出 | 需求交付量 | 周期内状态为“已完成”的需求数 | 个，按迭代统计 |
| 产出 | 代码合并量 | 周期内合并的提交数或变更行数 | 次或行，按周统计 |
| 质量 | 缺陷密度 | 周期内发现的缺陷数 ÷ 交付需求数或代码变更量 | 个/需求或个/千行，按迭代统计 |
| 质量 | 逃逸缺陷数 | 上线后发现的、本应在测试阶段拦截的缺陷数 | 个，按发布周期统计 |
| 质量 | 回滚次数 | 周期内因质量问题回滚的发布次数 | 次，按发布周期统计 |
| 使用 | 活跃使用人数 | 周期内至少使用一次AI能力的成员数 | 人，按周统计 |
| 使用 | 采纳率 | 被采纳的AI建议数 ÷ AI建议总数 | 百分比，按周统计 |
范围要同时界定四件事：团队（哪些成员计入）、任务类型（哪些任务纳入统计）、时间窗（试点前后各取多长）、样本量下限。样本量下限没有通用标准，可按任务波动程度设定，例如每类任务至少覆盖两个完整迭代，低于下限时只作趋势参考，不下结论。使用类指标适合描述采用情况，不宜单独作为收益证据。
数据口径与证据：从哪些系统取数、如何保证可比
数据来源通常分散在多个系统：工作项系统记录任务状态与流转，代码库记录提交与合并，流水线记录构建与发布，缺陷库记录缺陷与回滚，AI工具日志记录调用与采纳。评估前先列一张数据来源与口径对照清单，逐项写明字段、取数方式、统计周期和责任人。
口径统一是可比的前提。同一任务类型在不同团队可能有不同的状态定义，例如“完成”指开发完成还是测试通过；统计周期可能按自然周也可能按迭代。评估时应固定一套状态定义和周期，并对历史数据做同样的映射，否则前后对比会把口径差异误读为效率变化。
证明收益与AI有关，需要对照或基线，常见做法有三种：
- 历史同期对比：试点前若干周期的同类指标作为基线；
- 未使用组对比：条件相近的团队或任务类型不使用AI，作为参照；
- 分批试点：先小范围使用，再逐步扩大，比较各批次的变化。
定性证据用于解释数字背后的原因，包括成员访谈、问卷、评审记录。问卷可询问“哪些环节节省了时间”“哪些输出需要较多修改”，访谈记录应保留原话摘要和时间。定性材料不能替代定量计算，但能帮助判断指标变化是否由AI引起。
缺失值和异常值要事先定规则：缺失关键字段的任务是剔除还是单独统计，超长或超短的任务是否作为异常值标注，剔除比例超过多少时结论降级。规则写在评估方案里，取数后按规则执行，避免事后挑选数据。
计算与评估步骤：从原始数据到可复核结论
计算流程按六步走：定义指标、取数、清洗、计算、对照、解释。每一步留下记录，其他人拿同样的原始数据能算出同样结果。
常用公式示例：
- 平均任务周期 = 任务总耗时 ÷ 完成任务数；
- 返工率 = 返工任务数 ÷ 总任务数；
- 缺陷密度 = 缺陷数 ÷ 交付需求数；
- 采纳率 = 被采纳建议数 ÷ 建议总数。
分母为零要单独处理：某周期没有完成任务时，平均周期无定义，应标注“无数据”而不是记为零；样本过小时只报告原始数量和区间，不报告精确百分比。对照比较建议同时给出试点前后和试点组与对照组的差异，两者方向一致时结论更稳。
结论按证据强度分三级表述：有证据支持（指标变化方向一致、样本达到下限、对照可比）、证据不足（有变化但样本小或口径有差异）、无法判断（数据缺失或不可比）。分级写进评估报告，便于后续复评时对照。
一个示例：三周试点如何算出效率变化
以下为演示情景，数字仅用于说明计算方法，不代表任何真实团队的结果。
设定：一个8人研发小组，任务类型为“需求开发”，试点周期3周，对照为试点前3周的同类任务。原始数据经清洗后：试点前完成需求24个，任务总耗时合计960小时，返工任务6个；试点期完成需求27个，任务总耗时合计918小时，返工任务4个。
| 指标 | 试点前3周 | 试点期3周 | 变化 |
|---|---|---|---|
| 完成任务数 | 24 | 27 | +3 |
| 任务总耗时 | 960小时 | 918小时 | -42小时 |
| 平均任务周期 | 40小时 | 34小时 | -6小时（-15%） |
| 返工率 | 25% | 14.8% | -10.2个百分点 |
计算过程：平均任务周期 = 960 ÷ 24 = 40小时，918 ÷ 27 = 34小时；返工率 = 6 ÷ 24 = 25%，4 ÷ 27 ≈ 14.8%。解读时要注意：试点期完成任务数增加，可能包含任务难度差异；三周样本偏短，季节波动和人员变动未排除；返工率下降也可能来自评审流程调整。因此这组数据可以表述为“试点期平均任务周期和返工率均下降，方向与预期一致，但样本周期短，建议延长观察后再下结论”。
解读与限制：哪些结论能下、哪些不能
指标变化与AI使用同时发生，只能说明相关，不能直接证明因果。学习效应会让成员在试点后期越用越熟，季节波动会影响交付节奏，人员变动会改变任务分配，这些因素都可能单独造成指标变化。评估报告应列出已知的干扰因素及处理方式。
单指标不能代表整体绩效。周期缩短可能伴随质量下降，交付量增加可能来自任务拆分方式变化。建议至少同时报告一个过程指标、一个质量指标和一个使用指标，并说明它们之间的关系。
自报节省时间存在偏差：成员可能高估节省、忽略修改AI输出的时间，也可能因期望效应而倾向报告正面结果。自报数据可作为定性证据，与系统记录交叉验证后再使用。
样本量与统计显著性的关系要说明：样本小的时候，指标波动可能只是随机差异，报告应给出样本量和区间，避免用精确百分比暗示确定性。结论表述可采用“在本次试点范围内，X指标由A变为B，样本为N，存在以下不可比因素”的格式，并约定复评周期，例如一个季度后按同一口径重新取数。
用ONES承载评估数据与结论留痕
评估本身也是一项需要管理的工作：指标定义要有人确认，取数结果要能追溯，结论要经过评审，复评要按周期触发。这些动作可以在ONES中落地。
把评估任务和指标定义建成工作项，写明对象、周期、公式和责任人，指标变更时留下记录；取数结果和评估报告以文档形式归档，与对应工作项关联，评审意见和复评结论一并留存。这样下一次评估可以直接沿用口径，减少重复对齐。ONES Assistant 智能助手可基于项目、工作项和Wiki页面的上下文回答问题并执行操作，例如根据当前迭代生成项目周报并保存到Wiki，或基于指定Wiki页面组回答评估口径相关问题并附引用来源，便于评估过程中的信息查询与文档沉淀。评估所需的使用日志统计与导出能力，需结合具体部署环境确认。
常见问题
试点周期太短，指标有变化但样本不够，结论怎么写？
样本低于事先设定的下限时，只报告原始数量和变化方向，不报告精确百分比，也不下“效率提升”的结论。可以写成“试点期内平均任务周期由A变为B，样本为N，周期偏短，建议延长观察”。同时把样本量下限和复评时间写进评估方案，到期按同一口径重新取数，避免用一次短周期数据支撑推广决策。
团队中途调整了任务状态定义，前后数据还能直接比吗？
不能直接比。状态定义变化会改变“完成”的判定，进而影响完成任务数和平均任务周期。处理方式是按新定义对历史数据做同样的映射，重新计算基线；无法映射的部分单独标注并说明剔除比例。如果映射后可比样本过少，结论降级为证据不足，并在报告中写明口径变更的时间和内容。
没有未使用AI的对照组，怎么增强结论可信度？
可以用历史同期作为基线，并补充分批试点：先小范围使用，再逐步扩大，比较各批次的变化方向。同时收集定性证据，如访谈和评审记录，说明哪些环节节省了时间、哪些输出需要较多修改。报告中列出学习效应、季节波动、人员变动等干扰因素及处理方式，结论表述限定在本次试点范围内。
自报节省时间和系统记录对不上，以哪个为准？
以系统记录的计算结果为主，自报数据作为定性证据用于解释原因。两者差异较大时，先核对口径：自报可能只算了生成时间，忽略了修改AI输出的时间；系统记录可能包含等待和评审环节。把差异写进报告，说明各自覆盖的范围，再判断指标变化是否可信。
评估任务和指标定义在ONES中怎么留痕，方便下次复评？
可以把评估任务和指标定义建成工作项，写明对象、周期、公式和责任人，指标变更时留下记录；取数结果和评估报告以文档形式归档，与对应工作项关联，评审意见和复评结论一并留存。ONES Assistant 智能助手可基于项目、工作项和Wiki页面的上下文回答问题并执行操作，例如基于指定Wiki页面组回答评估口径相关问题并附引用来源，便于评估过程中的信息查询与文档沉淀。评估所需的使用日志统计与导出能力，需结合具体部署环境确认。
