应用里有几十个提示词后，管理问题才刚开始

一个 AI 应用刚上线时，提示词通常只有一条。几个月后，代码库里散着几十条，前半句还在，后半句没人知道为什么加。换模型时更麻烦，同一段文本换个模型，表现可能完全不同。Reddit 的 r/PromptEngineering 里有人问，应用里的提示词到底该怎么管。跟帖里没有万能工具，倒有几条被反复提到的做法。

第一条很朴素：别把提示词写成散落在代码里的字符串。集中放，给每条一个名字和版本。这样用户反馈某个回答不对时，能查到当时用的是哪一版提示词，不用靠猜。

第二条是写清楚为什么改。只留下 diff 不够。六个月后，新增一句让模型用用户语言回答，比一串增删符号有用得多。有网友说，这条被低估了。旧提示词里一半的句子是补丁，对应某个没人记得的故障。没有原因记录，没人敢删，提示词只会越来越长。

模型和参数也要和提示词放在一起。同样的文本，换模型、换 temperature，行为会变。把这些信息和提示词绑定，复现问题会容易很多。

改动还要有一小组测试输入兜底。每条提示词存 5 到 10 个输入，其中包括上次把它弄坏的那个边缘案例。每次修改都跑一遍。很多小调整会弄坏旧边缘案例，新场景反而未必中招。

具体存哪，跟帖里有两种路线。有人用仓库里的纯文本文件，一条提示词一个文件，文件头写模型、temperature 和一句为什么存在。git log 就是变更记录，代码评审也覆盖提示词修改。每次调用模型时，日志里记下提示词名字和版本，或者 commit hash。有人报 bad case，能直接定位到当时那段文本。

另一种做法是用 JSON schema 存 prompt_id、model、version 和 context_notes。需要跨模型搜索或 diff 时，结构化数据比文件顺手。

这些做法听着琐碎，核心是拿管理代码的方式管理提示词。提示词进了生产环境，就不再是一次性文本。它需要版本、原因和回归测试，否则团队只能对着一堆越来越长的字符串猜。