只用开发人员编写的规范问句测试，往往看不出上线后会遇到的表达问题。客户可能省略主体、写错产品名，或者在一句话里同时问两个问题。测试题集应覆盖这些表达，也覆盖本来就不应该回答的请求。没有答案的题目同样重要，它能检查系统是否会承认资料不足。

先明确问题与条件

为每道题写出适用条件、参考依据和可接受的处理方式。某些题目允许几种表达，评价重点是事实和下一步是否正确，不必逐字比对。涉及账户信息的测试使用脱敏样例，并检查身份与权限边界。题集按业务模块分组，方便知识更新后找到需要重测的部分。

把规则放进实际流程

例如同样问订单在哪里，可以分别设置已登录且有订单、尚未核验身份、订单已取消三种条件。正确响应不应完全一样。再加入假设不存在的功能问题，检查系统是否编出入口；客户要求转人工时，则检查是否立即进入相应流程。

逐项核对处理结果

  • 每次修改检索或提示规则，保存同一题集下的结果，并记录错在哪里。
  • 人工复核关注漏掉前提、来源不支持和操作风险，而不只给一个总分。
  • 新出现的真实问题经脱敏后加入题集，旧题也要随规则变化更新。
  • 把严重错误单独列出，有助于决定哪些问题必须在发布前解决。

上线前后怎样复查

测试集中的标准依据要有人负责更新，旧规则被取消后不再要求系统回答旧结论。失败题目保存当时输入条件，团队才能复现问题，而不是只得到一份模糊的错误数量统计。