生产环境中的提示词是软件行为的一部分。提示词管理就是这样对待它的一套规范：知道正在运行的是哪个版本，谁改了它、为什么改，是否经过测试，以及如何回退。这种做法有时被称为 PromptOps。
它解决的问题
- 提示词在某个控制台里被编辑，没人能说清它上周是什么样。
- 同一个提示词被复制到四个服务中，其中三个已经过时。
- 一处小小的措辞改动让 token 成本翻了一倍，直到看账单才发现。
- 模型升级改变了行为，却没有测试表明变了什么。
- API 密钥被粘贴进提示词文件并提交了。
把提示词存为文件
把每个提示词放在版本控制中的独立文件里，紧挨着使用它的代码。
prompts/
support-reply.md
ticket-classify.md
summarize-incident.md
文件天然带来历史记录、差异对比、评审、追溯和回滚。一个带有具名变量的纯文本或 Markdown 文件就足够了：
## Task
Classify the support ticket as billing, bug, or feature request.
## Output format
Return only the label.
## Input
<ticket>
{{ticket}}
</ticket>
避免通过分散在多个函数中的字符串拼接来构造提示词。如果没人能在一个地方读到完整的提示词，也就没人能评审它。
把模板与数据分开
提示词模板由固定的指令和具名变量组成。让它们保持分离：
- 变量是显式的。 用
{{ticket}}，而不是没有名字的格式占位符。 - 每个变量都加了分隔。 用标签包裹，这样插入的文字就不会被当作指令。
- 渲染发生在一处。 由一个函数填充模板、转义输入，并记录用的是哪个模板版本。
为每一次改动做版本控制
把提交当作版本。 每次改动都有作者、日期，以及解释原因的信息。
记录关键的一对。 行为取决于提示词和模型。每次请求都要记录提示词版本和模型标识，使输出可以追溯到产生它的组合。
为重要的提示词写变更日志。 每次改动一行：改了什么、为什么，以及对测试结果的影响。
给发布打标签。 提示词部署时打上标签。这样回滚就成了一个已知的操作。
像评审代码改动一样评审提示词改动
提示词的差异值得认真评审。评审者应该问：
- 这次改动是否与现有指令矛盾？
- 是否删除了某些东西，比如约束或输出格式？
- token 数是否有变化，这能接受吗？
- 是否有针对这次改动想要修复的行为的测试？
自动检查在人工查看之前就能回答其中一些问题。当提示词文件低于最低质量分、超出 token 预算或含有严重发现时，提示词测试门禁会让构建失败。配置存放在仓库里：
{
"include": ["prompts/**/*.md"],
"model": "gpt-4.1",
"minScore": 70,
"maxTokens": 2000,
"failOn": "critical"
}
由于检查是确定性的并且可以离线运行，它们在 CI 中不需要 API 密钥，也绝不会产生不稳定的失败。
发布前测试
静态检查确认提示词本身没问题。输出测试集确认它的行为依然正确。提示词变化时两者都要运行，模型版本变化时要重新运行输出测试。参阅提示词测试与评估。
逐步发布
对于有真实流量的提示词：
- 影子。 让新版本与旧版本并行运行，比较输出，但不展示给用户。
- 金丝雀。 把一小部分流量发给新版本，观察错误率、格式有效性和用户信号。
- 晋升或回滚。 依据数据来决定。
在新版本证明自己之前，让上一个版本保持可部署。
在生产中监控
按提示词版本跟踪：
- 输入输出 token 以及成本。
- 延迟。
- 验证失败的响应占比。
- 拒绝和回退。
- 你收集到的用户反馈。
要谨慎对待你记录的内容。提示词和输出可能包含个人数据和密钥。默认记录元数据，并在存储内容之前先脱敏。参阅提示词中的 PII 与密钥检测。
让密钥远离提示词
提示词文件会被阅读、对比、分享，并发送给第三方。绝不要在其中存放凭据。通过你的应用，而不是通过模型的上下文，把密钥传给工具。CI 中的扫描器可以抓住疏漏；提示词安全扫描器一旦检测到任何凭据就会失败。
归属与复用
- 为每个提示词指定负责人。 由某个人决定改动并回答问题。
- 通过库共享，而不是复制。 单一来源，在需要的地方导入。
- 记录契约。 它接受哪些变量、返回什么，以及它假定了什么。
- 淘汰旧的提示词。 没人使用的提示词仍然会被下一个发现它的人复制走。
经过筛选和测试的起点在这里很有帮助。PromptFlowEngine 模板在每次构建中都保持高分且没有警告。
专用工具还是纯文件
提示词管理平台增加了可视化编辑器、实验追踪，以及面向非工程师的访问。当工程以外的许多人都在编辑提示词时，它们值得采用。对大多数团队来说，git 中的文件加上自动检查就能提供基本能力，无需运维任何新东西。无论选择哪种，要求都一样：唯一的事实来源、历史记录、评审、测试和回滚。
一份起步清单
- 每个生产提示词都是版本控制中的一个文件。
- 变量有名字并加了分隔。
- 每次请求都记录提示词版本和模型。
- 每个拉取请求都会运行静态检查。
- 有一个测试集，在提示词或模型变化时运行。
- 设定并强制执行 token 预算。
- 提示词文件中没有密钥，并且自动检查。
- 有一种有文档记录的回滚方式。