研发 AI 应用效果评估要先把“AI 应用”落到具体研发场景，再为每个场景设定可复算的指标、统一口径与时间窗，通过对照组或前后对比验证变化，并用访谈、评审记录等定性证据解释结果。本文给出一套从目标设定到结论解读的完整方法，包括指标定义、取数口径、计算公式和数字示例，适用于编码辅助、代码评审、测试用例生成、需求文档撰写等场景的效果验证。ONES 可作为承载需求、缺陷与工作项数据的管理平台，为评估提供过程数据基础。
要点总览（TL;DR）
- 评估研发 AI 应用效果，先把“AI 应用”拆成编码辅助、代码评审、测试用例生成、需求文档撰写等具体场景，每个场景单独设定目标、单独取数。
- 每个场景保留 2 至 4 个核心指标，至少包含一个过程指标（如采纳率）和一个结果指标（如任务完成时长、返工率、缺陷密度、评审一次通过率），并写明分子分母与时间窗。
- 取数前先写口径说明，基线与观察阶段使用同一套定义、过滤条件和统计窗口；条件允许时设对照组，否则用前后对比并在结论中标注并行因素。
- 指标变化只说明相关性，需结合访谈、评审记录等定性证据解释，并用多指标交叉验证；样本量过小、分母为零、数据不可比的情况要单独处理。
- 评估结论按固定周期复评，沿用同一口径便于纵向比较；结果用于改进使用方式，不宜直接作为个人绩效依据。
评估目标：先明确要验证的研发场景
“AI 应用效果”本身无法直接测量，必须先拆成具体场景。研发环节中常见的可评估场景包括编码辅助、代码评审、测试用例生成、需求文档撰写四类，每类场景的预期改善方向和受影响角色不同，评估时应分别设定目标、分别取数，避免把多个场景混在一起得出笼统结论。
为每个场景写明三件事：谁在用、期望改变什么业务结果、用什么方向的指标观察。效率类目标关注任务完成时长、单位时间产出；质量类目标关注返工率、缺陷密度、评审一次通过率；协作类目标关注评审等待时长、跨角色交接次数、文档返工轮次。三类目标可以同时存在，但需要分开陈述，因为效率提升可能伴随质量波动，混在一起会掩盖真实变化。
| 场景 | 主要角色 | 预期变化 | 观察指标方向 |
|---|---|---|---|
| 编码辅助 | 开发工程师 | 减少重复编码时间，保持代码质量 | 采纳率、任务完成时长、返工率 |
| 代码评审 | 开发、评审人 | 缩短评审周期，提高一次通过比例 | 评审一次通过率、评审等待时长 |
| 测试用例生成 | 测试工程师 | 提高用例覆盖与编写效率 | 用例产出量、缺陷发现密度 |
| 需求文档撰写 | 产品、需求分析 | 缩短文档成稿时间，减少返工 | 文档完成时长、返工轮次 |
这张对照表是后续所有工作的起点：指标从目标推导，取数范围按场景划定，结论也只在对应场景内成立。一个场景的评估结果不能直接套用到另一个场景。
指标与范围：选哪些指标、覆盖多大范围
指标选择的原则是少而可复算。每个场景保留 2 至 4 个核心指标即可，其中至少一个结果指标、一个过程指标，避免指标堆叠导致口径混乱。过程指标反映使用行为，如采纳率、生成建议数；结果指标反映业务变化，如任务完成时长、返工率、缺陷密度。只看过程指标容易把“用得多”误当成“效果好”，只看结果指标则难以解释变化来源。
| 指标 | 定义 | 单位 | 分子 / 分母 | 时间窗 | 数据来源 |
|---|---|---|---|---|---|
| 采纳率 | AI 生成建议被实际采用的比例 | 百分比 | 被采纳建议数 / 生成建议总数 | 观察期内按周统计 | AI 工具使用日志 |
| 任务完成时长 | 工作项从开始到完成的时间 | 小时或天 | 完成时间 − 开始时间，取中位数 | 按工作项完成日期归属 | 工作项管理系统 |
| 返工率 | 完成后因问题被重新打开或修改的工作项占比 | 百分比 | 返工工作项数 / 总工作项数 | 观察期内完成的工作项 | 工作项状态流转记录 |
| 缺陷密度 | 单位产出中的缺陷数量 | 个/千行或个/工作项 | 缺陷数 / 代码行数或工作项数 | 按缺陷发现日期归属 | 缺陷管理系统 |
| 评审一次通过率 | 首次评审即通过的比例 | 百分比 | 一次通过评审数 / 评审总数 | 观察期内发起的评审 | 代码评审记录 |
统计范围需要同时界定四个维度：团队（哪些成员纳入）、仓库或项目（哪些代码库、哪些项目）、工作项类型（需求、任务、缺陷是否都计入）、时间窗（基线期与观察期各多长）。范围一旦确定，基线与观察阶段保持一致，中途调整范围会使前后数据不可比。时间窗建议覆盖完整的迭代周期，避开版本发布前后的异常波动期，基线期与观察期长度尽量相同。
数据口径与证据：怎么取数、怎么保证可比
取数前先写一份口径说明，逐项固定指标的定义、分子分母、统计窗口、数据来源和排除规则。对比组与实验组必须使用同一份口径说明，包括同一套工作项类型过滤条件、同一套状态判定规则。例如“返工”要明确是“完成后被重新打开”还是“评审未通过退回”，两种定义算出的数值差异很大，混用会让对比失去意义。
数据来源通常分布在多个系统：代码平台提供提交与评审记录，需求与缺陷系统提供工作项状态流转，流水线记录提供构建与测试结果，工时或事件日志提供时间投入。取数时保留原始记录和提取脚本或查询条件，便于他人复算。对同一指标，尽量从单一系统取数，跨系统拼接时注明关联键，如工作项编号。
定性证据用于解释数字背后的原因，常见形式包括：对使用者的结构化访谈、评审会议记录、AI 工具的使用日志（调用频次、使用时段、功能分布）。定性证据不替代定量指标，而是回答“变化为什么发生”“哪些环节受益明显”“出现了哪些指标未覆盖的问题”。
缺失值与异常值需要事先约定处理原则：工作项缺少开始时间的不计入时长统计并单独记录数量；时长明显偏离分布（如超过 3 倍四分位距）的样本单独列出，说明原因后再决定是否剔除；观察期内人员大幅变动或需求类型突变的区段，标注后单独分析，不与正常区段合并计算。
计算与评估步骤：从取数到结论的流程
评估按固定顺序推进，每一步留下可核对的产物：
- 确定场景与目标：输出场景-目标对照表，明确本次评估只覆盖哪些场景。
- 基线期取数：在引入 AI 前按口径说明采集指标，记录样本量与数据完整度。
- 引入 AI 并记录使用情况：记录启用时间、覆盖人员、使用方式，作为解释变量。
- 观察期取数：使用与基线期相同的口径和统计窗口采集指标。
- 对比计算：按公式计算各指标，同时计算变化量与变化比例。
- 解释与复核：结合定性证据解释变化，标注并行因素，交由参与团队复核数据。
核心公式如下：
- 采纳率 = 被采纳建议数 ÷ 生成建议总数 × 100%
- 返工率 = 返工工作项数 ÷ 总工作项数 × 100%
- 评审一次通过率 = 一次通过评审数 ÷ 评审总数 × 100%
- 任务完成时长变化 = 观察期中位时长 − 基线期中位时长（同时给出变化百分比）
- 缺陷密度 = 缺陷数 ÷ 代码行数（千行）或工作项数
对比设计有两种：条件允许时设对照组，即相似团队或相似模块不使用 AI，与实验组同期对比；条件不允许时用前后对比，即同一范围基线期与观察期对比。对照组能削弱季节性、需求波动等共同因素，但要求两组在人员经验、任务类型上尽量接近；前后对比实施简单，但更容易受外部因素干扰，解读时需更谨慎。样本量方面，工作项数量过少（如少于 30 个）时比例类指标波动大，应延长观察期或合并多个迭代，并在结论中注明样本规模。
分母为零的情况要单独处理：观察期内没有生成建议时采纳率无定义，应标注“无数据”而非记为 0；某类工作项没有返工记录时返工率为 0 是有效结果，但需确认统计范围确实覆盖了该类工作项。数据不可比时，如基线期与观察期的工作项类型构成差异明显，应按类型分层对比，或说明差异对结论的影响方向。
例子：一个编码辅助场景的评估演算
以下为演示情景，数字用于说明计算方法，不代表任何真实团队的表现。某 10 人开发团队在 4 周基线期内完成 120 个工作项，中位完成时长 36 小时，返工工作项 18 个。引入编码辅助工具后观察 4 周，完成 130 个工作项，中位完成时长 30 小时，返工工作项 16 个；期间工具生成建议 2000 条，被采纳 900 条。
| 指标 | 基线期 | 观察期 | 变化 |
|---|---|---|---|
| 工作项数 | 120 | 130 | +10 |
| 中位完成时长 | 36 小时 | 30 小时 | −6 小时（−16.7%） |
| 返工率 | 18 ÷ 120 = 15.0% | 16 ÷ 130 = 12.3% | −2.7 个百分点 |
| 采纳率 | 无数据 | 900 ÷ 2000 = 45.0% | — |
解读时可以说：观察期内任务完成时长中位数下降 6 小时，返工率下降 2.7 个百分点，采纳率为 45%，三项数据方向一致，支持“编码辅助在该团队产生了正向变化”的判断。不能说的是：这些变化全部由 AI 造成。观察期工作项数量增加、任务构成可能变化，团队熟练度也会随时间提升；采纳率只说明建议被使用的比例，不直接等于质量提升。若要增强因果解释力，可补充对照组数据、访谈记录，并对返工原因分类，看返工减少是否集中在 AI 参与较多的任务类型上。
解读与限制：结果能说明什么、不能说明什么
指标变化反映的是相关性，不是因果保证。解读结论前先排查并行因素：人员是否变动、需求类型与复杂度是否变化、同期是否上线了其他工具或流程调整、发布节奏是否不同。能排除的写明排除依据，不能排除的列为限制条件，与结论一起呈现。
样本偏差与小样本是常见局限。参与评估的往往是积极使用者，其表现可能优于团队平均；观察期过短会放大偶发波动。比例类指标在小样本下置信区间较宽，报告时应给出样本量，避免用一两个百分点的差异下强结论。
单指标不能代表整体效果。采纳率高但返工率上升，说明使用频繁而质量承压；完成时长下降但缺陷密度上升，说明速度提升可能以质量为代价。评估结论应建立在多指标交叉验证之上，并说明各指标的方向是否一致。
评估不是一次性动作。建议在工具使用稳定后按固定周期复评，例如每个季度或每个大版本结束后复评一次，复评时沿用同一口径以便纵向比较；当使用方式、团队构成或任务类型发生明显变化时，重新设定基线。评估结果用于改进使用方式和流程，不宜直接作为个人绩效依据，否则会诱导数据失真，削弱后续评估的可信度。
在数据承载上，需求、任务、缺陷的状态流转和完成时间通常记录在工作项管理系统中，ONES 可以承载这类工作项与缺陷数据，使基线期与观察期按同一口径提取，减少跨系统拼接带来的口径偏差；评估所需的定性证据和口径说明也可以随评估记录一并留存，便于复评时对照。
常见问题
基线期数据不完整，还能做前后对比吗？
可以，但需要先补齐关键字段再计算。常见缺失是工作项没有开始时间、状态流转记录中断。处理方式有两种：一是缩小统计范围，只纳入字段完整的工作项，并记录被排除的数量和占比；二是用可获得的替代口径，例如以首次提交时间代替开始时间，但要在口径说明中注明替代关系，且观察期使用同样的替代口径。如果缺失比例较高（例如超过两成），前后对比的结论应降级为参考，优先补充数据或延长基线期。
团队规模小、工作项数量少，指标波动很大怎么办？
小样本下比例类指标波动明显，几个工作项的差异就能让返工率变化好几个百分点。可行的做法包括：延长观察期，把多个迭代合并统计；按工作项类型分层对比，减少构成变化带来的干扰；同时报告中位数和样本量，避免只给百分比。对于采纳率这类依赖工具日志的指标，样本量通常较大，可以作为辅助证据。结论表述上应使用“方向一致”“初步支持”等措辞，避免用一两个百分点的差异下强判断。
采纳率高是否就说明 AI 应用效果好？
采纳率反映的是 AI 生成建议被实际使用的比例，属于过程指标，说明使用行为发生了，不能直接等同于业务结果改善。判断效果需要结合结果指标：任务完成时长是否下降、返工率与缺陷密度是否稳定或下降、评审一次通过率是否提高。如果采纳率上升的同时返工率也上升，可能说明建议被大量使用但质量承压，需要进一步分析返工原因和任务类型分布。多指标方向一致时，结论才更可靠。
评估结果能不能直接用于个人绩效考核？
不建议。把评估指标与个人绩效直接挂钩，容易诱导数据失真，例如刻意减少工作项拆分、回避标记返工，反而削弱后续评估的可信度。更合适的用法是把结果用于改进使用方式、调整工具配置和优化流程，例如针对采纳率低的功能开展培训，针对返工集中的任务类型补充评审规则。如果确实需要与个人评价关联，应选择不易被操纵的指标，并配合人工复核。
引入 AI 的同时还上线了其他流程调整，怎么区分影响？
当多个变化同时发生时，单靠前后对比难以拆分各自贡献。可以尝试三种方式：一是寻找未受其他调整影响的子范围做对照，例如部分模块未参与流程调整，单独对比；二是按时间分段分析，观察指标变化是否与 AI 启用时间点吻合；三是通过访谈和评审记录确认变化集中在哪些环节。如果无法区分，应在结论中明确列出并行因素，把结论限定为“整体变化”，不归因于单一措施。
