AI试点效果评估要先把“试点想改变什么”写成可观察的目标，再为每个目标配一组指标：使用侧看采纳与活跃，产出侧看返工与交付节奏，质量侧看缺陷与回滚，体验侧看评审通过率与人工修正量。每个指标都要固定分子、分母、时间窗和单位，并与试点前的基线或未使用AI的对照组比较。结论只说明在该范围内观察到的变化，不把单指标上升当作AI带来收益的证明。
要点总览（TL;DR）
- 评估从问题清单开始：把“试点有没有效果”拆成采纳、产出、质量三类可回答的问题，每个问题写明评估对象、时间窗和判断用途。
- 指标分四组：采纳看周活跃使用人数占比与人均交互次数，产出看交付周期、人工工时与评审轮次，质量看缺陷密度、回滚率与返工率，体验看一次通过率与人工修正比例。
- 每个指标写成口径卡，固定分子、分母、时间窗、单位和缺失值处理规则，基线期与试点期取数范围保持一致。
- 执行按六步走：定范围与基线、冻结口径、按周采集并记录异常、计算变化幅度、归因排查干扰、形成结论并标注证据强度。
- 结论限定在试点范围和时间窗内表述，单指标变化只描述现象，达标线来自试点前基线与业务要求。
先定评估目标：试点要回答哪几个问题
试点评估的起点是问题清单，指标清单排在后面。试点启动前，评估负责人应与试点团队负责人一起，把“AI试点有没有效果”拆成若干可回答的问题，每个问题写明评估对象、时间窗和判断用途。问题数量控制在三到五个，超出这个范围通常意味着试点范围本身没有收敛。
研发场景中的AI试点问题大致分三类。采纳问题关注团队是否真的在用：哪些角色在什么任务上使用了AI，使用是否持续。产出问题关注工作方式是否变化：需求从进入到交付的周期、单需求投入的人工工时、代码评审轮次是否出现可观察的移动。质量问题关注变化是否以牺牲质量为代价：缺陷密度、回滚率、AI生成内容的返工比例是否稳定。三类问题需要同时回答，只回答采纳问题容易把“装了工具”当成“产生了效果”。
每个问题还要绑定判断用途。继续投入、调整使用方式、停止试点是三种不同结论，对应的证据要求不同：继续投入需要产出或质量侧出现方向一致的变化；调整使用方式需要定位到具体环节的阻塞，例如评审环节修正量偏高；停止试点需要多个维度同时没有变化，或质量侧出现明显恶化。把用途写在目标清单里，可以避免试点结束后拿着数据反推结论。
评估目标清单建议包含四列：目标编号、待回答问题、评估对象与时间窗、判断用途。例如“目标2：AI辅助编码是否缩短需求交付周期；对象为试点团队A的20个已交付需求，时间窗为试点期8周；用途为决定是否扩大到第二个团队”。这份清单是后续指标设计和取数的依据，试点开始后不再随意增删。
指标与范围：采纳、产出、质量、体验四组指标
指标围绕S1的问题设置，每组只保留能稳定取数、能解释含义的少数几个。下表给出常用指标集合，指标名称、所属组、衡量对象和单位一次写清，避免同一指标在不同报表里出现两种叫法。
| 指标名称 | 所属组 | 衡量对象 | 单位 |
|---|---|---|---|
| 周活跃使用人数占比 | 采纳 | 试点团队中每周至少使用一次AI的人数占团队总人数 | 百分比 |
| 人均AI交互次数 | 采纳 | 试点期内人均每周与AI工具的交互次数 | 次/人·周 |
| 需求交付周期 | 产出 | 需求从进入开发到上线的自然日 | 天 |
| 单需求人工工时 | 产出 | 单个需求投入的人工工时合计 | 人时/需求 |
| 代码评审轮次 | 产出 | 一个合并请求从提交到合入经历的评审轮数 | 轮 |
| 缺陷密度 | 质量 | 单位交付量对应的缺陷数 | 个/千行或个/需求 |
| 回滚率 | 质量 | 上线后发生回滚的发布占全部发布的比例 | 百分比 |
| AI生成内容返工率 | 质量 | AI生成后被人工实质性修改或废弃的内容占比 | 百分比 |
| 评审一次通过率 | 体验 | 首次提交即通过评审的合并请求占比 | 百分比 |
| 人工修正比例 | 体验 | AI产出中人工修改行数占产出总行数的比例 | 百分比 |
每个指标都有明确的衡量边界。采纳类指标反映使用行为，不反映产出好坏；交互次数高可能是任务复杂，也可能是反复重试。产出类指标受需求拆分粒度影响，需求拆得越细，周期越短，因此基线期与试点期的拆分规则要保持一致。质量类指标需要区分缺陷发现阶段，测试阶段发现的缺陷与线上缺陷含义不同。体验类指标中的一次通过率依赖评审标准，评审人更换会直接影响数值。
指标集合不覆盖的内容也要写明：不评估模型本身的能力水平，不评估工具采购成本与许可费用，不把单个团队的数值外推到全组织。试点范围之外的团队、任务类型和工具版本不纳入统计，避免样本混杂。
数据口径：分子、分母、时间窗与缺失值
口径卡是评估能否复算的关键。每个指标一张卡，写清计算公式、分子、分母、时间窗、单位、数据来源和缺失值处理规则，交给数据同学即可取数。下表以三个指标为例展示口径卡结构，其余指标按同样格式补齐。
| 要素 | 周活跃使用人数占比 | 代码评审轮次 | AI生成内容返工率 |
|---|---|---|---|
| 计算公式 | 周活跃使用人数 ÷ 团队在册人数 | 评审轮数总和 ÷ 合并请求数 | 被实质修改或废弃的AI产出量 ÷ AI产出总量 |
| 分子 | 当周至少一次有效交互的去重人数 | 每个合并请求的评审轮数之和 | 人工修改行数超过阈值或整段废弃的产出量 |
| 分母 | 当周团队在册人数 | 当周合入的合并请求数 | 当周AI产出的总行数或总条目数 |
| 时间窗 | 自然周，周一至周日 | 按合并请求合入日期归属周 | 按产出被采纳或废弃的日期归属周 |
| 单位 | 百分比 | 轮/请求 | 百分比 |
| 数据来源 | 工具埋点 | 代码平台评审记录 | 人工抽样记录 |
基线期与试点期的取数范围必须一致：同一批团队、同类任务、相同的统计时间窗长度、相同的需求拆分规则。如果试点期团队人数发生变化，分母按在册人数逐周计算，不用期初人数统一折算。跨期比较时，节假日、版本封版等特殊周单独标注，不直接混入均值。
缺失值和边界情况按统一规则处理。分母为零时该周指标记为“无数据”，不记为零，也不参与均值计算；样本量低于约定下限（例如合并请求少于10个）时只报告原始计数，不报告比率；埋点数据缺失超过当周应记录量的一定比例时，该周标记为数据不完整，在结论中说明。工具埋点与人工记录的口径差异要提前对齐，例如“有效交互”是否包含自动补全、是否去重同一会话，这些定义写进口径卡，不在分析阶段临时调整。
评估步骤：从基线到对比的六步流程
评估流程按固定顺序执行，每一步留下产出物，保证结果可以被第二个人复算。下表给出六步流程、负责人和产出物。
| 步骤 | 动作 | 负责人 | 产出物 |
|---|---|---|---|
| 1 | 确定试点范围，选定对照组或基线期 | 评估负责人 | 范围说明与分组名单 |
| 2 | 冻结指标口径并留档 | 评估负责人与数据同学 | 口径卡版本记录 |
| 3 | 按周采集数据，记录异常事件 | 数据同学 | 周度数据表与异常日志 |
| 4 | 计算试点期与基线期指标值及变化幅度 | 数据同学 | 对比计算表 |
| 5 | 归因排查，排除发布节奏、人员变动等干扰 | 评估负责人与团队负责人 | 归因记录 |
| 6 | 形成结论并标注证据强度 | 评估负责人 | 评估报告 |
第1步的对照组选择决定结论强度。能设置同期对照组的，优先选任务类型相近、未使用AI的团队；无法设置对照组的，使用试点前足够长的基线期，基线期长度与试点期保持一致。第2步冻结口径后，试点期间新增的指标只能作为补充观察，不进入主结论。
第3步的异常日志记录三类事件：工具故障或不可用时段、团队人员进出、发布节奏变化（如集中封版、大版本上线）。这些事件在归因时用于解释指标波动。第4步计算变化幅度时同时给出绝对值和相对值，例如评审轮次从2.4轮降到2.1轮，降幅0.3轮、约12.5%，避免只报百分比掩盖基数大小。
第5步的归因排查逐项核对：指标变化是否与异常日志中的事件时间吻合，是否只出现在部分子团队，是否在多个指标上方向一致。第6步在报告中为每条结论标注证据强度，分为“有对照组支持”“仅有前后对比”“数据不完整仅作参考”三档，管理层据此判断结论的可信程度。
试点期间的工作项状态、评审记录和测试结果需要有稳定的记录位置。ONES 的项目与工作项数据可以承载需求、任务和缺陷的状态流转记录，ONES TestCase 支持测试用例与需求、任务关联，并提供测试计划进度与通过率概览，便于在评估时按同一时间窗回溯测试侧数据。采纳类指标如交互次数、活跃人数，需要另行确认工具的埋点或统计方式，再决定取数路径。
算一个例子：代码评审环节的AI试点
以下为演示情景，数据为假设值，用于说明计算过程。某研发团队8人，在代码评审环节引入AI辅助生成评审意见和修改建议，试点期8周，基线期为试点前8周。团队在这16周内需求拆分规则和评审标准未变，无人员进出。
原始数据：基线期合入合并请求160个，评审轮数合计384轮，首次提交即通过的请求48个，AI未介入，人工修正比例不适用。试点期合入合并请求152个，评审轮数合计319轮，首次提交即通过的请求61个，AI生成评审建议共约2400条，其中被人工作出实质性修改或废弃的约840条。
计算过程：评审轮次基线期为384÷160＝2.4轮，试点期为319÷152≈2.1轮，下降约0.3轮，降幅约12.5%。评审一次通过率基线期为48÷160＝30%，试点期为61÷152≈40.1%，上升约10.1个百分点。AI生成内容返工率为840÷2400＝35%，即约三分之二的AI建议被直接采纳或小幅调整后使用。
这组数据能支持的结论是：在该团队、该8周时间窗内，代码评审轮次下降、一次通过率上升，同时AI评审建议的返工比例为35%。不能得出的结论包括：评审效率提升全部由AI带来（同期可能有需求复杂度下降、评审人经验积累等因素）；该结果适用于其他团队或其他任务类型；返工比例35%属于可接受水平（这取决于团队对评审质量的业务要求，需要与基线期的人工评审修改情况对比后才能判断）。
解读与限制：哪些结论能说，哪些不能说
结论强度首先取决于样本量和试点周期。8周、150个左右合并请求的样本，可以观察到方向性变化，但不足以支撑精细的分层结论，例如按需求类型拆分后的差异。试点周期短于一个完整发布周期时，回滚率、线上缺陷密度这类滞后指标可能尚未充分体现，报告中应注明观察窗口不足。
指标之间存在牵制关系，解读时要成组看。评审轮次下降如果伴随一次通过率下降或线上缺陷密度上升，说明速度提升可能以质量为代价；AI生成内容返工率下降如果同时人工修正比例上升，说明团队在使用方式上发生了变化，需要结合使用记录判断。任何单指标的变化都只描述现象，不构成AI产生收益的证明。
达标线来自试点前的基线和业务要求，不设通用数值。例如评审轮次的改善目标，应由团队根据基线值和质量底线共同确定，并在试点启动前写入评估目标清单。评估报告中的结论按固定句式表述：“在[团队范围]、[时间窗]内，[指标]从[基线值]变为[试点值]，变化幅度为[数值]，证据强度为[档位]，可能的干扰因素包括[列举]。”这种表述把范围、时间、数值和限制放在一起，读者可以自行判断结论的适用范围。
报告还应附一份限制说明清单：样本覆盖了哪些团队和任务类型，哪些指标因数据缺失未纳入，哪些同期事件可能影响结果，哪些结论需要更长周期或更大样本才能确认。清单与结论一起交付，避免结论在传播过程中被简化成“AI让效率提升了12%”这类脱离范围的表述。
常见问题
试点期只有8周、样本量不大，评估结论怎么写才站得住？
样本量和周期决定了结论能说到什么程度。8周、一百多个合并请求的样本，可以支撑方向性判断，例如评审轮次是否下降、一次通过率是否上升，但不足以支撑按需求类型、按人员分层后的细分结论。写法上建议把范围、时间窗和数值放在同一句里，例如“在试点团队A的8周窗口内，评审轮次从2.4轮降到2.1轮”，并注明证据强度属于“仅有前后对比”还是“有对照组支持”。
对回滚率、线上缺陷密度这类滞后指标，如果试点期短于一个完整发布周期，应在报告中注明观察窗口不足，结论留待下一周期补充，不用短期数据下判断。
团队人数在试点期间发生变化，采纳类指标的分母怎么处理？
分母按周计算，不用期初人数统一折算。周活跃使用人数占比的分子是当周至少一次有效交互的去重人数，分母是当周团队在册人数，两者都按自然周取数。人员进出属于异常事件，应记录在异常日志里，归因时用于解释指标波动。
如果某周在册人数过少，或新成员尚未进入稳定使用状态，可以在报告中单独标注该周，不直接混入均值。口径卡中提前写明“有效交互”的定义，例如是否包含自动补全、同一会话是否去重，避免分析阶段临时调整。
工具埋点数据和人工记录数据对不上，以哪个为准？
先判断两类数据各自衡量什么，再决定用途，不用简单取舍。埋点数据适合统计使用行为，例如交互次数、活跃人数，但“有效交互”的定义需要与工具方确认；人工记录适合统计返工、修正这类需要判断的内容，但受记录人主观标准影响。
可行做法是在口径卡中分别写明两类数据的数据来源和统计规则，同一指标只选一种来源作为主口径，另一种作为交叉验证。两者差异较大时，在报告中说明差异原因，例如埋点包含自动触发、人工记录只统计实质性修改，而不是把两个数值平均或替换。
试点期间工作项和测试记录分散在多个地方，评估时怎么回溯？
评估要求按同一时间窗回溯需求、任务、缺陷和测试结果，记录位置需要相对稳定。ONES 的项目与工作项数据可以承载需求、任务和缺陷的状态流转记录；ONES TestCase 支持测试用例与需求、任务关联，并提供测试计划进度与通过率概览，便于按时间窗取测试侧数据。采纳类指标如交互次数、活跃人数，需要另行确认工具的埋点或统计方式，再决定取数路径。
建议在试点启动时就确定每类数据的记录位置和责任人，写进评估执行流程单，避免试点结束后再从多个系统拼数据。
评审轮次下降但缺陷密度上升，这个试点算成功还是失败？
这种情况说明指标之间出现了牵制，不能只凭一个方向下结论。评审轮次下降反映评审环节的往返减少，缺陷密度上升反映交付质量承压，两者同时出现时，需要排查变化是否集中在特定需求类型或特定评审人，以及缺陷是在测试阶段还是线上被发现。
报告应把两个指标成组呈现，说明速度变化与质量变化同时存在，并给出下一步动作建议，例如收紧AI评审建议的采纳标准、对高风险需求保留人工复核。是否继续投入取决于团队对质量底线的业务要求，这个判断应在试点启动前写入评估目标清单，而不是事后临时设定。
