像管理代码一样管理提示词版本

“随手改一下提示词”却不做测试，就像一次未经测试的生产环境提交——差异往往要等到已经出了问题才会被发现。

提示词是代码，不是配置

提示词和一行代码一样，决定着系统的行为——因此它理应得到同等的重视：纳入 Git 版本控制、变更可追溯，以及在每次上线前进行测试。

纳入 Git 版本管理

提示词应当放在代码仓库中，而不是一份散落的文本文件或聊天窗口里。这样一来，每一次改动都能通过提交（commit）追溯，可以在 diff 中精确查看，并在需要时通过 revert 撤销。

测量改动前后的差异

一个小型的、固定的测试用例集合，配上预期行为，可以显示出一次提示词改动究竟是真的带来了改善，还是在悄悄地让别的地方变差。没有这个参照，任何判断都只能凭直觉。

识别回归并回滚

如果一次改动之后，测试集的表现比之前更差，这就是回归的明确信号——而借助版本管理，之前那个能正常工作的状态随时可以恢复。

为什么“随手改一下”是有风险的

由于语言模型是把整个上下文作为一个整体来处理的，同一个提示词中改动一句话，可能会在其他地方产生意想不到的影响。没有测试，这类副作用往往要好几天都不会被发现，直到某个用户偶然触发了它。

示例

改动前版本（prompts/support-antwort.md，v1.2）： “请礼貌且简短地回答客户的问题。” → 测试集合：30/30 个测试用例符合预期格式。改动后版本（v1.3，新增一句话）： “请礼貌、简短地回答客户的问题，并提出一个解决方案建议。” → 重新运行测试集合：27/30 通过——有 3 个测试用例现在给出了不必要的冗长解决方案，而不是要求的简短回答。 → 结果：识别出回归，v1.3 在上线前被进一步打磨，而不是直接上线。

🛠️ 练习——自己动手试试

为你自己的一个提示词构建一个小型测试集合，并在采纳一次改动之前先针对该集合进行检验。

如果尚未这样做，把一个现有的提示词存放为一个独立的文件，放入一个 Git 仓库中。
编写 10 个小型测试用例，包含输入和预期行为（例如预期的格式或预期的内容）。
让当前版本的提示词针对全部 10 个测试用例运行，并记录成功率。
按计划修改提示词，将该改动单独提交，并让同样的 10 个测试用例再次运行。
在将该改动确立为标准版本之前，比较两次的成功率。

✅ 自查清单

☐ 改动之后成功率是否有所下降，尽管你原本并没有预料到这一点？
☐ 你能否通过 Git 历史记录在一分钟之内恢复旧版本的提示词？

小测验

为什么仅凭直觉判断，不足以评估一次提示词改动是否真的是一种改进？