提示词管理：让提示词不再埋在代码里

你写下的第一段提示词，作为一个字符串字面量愉快地住在某个函数里。到第十段时就不一样了。到那时，你的提示词散落在各个文件里，带着细微变体被重复复制，无法被审阅，而且只有能编辑并重新部署代码的人才改得动。提示词管理就是把提示词当作一等资产来对待的纪律——可版本化、可审阅、无需部署即可编辑——而不是当作埋在应用里的、附带的字符串。本指南解释这一转变为何重要，以及如何在不过度工程化的前提下完成它。

为什么硬编码的提示词会变成问题

一段提示词其实并不是代码，尽管它住在一个代码文件里。它是内容：措辞、范例、指令和语气，你会想根据模型的表现频繁地去调整它们。把那份内容埋在源码里，有可预见的后果。

• **改动需要部署。**调整提示词里的一句话，意味着一次代码改动、一次审阅和一次发布——而它实质上只是文案校对。
• **没人能把提示词当作提示词来审阅。**它待在被转义的字符串和拼接之中，真正的指令难以阅读、又容易弄坏。
• **重复会漂移。**同一段提示词被复制到三个地方，结果会在其中两个地方被改动，于是你的系统就因为没人找得到的原因而表现不一致。
• **非工程人员被挡在门外。**最擅长打磨措辞的人——领域专家、文案、产品同事——碰不到一段住在代码仓库里的提示词。

对一段提示词来说，这些都不要紧。可一旦提示词成为你产品的核心，它们就全都要紧了。

把提示词与调用分开

第一步、也是最有价值的一步很简单：把提示词从内联字符串字面量中拉出来，放进一个专门的地方。那个地方可以朴素到只是一个模板文件的文件夹或一个配置模块，也可以复杂到一个受管理的提示词注册中心。重点在于，提示词有了一个家，它不再与调用模型的逻辑纠缠在一起。

一旦提示词有了家，几件好事就自然随之而来。你可以把它当作纯文本来阅读。你可以对它做 diff。你可以给它起个名字，并从多个调用处引用它而无需复制。而且你在"我们向模型问什么"和"我们如何调用模型"之间，创造了一条干净的接缝——这两件事因不同的原因、以不同的速率发生变化。

把提示词当作模板，而非字符串

大多数真实的提示词都有固定的骨架和可变的部分：一组稳定的指令，加上用户的输入、检索到的上下文或运行时的值。请用模板、而非字符串拼接，来显式地为此建模。

模板让结构变得可见。指令、格式规则，以及动态内容的占位符，都被摆在一个人类可以阅读的地方。拼接隐藏了那个结构，并招来微妙的 bug——一个缺失的空格、一个被注入到错误位置的值、一个不再匹配你所要求格式的范例。把可变部分清楚地标记出来，在调用之前验证它们都已就位，你就消除了一整类无声的失败。

这也是你防范提示词注入的地方。当用户提供的文本流入一个模板时，要审慎地决定它去往何处、以及如何告诉模型对待它。模板让那条边界变得显式；一个拼接而成的字符串则把它模糊掉了。

像版本化代码那样版本化提示词

一段控制产品行为的提示词，配得上与代码相同的变更纪律，因为改动它就改动了你的用户所体验到的东西。这意味着版本控制和审阅。

当一段提示词作为一个文件住在你的仓库里时，你几乎免费就能得到这些：历史、diff、blame，以及拉取请求审阅。当它住在一个受管理的系统里时，等价的功能应当被内建进去——每一次改动都被记录、可追溯、可逆转。无论哪种方式，要求都是相同的：

• **历史。**你能看到这段提示词上周写的是什么、是谁改的。
• **审阅。**对一段面向客户的提示词的改动，会像代码改动那样，得到第二双眼睛的把关。
• **回滚。**当一次"小小的措辞调整"拉低了质量时，你可以在几秒内回退，而不必凭记忆复原旧的文本。

要避免的失败模式，是那种毫无记录就发生改变的提示词。行为变了，没人知道为什么，而且没有任何东西可以回退到。

把提示词改动与部署解耦

这一切结构的回报，是能够在不发布代码的情况下改动一段提示词。无论你是通过运行时加载的配置、还是一个专门的提示词服务来实现它，目标都一样：一次措辞修正不应当需要走完整的"构建—发布"周期。

这之所以重要有两个原因。第一，速度——模型行为是迭代式的，而"观察到一个糟糕的输出、调整提示词、看到效果"的循环应当很快。第二，准入——当提示词与部署解耦后，具备恰当专长的人就能在护栏之内安全地打磨它们，而不必成为你发布流水线的一部分。这里要当心：与部署解耦，绝不能意味着与审阅解耦。目标是快且受治理，而不是快且无人负责。

在提示词上线之前测试它

由于一次提示词改动可能无声地拉低质量，请把提示词当作可测试的。你不需要繁复的机械装置就能起步。保留一小组有代表性的输入，以及你期望的那种输出，并在采用一个候选提示词之前，让它在它们上面跑一遍。

这能逮住那个常见的意外：改进了一个情形，却悄悄弄坏了另一个。一段提示词是一个关于行为的全局设置；一次修好你眼前那个范例的改动，可能让你没在看的另外三个范例发生回退。一个常备的评估集——哪怕只是一把案例——就把那个看不见的风险，变成了一道看得见的检查。把它与模型提供方自己的指引配合使用，因为来自 Anthropic 和 OpenAI 的文档描述了每个模型如何响应结构、系统指令和格式，而这些正是你的测试应当去演练的。

别过度工程化

一句克制的话：提示词管理是一条光谱，你应当待在你的项目实际所处的位置。一个只有三段提示词的单人原型，并不需要一个注册中心、一套审阅工作流和一个评估框架——它需要的是把提示词从内联字符串中拉进可读的文件里。一个由提示词驱动跨团队核心行为的产品，则需要完整的纪律。两个方向的错误都真实存在：把一切硬编码直到它变得无法管理，或者在还没有任何东西可管理之前就构建一套重量级系统。让结构与利害相匹配。

总结

提示词是控制行为的内容，所以请像管理"控制行为的内容"那样管理它们。把它们从内联字符串中拉进一个属于自己的家，把它们的结构建模为模板而非拼接，对它们进行版本化好让改动被记录、可逆转，并在不放弃审阅的前提下把措辞改动与代码部署解耦。保留一个小小的评估集，好让一次帮到某个情形的调整不会无声地弄坏另一个。轻装起步，并随着利害的上升逐步增加纪律——目标是你能够带着信心去阅读、审阅和改动的提示词，而不是一个你不敢碰的字符串。