研发 AI 应用效果评估要回答的是“AI 在具体研发环节带来了什么可验证的变化”，而非“AI 工具本身有多强”。做法是先界定评估对象、使用场景和决策用途，再围绕任务成功率、输出质量、采纳程度、效率收益和投入产出建立可复算指标，用对照组或前后对比验证收益来源，并在结论中说明分母、缺失值处理和不可比因素。本文给出指标定义、计算口径、执行流程和一个完整算例，范围限于 AI 应用效果，不涉及一般研发效能体系建设或模型基准测试。
要点总览（TL;DR）
- 评估前先写一页目标说明：评估对象、纳入的研发环节、要支持的决策、观察期和对比基准，四项缺一不可。
- 核心指标分五类：任务成功率、输出质量、采纳程度、效率收益、投入产出，各自回答不同问题，不能互相替代。
- 口径要固定到公式、分子分母、判定标准、时间窗和缺失值规则，并附数据来源清单，保证他人能按同一口径复算。
- 收益验证优先用同期对照组，无法设置时用前后对比，并逐项记录人员变动、需求难度等干扰因素。
- 解读时先看样本量和分母，单指标不能作为整体绩效结论，结论需标注有效期并按周期复评。
评估目标：先回答 AI 在哪些研发环节产生了什么变化
评估开始前先写一份评估目标说明，把“评估 AI 应用效果”拆成几个能直接回答的问题。目标说明至少包含四项：评估对象、使用场景、要支持的决策、评估时间窗。缺少其中任何一项，后续指标很容易变成数字堆砌，无法支撑判断。
评估对象要具体到某个 AI 应用及其使用范围，例如“某代码补全工具在支付业务后端团队的日常开发中使用”，而不是笼统的“公司 AI 能力”。使用场景要落到研发环节，例如需求拆解、编码、单元测试编写、代码评审意见生成、缺陷定位、技术文档撰写。同一工具在不同环节的效果差异可能很大，混在一起统计会掩盖真实情况。
决策用途决定评估的严格程度。常见决策有三类：是否继续投入或续费；是否从试点团队扩大到更多团队；是否调整使用方式，例如改变提示模板、使用规范或接入位置。续费决策更关注投入产出，扩面决策更关注效果在不同任务难度下是否稳定，用法调整更关注具体环节的失败原因。评估设计应优先服务其中一个主决策，其余作为参考。
时间窗要同时确定观察期和对比基准。观察期建议覆盖完整的研发节奏，例如连续 4 至 8 周，避开版本发布前后的极端波动。对比基准有两种选择：使用前的同团队历史数据，或同期未使用 AI 的相似团队。前者容易采集但受季节和任务结构变化影响，后者可比性更强但需要团队条件接近。选择哪种基准要在目标说明中写明，不能事后挑选更有利的一种。
完成标志是形成一页纸的目标说明，包含：评估对象一句话描述、纳入的研发环节清单、主决策问题、观察期起止日期、对比基准及选择理由。这份说明是后续所有指标口径的依据，评估过程中如需调整，应记录调整时间和原因。
指标与范围：任务成功率、输出质量、采纳程度、效率收益和投入产出
五类指标分别回答不同问题，不能互相替代。任务成功率回答“AI 能不能把这件事做完”，输出质量回答“做完的结果好不好”，采纳程度回答“研发人员实际用了多少”，效率收益回答“时间有没有减少”，投入产出回答“这些收益是否值得成本”。下表给出定义、单位和适用环节。
| 指标类别 | 指标名 | 定义 | 单位 | 适用环节 |
|---|---|---|---|---|
| 任务成功率 | AI 任务完成率 | 在纳入统计的 AI 使用任务中，输出经判定可直接使用或仅需轻微修改即可使用的任务占比 | 百分比 | 代码生成、测试用例生成、缺陷定位建议、文档初稿 |
| 输出质量 | 一次通过率 | AI 输出在首次评审或首次运行中通过的比例，按环节定义通过标准 | 百分比 | 代码评审、单元测试、静态检查 |
| 输出质量 | 缺陷密度 | AI 参与产出的工作项在观察期内被确认的缺陷数除以产出规模 | 个/千行或个/工作项 | 编码、测试 |
| 采纳程度 | 建议采纳率 | 被采纳的 AI 建议条数除以 AI 给出的建议总条数 | 百分比 | 代码补全、评审意见、修复建议 |
| 采纳程度 | 活跃使用率 | 观察期内至少使用一次 AI 功能的研发人员数除以纳入团队人数 | 百分比 | 全环节 |
| 效率收益 | 环节耗时变化 | 同一类任务在使用 AI 前后的平均处理时长之差，或与对照组的差值 | 小时/任务 | 编码、测试编写、文档撰写 |
| 效率收益 | 返工率变化 | 因质量问题重新打开或退回的工作项占比变化 | 百分比 | 编码、评审 |
| 投入产出 | 单位任务 AI 成本 | 观察期内 AI 工具与相关配套投入除以完成的纳入任务数 | 元/任务 | 全环节 |
| 投入产出 | 节省工时折算 | 效率收益折算的工时乘以团队工时成本口径 | 人时或金额 | 全环节 |
每类指标对应不同角色。任务成功率和输出质量主要由使用 AI 的研发人员和评审人判定；采纳程度由工具侧记录或使用日志统计；效率收益需要项目管理人员配合提取工作项流转时间；投入产出由效能或财务口径提供成本数据。角色分工要在评估启动时确认，避免事后对数据来源产生争议。
范围上明确不纳入两类内容：一是一般研发效能指标，如整体交付周期、需求吞吐量、线上事故率，这些受版本规划、人员变动、架构调整等多因素影响，不能单独归因于 AI；二是技术模型基准测试，如代码生成基准得分、模型推理能力评测，这类结果反映模型能力，不反映团队实际使用效果。若评估中确实需要参考模型能力数据，应作为背景信息单独说明，不混入效果指标。
数据口径：分子分母、时间窗与缺失值怎么定
口径的作用是让不同团队、不同周期算出的结果可以复算和比较。每个指标都要写清公式、分子、分母、判定标准、时间窗和缺失值规则。以下给出关键指标的口径要点。
任务成功率的分子分母。分母是观察期内纳入统计的 AI 使用任务数，任务以工作项或明确的交互记录为单位，同一任务多次调用 AI 只计一次。分子是其中判定为成功的任务数。判定标准需事先约定，例如“输出可直接提交评审且无需人工改写逻辑”计为成功，“需要补充关键逻辑或重写超过一半”计为失败，“仅调整格式或变量名”计为成功。判定由使用人和评审人共同确认，争议任务单独记录，不计入分子也不计入分母，并在报告中说明数量。
采纳程度的统计对象。采纳率的分母是 AI 给出的建议条数，分子是被采纳的建议条数。建议的计数单位要统一：代码补全按一次补全建议计一条，评审意见按一条意见计一条，修复建议按一个修复点计一条。采纳判定以建议内容进入最终产物为准，例如补全代码保留在提交记录中、评审意见被回复确认并修改。同一建议被多次展示只计一条，去重按建议内容哈希或工具侧唯一标识执行。
时间窗与去重。所有指标使用同一观察期，起止时间精确到日。跨期任务按完成时间归属，未完成任务不计入成功率分母，但在活跃使用率中计入使用人数。同一研发人员在同一环节的多次使用不重复计入人数类指标。对比基准期与观察期长度一致，若基准期数据缺失超过两成，应缩短观察期或改用对照组。
缺失值处理。缺失分三类：工具日志缺失、判定记录缺失、成本数据缺失。工具日志缺失超过单指标样本的一成时，该指标标注为“数据不完整”，不给出确定结论；判定记录缺失的任务从成功率分母中剔除并单独列出数量；成本数据缺失时投入产出指标留空，不用估算值替代。所有缺失处理方式在口径说明中固定，评估过程中不临时更改。
数据来源可核验。每个指标注明数据来源系统、提取方式和提取时间。工作项状态、评审记录、提交记录应能追溯到具体条目；工具使用日志应保留原始记录以便抽样复核。评估报告附一份数据来源清单，供他人按同样口径复算。
计算与评估步骤：从取数到结论的流程
执行流程分五步，按顺序完成，每步留下可检查的中间产物。
- 取数与清洗。按口径说明从工作项系统、代码仓库、评审记录和工具日志提取观察期与基准期数据。清洗规则包括：剔除测试账号和机器人记录；统一任务标识，合并同一任务的多次交互；标记缺失字段。清洗后输出一张任务级明细表，每行一个任务，包含团队、环节、使用日期、是否成功、建议条数、采纳条数、处理时长等字段。
- 逐指标计算。先算分母明确的比率类指标，任务成功率、一次通过率、采纳率、活跃使用率；再算耗时和返工类指标，按团队和环节分组计算均值或占比；最后算投入产出，成本数据到位后再计算。每个指标同时输出样本量和缺失数量，样本量过小的分组单独标注。
- 设置对照。优先采用同期对照组：选择任务类型、技术栈和人员经验相近的未使用团队，按相同口径计算指标。无法设置对照组时采用前后对比，基准期取使用前同等长度的连续周期，并检查两个周期的任务结构是否接近，例如需求类型分布、平均任务规模。结构差异明显时，在报告中列出差异项，不直接比较总量。
- 收益归因。计算效率收益时排除以下干扰：同期人员变动、版本节奏差异、需求难度变化、其他工具或流程改进、统计口径调整。做法是对每个干扰项记录是否存在及影响方向，无法排除的干扰在结论中说明。归因结论使用“在排除已识别干扰后，观察期内该环节平均处理时长下降 X 小时”这类表述，不写成“AI 带来了 X 小时收益”。
- 形成结论与复评计划。按“指标结果—样本量—限制条件—建议动作”的结构输出结论，明确哪些结论可以支持决策，哪些需要补充数据。复评时间建议与下一个研发周期对齐，复评时沿用同一口径，口径变更需单独说明。
评估所需的任务明细、判定记录和成本数据通常分散在工作项、文档和评审记录中。ONES 可以承载这些工作项状态、评审记录和文档，让评估人员按团队、环节和时间窗提取同一口径的数据，减少手工汇总造成的口径偏差。评估流程本身仍按上述步骤执行，工具承担的是数据归集和状态留痕。
例子：一个研发环节的完整算例
以下为演示情景，数据为假设值，用于说明公式代入和结果解读方式。
场景与假设。某后端团队在编码环节使用 AI 代码补全工具，观察期为 4 周。纳入统计的任务为 200 个编码工作项，其中 12 个因判定记录缺失被剔除，有效任务 188 个。工具日志记录 AI 给出补全建议 5000 条，去重后 4600 条，其中 1380 条保留在最终提交中。基准期为使用前 4 周，同类任务 180 个，平均处理时长 6.5 小时；观察期有效任务平均处理时长 5.8 小时。观察期 AI 工具及配套投入合计 24000 元。
任务成功率。188 个有效任务中，判定为成功的有 141 个，需要重写关键逻辑的 39 个，争议任务 8 个未计入。任务成功率 = 141 ÷ 188 ≈ 75.0%。报告中同时注明剔除 12 个缺失任务和 8 个争议任务。
采纳程度。采纳率 = 1380 ÷ 4600 ≈ 30.0%。若按原始建议条数计算则为 1380 ÷ 5000 = 27.6%，两种口径差异来自去重，报告采用去重口径并说明原因。
效率收益。前后对比的平均处理时长差为 6.5 − 5.8 = 0.7 小时/任务。按观察期 188 个任务折算，节省约 131.6 小时。该结果需检查两个周期任务结构是否接近；若观察期包含更多小规模任务，0.7 小时的差值可能被高估，应在结论中注明。
投入产出。单位任务 AI 成本 = 24000 ÷ 188 ≈ 127.7 元/任务。节省工时折算需使用团队统一的工时成本口径，本例不给出金额结论，只保留工时数据供决策方按自身口径换算。
结果解读。可以得出的结论是：在演示条件下，该环节任务成功率约四分之三，采纳率约三成，平均处理时长下降 0.7 小时，单位任务 AI 成本约 128 元。不能得出的结论包括：不能据此推断 AI 是时长下降的唯一原因；不能把 75% 的成功率当作所有编码任务的通用水平；不能由单环节结果推断其他研发环节的效果；不能把采纳率低直接解释为工具无用，采纳率受建议类型和展示方式影响。
解读与限制：指标能说明什么、不能说明什么
指标说明的是观察期内的统计结果，不是因果保证。解读时先看样本量和分母，再看结果方向，最后看限制条件。以下规则用于避免常见误读。
- 分母为零或样本过少。某环节没有有效任务时，成功率不计算，报告写“无有效样本”，不写 0%。样本量低于约定下限（例如少于 30 个任务）时，比率类指标只作参考，不进入决策结论；确需使用时应给出置信区间或直接标注“样本不足”。
- 跨团队与跨任务难度的可比性。不同团队的技术栈、需求复杂度和人员经验不同，直接比较成功率或耗时容易得出错误结论。比较时按任务类型和规模分层，或只比较同一团队的前后变化。分层后样本进一步减少的，合并展示并说明分层依据。
- 指标与因果的区别。前后对比和对照组只能支持“相关”判断，排除干扰后才能谨慎表述为“在该观察期内，使用 AI 的环节耗时下降”。存在未识别干扰时，结论应保留不确定性，不用单指标替代整体判断，也不把某团队的结果推广为组织级结论。
- 结论表达。建议采用固定结构：指标名称、结果值、样本量、时间窗、对比基准、已排除和未排除的干扰、适用建议。避免只写“效果显著”或“提升明显”这类无法复算的表述。
- 复评建议。评估结论标注有效期，通常与一个研发周期对齐。复评时沿用原口径；因业务变化需要调整口径的，新旧口径结果并列展示，不直接拼接趋势。复评重点检查上次未排除的干扰是否仍然存在，以及效果在不同任务难度下是否稳定。
把上述规则写进评估报告模板，可以让不同团队按同一方式解读结果，也便于管理层在续费、扩面和用法调整三类决策中引用有依据的结论。
常见问题
观察期应该多长，遇到版本发布等特殊节点怎么处理？
观察期建议覆盖完整的研发节奏，连续 4 至 8 周较为常见，并避开版本发布前后的极端波动。如果观察期无法避开大版本发布，可以在报告中标注该时段，并将发布前后的任务单独分组，比较两组结果是否一致。基准期与观察期长度保持一致；基准期数据缺失超过两成时，缩短观察期或改用同期对照组。
团队规模小、任务样本少，还能做效果评估吗？
可以做，但结论要降级。样本量低于约定下限（例如少于 30 个任务）时，比率类指标只作参考，不进入续费或扩面决策；确需使用时给出置信区间或直接标注“样本不足”。另一种做法是延长观察期积累样本，或把多个相近环节合并统计，合并时说明合并依据和环节差异。
采纳率低是否说明 AI 工具没有价值？
不能直接这样解释。采纳率受建议类型、展示方式和任务构成影响：补全类建议条数多、单条价值低，采纳率天然偏低；评审意见类建议条数少，采纳率通常更高。解读时应按建议类型分别统计，并结合任务成功率和效率收益一起看。采纳率低但任务成功率高，可能说明研发人员只采纳了少数关键建议。
没有条件设置同期对照组，前后对比的结论怎么写才稳妥？
前后对比只能支持相关判断。写法上先检查两个周期的任务结构是否接近，例如需求类型分布和平均任务规模；结构差异明显时列出差异项，不直接比较总量。结论采用“在排除已识别干扰后，观察期内该环节平均处理时长下降 X 小时”这类表述，并写明未排除的干扰，避免写成“AI 带来了 X 小时收益”。
评估数据分散在工作项、代码仓库和工具日志里，怎么保证口径一致？
先固定口径说明，再按同一规则从各来源提取数据，输出一张任务级明细表，每行一个任务，包含团队、环节、使用日期、是否成功、建议条数、采纳条数、处理时长等字段。每个指标注明数据来源系统、提取方式和提取时间，保留原始记录以便抽样复核。ONES 可以承载工作项状态、评审记录和文档，便于按团队、环节和时间窗提取同一口径的数据，减少手工汇总造成的偏差。
评估结论多久需要复评一次，口径变了怎么办？
结论标注有效期，通常与一个研发周期对齐。复评沿用原口径，重点检查上次未排除的干扰是否仍然存在，以及效果在不同任务难度下是否稳定。因业务变化需要调整口径时，新旧口径结果并列展示，不直接拼接趋势，并说明调整时间和原因。
