验证研发AI效率收益，关键是把“AI上线前后差异”拆成可归因的部分：先固定一组稳定、可复算的基线指标，再设置与基线同口径的对照周期，最后用事先写定的验收口径判断收益是否成立。避免把自然波动算作收益，重点在三点：基线取多个周期并记录波动区间；对照组与实验组在任务类型、人员、需求复杂度上尽量可比；验收标准提前锁定，包含效应阈值、显著性判断和排除项，事后不因结果调整口径。
要点总览（TL;DR）
- 基线取AI上线前4–8个完整自然周，记录均值、中位数和波动区间，并保存取数快照，让第三人能复算出同一组数字。
- 对照周期与基线保持同口径：能分组时优先同期对照或分批上线形成自然对照，前后对照需设置学习期与洗脱期，并披露季节性、人员变动等混杂因素。
- 验收口径在收集数据前锁定，包含效应阈值、波动区间或显著性判断、排除项与一票否决条件，事后变更保留记录、不追溯修改判定。
- 判定时先算变化量相对基线波动区间的位置，再逐项对照验收口径；效率改善但返工率等质量指标恶化，整体结论仍为不通过。
- 结论限定在具体指标、团队和周期内表述，披露混杂因素，单指标改善不能代表整体研发效率，推广前做同口径复验。
评估目标：要证明的是哪一类收益
“AI效率收益”是一个笼统说法，落到评估上必须先拆成具体收益类型。研发环节常见的可验证收益包括：需求交付周期时间缩短、单位周期内完成的需求吞吐量提升、返工率下降、评审等待时间减少。这四类指标的改善机制不同，数据来源不同，受自然波动影响的程度也不同，一次评估通常只适合验证其中一到三类。
评估对象同样需要先明确。是某个团队的交付效率，还是某个项目从需求到上线的周期，抑或代码评审、测试用例编写等具体环节的处理时间？对象不同，基线的取数范围和对照分组方式都会变化。评估对象应落在团队、项目或环节层面，单个模型在标准测试集上的能力表现属于技术基准测试，不在本文讨论范围内。
本文也不覆盖一般研发效能指标体系的搭建。评估的前提是团队已有可用的工作项、工时、评审记录等过程数据；如果这些数据尚未稳定采集，应先解决数据基础问题，再谈收益验证。
| 收益类型 | 可观察指标 | 适合的评估对象 | 主要噪声来源 |
|---|---|---|---|
| 周期时间 | 需求从进入开发到上线的时长 | 项目、团队 | 需求复杂度差异、节假日、依赖阻塞 |
| 吞吐量 | 单位周期完成需求数或故事点数 | 团队 | 需求拆分粒度变化、人员增减 |
| 返工率 | 返工工作项占已完成工作项比例 | 环节、团队 | 缺陷判定标准变化、测试覆盖差异 |
| 评审等待 | 评审发起到首次响应的时长 | 环节 | 评审人可用性、提交时间分布 |
建议在评估启动时只勾选1–3类收益，并为每类写明“本次要回答的问题”。例如：“在需求类型和人员基本稳定的前提下，AI辅助编码上线后，后端团队的需求交付周期中位数是否下降超过10%。”问题写得越具体，后续基线和验收口径越容易对齐。
指标与范围：选哪些指标、覆盖哪些人和任务
指标必须给出可复算的定义，否则不同人取数会得到不同结果。每个指标至少写清五项：指标名、计算公式（分子与分母）、单位、统计时间窗、纳入与排除规则。分子分母要落到具体工作项状态或时间戳字段，避免使用“大约”“平均来看”这类无法复核的描述。
| 指标名 | 公式（分子/分母） | 单位 | 时间窗 | 纳入/排除规则 |
|---|---|---|---|---|
| 需求交付周期中位数 | 需求从“进入开发”到“已上线”的时长，取中位数 | 天 | 按需求上线日期归入自然周 | 纳入标准需求类型；排除实验性需求、外包需求、跨团队强依赖且阻塞超过5天的需求 |
| 周吞吐量 | 当周状态变为“已完成”的标准需求数 | 个/周 | 自然周（周一至周日） | 排除被取消、合并或拆分后重复计数的需求 |
| 返工率 | 发生返工的工作项数 / 当期完成工作项总数 | 百分比 | 按完成日期归入自然周 | 返工以状态回退或新建关联缺陷为准；排除需求变更导致的正常调整 |
| 评审首次响应时长 | 评审创建到首位评审人响应的时长，取中位数 | 小时 | 按评审创建日期归入自然周 | 排除非工作时间发起的评审，或单独标注 |
纳入范围要写清哪些团队、哪些需求类型、哪些环节使用了AI。例如“后端两个小组在编码和单元测试环节使用AI助手，需求类型限定为标准产品需求”。排除范围同样要提前写明：实验性需求、外包交付、跨团队强依赖需求通常波动大且归因困难，建议排除或单独分层统计，而不是混入主口径。
范围一旦确定，基线和对照期都沿用同一套纳入排除规则。中途扩大或缩小范围，等于换了口径，前后数据不可直接比较。
数据口径与证据：基线怎么取才不被单点带偏
基线取单点最容易把偶然波动当成起点。合理做法是取AI上线前若干个完整周期，至少覆盖4–8个自然周，计算均值、中位数和波动区间（如第25到第75百分位，或均值±1个标准差）。中位数对极端值更稳健，适合周期时间这类长尾分布指标；均值和波动区间用于判断后续变化量是否超出正常范围。
取数时要记录数据来源系统、取数时点、查询条件和原始快照。快照可以是导出文件或固定报表版本，目的是让第三人在几个月后仍能复算出同一组数字。基线方案建议包含以下清单：
- 基线周期起止日期，以及每个周期的指标值；
- 均值、中位数、波动区间上下限；
- 数据来源系统与字段名，取数脚本或报表链接；
- 取数时点与快照存放位置；
- 缺失值清单：哪些周数据不完整，原因是什么；
- 口径变更记录：统计字段、需求类型定义是否发生过调整；
- 人员变动记录：基线期内是否有成员加入或离开。
缺失值和口径变更要标注而不是直接删除。某个周数据缺失，可以说明原因后从均值计算中剔除，但需在报告中披露；口径变更则应把变更前后分段统计，不把两段数据拼成一个基线。人员变动较大的周期，可单独标注为“不稳定周期”，在波动区间计算时说明处理方式。
对照周期怎么设：同期对照、分批对照与洗脱期
前后对照（AI上线前 vs 上线后）实施简单，但容易把季节性、需求节奏变化、人员调整算进收益。同期对照（同一时间段内使用AI的组与未使用AI的组比较）能抵消共同的时间因素，前提是两组在任务类型、人员能力和需求复杂度上可比。分批上线则介于两者之间：先在一部分团队或环节启用AI，另一部分保持原状，形成自然对照组，运行一段时间后再轮换或推广。
| 对照方式 | 适用条件 | 主要偏差 | 控制手段 |
|---|---|---|---|
| 前后对照 | 团队规模小、无法分组，且业务节奏稳定 | 季节性、需求结构变化、人员变动 | 拉长基线周期、披露混杂因素、设置洗脱期 |
| 同期对照 | 存在可比的未使用AI团队或环节 | 两组任务难度和人员能力不完全一致 | 按需求类型分层比较，记录分组依据 |
| 分批对照 | 可分批推广，团队间业务相近 | 先启用组的学习效应、后启用组的观望效应 | 设置学习期，轮换后复验 |
无论哪种方式，都要设置学习期和洗脱期。学习期指AI启用后的前一段时间（例如2–4周），团队尚在适应工具和提示方式，这段数据单独标注，不计入收益判定。洗脱期用于前后对照：上线前的最后一段时间可能已受试点准备影响，上线初期也可能有集中清理积压的动作，把这些边界周期排除后比较更干净。
对照周期长度与样本量直接相关。周期时间这类波动大的指标，单个周期内完成的需求数太少时，中位数会剧烈跳动。经验上每个比较组在每个周期内至少有20–30个完成需求，再考虑4周以上的观察窗口；样本不足时应延长周期或合并需求类型，而不是缩短周期硬做比较。
验收口径：阈值、显著性与排除项怎么写
验收口径要在数据收集前写定并锁定，锁定方式可以是在评估文档中记录版本和确认人，或在项目管理工具中把验收标准作为独立页面固定下来。锁定后如需变更，保留变更记录并说明原因，不追溯修改已产生的判定。
效应阈值回答“改善多少才算有意义”。阈值不宜照搬通用数字，应结合基线波动和业务可感知程度设定。一个实用做法是：先看基线波动区间宽度，阈值至少大于波动区间的一半；再结合业务目标，例如交付周期中位数下降10%或绝对减少2天。阈值过低会把噪声当收益，过高则可能错过真实改善。
波动判断用两种方式之一：一是变化量是否落在基线波动区间之外；二是对基线和对照期的周期值做简单显著性检验（如Mann-Whitney U检验），看差异是否可能由随机波动产生。样本量小时优先用波动区间判断，并明确标注“证据强度有限”。
| 指标 | 效应阈值 | 判定规则 | 排除项/一票否决 | 锁定时间 |
|---|---|---|---|---|
| 需求交付周期中位数 | 下降≥10%且绝对减少≥2天 | 变化量超出基线波动区间下限，且达到阈值→通过；在区间内→待观察；反向超出→不通过 | 返工率同步上升超过2个百分点则整体不通过 | 数据收集前 |
| 周吞吐量 | 提升≥8% | 连续3个周期高于基线第75百分位→通过 | 需求平均规模明显变小需重新核对口径 | 数据收集前 |
| 返工率 | 下降≥1个百分点 | 对照期均值低于基线第25百分位→通过 | 缺陷判定标准变更未同步则判定无效 | 数据收集前 |
排除项和一票否决条件要单独列出。效率指标改善但质量指标恶化，不能判定为收益成立。常见的一票否决包括：返工率或线上缺陷率显著上升、评审等待时间明显延长、需求交付后客户投诉增加。这些条件与效率阈值同时生效，任一触发即整体不通过或转入待观察。
计算与评估步骤：从原始数据到结论
计算流程应能让另一名分析者按步骤复算出相同结论。建议按以下顺序执行：
- 按指标定义从数据源导出基线和对照期的原始工作项清单，保存快照。
- 按纳入排除规则清洗数据，记录被排除的数量和原因。
- 按周期计算每个指标的均值、中位数和波动区间，基线与对照期使用相同统计方法。
- 计算变化量：对照期中位数减基期中位数，同时计算相对变化百分比。
- 判断变化量相对基线波动区间的位置：高于上限、落在区间内、低于下限。
- 对照验收口径表逐项判定，记录每项为通过、不通过或待观察。
- 汇总排除项检查结果，形成整体结论。
分母为零、样本不足和口径不一致是三类常见异常。分母为零（某周期无完成需求）时该周期不参与中位数计算，但需在报告中说明；样本不足时延长观察窗口或合并相近需求类型，并降低结论强度；口径不一致时以锁定版本为准，变更后的数据单独统计，不混入主结论。
结论汇总模板可包含：评估问题、指标与口径版本、基线与对照期数值、变化量与波动区间位置、逐项判定、排除项检查、整体结论、限制说明。这份汇总既是验收依据，也是后续复验的起点。
在评估执行过程中，基线快照、分组名单、验收口径版本和逐项判定结果需要有统一的存放位置。ONES 的项目与 Wiki 能力可以把评估方案、口径版本和结论汇总作为页面留存，工作项状态和评审记录则提供原始数据来源；ONES Assistant 智能助手可基于项目、工作项和 Wiki 页面上下文回答评估相关问题，并把结果保存为工作项或 Wiki 页面，减少在多个页面间查找和重复录入。对于采用瀑布管理方式的团队，ONES 瀑布项目管理方案支持设置项目计划和里程碑基线并对比计划与执行偏差，这类基线对比面向计划执行，与本文的AI效率收益口径需要分别定义。
例子：一次需求交付周期收益验证的完整演算
以下为演示情景，数字为假设值，用于说明判定逻辑。
某后端团队在编码环节启用AI助手。基线取上线前8个自然周，每周完成的标准需求数为22–31个，需求交付周期中位数分别为：9.5、10.2、9.8、11.0、10.5、9.2、10.8、10.0天。基期中位数约10.1天，均值约10.1天，波动区间（第25到第75百分位）为9.65–10.65天。
AI上线后设2周学习期不计入，随后取4周对照期，交付周期中位数分别为9.4、9.9、9.6、9.8天，对照期中位数9.7天。变化量为9.7−10.1=−0.4天，相对下降约4%。验收口径设定的阈值是下降≥10%且绝对减少≥2天，同时要求变化量低于基线波动区间下限9.65天。对照期中位数9.7天落在基线波动区间内，未达到阈值，判定为“待观察”，不能算作收益。
再看质量排除项。假设同一对照期内返工率从基线的6.0%上升到8.5%，上升2.5个百分点，超过“返工率上升超过2个百分点则整体不通过”的一票否决条件。即使交付周期出现更大幅度下降，本次评估整体结论也应为“不通过”，并记录返工上升的原因待查。这个例子说明：单看周期指标的小幅改善容易误判，波动区间和排除项共同作用才能挡住把噪声当收益的结论。
解读与限制：哪些结论能说、哪些不能说
评估结果首先是一个相关性描述：在设定的口径和周期内，使用AI的组或时段与指标变化同时出现。要把它说成因果关系，需要对照设计足够干净、混杂因素已披露且影响有限。报告中应列出已知混杂因素，例如同期需求复杂度变化、人员调整、其他工具或流程变更，并说明它们可能影响的方向。
单指标改善不能代表整体研发效率提升。交付周期缩短可能伴随返工增加或评审压力上升，吞吐量提升可能来自需求拆分变细。结论表述应限定在具体指标、具体团队和具体周期内，例如“在2026年第二季度、后端两个小组、标准产品需求范围内，交付周期中位数下降X%，返工率未超过排除阈值”，而不是“AI使研发效率提升X%”。
结论还要写明适用范围和复验建议。团队规模、需求结构或工具使用方式发生变化后，原结论不一定继续成立。建议在推广到其他团队前做一次同口径复验，或在3–6个月后重新取基线对照，确认收益是否持续。对于证据强度不足的“待观察”结论，应明确后续观察窗口和再次判定的时间点，避免长期悬置或被误读为已通过。
常见问题
基线周期取多长合适，遇到数据缺失或口径变更怎么办？
基线建议覆盖AI上线前4–8个完整自然周，计算均值、中位数和波动区间。周期时间这类长尾分布指标以中位数为主要参照，均值和波动区间用于判断后续变化是否超出正常范围。周期太短容易被单周异常带偏，太长则可能混入业务结构调整。
数据缺失时标注原因后从统计中剔除，并在报告中披露；口径变更应把变更前后分段统计，不拼成一个基线。人员变动较大的周期单独标注为不稳定周期，说明在波动区间计算中的处理方式。
团队规模小、无法分组做同期对照，还能验证收益吗？
可以，但需要更谨慎地控制偏差。小团队常用前后对照，此时应拉长基线周期、设置洗脱期排除上线前后的边界数据，并把同期发生的需求复杂度变化、人员调整、其他流程变更逐项披露。若条件允许，分批上线让部分环节先启用AI，也能形成自然对照。
样本不足时不要缩短周期硬做比较，可以延长观察窗口或合并相近需求类型，同时在结论中标注证据强度有限。
效应阈值应该定多少，有没有通用标准？
没有适用于所有团队的通用数字。一个实用做法是先看基线波动区间宽度，阈值至少大于波动区间的一半，再结合业务可感知程度设定，例如交付周期中位数下降10%或绝对减少2天。阈值过低容易把噪声当收益，过高可能错过真实改善。
阈值与判定规则应在数据收集前写入验收口径并锁定，锁定后如需调整，保留变更记录并说明原因，不追溯修改已产生的判定。
效率指标改善了，但返工率同时上升，结论怎么判？
按事先写定的排除项处理。常见做法是把返工率或线上缺陷率显著上升、评审等待明显延长、客户投诉增加列为一票否决条件，与效率阈值同时生效，任一触发即整体不通过或转入待观察。
这类情形应在结论中写明效率指标的变化幅度和触发排除项的具体指标，并记录原因待查，避免只引用改善的那一项指标对外表述。
评估结论过一段时间还成立吗，什么时候需要复验？
结论的适用范围是具体指标、具体团队和具体周期。团队规模、需求结构、工具使用方式发生变化后，原结论不一定继续成立。建议在推广到其他团队前做一次同口径复验，或在3–6个月后重新取基线对照，确认收益是否持续。
判定为待观察的指标应写明后续观察窗口和再次判定的时间点，避免长期悬置或被误读为已通过。
