问题从日常工作中收集
验收问题应来自真实使用场景，例如查询制度、解释产品差异或整理业务材料，而不是只选择模型容易回答的通用常识。可以请业务人员列出常见问题和容易出错的问法，去除个人资料后形成样例。每条问题保存使用角色、必要背景与参考依据，让测试人员知道什么样的回答对实际工作才有帮助。
明确合格答案应包含什么
同一个问题可以有不同表达方式，因此不宜只比对一段固定文字。验收表可以记录必须包含的要点、不能出现的错误结论以及是否需要引用来源。对于调用业务工具的任务，还应检查操作对象、权限与执行结果。由业务负责人确认这些标准，比单独用回答长度或语言流畅度判断质量更可靠。
加入边界和失败情形
资料缺失、问题存在歧义、用户没有访问权限及输入包含错误前提，都应进入测试集合。助手应该在适当的时候询问或说明无法确认，而不是总给出完整答案。还要测试外部材料中的诱导内容不会改变系统权限，以及工具失败时不会宣称成功。测试资料应经过授权和必要处理，避免为了验收导入真实敏感信息。
每次修改后保留可比较记录
知识库更新、提示调整或模型更换后，使用同一批核心问题重新测试，并记录版本、结果和错误原因。新增业务再逐步补充样例，不需要一开始就追求很大的题库。上线决策应结合业务风险和人工兜底能力，先开放边界清楚的场景，让后续优化有可复查的依据，而不是依赖一次演示效果。
方案落地前需要确认
本文以“企业 AI 助手上线前”为主题讨论功能设计，属于方案指南，不代表某个客户项目的实际交付承诺。具体实施前，应由业务负责人确认适用规则、使用角色、现有系统接口和验收方式，再通过原型验证关键操作。对于暂时不能确定的条件，保留待确认清单，在范围明确后评估开发周期与费用，避免将示例直接套用于不同企业。