提示词的沉淀与版本

散落在代码里的提示词，迟早会变成没人敢动的一坨。

提示词一开始都是随手写的字符串。等产品做了半年，它会变成一段几百字、结构混乱、没人敢删任何一句的东西。这不是能力问题，是没把它当资产管。

你会遇到的现象：

它是怎么烂掉的

过程几乎是固定的。

先是有个功能要用模型，工程师在代码里拼了一段提示词。跑得不错，上线。然后出了个问题——它编了个数据，有人加了一句「不要编造数据」。又出了个问题——它回答太长，再加一句「控制在三句以内」。再有人发现某种输入下格式会乱，又加了两句特殊说明。

与此同时，另一个功能也要用模型，工程师复制了一份，改了改。第三个功能又复制了一份。

半年后：**同一条「不要编造数据」的规矩，在四个文件里有四种不同写法，其中一个当初忘了加。**有人想统一改一下措辞，得翻遍代码；改完还不知道会不会影响其他功能，因为没有测试样例。

这不是某个人不专业造成的，是每一步都很合理、累积起来就失控的典型过程。两家主流模型厂商的官方提示词指南，核心都在讲一件事：把提示词当作要长期维护的工程资产，而不是一次性写死的话术。anthropic-prompt-eng

不需要什么复杂工具，做到这三条就能解决绝大部分问题。

**一、把提示词从代码里拿出来。**放到独立的文件或配置里，业务代码只引用。这一步的直接好处是：**提示词的改动能被单独 diff。**你能一眼看出这次改了哪句话，而不是淹没在代码变更里。

更重要的是，共用的部分可以只写一次。「不要编造数据，没有依据就说没有」这类约束是全站通用的，定义一处、各处引用——改一次，全站生效。这和把反复要重申的规矩沉淀下来是同一件事。

**二、每一条限制都注明来历。**这是最容易被跳过、但价值最高的一条。给每条不那么显然的限制加一句注释：它是为了解决什么问题加进来的、哪次出的事、加完之后测试分数变化如何。

为什么重要？因为提示词里最贵的东西不是那句话本身，是**「当初为什么要加它」这个信息**。没有它，后来的人面对一句看起来多余的限制，只有两个选择：不敢删（于是越积越多），或者删了（然后半年前那个 bug 又回来了）。

三、连同测试样例一起进版本库。上一节那组测试样例，和提示词是一体的——它们应该放在一起、一起版本化。官方指南反复强调用系统性迭代代替凭感觉改，任何一次提示词改动都该跑一遍看分数；出了问题，也能查到是哪一版引入的。openai-prompt-eng

如果条件允许，把这个跑分接进日常的检查流程，改动提示词时自动跑一遍。做不到自动化也没关系，有一份能手动跑的样例，已经比大多数团队做得好了。

最后一个现实问题：提示词到底该谁维护？

它有点尴尬——写起来像文档，跑起来像代码，改起来影响的是产品体验。所以经常出现两种失效：工程师觉得这是产品的事，产品觉得这在代码里是工程的事，最后没人系统地管。

比较务实的分工是：提示词的内容归产品，存放和调用方式归工程。

产品负责决定说什么——背景怎么写、限制有哪些、什么算做对了、测试样例的标准答案是什么。这些本质上是产品判断，不是技术问题。提示词就是需求文档，而需求文档一直都是产品的活。

工程负责怎么放、怎么引用、怎么版本化、怎么把跑分接进流程。这样分工还有个好处：产品能直接改提示词、直接看效果，不用每次都排期。迭代速度会快一个量级——而提示词这东西，恰恰是靠快速迭代磨出来的。

最后给一条判断标准，检验你们的提示词管得好不好：**新来一个人，能不能看懂每一句为什么在那儿？**能，说明管住了；不能，说明它已经开始腐烂了，趁早花半天整理一遍。