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

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

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

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

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

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

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