一家门店里，销售和财务对「卖了多少辆车」各有一套算法，讨论转化时先要花时间对口径；客户第二次进店，顾问却常常从零问起上次聊到了哪里。本体项目正是为解决这些问题而来——团队形成共同理解，任务带着上下文推进。它的投入是否值得，同样需要一套能说清的证据，而不是一句「大家感觉有用」。

设想一次试点演示，Agent 生成了一份销售跟进简报。它能找出试驾记录，概括客户顾虑，还能建议下一步行动。演示结束后，销售负责人更关心的问题是：这件事值得让更多顾问使用吗？

一份看起来合理的输出，还不足以回答这个问题。对象可能找错，建议可能无法执行；即便顾问节省了时间，销售结果也未必已经发生变化。本体项目需要分别证明业务理解正确、任务确实完成、同等质量下效率改善，以及经营结果怎样变化。每一层都要有自己的证据，不能用后一层的愿望替代前一层的检查。

本篇沿用汽车销售场景，给出一套试点验收方法。它帮助团队判断当前已经证明了什么，下一步还需要观察什么。第一轮可以先验证一项具体任务，销量变化留待继续观察。本文重点说明应怎样收集证据，而不提供未经测量的效果数字。

先把「销售提效」变成一项可验收的任务

「帮助销售提高转化」是方向，难以直接检查。可以先选一项频繁发生、信息分散、完成标准较清楚的任务，例如为一次试驾后的跟进准备简报。

任务范围应包括哪些购车机会、使用哪些记录、交给谁、何时交付，以及业务人员拿到后要完成什么。简报的验收标准也要提前确定：至少应找到正确的机会和参与人，区分已确认事实与待确认问题，给出有依据、可使用的跟进准备。

随后保存原有做法。顾问此前要去哪些地方找信息，怎样整理，谁来核对？如果原有流程没有记录，就先观察几次，建立可以比较的基线。不能把准备齐全的 Agent 演示，与顾问临时找不到资料的情况直接比较。

第二篇确定的业务定义也需要带入试点。家庭是客户单元，统计和跟进围绕一次购车机会；订单创建、教学下订条件、取消和交付分别记录。定义一旦改变，试点结果就需要标注适用版本，否则不同批次的数字很难解释。

第一层，先确认它理解的是同一笔业务

正确性检查要深入到记录，不能只看简报语言是否自然。

选择一组由业务人员核对过的机会，写出应当使用的参与人、体验活动、订单状态和原文依据。样本应覆盖日常情况，也包含容易混淆的记录，例如同一机会的重复试驾、两位家庭成员参与同一次活动，以及订单在观察截止后才确认的情况。

检验时既看该出现的内容有没有出现，也看不该出现的有没有混入。把另一笔机会的顾虑写进当前简报，即使顾虑本身真实，也会误导顾问。对已有记录无法判断的问题，合理输出应保留为待确认，不能用流畅的解释掩盖信息不足。

这里有两类错误，需要分别登记。一类是源数据就不完整或互相矛盾；另一类是数据可用，但对象归属、映射、知识引用或查询理解出错。两者的修正责任不同，混在一个「回答不准」的分数里，团队很难改进。

事先约定哪些错误必须阻止输出被使用。机会混入、订单节点误判、建议缺乏依据，通常应优先修正。团队可以根据任务风险决定具体标准，不必照搬一个统一的「准确率达标值」。

第二层，完成的证据要落到任务与业务记录

任务日志显示运行成功，证明这一轮运行完成了相应处理。简报已经生成，证明输出存在。它们还不能证明顾问已经联系客户，更不能证明客户已经下订。

因此，需要把完成标准分开。如果试点目标是准备简报，就由使用者确认它是否可用、是否按时交付。如果目标还包含安排跟进，要确认待办是否创建、责任人和时间是否正确。若目标包含实际联系或更新业务记录，就要检查对应系统里的结果。

跟进未成功时，也要如实保留状态。重复触发有没有产生重复待办，失败后如何处理，顾问更正了什么，都是任务可持续使用的重要证据。具体工具和源端授权按实际配置核对，不能仅凭 Agent 的文字说明判定正式操作已经发生。

对于一次试驾后的任务，建议把「简报生成」「顾问采用」「实际联系」「补充记录」分别留证。这样才能知道问题停在哪一环。若顾问没有采用，需要区分输出不合适、任务时机不对，还是工作安排没有接上。

