15｜Agent 表现不错，凭什么决定进入试点？

评测的作用，是把“感觉不错”变成有样本、有标准、有边界的判断。它不保证所有未来任务都成功，但应当帮助团队知道哪些能力已有证据，哪些失败会阻止试点，以及下一步应该修什么。

前面三个案例提供了不同后果：租赁系统可能错误承诺资源，设计系统可能确认错版本，物流系统可能重复增加库存。它们要求我们从业务风险反推评测，而不是只收集看起来容易成功的问题。

POC 关注关键假设能否成立，例如分散资料能否支持一个完整任务。Eval 按明确样本和标准检查具体行为，为是否继续提供证据。进入真实工作后的 Pilot 则观察有限用户、数据与责任条件下的实际使用。

因此，一轮评测应先写明决定用途。是比较两个候选方案，检验一个版本修复，还是判断某个窄范围能否进入试点？用途不同，样本与观察重点也不同。

如果要判断物流系统能否进入试点，只测商品名称提取并不充分。还要检查时效、同批关联、数量计算、审批和重复处理。局部能力通过可以支持继续开发，却不能自动支持扩大动作权限。

评测范围应与试点范围相对应。只验证一个 SKU、两个仓库和人工批准的方案，就应按这些条件讨论下一步，不能把结果解释为全公司自动补货能力已成立。

代表样本覆盖主要真实任务分布，边界样本检查规则与能力边缘，高风险样本针对严重后果，长尾样本保留低频但确实可能发生的异常。频率与风险都需要覆盖。

租赁可以包含普通询价、改期、特殊现场和历史优惠；设计可以包含正确历史稿、相似未采用稿、父版本错误和单件确认；物流可以包含旧库存、重复单据、延期和质量隔离。每个样本都要能说明为什么值得测试。

真实项目应尽量使用授权的业务样本，并处理不必要的敏感信息。没有足够真实数据时，可以先构造模拟样本检验机制，但需要清楚记录它的来源与局限。模拟通过不能改写成企业实际表现。

样本还要保留上下文。同一句“可以了”，如果不知道客户看到的是哪个版本，就无法判断是否应产生确认。只截取最后一句话，会把业务任务变成脱离条件的问答题。

评测卡不一定很长，但必须能够让另一个人重现判断。只写“答案基本正确”，既无法定位问题，也无法比较后续版本。

对于多轮任务，还应记录变化发生的位置。例如先生成报价，再修改日期，最后尝试接受旧版本。若只直接输入最终日期，就无法检查旧版本失效机制。

一次任务可以从四层观察：模型输出是否有依据，系统链路是否正确完成，用户是否能接续工作，业务影响是否符合预期。离线评测通常先覆盖前两层，再为试点中的用户与业务观察准备标准。

在输出层，检查事实、引用、完整性与拒答；在系统层，检查工具选择、参数、权限、状态变化与异常；在用户层，检查结果是否可理解、可交接；在业务层，检查时间、质量、风险等指标是否在相同口径下变化。

高风险任务还需要独立的否决项。一个系统即使多数普通任务正确，只要仍然可能把未确认资源标成已安排，就不应靠其他维度高分抵消。

下面是一个纯粹的评分说明：假设一百个测试任务中九十八个满足普通质量标准，但其中一次产生未经批准的正式写入。不能只汇报“98% 表现良好”，还应单独报告越权事件，并按预先约定决定是否阻断。平均数描述整体，关键失败决定边界。

能够明确计算的内容，优先采用确定性检查，例如报价明细、运输次数、库存变化和版本关联。接口输入输出可以通过契约检查，权限与恶意输入则需要专门的安全或对抗样本。

开放文本可以使用评分量表、模型辅助评审和人工抽查。使用模型作为评审者时，应注意风格、长度和位置等偏差，并用人工结果校准。裁判模型给高分，也不能单独证明专业事实正确。

视觉任务需要文件对照与专业判断。准确文字、画布尺寸、父版本和确认关系可以客观核对；构图、品牌表达和系列协调需要设计师判断；毫米位移还需要可成立的测量基准。

方法选择应当覆盖失效面。没有必要把所有任务都交给同一种评测器，也不应因为已经有自动分数，就取消承担最终专业责任的人。

最终答案错，可能来自资料、检索、字段映射、规则、模型、工具或流程。应沿输入到结果查找最早偏离预期的环节，而不是默认修改提示词。

租赁旧报价仍可接受，可能是状态资格没有绑定需求版本；物流刚上传的旧库存被选中，可能是时间规则错误；设计精修结果没有回到版本链，可能是人工回流流程缺失。三种问题需要完全不同的修复。

记录错误类型、严重度、根因、修复责任与影响范围，有助于形成有意义的回归集。安全事件还应按相应流程单独升级，不只是混在普通质量问题里排队。

修复后先复现原失败，再检查受影响分支与必要正常对照。没有新变化时，不必为了制造工作量无限重复全部测试；有跨模块影响时，则应相应扩大范围。

评测样本需要版本管理，也要避免与开发材料混淆。如果把标准答案直接加入生成上下文，再用同样问题验证，很可能只证明系统记住了答案。

可以区分用于调试的样本和用于独立检查的样本，记录采样口径、标注标准和争议处理。样本发生变化时，说明变化原因，避免新旧分数在不同题目上被直接比较。

同样，两个互斥业务情境应独立初始化。测试一笔收货“全部合格”和“部分隔离”，不能在同一库存上先后累计两次。测试环境本身若状态错误，得到的结论也会失真。

一份可用的评测报告应包含目标、范围、版本、样本、方法、结果、失败、未覆盖项和下一步。最重要的部分，是解释结果能够支持什么。

进入试点时，还应准备真实用户、数据、动作边界、观察周期、支持与回退。评测证明的能力，需要在这些条件下继续接受检验。

当团队能够拿出失败与限制，而不仅是成功截图，试点才有可管理的起点。下一篇会继续讨论系统进入真实组织后，怎样安排使用、维护、恢复和长期责任。

AI随心创提供试点与团队落地支持，围绕真实任务验证效果，并整理操作说明、失败样例和后续优化清单。沟通前可以准备几条成功任务和几条失败任务，连同输入、预期与实际结果一起讨论。