easynet.run · 全部问题场景

AI 照着旧说明操作,错得还很有底气。

退款规则上周改了,助手却引用旧培训文档回答客户。旧文档写得很完整,新规则只有一条更新通知;两份都能搜到,它选了看起来更像答案的那份。问题不是没有资料,而是资料没有明确告诉读者哪份现在还有效。

先维护一个正式规则来源,比不断往知识库添加更新说明更重要。现有文档平台能标记废弃、替换和生效时间时,直接使用这些状态。无需为了 AI 复制出另一套规则,再让两边一起过期。

Context 可以帮助助手找到相关材料,但收藏与目录并不判断业务有效性。要做好这个场景,需要把正式来源的状态接进来,让查询默认返回当前规则,并保留旧版本用于解释历史事件,而不是让所有版本平等竞争搜索排名。

例如,当前退款规则明确生效日期、适用订单和负责人。助手问某笔订单时,先确定应使用哪个时期的规则,再取得对应说明;旧文档入口则指向替代版本。最新修改时间不一定代表已经批准,未来生效的草稿也不能提前用于答复。

涉及实际退款,提供方还要在执行前检查适用规则。助手读错了材料,不应因此绕过业务限制;展示层更新也不能作为执行端已经更新的证据。这部分版本连接与校验需要由规则和服务维护者一起落实。

拿新旧规则各自适用的订单测试,让助手说明为什么使用这一版,并尝试从旧链接进入。预期不是抹掉历史,而是让当前工作少受废弃说明误导。它查到的应是能承担这次判断的依据,而不只是文字最像问题的一篇文章。

  1. 01

    识别订单日期

    先确定规则适用对象。

  2. 02

    检查正式规则

    批准、有效期、替代关系。

  3. 03

    执行前复核

    旧链接不授权旧规则执行。

保留历史,但执行使用适用的规则。

明确区分旧版与现行版

文档目录的数据示例;订单适用性仍由业务程序检查。

示例内容 · json
{
  "document": "refund-guide-v2",
  "status": "retired",
  "replaced_by": "refund-guide-v3",
  "retain_for": "historical-order-review"
}

预期结果:旧文档能回查,但当前任务会被引导到后继规则核对。

接入时的检查项
  • 新查询不将废弃材料当作现行依据。
  • 历史任务仍能回查当时适用规则。
  • 带旧规则参数的业务操作在执行端被拒绝。
源码与接入资料