提示词管理
它会一段段长成没人敢删的东西，不是能力问题，是没当资产管理。拿出来、注明来历、剪掉不再生效的规矩，这三件事就够。
每个提示词刚诞生时，都只是随手敲进去的一小段文字。产品运营半年之后，它往往已经膨胀成几百字、层次混乱、谁都不敢动其中任何一句的样子。这跟个人能力没什么关系，问题在于它从来没被当成一份资产来对待。
读完你能回答：
- 怎么判断一份提示词已经烂了？
- 把它从代码里搬出来，为什么还是不够？
- 一条限制该不该留，靠什么信息判断？
判定它烂没烂，一句话就够
判断的标准不需要什么工具：一个刚接手的人，能不能看懂每一句话为什么待在那儿？
看得懂，说明每条规矩的来历都还在手上。看不懂，说明那些来历已经丢了——加它的人多半也早就不记得。到这一步，它其实已经开始腐坏，最好趁早抽半天梳理一遍，别等到想改却没人敢动的时候。
这份判断之所以成立，是因为提示词里真正值钱的东西不是某句限制本身，而是它背后那段来历。接下来要说的，就是这段来历怎么丢的、又该怎么补回来。
没人故意搞破坏，是一步步堆出来的
这类退化几乎每次都是同一个剧本。
最初只是某个功能要调用模型，工程师顺手把一段话嵌进代码。效果能看，就发了。接着暴露出第一个毛病：它凭空造了个数字，于是有人在里面补上「不要编造数据」。没多久又发现同一句话在客服场景和内部工单场景里的语气完全不同，再补一句「不要用感叹号」。后来又发现它把客户原话里的错别字也一并改了，又添了两行针对性的说明。
与此同时，第二个功能也要用模型，工程师把这段复制过去，稍作修改。第三个功能照做一遍。
半年之后再看：「不要编造数据」这一条，散落在四个文件里，写法各不相同，其中一处当初压根没加上。有人打算把措辞统一一下，得挨个文件翻；改完心里也没底，因为没有任何测试样例能告诉他别的功能有没有被带坏。
没有谁做得不专业。这是一类典型的累积事故：单独看每一步都站得住脚，堆在一起就失了控。官方提示指南反复强调的也是这一点：提示词属于需要长期维护的工程资产，而不是一次写完就再也不碰的文案。anthropic-prompt-eng
搬出代码，是让它重新可改的第一步
上面那堆麻烦有个共同的源头：它住错了地方。提示词混在代码里，改动也混在代码改动里，谁也看不出这一次究竟动了哪一句。
所以第一件事是让它离开代码。单独存成文件或配置项，业务代码只负责引用。直接的好处是：每次调整都能被单独拿出来对比。改了哪一句一目了然，不会再被淹没在一大堆代码变更里。
更关键的是，重复出现的部分只需要写一遍。「没有依据就不要编数据，直说没有」这类约束在很多场景都用得上，在一处定义、各处引用，改一次就全部生效。
一条规矩要能被判断，得带上来历和样例
搬出代码只解决了「找不到地方改」。接下来要解决「改的时候心里有没有底」，而这需要两样东西到位。
一样是来历。凡是看起来不那么显然的限制，都配一句注释：*它当初是为了堵什么漏洞、由哪次故障引出、加进去之后样例得分有什么变化。*这一条最常被省略，收益却最大。缺了这段背景，接手的人看到一句似乎多余的规矩，能做的只有两件事：不动它，于是规矩越堆越多；或者删掉它，然后半年前那个故障重新出现。
另一样是样例。迭代用的那组样例与提示词本就是一体的，应当同处存放、同步纳入版本管理。每次调整都过一遍样例、记录得分；日后出问题，也能追溯到是哪一版引进的。openai-prompt-eng
条件允许的话，把评分挂到日常检查上，提示词一动就自动执行一次。自动化暂时做不到也无妨，手里有一份能手工执行的样例，就已经领先于多数团队了。
只加不减，是另一半维护工作
前面几件事处理的是「不敢改」，这一条处理的是「只加不减」。
提示词最典型的崩坏方式就是只加不减：一出问题就补一句，谁也没删过。几年累积下来，里面会同时住着几条互相打架的约束，还有一批写给早已下线的场景的特例。条目越多，每一条被认真执行的分量就越轻——它们彼此稀释，真正要紧的那几条也被埋在了中间。
因此，删减是维护的组成部分，而不是可以省掉的动作。一条规矩该不该留，问三个问题：
- 它拦的那个问题现在还会出现吗？场景已经下线、入口早已关闭，那这条规矩就只是一段过期的记录。删掉。
- 它名下还有样例吗？样例集里对应它的那一条如果已经被移除或改写成别的，这条规矩就没了验收依据——一条没有样例的规矩，没有人能判断它究竟还在不在起作用。
- 它和别的规矩打架吗？两条互相排斥的约束并存，正是长期只加不减最典型的产物。此时该争的不是谁对，而是回到它们各自拦的那个问题，看哪一个今天仍然真实存在。
反过来说，有一种情形不构成删除理由：你根本看不懂它是干什么的。这只是说明当初的来历没被记下来。此时该做的，是把注释和样例补齐，让它重新变得可判断——而不是把它删掉、赌一把没事。
说什么归产品，怎么放归工程
还剩一个很现实的问题：提示词归谁管？
它的身份有点尴尬：形态像文档，运行方式像代码，可一旦改动，受影响的是用户体验。于是常见的推诿有两种：工程师认为这是产品的职责，产品认为它存在代码里就该工程负责，结果是没有人系统地照看它。
一个比较落地的划分是：提示词写什么由产品负责，怎么存、怎么调用由工程负责。
说什么由产品拍板——背景怎么描述、设哪些限制、做到什么程度算合格、样例的标准答案是什么。这些都是产品判断，不属于技术范畴。提示词本身就是一份需求文档，而需求文档向来是产品的分内事。
放在哪里、如何被引用、怎样纳入版本管理、评分怎么接入流水线，这些由工程处理。这样划分还有一个附带好处：产品可以自己动手改、自己看结果，不必每次都走排期。迭代会快上整整一个量级——而提示词的质量，恰恰只能靠快速迭代磨出来。
写法之外的判断
提示词既然是一份需求文档，把它写清楚就是本职，谈不上什么技巧：缺哪一段就在哪一段跑偏，例子传递的信息比形容词准，要给程序读的部分必须把格式定死，每次只动一处、并且有样例可比。
而这一切能成立的前提，是提示词本身处于可修改的状态。这正是本篇的主题。
资产稳住之后，稳定性还剩最后一个变量：随机性。温度与随机性讲的是为什么「调低」不等于「调准」。至于再往后——把它并入更大的上下文统一调度，是上下文工程的事；让模型掌握它语料里从未出现过的东西，先检索再回答从建立索引一直讲到拼接上下文。