把提示词和检索语料纳入依赖管理

LLM 功能出了问题，排查范围不能只停在模型上。dev.to 的这篇文章把检索语料、提示词模板和工具响应放进依赖管理的视角：这些输入一旦悄悄变化，系统行为也可能跟着变。作者主张为它们记录版本、审查变更，并保留能追溯到具体请求的证据。

目前能确认什么

作者根据自己参与处理的故障指出，问题经常来自模型读到的语料、被修改的提示词，以及未经校验的工具响应。这是作者的经验陈述，不能据此断言所有 LLM 系统都有相同的故障分布。

软件依赖通常通过锁文件固定版本；检索增强生成（RAG）还会把检索到的文档交给模型，因此语料变化同样可能影响答案。动态模型别名则增加了另一层不确定性：调用名称没变，背后的模型行为未必保持一致。

节选给出的做法是建立只追加的语料清单，记录文档标识、内容哈希、来源和信任等级，再纳入 Git 审查。清单负责让变化可见，检索层负责执行信任规则。 示例里的正则只能辅助筛查隐藏指令，作者也明确承认它会漏检。

评测方面，作者要求关联提示词、语料、评测运行和部署记录，同时观察具体失败用例的变化，不能只盯总分。

我的判断

对程序员最直接的启发是：知识库更新和提示词修改，都应该被当作可能改变线上行为的发布动作。

如果客服助手突然答错，排查时应能还原当时使用的提示词、检索文档和工具返回。只有模型名称与耗时，往往解释不了答案为什么变了。

不过，内容哈希能证明输入是否变化，不能证明输入可信。 外部文档里的隐藏指令和伪造事实，还需要来源审查、权限边界与对抗评测配合处理。

节选没有展开工具响应如何校验，灰度发布部分也不完整。它提供的是一套可追溯的管理思路，尚不足以证明这些措施能覆盖多少故障或攻击。