AI应用演示时，往往会用准备充分的样例：提问清楚、资料完整、网络稳定、操作路径顺畅。真实业务里却会有缺字段、资料冲突、格式不一和多人同时使用。

因此，验收不应只看系统能否生成一段不错的答案，而要看目标岗位能否在约定范围内完成工作，以及系统遇到不确定情况会怎样处理。

先从业务任务写验收样例

把目标拆成可以演示的步骤：谁提交什么输入，系统应该给出什么结果，由谁核对，结果保存到哪里。样例尽量覆盖日常最常见的任务，也包含一两个容易出错的情况。

例如整理客户需求，可以核对关键字段有没有遗漏、事实是否与原记录一致、未知信息是否标为待确认，而不是只评价“这段摘要写得流畅”。

从工作任务出发 不只看演示画面

边界情况比标准样例更能发现问题

资料缺失、文件格式异常、重复提交、用户越权和接口暂时不可用，都需要有可预期的表现。系统可以提示、暂停或交给人工，但不应把错误默默当作成功。

如果用了模型回答业务问题，还要看找不到依据时会不会明确说明；如果会生成对外文案，要确认哪些内容必须由人审核。把边界写进验收，不等于要求任何情况都自动解决。

性能和可用性要在实际条件下看

单人测试顺畅，不代表多人使用也一样。应使用代表性的文件大小、输入长度和使用人数，在拟部署的环境里观察等待时间和失败情况。需要的标准应由业务要求确定，而不是照搬别的项目数字。

还要让真正使用的岗位从入口完成一次操作：登录、提交、核对、修改、保存和反馈。管理员能操作，不代表普通员工的权限与路径都正确。

验收通过之后 仍要有人负责运行

交付包含说明和维护责任

需要明确资料由谁更新，账号和权限由谁管理，出现错误如何反馈，服务异常时如何联系处理。模型或资料变动后，原来的样例还应能用于复查。

第一阶段可以用小范围试用记录问题，区分必须修复、可以优化和超出当前范围的需求。这样双方讨论的是可核对的结果，也能更清楚地安排后续改进。

聊聊你的业务场景

准备启动AI定制项目时，先挑三件最重要的日常任务，分别准备正常样例和异常样例。用这些材料讨论交付，比只列一长串功能名称更容易形成共同的验收标准。