研发 AI 应用效果评估的依据要能支撑一个具体判断：这项投入是否值得继续、是否扩大范围、哪些环节需要调整。可用的依据通常分四层：先界定决策问题与评估范围，再确定可复算的指标与数据口径，同步留存过程与产出证据，最后用对照设计解释结果。本文按这四层展开，并给出指标口径表、证据清单和一个带数字的演算示例，帮助团队把“感觉有用”变成可核验的结论。
要点总览（TL;DR）
- 评估依据分四层：先界定决策问题与范围，再定可复算的指标口径，同步留存过程与产出证据，最后用对照设计解释结果。
- 指标口径至少写清公式、分子、分母、单位、统计时间窗和缺失值处理；分母为零时写“本期无有效样本”，不记 0%。
- 每个指标背后要有可追溯的证据：使用记录、采纳与修改记录、评审记录、返工与缺陷记录，并指定采集时点与责任人。
- 验证优先用前后对照或分组对照并标注样本量；解读顺序是先核对口径与数据完整性，再看差异，最后结合证据。
- 达标线来自团队自身基线或试点方案约定，单次结果不足以支撑长期判断时，建立按迭代持续采集的机制。
评估要回答哪些决策问题
评估的起点是决策问题，指标是回答问题的工具。研发场景中，AI 应用评估通常对应四类决策：是否继续投入、是否扩大到更多团队或环节、是否调整工具用法与流程、试点是否通过验收。四类问题需要的证据强度不同，继续投入看趋势与成本，扩大范围看可复制性，调整环节看问题定位，验收看事先约定的条件是否满足。
每类决策都要写清评估对象和时间窗。评估对象可以是某个团队、某类研发环节（如需求拆解、编码辅助、测试用例编写、文档撰写），也可以是某种工具用法（如用 AI 生成初稿再由人修改）。时间窗要明确起止日期，并与迭代周期或版本节奏对齐，避免统计区间跨越多轮组织调整。
范围说明还要写明不纳入的内容。一般研发效能指标（如整体交付周期、人均故事点）反映的是团队综合产出，不能单独归因于 AI 应用；技术模型基准测试考察的是模型本身的能力，与团队实际使用效果是两件事。这两类内容可以在报告中作为背景，不作为本次评估的结论依据。
| 决策问题 | 评估对象 | 建议时间窗 | 不纳入项 |
|---|---|---|---|
| 是否继续投入 | 试点团队 + 指定环节 | 至少两个完整迭代，含基线期 | 整体研发效能指标、模型基准分数 |
| 是否扩大范围 | 多个团队或同类环节 | 各团队同口径的观察期 | 未使用 AI 的历史项目数据混算 |
| 调整哪些环节 | 单个环节的工具用法 | 按任务类型分组统计 | 跨环节合并的平均值 |
| 试点是否验收 | 试点范围整体 | 试点方案约定的周期 | 试点外团队的临时反馈 |
需要哪些指标与数据口径
指标按回答的问题分组，比按工具功能罗列更有用。效率类看任务耗时与流转速度，质量类看返工、缺陷与评审一次通过情况，采用类看使用频次与采纳比例，体验类看使用者的主观评价与障碍反馈。每组选两到三个指标即可，指标过多会让口径维护成本超过评估收益。
每个指标必须写清公式、分子、分母、单位、统计时间窗和缺失值处理。同一指标在不同团队之间不可比，最常见的原因是分母定义不同：例如“采纳率”的分母是 AI 生成次数还是人工发起次数，结果会差很多。口径表要在评估开始前定稿，中途修改需记录版本和原因。
| 指标 | 公式 | 分子 | 分母 | 单位 | 时间窗 | 缺失值处理 |
|---|---|---|---|---|---|---|
| 任务平均处理时长 | 总处理时长 ÷ 完成任务数 | 任务从开始到完成的累计时长 | 统计期内状态为完成的任务数 | 小时/任务 | 按迭代统计 | 未记录起止时间的任务剔除并注明数量 |
| AI 建议采纳率 | 被采纳次数 ÷ 有效生成次数 | 人工确认采纳或仅做少量修改的生成结果 | 排除报错、超时后的生成次数 | 百分比 | 按周统计 | 分母为零时记“无数据”，不记 0% |
| 返工率 | 返工任务数 ÷ 完成任务数 | 因内容错误或不符合要求被退回的任务 | 统计期内完成任务数 | 百分比 | 按迭代统计 | 返工原因未标注的单独列出 |
| 评审一次通过率 | 一次通过数 ÷ 提交评审数 | 首次评审即通过的需求或代码变更 | 统计期内提交评审的总数 | 百分比 | 按版本统计 | 评审记录缺失的样本不计入并说明 |
| 周活跃使用人数占比 | 周内使用人数 ÷ 纳入评估人数 | 当周至少使用一次的人数 | 评估范围内有账号的人数 | 百分比 | 自然周 | 休假、转岗人员从分母中剔除并记录 |
分母为零时，结论应写“本期无有效样本”，不能写成效果为零或下降 100%。数据缺失要区分随机缺失和系统性缺失：个别任务漏记时间可以剔除，某个团队整体没有记录则说明采集流程有问题，应先补流程再比较。指标口径发生变更时，报告中要标注变更日期，跨口径的数据不直接画在同一趋势线上。
过程与产出证据怎么留存
指标回答“变化了多少”，证据回答“变化是怎么发生的”。可核验的证据包括：使用记录（谁在什么任务上使用了 AI、使用频次）、采纳与修改记录（生成内容被保留、改写或弃用的具体情况）、评审记录（评审意见与结论）、返工与缺陷记录（退回原因、缺陷来源）。这些记录要在事情发生的时点采集，事后补记的可信度会明显下降。
证据采集要指定责任人。常见分工是：使用记录由工具侧或平台侧自动留存，采纳与修改记录由使用者或结对评审人确认，评审与返工记录由项目管理者在流程节点登记。每个指标至少对应一类证据，评估报告中的每条结论都能回溯到具体记录。
| 证据类型 | 采集时点 | 责任人 | 对应指标 |
|---|---|---|---|
| AI 使用记录 | 每次使用后自动记录 | 平台管理员 | 周活跃使用人数占比、生成次数 |
| 采纳与修改记录 | 任务提交或评审时 | 任务执行人 | AI 建议采纳率 |
| 评审记录 | 评审会议或线上评审完成时 | 评审组织者 | 评审一次通过率 |
| 返工与缺陷记录 | 任务退回或缺陷登记时 | 项目管理者、测试负责人 | 返工率、缺陷密度 |
| 使用者反馈 | 试点中期与结束时各一次 | 试点负责人 | 体验类评价 |
证据不足时，结论要相应降级。例如只有使用记录、没有采纳与修改记录，就只能说明“工具被打开过”，不能推断“内容被用上了”。报告中可以用“初步观察”“待补充证据”等表述，并列出补齐证据的计划，避免把弱证据写成确定结论。
评估过程本身也需要留存载体。使用记录、评审意见和返工原因如果分散在聊天工具和个人文档里，复核成本会很高。ONES Assistant 智能助手可连接 ONES Project、ONES Wiki 与 ONES TestCase，理解项目、工作项、迭代和 Wiki 页面等上下文，并把结果保存为工作项、Wiki 页面等内容，便于把评估口径、证据清单和阶段结论沉淀在同一处；基于指定 Wiki 页面组回答问题时还可附引用来源，方便复核依据。工具留存解决的是“记录在哪、能否追溯”，效果结论仍要由指标和对照设计得出。
评估怎么算、怎么验证
计算前先划分基线期与观察期。基线期是 AI 应用尚未引入或尚未改变用法的时段，观察期是引入后的时段，两段的时间长度和任务类型应尽量接近。基线数据不足时，可以退而使用同期的分组对照：选择任务类型、复杂度相近的两个团队，一组使用 AI，一组维持原流程。
前后对照适合评估单一团队在引入前后的变化，前提是同期没有其他重大流程变更；分组对照适合无法回溯基线或需要排除季节性波动的场景，前提是两组任务构成可比。两种设计都要标注样本量，样本量过小时，百分比差异容易被个别任务放大。
- 核对口径：确认指标定义、时间窗、分母范围与评估方案一致，记录任何变更。
- 检查数据完整性：统计缺失记录数量与占比，判断缺失是否集中在某个团队或某类任务。
- 逐项计算：按指标口径表计算基线与观察期数值，同时给出样本量。
- 比较差异：计算绝对差与相对差，结合样本量判断差异是否值得进一步解释。
- 结合证据解释：回到使用记录、评审记录和返工原因，说明差异可能来自哪些环节。
- 形成结论与下一步动作：写明结论适用范围、待验证事项和后续采集计划。
结果解释按固定顺序进行：先看口径与数据完整性，再看差异大小与样本量，最后看证据。顺序颠倒容易出现“先有结论再找数据”的情况。如果口径不一致或缺失严重，正确做法是先修复数据，而不是在报告中加一段说明继续比较。
一个可复算的评估示例
以下为演示情景，数字用于说明计算方法，不代表任何真实团队的水平。某研发团队在需求拆解与测试用例编写两个环节引入 AI 辅助，基线期为 3 月 1 日至 3 月 28 日（两个迭代），观察期为 4 月 7 日至 5 月 2 日（两个迭代），评估对象为该团队 12 名成员。
指标一：AI 建议采纳率。观察期内 AI 在测试用例编写环节共产生有效生成 480 次，其中 312 次被直接采纳或仅做少量修改，采纳率为 312 ÷ 480 = 65.0%。同期有 36 次生成因超时或报错被排除在分母外，报告中注明排除数量。基线期该环节未使用 AI，无对应数值，因此该指标只呈现观察期结果，不做前后比较。
指标二：测试用例返工率。基线期完成测试用例任务 150 个，其中 27 个因覆盖不全或描述错误被退回，返工率为 27 ÷ 150 = 18.0%。观察期完成 160 个，退回 19 个，返工率为 19 ÷ 160 = 11.9%。绝对差为 6.1 个百分点，相对下降约 33.9%。样本量分别为 150 和 160，差异值得进一步核查，但同期该团队还调整了用例评审模板，因此不能把下降全部归因于 AI。
缺失与分母为零的处理。观察期有 8 个任务未记录开始时间，处理时长指标无法计算，这 8 个任务从时长统计中剔除，并在报告中注明占观察期任务的 5%。另一个小组在观察期前两周没有产生任何 AI 生成记录，其采纳率分母为零，报告写“本期无有效样本”，不参与团队平均值计算。
示例结论的边界：以上结果只适用于该团队、该时间窗和这两个环节；采纳率反映的是生成内容被保留的比例，不直接等于质量提升；返工率下降与评审模板调整同时发生，需要分组对照或延长观察期才能区分各自贡献。
结果怎么解读、有哪些限制
单个指标不能代表整体效果。采纳率高可能说明生成内容贴合需求，也可能说明使用者降低了判断标准；返工率下降可能来自质量提升，也可能来自评审尺度放宽。解读时要同时看效率、质量、采用和体验四组指标，并回到证据确认变化发生的环节。
常见干扰有三类。样本量小，几个任务的差异就能让百分比大幅波动，此时更适合报告绝对数量和典型事例。选择偏差，主动使用 AI 的往往是熟练成员或简单任务，直接与全体比较会高估效果。同期其他变更，如流程调整、人员变动、需求结构变化，会与 AI 应用的影响混在一起，需要在报告中列出并说明处理方式。
达标线应来自团队自身基线或试点方案中事先约定的目标，例如“返工率不高于基线期水平”“采纳率在观察期后半段趋于稳定”。没有内部基线时，可以先设定观察性目标并注明其性质，不宜套用来源不明的通用标准。评估结论建议按以下结构表述：评估范围与时间窗、各指标数值与样本量、证据支持的变化环节、结论适用范围、待验证事项与下一步动作。
结论转为动作时，要区分三种情况：指标与证据一致向好，可进入扩大范围评估；指标改善但证据不足，先补齐记录再下结论；指标无变化或变差，回到具体环节分析是工具用法、任务匹配度还是流程配合的问题。评估的价值在于让下一步投入有依据，单次结果不足以支撑长期判断时，应建立按迭代或按版本的持续采集机制。
常见问题
基线期数据缺失或根本没有基线，还能评估吗？
可以评估，但要换一种设计并降低结论强度。基线期数据缺失时，优先考虑分组对照：选任务类型、复杂度相近的两个团队，一组使用 AI，一组维持原流程，比较同期结果。如果连分组对照也做不了，就只呈现观察期指标，并明确写成“无基线，仅作观察记录”，不写前后升降。
另一种做法是补一段回溯期：从历史任务记录中提取同口径数据作为参照，但要说明历史任务与当前任务在需求结构、人员构成上的差异。无论哪种方式，报告中都要标注样本量和数据来源，避免把弱设计写成确定结论。
评估周期多长比较合适，中途能改指标口径吗？
周期与决策节奏对齐比追求固定长度更实际。一般建议基线期和观察期各覆盖至少两个完整迭代，让任务类型分布相对稳定；如果评估的是版本级环节（如测试用例编写），可以按版本节奏划分。周期过短时，个别任务就能让百分比大幅波动。
口径尽量在评估开始前定稿。中途确需修改，要记录变更日期和原因，跨口径的数据不画在同一趋势线上，报告中分段呈现。修改后重新累计样本，不把新旧口径的数据合并计算。
采纳率高是不是就说明 AI 效果好？
采纳率只说明生成内容被保留的比例，不能单独代表效果。采纳率高可能来自内容贴合需求，也可能来自使用者降低了判断标准；采纳率低可能是生成质量不足，也可能是任务本身不适合 AI 辅助。
判断时要和返工率、评审一次通过率、任务处理时长等指标一起看，并回到采纳与修改记录确认改动发生在哪里。如果采纳率上升同时返工率也上升，说明保留的内容里有相当部分需要返工，这时更应关注质量环节而不是继续扩大使用范围。
同期还有流程调整，怎么区分 AI 带来的变化？
先在设计阶段就把同期变更列出来，包括流程调整、评审模板更换、人员变动和需求结构变化，并在报告中说明处理方式。能拆分环节的，按环节分组统计，让受流程调整影响的任务与主要受 AI 影响的任务分开比较。
无法拆分时，可以延长观察期，看变化是否在流程调整稳定后仍然持续；也可以增加一个未使用 AI 的对照团队。如果两种方式都不可行，结论就写成“变化与 AI 应用同期发生，贡献程度待验证”，并列出后续验证计划，不把全部改善归因于 AI。
评估记录分散在聊天工具和个人文档里，怎么保证可复核？
关键是让记录在流程节点上自然产生，而不是事后收集。使用记录由平台侧自动留存，采纳与修改记录在任务提交或评审时确认，返工原因在任务退回时登记，评审结论在评审完成时归档。每个指标对应一类记录，报告中的每条结论都能回溯到具体条目。
记录载体集中会明显降低复核成本。ONES Assistant 智能助手可连接 ONES Project、ONES Wiki 与 ONES TestCase，理解项目、工作项、迭代和 Wiki 页面等上下文，并把结果保存为工作项、Wiki 页面等内容，便于把评估口径、证据清单和阶段结论沉淀在同一处；基于指定 Wiki 页面组回答问题时还可附引用来源，方便复核依据。工具解决的是记录在哪、能否追溯，效果结论仍要由指标和对照设计得出。
