客服助手突然在每条回复里都加上一句退款政策。模型没换过。原来是上周二有人为了修正一个别扭的回答，改了指令，新加的那句话影响到了所有对话。

指令、示例和检索设置对 AI 工作流的影响不亚于代码。一处小改动可能修好一个问题，却悄悄弄坏另外五个。一套轻量的变更流程就能避免这种情况，也不会拖慢团队。

所有修改记在同一个地方

把当前指令放在能查看历史的文件或工具里，而不是某个人的聊天窗口里。每次修改记录：

  • 改了什么： 修改前后的完整文字。
  • 为什么改： 触发修改的具体例子或投诉。
  • 谁批准的，什么时候上线。
  • 当前版本号，用 v14 这样简单的标签即可。

以后发现回答不对，团队可以直接查是不是某次修改之后开始的，不用靠猜。

每次都用同一组用例重测

保留一小组固定测试用例：常见问题、容易出错的边界情况，以及应该拒绝或转人工的请求。每次修改前后都完整跑一遍，而不只是测你想修的那个问题。

把前后结果并排比较。留意回答是否变长、丢了来源链接、语气变了，或者开始做出公司并不提供的承诺。如果目标问题修好了、别的却坏了，先调整再上线。

怎样建立第一批测试用例，可参考 AI 质量测试指南。

一次只改一处

如果同一次发布里既改指令、又换模型、还调检索，出了新问题就无法判断是哪一项造成的。能分开就分开，也要记下外部变化，例如服务商更新了模型版本。

保留回退的路

让上一个版本可以随时恢复。事先约定谁可以回退、什么情况下回退，例如审核人员一天内两次看到异常类型的回答。回退应该是常规操作，而不是紧急抢修。

上线后的头几天重点观察

每次修改后抽查一部分真实对话或输出。既看预期改善的情况，也看几类没改动过的场景。团队确认新版本表现符合预期后，再关闭这条变更记录。

一份简短的变更记录加一套可重复的测试，能把改提示词从凭感觉变成正常维护。如需为现有工作流建立变更流程，欢迎联系 Storm Nova Labs。