提示词的沉淀与版本 | 提示词工程 | 做产品

提示词的沉淀与版本

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

你会遇到的现象

• 提示词里有句奇怪的限制，没人记得为什么加，也没人敢删

• 同一条规矩在三个功能里有三种写法，改的时候漏了一个

• 线上效果突然变差，想回滚，但不知道上一版提示词长什么样

它是怎么烂掉的

过程几乎是固定的。

先是有个功能要用模型，工程师在代码里拼了一段提示词。跑得不错，上线。

然后出了个问题——它编了个数据。有人加了一句「不要编造数据」。又出了个问题——它回答太长，再加一句「控制在三句以内」。再有人发现某种输入下格式会乱，又加了两句特殊说明。

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

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

这就是那张图左边的状态。它不是某个人不专业造成的，是每一步都很合理、累积起来就失控的典型过程。

三件该做的事

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

一、把提示词从代码里拿出来。

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

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

二、每一条限制都注明来历。

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

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

三、连同测试样例一起进版本库。

上一节那组测试样例，和提示词是一体的——它们应该放在一起、一起版本化。这样任何一次提示词改动，都能跑一遍看分数；出了问题，也能查到是哪一版引入的。

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

拼在代码里

chat.js 「不要编造数据」

summary.js 「没依据不要瞎猜」

tickets.js 「不许编造」

report.js 当初忘了加 一条规矩四种写法，想统一改措辞得翻遍代码

当成资产管

prompts/no-fabrication.md 不要编造数据，没有依据就说没有 // 2 月工单事故后加，跑分 +6

对话 摘要 工单 报表 定义一处、各处引用：改一次，全站生效

最贵的不是那句话，是「当初为什么加它」这个信息 没有它，后来的人只有两个选择：不敢删（越积越多），或者删了（半年前那个 bug 又回来）。 测试样例和提示词是一体的，应该放在一起、一起版本化——改一次就能跑一遍看分数。

左边那种局面不是谁不专业造成的，是每一步都很合理、累积起来就失控。检验标准很土：新来一个人，能不能看懂每一句为什么在那儿。

这活归谁

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

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

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

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

工程负责怎么放、怎么引用、怎么版本化、怎么把跑分接进流程。

这样分工还有个好处：产品能直接改提示词、直接看效果，不用每次都排期。迭代速度会快一个量级——而提示词这东西，恰恰是靠快速迭代磨出来的。

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

提示词怎么迭代 测试样例和提示词是一体的，要一起版本化。

约束沉淀 反复要重申的规矩，怎么固化下来不再重复说。

规格、提示、约束的分工 一次性的写规格，反复的写约束，临时的写提示。