# AI 照着旧说明操作，错得还很有底气。 | EasyNet

Source: https://easynet.run/cases/problems/stop-following-retired-instructions

[easynet.run · 全部问题场景](https://easynet.run/cases#problem-scenarios)

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

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

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

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

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

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

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

01

识别订单日期

先确定规则适用对象。

02

检查正式规则

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

03

执行前复核

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

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

明确区分旧版与现行版

文档目录的数据示例；订单适用性仍由业务程序检查。
示例内容 · json

```
{
  "document": "refund-guide-v2",
  "status": "retired",
  "replaced_by": "refund-guide-v3",
  "retain_for": "historical-order-review"
}
```

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

接入时的检查项

新查询不将废弃材料当作现行依据。

历史任务仍能回查当时适用规则。

带旧规则参数的业务操作在执行端被拒绝。

源码与接入资料

[上下文接入指南](https://easynet.run/docs/connect/context)

[函数接入指南](https://easynet.run/docs/connect/function)