研发AI应用试点结束时，团队常面对一个尴尬局面：大家感觉“用得还行”，却拿不出可复核的结论。验收标准要解决的就是这个问题——把试点目标拆成可计算的指标，写清口径与证据，再用分档规则判定通过、有条件通过或不通过。本文给出一套可直接套用的指标定义、计算流程与判定方法，适用于需求分析、测试用例等研发管理场景中的AI助手试点。
要点总览（TL;DR）
- 验收对象锁定到具体业务场景与角色，把“AI好不好用”拆成效果、使用、质量与风险三类可核验问题。
- 每项指标写清公式、分子分母、时间窗、单位、数据来源与缺失值处理，形成可复核的口径卡。
- 判定采用分档规则：核心指标达到目标值为通过，落在可接受区间为有条件通过并附整改项，低于下限则暂停扩面。
- 分母为零或样本不足时延长观察期或标注证据不足，不直接判通过；风险类事件单独处理。
- 结论写明试点范围、观察期、样本量与未覆盖场景，指标结果不外推为全面推广后的效果。
试点验收要回答哪几个问题
验收的对象是试点范围内的具体业务场景与角色，例如“某产品团队在需求评审环节使用AI助手生成初稿”，而非AI工具本身。工具只是载体，验收要判断的是：在约定的场景、人群和时间窗内，AI是否带来了可观察、可归因的变化。把对象锁定到场景与角色，后续指标才有明确的分子分母。
围绕这个对象，验收问题可以归为三类：
- 效果目标：AI介入后，任务完成情况、返工情况、人工干预程度是否达到试点前设定的水平。
- 使用目标：目标人群是否真正用起来，使用是否覆盖了约定场景，频次是否稳定。
- 质量与风险目标：AI输出被采纳的比例如何，需要纠正的比例是否可控，是否出现敏感信息泄露或合规事件。
三类问题分别回答“有没有用”“有没有人用”“用得安不安全”，缺一类都会让结论失真。只谈效果不看使用，可能把少数重度用户的表现当成整体；只看使用不看质量，可能忽略返工带来的隐性成本。
验收结论设定三种形态：通过，核心指标达到目标值，可进入扩面准备；有条件通过，指标落在可接受区间，需附整改项并在约定时间内复评；不通过，核心指标低于下限，暂停扩面，先解决暴露的问题。三种形态要在试点启动前写入验收方案，避免结束后再讨论“算不算过”。
验收时点与观察期同样需要前置约定。常见做法是设置一段试运行期用于磨合与调参，试运行期数据不计入正式统计；正式观察期建议覆盖至少一个完整的迭代周期或一个季度，具体长度取决于业务节奏。观察期太短，样本不足；太长，问题暴露滞后。长度一旦确定，验收时不再临时调整。
验收指标与统计范围怎么划
指标清单按三类目标展开，每项指标都要有明确的单位与统计粒度。下表给出一个可直接改用的指标定义框架，具体目标值由试点团队根据基线自行设定，不存在通用达标线。
| 指标名 | 类型 | 单位 | 统计粒度 | 纳入范围 | 排除项 |
|---|---|---|---|---|---|
| 任务完成率 | 效果 | 百分比 | 任务/周 | 试点场景内全部任务 | 试运行期首周、测试数据 |
| 返工率 | 效果 | 百分比 | 任务/周 | 经AI辅助产出的交付物 | 需求变更导致的返工 |
| 人工干预比例 | 效果 | 百分比 | 任务/次 | AI输出后需人工修改的任务 | 格式调整类微调 |
| 活跃使用人数 | 使用 | 人 | 人/周 | 试点名单内成员 | 异常账号、离职账号 |
| 周均使用频次 | 使用 | 次/人 | 人/周 | 活跃用户 | 系统自动触发次数 |
| 场景覆盖率 | 使用 | 百分比 | 场景/周期 | 约定试点场景 | 未纳入试点的场景 |
| 输出采纳率 | 质量 | 百分比 | 输出条数/周 | 抽样或全量AI输出 | 明显无效的重复输出 |
| 需纠正比例 | 质量 | 百分比 | 输出条数/周 | 评审判定需实质修改的输出 | 仅措辞润色 |
| 敏感信息与合规事件数 | 风险 | 起 | 事件/周期 | 试点范围内全部事件 | 无 |
统计范围要写清三件事：纳入哪些团队与角色、覆盖哪些场景、统计哪个时间窗。排除项同样要写明，例如试运行期首周数据、测试账号产生的记录、因组织调整中断使用的周期。排除项一旦确定，验收时不得因结果不理想而临时扩大排除范围。
指标数量宜控制在八到十二项。指标过多会稀释重点，也增加取数与核对成本。建议从中选出三到五项作为核心指标，其余作为辅助指标，核心与辅助的划分在试点启动前确定。
数据口径与证据怎么留
口径卡是验收可复核的基础。每项指标写清五要素：数据来源、计算公式（含分子分母）、时间窗、缺失值处理规则、证据形式。以下用三项指标示范口径卡的写法。
| 指标 | 数据来源 | 公式 | 时间窗 | 缺失值处理 | 证据形式 |
|---|---|---|---|---|---|
| 任务完成率 | 工作项记录中的状态流转 | 按期完成的任务数 ÷ 试点场景内应完成任务总数 × 100% | 观察期内每个迭代 | 状态未更新的任务不计入分母，单独列出数量 | 工作项导出表、状态变更记录 |
| 输出采纳率 | 评审记录与输出记录对照 | 被采纳的AI输出条数 ÷ 纳入统计的AI输出总条数 × 100% | 观察期全周期 | 无评审记录的输出不计入分母 | 抽样评审表、评审意见 |
| 人工干预比例 | 任务修改记录 | AI输出后发生实质修改的任务数 ÷ 使用AI辅助的任务总数 × 100% | 观察期全周期 | 修改记录缺失的任务标注为“无法判定”，不计入分子分母 | 修改前后版本对照、修改说明 |
定性证据与定量数据同等重要。抽样评审记录要说明抽样方法（随机抽样或分层抽样）与样本量；用户反馈整理成问题清单，每条问题标注提出人、场景、处理状态与闭环时间。问题清单的价值在于解释数字背后的原因——采纳率偏低，是输出质量不足，还是使用方式不对，需要定性证据支撑判断。
证据留存要求原始数据可回溯。系统日志、工作项记录、评审记录应保留导出件或快照，抽样过程可复现。若观察期内发生口径变更，例如调整了某指标的统计范围，需在验收材料中单独记录变更时间、原因与影响，变更前后的数据分段呈现，不混算。
在ONES中开展试点时，试点任务、评审记录与问题闭环可以承载在同一套工作项与文档体系中。ONES Assistant连接ONES Project、ONES Wiki与ONES TestCase，理解项目、工作项、迭代和Wiki页面等工作上下文，基于相关项目数据和团队知识回答问题并执行后续操作；其输出过程可追踪、结果可审计，便于在验收时回溯AI参与的任务与评审痕迹。取数时仍需按上文口径卡确认具体字段与导出方式，以实际系统配置为准。
验收怎么算、怎么判
计算按五步走：取数，从约定来源导出原始记录；清洗，剔除排除项、处理重复与异常记录；按口径计算，逐项套用公式得出指标值；交叉核对，用第二种来源或人工抽样验证关键指标，差异超过约定阈值时查明原因；形成指标结果表，每项指标附计算过程与证据索引。
分档判定为每项指标设定三个值：目标值、可接受区间下限、下限。目标值对应“通过”，落在可接受区间对应“有条件通过”，低于下限对应“不通过”。三个值的设定依据是试点前的基线数据与业务期望，没有基线时可用试运行期数据作为参考，并在结论中注明基线来源。
组合判定规则建议如下：核心指标全部达到目标值，且辅助指标无低于下限项，判为通过；核心指标全部不低于可接受区间下限，允许一至两项辅助指标落在可接受区间，判为有条件通过，附整改项与复评时间；任一核心指标低于下限，或风险类指标出现约定级别以上的事件，判为不通过。核心与辅助的名单、允许落在区间的项数，都在试点启动前写定。
分母为零或样本不足时，不直接判通过。处理方式有两种：延长观察期补足样本，或在结论中标注“证据不足”，该项指标不参与组合判定，同时说明缺失原因。风险类指标出现敏感信息或合规事件时，按事件级别单独处理，不因其他指标达标而抵消。
验收会议按固定流程进行：先呈现指标结果表与证据索引，再由试点团队与业务方逐项核对异议，异议涉及数据的当场查证，最后形成结论并签署。会议记录与结论一并归档，作为后续扩面决策的依据。
一个可复算的验收示例
以下为演示情景，数字用于说明计算方法，不代表任何真实项目结果。
某研发团队在需求分析与测试用例两个环节试点AI助手，试点成员20人，观察期为一个季度共6个迭代。试点前约定：任务完成率目标值90%、可接受区间下限85%、下限80%；输出采纳率目标值70%、可接受区间下限60%、下限50%；人工干预比例目标值30%以下、可接受区间上限40%、下限（即超过即不通过）50%。
任务完成率：观察期内两个场景应完成任务共240项，按期完成216项，完成率216÷240＝90%，达到目标值。
输出采纳率：AI输出共1200条，其中100条无评审记录不计入分母，纳入统计1100条，被采纳748条，采纳率748÷1100≈68%，落在60%至70%之间，属有条件通过区间。
人工干预比例：使用AI辅助的任务共200项，其中发生实质修改的58项，干预比例58÷200＝29%，低于30%，达到目标值。
组合判定：三项核心指标中两项达标、一项落在可接受区间，按规则判为有条件通过，整改项为“提升输出采纳率”，复评时间设在下一个迭代结束后。复评时若采纳率达到70%以上，转为通过；若仍低于60%，则重新评估是否暂停扩面。
样本不足的处理示例：若测试用例场景在观察期内仅产生30条AI输出，低于约定的最小样本量50条，则该场景的采纳率标注为“证据不足”，不参与组合判定，改为延长一个迭代观察，或在结论中限定该场景的判定范围。
结果怎么解读，哪些限制要写进结论
指标反映的是试点期、试点范围内的表现。试点团队通常配合度高、场景经过挑选，全面推广后人群扩大、场景变杂，效果可能出现回落。结论中应明确写出“本结论仅适用于试点场景与试点人群”，不外推为全面推广后的预期效果。
使用频次高不等于价值高。频次需要与采纳率、返工率、人工干预比例一起看：频次上升而采纳率下降，可能说明用户在反复尝试却得不到可用输出；频次平稳而干预比例下降，才更接近效率改善的信号。单看任何一项都容易误判。
样本量小、场景单一时，结论要加限定表述。例如“在20人团队、两个场景、一个季度的范围内，核心指标达到约定水平”，而非“AI应用取得全面成功”。避免把单指标达标写成整体成效，也避免为不同团队设定统一的达标线——基线不同，目标值本就应当不同。
结论模板可参考以下结构：
- 判定结论：通过／有条件通过／不通过，一句话说明依据的核心指标。
- 指标摘要：各项指标的计算结果、目标值与区间对照。
- 限定条件：试点范围、观察期长度、样本量、口径变更情况。
- 未覆盖场景：本次未纳入试点的环节与角色，说明原因。
- 后续观察项：有条件通过时的整改项与复评时间；通过时的扩面观察指标。
把限定条件与后续观察项写进结论，验收才不只是给试点画一个句号，而是为下一步扩面提供可追踪的起点。
常见问题
试点启动前没定验收指标，结束后还能补吗？
可以补，但结论的可信度会下降。补定指标时，应基于试点前已有的基线数据或试运行期数据设定目标值，并在验收材料中注明目标值的确定时间与依据。若指标是在看到结果之后才定的，容易不自觉地朝有利方向调整，建议由未直接参与试点的业务方参与确认，并把这一情况写进结论的限定条件。
试点团队人数很少，指标算出来波动很大，怎么判？
样本量小时，先看是否达到事先约定的最小样本量。未达到时，该项指标标注为“证据不足”，不参与组合判定，处理方式为延长观察期补足样本，或在结论中限定判定范围。若样本量勉强达标但波动明显，可增加统计周期数取均值，并在结论中说明样本规模，避免用单周数据下结论。
观察期内调整了统计口径，验收结果怎么处理？
口径变更需单独记录变更时间、原因与影响，变更前后的数据分段呈现，不混算。若变更影响核心指标的可比性，可用变更后的口径重新计算全周期数据（前提是原始记录支持回溯），或只对变更后区间作判定并注明覆盖时长。无论哪种方式，都应在结论中说明，不能把两段口径不同的数据直接相加。
AI 输出采纳率怎么统计才不至于各说各话？
关键是先定义“采纳”。建议在口径卡中写明：以评审记录为准，评审人判定为可直接使用或仅需格式微调的输出计为采纳，需实质修改的计为未采纳，无评审记录的输出不计入分母并单独列出数量。抽样评审时说明抽样方法与样本量，评审表保留评审人、时间与意见，便于复核时逐条对照。
试点期间出现一次敏感信息事件，其他指标都达标，能判通过吗？
风险类指标按事件级别单独处理，不因其他指标达标而抵消。若事件达到试点方案中约定的级别，通常判为不通过或暂缓扩面，先完成原因分析与整改，再评估是否重新观察。事件未达约定级别时，可在有条件通过的结论中列为整改项，明确整改责任人与复评时间。
验收通过后直接全面推广，还需要看什么？
验收结论只反映试点期、试点范围内的表现，全面推广后人群扩大、场景变杂，效果可能回落。扩面阶段建议保留试点期的核心指标作为观察项，按相同口径持续统计，并新增覆盖场景数与新增用户的使用情况。发现指标明显偏离试点水平时，回到口径卡核对是数据问题还是使用方式问题，再决定是否调整推广节奏。
