研发AI效果评估的关键，是先界定AI介入了哪个研发环节、改变了什么动作，再为每个环节设定可复算的指标。本文按“评什么—用什么指标—数据怎么取—怎么算—怎么解读”的顺序，给出指标口径、计算步骤和结果解释边界，并附一个编码环节的完整算例。评估所需的采纳记录、工作项流转和评审数据，通常可以在研发管理工具中沉淀。
要点总览（TL;DR）
- 先按研发环节拆解评估对象，写明AI介入的具体动作与预期改变，再为每个环节设定指标，避免笼统评价整体AI价值。
- 指标分过程、结果、体验三类，每个指标写清统计对象、时间窗、单位与最小样本要求，保证不同人按同一口径能复算出相同结果。
- 计算按固定窗口取数、清洗、计算并标注样本量、同口径对比、排查替代性解释、形成结论六步推进，结论分支持、部分支持、证据不足三档。
- 解读时守住边界：相关不等于因果，采纳率高不代表质量高，短期小样本试点结论不宜直接外推到全组织，也不设通用达标线。
- 评估结果适合用于调整使用方式与投入节奏；若与考核关联，宜用团队级结果并配合质量指标，避免使用行为变形。
评估目标：先界定AI用在哪个研发环节
笼统地问“AI有没有效果”，很难得到可验证的答案。更可行的做法是把AI应用拆到具体研发环节，逐个环节写明AI介入的动作和预期改变，形成一份评估对象清单。清单之外的环节本次不评，避免范围失控。
常见可纳入评估的研发环节包括：需求分析与拆解、编码、代码评审、测试用例生成、缺陷定位、文档撰写。每个环节都要落到“AI做了什么、期望改变什么”，例如编码环节的AI补全期望减少编写耗时，代码评审环节的AI建议期望减少评审轮次或漏检问题。
| 研发环节 | AI介入的具体动作 | 预期改变 |
|---|---|---|
| 需求分析 | 辅助拆解需求、生成验收要点 | 需求澄清耗时、返工修改次数 |
| 编码 | 代码补全、片段生成 | 编码耗时、合并后返工率 |
| 代码评审 | 生成评审意见、问题提示 | 评审轮次、评审发现的问题数 |
| 测试用例生成 | 根据需求或代码生成用例草稿 | 用例编写耗时、用例覆盖缺口 |
| 缺陷定位 | 辅助分析日志与调用链 | 定位耗时、一次修复率 |
| 文档撰写 | 生成说明文档、周报草稿 | 文档撰写耗时、文档更新及时性 |
评估粒度需要事先确定。团队级评估看整体使用情况和产出变化，适合判断是否扩大投入；项目级评估围绕单个项目的交付与质量，适合验证特定场景；个人级评估关注个体使用行为，适合调整使用方式，但样本小、波动大，不宜单独下结论。三种粒度可以并存，但同一份报告里要标明结论属于哪一级。
需要说明的是，本文讨论的是AI应用效果，技术模型基准测试（如代码生成准确率评测）和通用研发效能指标体系建设不在本次评估范围内，后者属于另一套方法。
指标与范围：选哪些指标、覆盖多大样本
指标不宜多，但要覆盖三个层面：AI是否被用起来、用起来后产出是否变化、使用者是否认可。三类指标配合使用，才能避免只看一头。
- 过程指标：反映AI的实际使用程度，如AI建议采纳率、AI生成内容占比、活跃使用人数占比。
- 结果指标：反映研发产出变化，如需求交付周期、返工率、缺陷密度、评审轮次。
- 体验指标：反映使用者的主观判断，如满意度评分、对AI建议的信任度、继续使用意愿。
每个指标都要写清四个口径要素：统计对象（哪些工作项、哪些提交、哪些人）、时间窗（统计起止日期，以及按创建时间还是完成时间归集）、单位（百分比、小时、个、轮次）、最小样本要求（低于多少条记录不出结论）。这四项缺一项，后续就无法复算。
对照方式有三种，选择取决于条件是否具备：
| 对照方式 | 适用条件 | 主要局限 |
|---|---|---|
| 试点前后对比 | 同一团队、同类任务，试点前后任务结构相对稳定 | 季节波动、人员变动会混入差异 |
| 使用组与未使用组对比 | 存在可比的任务和人员，能划分出两组 | 两组任务难度可能不同，需做匹配 |
| 分阶段灰度对比 | 可分批次放开使用，批次之间条件接近 | 先放开批次可能承担更成熟的任务 |
范围界定同样要写进方案：纳入哪些团队、哪些项目类型、哪些代码库或需求类型；排除项也要写明，例如实验性项目、外包团队、统计期内发生重大组织调整的项目。排除项写清楚，结果才不会被质疑“挑数据”。
数据口径与证据：分子分母从哪里取
指标能否算出来，取决于数据是否可得、是否对得上。研发AI评估的数据通常来自四类来源：研发管理工具中的工作项状态流转记录、代码仓库的提交与评审记录、CI流水线的构建与测试结果、面向使用者的问卷。取数前要确认各系统的记录能按同一标识（如工作项编号、提交号、人员账号）关联。
每个指标都要给出分子、分母和公式。以下为常用指标的参考口径，实际使用时按团队工具字段调整：
| 指标 | 分子 | 分母 | 单位 | 时间窗示例 |
|---|---|---|---|---|
| AI建议采纳率 | 被采纳的AI建议数 | AI建议总数 | % | 按周统计，取试点期均值 |
| AI生成内容占比 | 含AI生成内容的提交或文档数 | 同期提交或文档总数 | % | 按周统计 |
| 需求交付周期中位数 | — | — | 小时或天 | 按需求完成时间归集 |
| 合并后返工率 | 合并后需修复的提交数 | 同期合并提交总数 | % | 合并后14天内 |
| 缺陷密度 | 统计期内新增缺陷数 | 同期交付需求数或代码行数 | 个/需求 | 按版本或迭代 |
| 满意度 | 评分≥4的人数 | 有效问卷人数 | % | 试点结束时一次性收集 |
缺失值处理规则要提前定好，常见情形有三类。无记录：某工作项没有状态流转记录，按缺失处理并从分母中剔除，同时记录剔除数量。未标记AI使用：无法判断是否使用AI的记录，单独归为“未知”组，不并入使用组或未使用组。跨系统对不齐：工作项与提交无法关联时，该条记录不参与依赖关联的指标计算，并在报告中说明影响范围。
定量结果需要定性证据配合解释。访谈记录、评审意见、典型任务样本（如同一类需求在试点前后的处理过程）可以帮助判断数字变化是否来自AI，还是来自任务本身变简单了。定性证据也要有留存方式，例如访谈提纲、记录人和日期。
如果评估数据分散在多个系统中，可以在研发管理工具里统一沉淀。ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，能理解项目、工作项、迭代和 Wiki 页面等工作上下文，并可将结果保存为工作项、Wiki 页面等内容。评估方案、指标定义表和阶段性结论可以沉淀在 Wiki 页面中，与工作项记录相互对应，便于复算时追溯。
计算与评估步骤：从取数到结论的六步
同一份数据由不同人计算应得到相同结果，这要求步骤固定、口径固定。以下六步可以作为通用流程。
- 固定评估窗口与基线期。写明试点起止日期和基线期起止日期，两者长度尽量一致，并确认期间没有重大流程变更。
- 按指标定义取数并清洗。逐指标导出原始记录，按缺失值规则处理，记录剔除条数和原因。
- 计算各指标值并标注样本量。每个指标同时给出数值和参与计算的记录条数，样本量不足最小要求的标注“样本不足”。
- 做同口径对比并给出差异区间。使用组与未使用组、或试点前后，按相同公式计算，差异用绝对值和相对变化同时表达，并给出区间而非单点。
- 排查替代性解释。检查任务难度、人员构成、需求类型是否在两组或两期之间发生变化；有变化时说明其对结果的可能影响。
- 形成结论。按“支持、部分支持、证据不足”三档判定，每档写明条件。
判定规则建议如下：结果指标在同口径对比中方向一致、差异区间不跨零、样本量达到最小要求，且替代性解释排查后仍成立，判为“支持”；部分指标改善、部分指标无变化或方向相反，判为“部分支持”；样本不足、数据缺失严重或差异可被任务结构变化解释，判为“证据不足”。
分母为零或样本过小时，不计算比率，直接标注“不可计算”并说明原因，例如“统计期内AI建议数为0”。不要用0%或100%代替缺失，也不要用扩大时间窗的方式凑样本而不说明。
例子：一个编码环节的完整算例
以下为演示用假设数据，用于说明计算过程，不代表任何真实团队的结果。
背景：某团队在编码环节引入AI辅助，试点8周，选取20名工程师，其中10人使用AI辅助（使用组），10人未使用（未使用组），两组承担同类需求。基线期为试点前8周。
指标一：AI建议采纳率。试点期内系统记录AI建议共4800条，其中被采纳1728条。采纳率=1728÷4800=36.0%。该指标只在使用组内计算，用于确认AI确实被使用，不直接说明产出变化。
指标二：需求交付周期中位数。使用组试点期完成需求46个，周期中位数62小时；基线期完成需求44个，中位数78小时。未使用组试点期中位数75小时。同口径对比：使用组较自身基线缩短16小时，较未使用组同期少13小时。
指标三：合并后返工率。使用组试点期合并提交320次，其中合并后14天内需修复的28次，返工率=28÷320=8.75%；基线期为9.1%；未使用组同期为8.9%。差异较小。
结论示例：交付周期指标显示改善，方向与预期一致，样本量满足要求，判为“支持”；返工率基本持平，说明效率提升未伴随明显的质量下降，但也不能证明质量提升；采纳率36.0%说明AI被部分使用，需结合访谈了解未采纳原因。若访谈发现试点期需求拆分更细，则周期缩短可能部分来自需求结构变化，结论应调整为“部分支持”，并补充同类需求的配对对比数据。
解读与限制：哪些结论能下、哪些不能
评估结果的价值在于指导下一步动作，而不是给AI下一个总体定论。解读时需要守住几条边界。
相关不等于因果。周期缩短可能来自需求拆分方式变化、人员调整、需求类型变简单等混杂因素。报告里应列出已排查的替代性解释和未能排除的因素，让读者知道结论的强度。
指标之间会相互影响。采纳率高只说明AI建议被接受得多，不代表产出质量高；如果返工率和缺陷密度同时上升，效率改善可能以质量为代价。过程指标、结果指标、体验指标要放在一起看，单个指标不构成AI整体价值的证明。
样本量和观察期决定结论的适用范围。8周试点、几十个需求的样本，适合判断“这个团队在这个环节是否值得继续用”，不宜直接外推到全组织。扩大范围前，建议在更多团队重复同口径评估。
不设通用达标线。采纳率多少算好、周期缩短多少算有效，取决于基线水平和业务目标。阈值应在评估方案中结合基线确定，并在报告中写明设定依据。
评估结果的使用方式也要提前约定。结果适合用于调整使用方式、优化提示与流程、决定投入节奏；直接作为个人绩效依据，容易导致使用行为变形，例如为凑采纳率而接受低质量建议，反而破坏数据可信度。若确需与考核关联，应使用团队级结果并配合质量指标。
常见问题
试点期只有几周、样本只有几十个需求，这样的评估结果能用吗？
可以用，但要限定用途和表述。样本量小、观察期短时，结论适合回答“这个团队在这个环节是否值得继续用”，不适合直接外推到全组织或作为AI整体价值的证明。
具体做法是：在报告中同时给出指标值和参与计算的记录条数，样本量低于方案设定的最小要求时标注“样本不足”；差异用区间表达而非单点；扩大范围前，在更多团队按同一口径重复评估，观察方向是否一致。
团队没有单独标记哪些工作用了AI，采纳率这类指标还能算吗？
能算的指标会受限，需要调整口径并说明影响。无法判断是否使用AI的记录，建议单独归为“未知”组，不并入使用组或未使用组，避免把不确定的记录算成使用或未使用。
依赖AI使用标记的指标（如采纳率、生成占比）在标记缺失严重时，可先标注“数据不足”，同时用不依赖该标记的结果指标（如交付周期、返工率）做辅助判断，并在报告中写明缺失条数和剔除规则。后续评估前，先把使用记录方式固定下来，再开始统计。
交付周期缩短了，怎么判断是不是AI带来的？
需要排查替代性解释。常见混杂因素包括需求拆分变细、人员构成变化、需求类型变简单、统计期内发生流程调整。做法是检查使用组与未使用组、试点前后两期的任务难度和需求类型分布是否可比，必要时做同类需求的配对对比。
如果差异可被任务结构变化解释，结论应调整为“部分支持”或“证据不足”，并列出已排查和未能排除的因素。相关关系可以支持继续观察和投入，因果结论需要更严格的对照条件。
评估结果要不要和工程师个人绩效挂钩？
建议谨慎。把采纳率等过程指标直接作为个人绩效依据，容易让使用行为变形，例如为凑采纳率而接受低质量建议，反而破坏数据可信度。
更稳妥的用法是把结果用于调整使用方式、优化提示与流程、决定投入节奏。若确需与考核关联，宜使用团队级结果，并同时看返工率、缺陷密度等质量指标，避免单一指标驱动。
评估数据分散在项目管理、代码仓库和问卷里，怎么保证能复算？
关键是固定口径并保留原始记录。每个指标写清数据来源系统、取数条件、分子分母公式、时间窗和剔除规则；取数后保留原始导出文件和清洗记录，注明剔除条数与原因。
评估方案、指标定义表和阶段性结论可以统一沉淀在文档中，与工作项记录相互对应，便于他人按同一口径复算。ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，能理解项目、工作项、迭代和 Wiki 页面等工作上下文，并可将结果保存为工作项、Wiki 页面等内容，适合承载评估方案与结论的沉淀。
