先建评测集
从近三个月工单里抽三十到五十条任务，覆盖主路径、常见异常与不可答情形，每条标注期望结果与验收人。为什么不能只用演示题：演示题经过挑选，无法暴露边界。评测集要冻结版本，后续回归沿用同一批。
阈值先定后测
开跑之前写下通过条件，例如任务完成率、人工接管率上限、单任务时延与调用成本。怎么定：参考当前人工基线与业务容忍度，而不是某家平台的演示数据。阈值事后调整，等于没有验证，评审时也解释不清。
同批同环境
两个平台用同一批样本、同一份工具清单、同一套权限，在同一周内跑完。环境不一致时，差异会被网络、账号与数据版本掩盖。边界是涉及生产写操作的场景，应在隔离环境用影子数据验证，不直接动真实单据。
失败分类再决
把失败分成工具调用错误、理解偏差、流程缺失、权限不足四类，统计各自占比。怎么用：工具类失败可靠改造解决，流程缺失要回到需求，理解偏差则说明任务不适合当前的模型与提示词设计，勉强上线只会增加接管。
适用与不适用
适合谁
- 已有一到两家候选、准备做验证的企业
- 需要向管理层提交选型依据的项目负责人
不适合谁
- 还没有真实任务样本、只能做演示比较的团队
- 已签约、只想补一份验证材料的项目
典型场景
某制造企业的设备报修派单场景进入验证。信息化部门从工单系统抽取四十条任务冻结成评测集，先定完成率与接管率阈值，再让两家平台在同一周内跑同一批样本；业务负责人逐条复核失败原因，最后按决策门选择其中一家进入试点。
可执行步骤
- 从近三个月工单抽取三十到五十条任务，覆盖主路径、常见异常与不可答情形
- 为每条任务标注期望结果、可接受的处理方式与验收人，冻结版本后不再改题
- 开跑前书面写下通过阈值、一票否决项与决策门规则，由业务与技术双方签字
- 要求候选平台在同一周内跑同一批样本，逐条记录失败类型、接管次数与耗时
- 按决策门给出结论：通过、有条件通过或终止，并写明条件、复核时间与责任人
常见坑
- 阈值在看完结果后才调整，验证变成给已选方案补证据，评审会上无法解释取舍依据，也说不清为什么不选另一家。
- 样本由供应商挑选，全是整理干净的演示数据，真实工单一上手就大面积失败，验证结论无法向上汇报。
- 只统计成功案例、不记录失败类型，决策时说不清问题是能靠改造解决还是要换方案，评审只能凭印象投票。
- 验证环境与生产不一致，账号权限、网络与数据版本都不同，结果无法外推，上线后指标容易回落，返工又要重测。
自检与验收清单
- 评测集是否覆盖主路径、常见异常与不可答情形，形成书面记录
- 通过阈值与一票否决项是否在开跑前书面确认，并由双方签字
- 各候选平台是否使用同一批样本、同一套工具与权限
- 失败分类统计与决策门结论是否留档，可供事后复核
常见问题
验证要做多久？
单场景两到四周比较常见。任务涉及多个系统联动或需要写操作时，建议延长到六周，并加入故障与超时演练。时间不足时宁可以减少样本量，也不要减少样本的真实性，避免验证拖成长期试点。
只有一家候选还需要验证吗？
需要，但目的不同：不是比较，而是确认它能否达到阈值。此时更应把否决项写清楚，例如权限不足或无法接管就终止，避免因为已投入时间而勉强上线，也便于向管理层交代，交接时也有据可查。
评测集要不要定期更新？
要。业务规则、系统接口与模型版本变化后，旧题集会逐渐失真。建议每季度补充新的异常样本，保留旧样本做回归对比，更新记录与评分标准一并留档，便于审计、复盘与跨期对比。