# 上次已经否掉的方案，换个 AI 又推荐一次。 | EasyNet

Source: https://easynet.run/cases/problems/remember-rejected-options

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

# 上次已经否掉的方案，换个 AI 又推荐一次。

你已经解释过，客户合同不允许把资料交给某个云服务。新助手只看到性能和预算要求，又把它推荐为最佳方案。你再次打断它；如果没注意，它可能已经按这个方向写好了接入代码。重复解释的代价，最后变成了返工。

把硬性约束写进项目说明，是最应该先做的事。一个团队、一份维护良好的文档就能解决时，不必另外保存所有聊天。难点在于约束来自不同地方：客户邮件、架构讨论、采购条件，而新的助手往往只读到了眼前的任务。

可以用 Context 把当前项目的约束说明与出处组织起来，让任务开始时有一个明确的材料入口。还需要接好助手读取它的方式，并要求重要建议说明所依据的条件；收藏过一份文档，不等于每个新会话都会自动使用它。

记录最好写成“这个客户的资料不能发送到该服务，依据是这份仍有效的约定”，而不是“永远不要用这个服务”。另一个客户可能没有同样限制，合同也可能变化。原因、适用项目和复查条件都在，旧判断才不会变成一条来历不明的永久禁令。

真正禁止的操作还应在执行端拦住。助手即使误选了工具，提供方也要检查当前任务是否允许把这些数据送出。文档能帮助模型少走错路，却不能代替网络、凭证和业务访问控制；这两层分别解决理解与执行的问题。

用一个全新会话提出原来的需求，看看它是否先识别限制，并能解释为什么排除那个选项。再换一个不受限制的项目，确认它没有机械沿用。你想留下的是做判断的依据，让下一位不必重走讨论，而不是让每次历史意见都变成今天的障碍。

01

保留决定出处

合同条款和适用项目。

02

规划前读取

解释为什么这条接入不适用。

03

执行端守住限制

模型误选时仍不能越权上传。

被否决的不是整个工具，而是特定项目中的一条路径。

带范围的决定记录

人工审核的项目记忆；实际网络限制需另行执行。
示例内容 · markdown

```
# Decision: Project Cedar

Do not send client source files to external OCR.
Reason: project data-processing agreement.
Source: <approved contract reference>
Allowed route: approved in-house OCR service.
Review when: the data owner approves a new agreement.
Scope: Cedar only.
```

预期结果：新会话能解释Cedar的限制，不把它套到所有项目。

接入时的检查项

新会话能识别该方案在当前项目为何不适用。

另一个不受限制的项目不会继承禁令。

解除限制后能看到新状态而不是永久拒绝。

源码与接入资料

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

[Claude 官方：记忆导入与导出（不是完整会话的持续同步）](https://support.claude.com/en/articles/12123587-import-and-export-your-memory-from-claude)