准备检查任务过程时，可查看 WinNexo 的任务输出与记录说明，将产品运行记录与业务完成证据分别核对。

第三层，在同等质量下计算实际节省

效率比较容易出现一个误差：生成简报只花了很短时间，但顾问还要查原文、修错误、补遗漏。若只记录生成时间，就可能把工作转移当成效率改善。

更有用的比较是，同样质量的一份可用简报，原来和现在各需要多少总时间。原有查找、整理和核对需要计入；采用新方式后，等待、人工复核、返修及补录也需要计入。上线初期的建模与配置投入，以及后续维护工作，可以另行登记，避免混入每次任务时长。

对比任务应尽量接近。需要整理一次简单接待的机会，与经历多次试驾、多人参与和报价调整的机会，工作量很可能不同。按任务复杂程度分组，说明参与人员、记录范围和计时方式，比只给一个平均节省比例更有解释力。

如果输出质量下降，再快也不能沿用原来的比较结果。试点应同时报告哪些输出达到使用标准，以及达到该标准花了多少时间。不满足质量门槛的结果，需要说明返工或不可用情况。

图：四层验收回答不同问题——理解正确、任务完成可较早检查，效率比较需同等质量与完整计时，经营结果还需观察范围与比较依据；不能将四层直接画成必然发生的收益链。

第四层，经营变化需要同批机会和比较依据

当团队开始讨论转化率，就要重新回到第二篇的问题：分子和分母是否来自同一批机会，观察窗口是否相同，下订采用哪个条件，取消怎样处理？

例如，以某段时间首次完成有效体验的机会作为一批，观察约定期限内的下订情况，就不能随意拿当月新增订单去除以当月试驾次数。已经下订但尚未交付，也不能与没有下订的机会归为同一问题。口径不同，数字所反映的业务进展就不同。

同时，需要说明比较对象。可以在条件允许时设置对照，或选择记录范围、顾问经验、门店与时期尽可能接近的任务组。比较设计应在试点开始前确定，避免看到结果以后再挑一组好看的基线。

即使看到改善，也还要检查同期变化。促销、车型供给、线索质量、团队调整，都可能影响订单结果。例如，试点期间门店恰好推出限时促销，试驾到下订的转化随之上升，就不能直接把改善归因于简报——应对比同期无促销的可比门店或时段，或等促销结束后继续观察同批机会。简报使用与经营变化同时发生，不能单凭这一点认定变化全部来自本体或 Agent。若尚未排除这些影响，可以先如实报告观察到的差异，并说明归因仍需进一步验证。

经营证据通常积累较慢。团队完全可以先证明某项任务做得更准确、更省时，再继续观察销售结果。这样的阶段性结论，已经足以支持一个有限范围的下一步决策。

用一张验收卡，决定扩大还是继续修正

试点开始前，可以把核心约定压缩到一张卡中，避免业务与技术各自验收不同的目标。

扩大范围的理由，应与已经取得的证据相称。若只验证了试驾后简报，就先考虑扩大这一任务的使用，不把结论延伸到整个销售周期。如果反复出现机会归属错误，先修正语义与映射；若输出可用但没有接入顾问工作，则应调整任务时机和责任安排。

版本与维护同样需要纳入决策。保存试点所用的数据范围、语义定义、知识来源和任务配置，业务口径改变后重新检查已知样本。后续出现效果波动，团队才能分清是客户条件变了，还是系统使用的定义与信息发生了变化。

这套方法最终服务于一个具体判断：当前任务是否值得继续使用，以及下一轮应该扩大哪里、修正哪里。若希望进一步了解语义、知识和任务的产品组织方式，可阅读 WinNexo 产品概览。准备开展本体或销售 Agent 试点，可以通过瓴羊官方联系入口交流目标任务、现有数据与验收范围，再决定第一轮需要验证什么。

回顾与延伸： · 04 从本体到行动：业务语义如何帮助 Agent 推进销售工作？——行动定义与任务完成证据 · 06 本体与逆向语义建模：如何从已有数据提炼业务定义？——从已有数据建设业务语义 · 07 本体在汽车销售中的应用：从试驾记录到下一次有效跟进——跨次跟进的案例解读与待补实证项

资料来源

NIST AI RMF 1.0 核心框架：参考其结合使用情境、记录测试与评估证据、持续检查的原则。本文四层业务验收为方法整理，并非该框架的原有分类。 WinNexo 自动化任务指南：任务输出、状态与执行记录的产品说明。