研发智能体选型的验收标准，需要围绕本次试点的业务目标拆成可复算的指标组，用同一套口径回答“是否达到进入采购或扩大试点的条件”。本文给出五组核心指标、分子分母与数据来源的写法、从基线到判定的执行流程，并用一个需求整理智能体的算例演示计算，最后说明阈值设定和结论使用的边界。
要点总览（TL;DR）
- 验收标准先锁定试点场景和决策用途，再拆成质量、效率、采纳、成本、安全合规五组指标，避免变成功能对照表。
- 每个指标写清分子分母、数据来源、缺失值规则和证据形式，基线与试点期使用同一套统计边界，保证不同人复算结果一致。
- 判定采用“必须通过项+加权评分项”组合：必须通过项任一不满足即不通过，加权得分只在必须项全部满足时用于放行判断。
- 阈值结合基线、任务难度和业务容忍度设定，不套用通用达标线；分母为零或样本不足时不做比率判定，只并入累计口径。
- 验收结论只对本次试点的团队、任务类型和时间窗有效，需写明复评周期，并区分指标相关性与因果结论。
验收要回答什么：把选型目标转成可判断的问题
验收标准的第一项工作，是写清这次试点要验证什么业务问题、结论将用于哪个决策。研发智能体可以落在需求整理、测试用例生成、缺陷归因、日志排查辅助、接口文档补全等任务上，不同任务的验收重点差别很大。先锁定场景，再谈指标，标准才不会退化成一张功能对照表。
建议在试点启动前填写一张对照表，把目标、问题和用途固定下来：
| 试点目标 | 待验证问题 | 决策用途 |
|---|---|---|
| 减少需求评审前的整理工时 | 智能体产出的需求条目能否被直接采纳，返工比例多高 | 达到阈值则进入采购评审 |
| 提升测试用例初稿覆盖率 | 生成的用例经评审后可用比例、人工补充幅度 | 达到阈值则扩大试点团队 |
| 缩短缺陷初步归因时间 | 归因建议被采纳的比例与平均处理时长 | 未达标则退回，调整场景后复评 |
同时区分两类验收项。“必须通过项”是一票否决性质的条件，例如敏感数据外发次数为零、权限越界事件为零、核心任务质量不低于设定下限；任一项不满足，结论即为不通过。“可接受项”用加权评分累计，允许个别指标略低于目标，由综合得分决定是否放行。这个区分要在试点前确定，避免验收时因结果不理想临时调整规则。
指标与范围：五组核心指标及统计边界
研发智能体的验收指标可归为五组：质量、效率、采纳、成本、安全合规。每组选一到两个主指标即可，指标过多会稀释判断力，也会增加取数负担。
| 指标组 | 指标示例 | 统计对象 | 时间窗 | 单位 |
|---|---|---|---|---|
| 质量 | 一次通过率、返工率、人工修正幅度 | 智能体产出的任务交付物 | 试点全程，按周汇总 | 百分比；修正幅度按字段数或行数计 |
| 效率 | 单任务处理时长、端到端周期 | 纳入试点的任务单 | 与基线同口径的连续四周 | 分钟/任务；小时/周期 |
| 采纳 | 建议采纳率、周活跃使用留存 | 有效建议；试点参与人 | 按周统计，留存看连续周 | 百分比 |
| 成本 | 单任务调用成本、人工复核工时 | 任务单；复核记录 | 试点全程 | 元/任务；人时/任务 |
| 安全合规 | 敏感数据外发次数、权限越界事件 | 调用日志与权限审计记录 | 试点全程，按事件计 | 次 |
统计范围要同步写明：纳入哪些任务类型（例如只统计需求整理中的新增条目，不含历史条目迁移）、哪些角色参与（产品、测试、开发各自的任务是否合并统计）、起止时间，以及排除项（试点前已存在的任务、因需求变更而取消的任务、非智能体环节导致的返工）。范围一旦确定，基线和试点期必须使用同一套边界，否则前后数据不可比。
数据口径与证据：分子分母、来源与缺失值处理
口径的作用是让两个人用同一批数据算出同一个数。每个指标至少写清四件事：公式与分子分母、数据来源、缺失值规则、证据留存形式。
| 指标 | 公式 | 数据来源 | 缺失值/异常值规则 | 证据形式 |
|---|---|---|---|---|
| 建议采纳率 | 被采纳建议数 ÷ 有效建议数 | 智能体建议记录、评审结论 | 未评审的建议不计入分母；重复提交合并为一条 | 建议清单与评审结论导出 |
| 一次通过率 | 首次评审通过的任务数 ÷ 提交评审的任务数 | 评审记录 | 中途撤回后重新提交的，以最后一次提交计 | 评审记录与签字 |
| 返工率 | 发生返工的任务数 ÷ 完成任务数 | 任务流转记录 | 因需求变更导致的返工单独标记并排除 | 任务状态变更日志 |
| 单任务处理时长 | 任务处理总时长 ÷ 完成任务数 | 任务开始与完成时间戳 | 跨周未完成的任务不计入当期 | 时间戳导出 |
| 单任务调用成本 | 调用总费用 ÷ 完成任务数 | 调用账单或用量日志 | 调试期调用单独归集，不摊入任务成本 | 用量明细导出 |
“人工修正幅度”这类定性偏多的指标，建议改为可核验的计数：按字段统计被修改的条目数，再除以总条目数，得到修正比例。评审类指标要保留抽样记录和评审人签字，日志类指标要能导出原始明细，保证验收会上可以现场复算。取数和证据留存如果分散在多个系统，可以在试点方案里指定一个统一承载位置，把任务单、评审结论和用量记录关联到同一工作项下，减少验收时的对账成本。ONES 的工作项与评审记录可以承担这类承载，具体字段设计按团队现有流程配置。
计算与评估步骤：从基线到阈值的完整流程
验收按五步执行，每一步都有明确产物，便于中途检查。
- 采集基线。在引入智能体之前，用与试点完全相同的任务类型、角色和统计口径，采集四周左右的历史数据，得到各指标的基线值。基线是阈值设定的参照，没有基线的阈值只能凭感觉。
- 设定阈值。把指标分为必须通过项与加权评分项。必须通过项给出硬性下限，加权项给出目标值与权重，权重之和为100%。阈值、权重和判定规则在试点启动会上确认并留档。
- 试点期取数。按固定时间窗（建议每周一次）导出数据并复算，形成周报。周报只呈现数据和偏差，不在过程中修改口径；确需调整口径的，要同时重算基线，并在验收报告中说明。
- 对照判定。试点结束后，用最终数据对照阈值逐项判定，记录未达标项的偏差原因，区分是产品能力问题、场景不适配还是使用方式问题。
- 形成结论。结论写明：必须通过项是否全部满足、加权得分多少、建议进入采购、扩大试点还是退回，以及复评时间和需要补充验证的问题。
判定规则建议写成一句话模板：“必须通过项全部满足，且加权得分不低于X分，判定为通过；必须通过项任一不满足，判定为不通过，无论加权得分多少。”这样在验收会上可以直接套用，减少争议。
算例：一个需求整理智能体的验收计算
某团队试点用智能体辅助需求整理，统计时间窗为四周，纳入范围为产品经理提交评审的新增需求条目，共120条。智能体对每条需求给出整理建议，评审人逐条标记采纳或驳回。
采纳率。有效建议数120条，其中被采纳96条，采纳率 = 96 ÷ 120 = 80%。另有8条建议因评审人休假未评审，按规则不计入分母，因此分母为120而非128。
返工率。完成任务数120条，评审后需要返工的18条，其中3条因需求本身变更导致，按规则排除，返工率 = 15 ÷ 120 = 12.5%。
单任务处理时长。120条任务的处理总时长为5400分钟，单任务平均时长 = 5400 ÷ 120 = 45分钟；基线为62分钟，缩短约27%。
判定。假设必须通过项为“敏感数据外发次数为0”和“采纳率不低于75%”，加权项中返工率目标不高于15%、单任务时长目标不高于50分钟。本例必须通过项均满足，加权项也达标，结论为通过，建议进入采购评审。
若必须通过项未达标，例如采纳率为72%，结论写法应为：“必须通过项‘采纳率不低于75%’未满足，实际72%，本次验收判定为不通过；加权得分仅作参考，不作为放行依据。建议分析未采纳建议的集中类型，调整提示词与评审流程后于六周后复评。”
分母为零或样本不足时，不计算比率，直接标注“样本不足，不做比率判定”，并说明后续补样计划。例如某周有效建议仅5条，该周采纳率不单独作为判定依据，只并入累计口径。
解读与限制：阈值怎么定、结论怎么用
阈值应结合基线、任务难度和业务容忍度设定。基线较好时，阈值可以设为“不低于基线”或“较基线改善一定比例”；基线本身波动大的任务，阈值要给区间而非单点。行业里没有通用的达标线，把别处的数字直接搬过来，容易得出与自身业务无关的结论。
解读时注意三类限制。第一，样本量不足会让比率失真，小样本周的数据只作趋势参考。第二，场景差异导致不可比，需求整理与缺陷归因的任务结构不同，指标不能横向比较，也不宜合并成一个总分。第三，指标之间存在权衡，采纳率上升可能伴随返工率同步上升，说明建议更容易被接受但质量下降，这时应看两个指标的联合表现，而不是单独奖励其中一个。
验收结论只对本次试点范围有效，写明适用团队、任务类型和统计时间窗。建议设定复评周期，例如进入采购后每季度复评一次，或在任务类型、模型版本、使用人数发生明显变化时触发复评。单指标达标不能证明智能体带来了整体效率提升，因果判断需要结合对照或前后对比设计，验收报告应把相关性和因果性区分表述。
常见问题
试点期发现口径定义不合理，中途可以改吗？
可以改，但要付出重算成本。口径调整后，基线和已产生的试点数据都需要按新口径重新计算，否则前后不可比。建议在试点启动会上把口径、阈值和判定规则一次确认并留档；确需调整的，在验收报告中单独说明调整原因、调整时点和重算结果，避免验收会上对数据口径产生争议。
智能体只在部分任务上使用，验收时怎么统计才公平？
把统计范围限定在智能体实际参与的任务上，同时记录未使用智能体的同类任务作为参照。两类任务的任务类型、角色和难度要尽量接近，否则对比意义有限。如果无法找到可比参照，就只报告智能体参与任务的绝对指标，并在结论中说明缺少对照，不把改善全部归因于智能体。
必须通过项和加权评分项的权重怎么分配？
必须通过项只放一票否决性质的条件，例如敏感数据外发为零、权限越界为零、核心任务质量不低于下限，这类条件不宜过多，否则验收容易直接失败。加权评分项按业务优先级分配权重，权重之和为100%，并在试点前确认。权重反映的是团队对各项结果的重视程度，没有统一标准，关键是事前定好、事后不改。
验收通过后，还需要持续跟踪哪些指标？
建议保留采纳率、返工率、单任务处理时长和敏感数据外发次数这几项作为常态跟踪指标，按季度或在使用人数、任务类型、模型版本发生明显变化时复评。持续跟踪的重点是发现指标漂移，例如采纳率上升但返工率同步上升，说明建议更容易被接受而质量下降，需要回到提示词和评审流程上排查。
多个团队同时试点，验收结论可以合并成一个吗？
不建议直接合并。不同团队的任务结构、人员经验和业务容忍度不同，指标不可比，合并成一个总分容易掩盖单个团队的问题。可行做法是各团队按同一套口径分别出具验收结论，再由选型决策方汇总，说明各团队的达标情况和差异原因，把合并判断建立在分团队结论之上。
