原创

Prompt 管理方法

当产品里只有一两个 AI 功能时，prompt 写在代码里问题不大。

但只要 AI 功能开始增多，prompt 很快就会变成一团乱麻：谁改过不知道，为什么改不知道，线上效果变差不知道，模型升级后哪里坏了也不知道。

Prompt 不是一句临时指令，而是 AI 产品的生产配置。

本文参考了 OpenAI 官方资料：

Prompt 为什么要管理

Prompt 会直接影响输出质量、成本、延迟、稳定性和安全边界。

如果不管理，你会遇到这些问题：

同一个功能在不同地方有多个 prompt
改了 prompt 以后没人知道
线上输出突然变差但无法回滚
不同语言版本风格不一致
模型升级后旧 prompt 失效
测试环境和生产环境 prompt 不一致
人工经验只存在聊天记录里

Prompt 管理的目标，是让 prompt 可以被记录、复用、测试、比较、发布和回滚。

Prompt 要有唯一名称

每个 prompt 都应该有稳定名称。

例如：

blog_outline_generator
blog_draft_writer
seo_page_builder
product_description_rewriter
support_reply_classifier
invoice_email_summarizer

不要用：

new_prompt
test_prompt_2
final_prompt_final
prompt_for_ai

名称要表达用途，而不是表达当时心情。

一个产品里如果有几十个 prompt，命名就是第一层秩序。

Prompt 要版本化

Prompt 和代码一样，需要版本。

可以记录：

prompt_id
version
status
model
temperature
input_schema
output_schema
system_message
user_template
examples
created_by
created_at
change_note

版本状态可以是：

draft
testing
active
deprecated
archived

上线时不要直接覆盖旧 prompt。新 prompt 应该生成新版本，测试通过后再切换 active。

这样出问题时可以回滚。

输入和输出要结构化

Prompt 最怕输入随意、输出随意。

输入字段最好固定：

topic
audience
tone
language
sources
constraints
format
examples

输出也要固定：

{
  "title": "string",
  "summary": "string",
  "sections": [],
  "warnings": [],
  "confidence": "number"
}

OpenAI Structured Outputs 文档说明，可以使用 JSON Schema 约束模型输出，减少程序解析的不确定性。

当 prompt 变成结构化接口，它才能进入工程系统。

示例输入很重要

只写规则不够。

好的 prompt 通常需要示例：

输入示例
理想输出示例
错误输出示例
边界场景示例
不应该出现的表达

示例能帮助团队理解这个 prompt 的标准，也能作为测试样本。

OpenAI prompt engineering 文档也建议通过示例和清晰指令来改善模型输出。

建立 Prompt 测试集

每个重要 prompt 都应该有测试集。

测试集可以包含：

常规输入
长输入
短输入
缺字段输入
多语言输入
敏感场景
边界案例
历史失败案例
高价值真实样本

每次改 prompt、换模型、改参数，都跑一次测试。

测试不一定复杂。早期可以用 20 到 50 条样本，人工打分也行。

评价标准要明确

不要只说“这个 prompt 效果更好”。

先定义评分标准：

准确性
完整性
可读性
格式合规
品牌语气
事实风险
重复程度
是否遵守禁止项
是否适合发布

可以用 1 到 5 分，也可以用 pass / fail。

OpenAI Optimize Prompts Cookbook 展示了如何用评估来比较 prompt 变体。核心思想是：先定义任务和评价，再迭代 prompt。

Prompt 不能只存在代码里

Prompt 可以放在代码里，但不应该只存在代码里。

随着团队和功能变多，你需要一个可查看的 prompt registry。

早期可以是：

/prompts 目录
Markdown 文件
YAML 配置
数据库表
Notion 表格
内部后台

每个 prompt 页面至少展示：

用途
当前版本
输入字段
输出格式
示例
负责人
最近修改
测试结果
上线状态

这样产品、运营、内容、工程才能围绕同一份资产讨论。

发布要有灰度

Prompt 改动可能影响线上用户。

不要所有用户同时切新版本。

可以按以下方式灰度：

先在测试环境跑样本
内部账号使用新版本
5% 流量使用新版本
对比满意度、失败率、成本和延迟
确认稳定后扩大比例
保留旧版本回滚能力

Prompt 发布也应该有发布记录。

如果某天输出突然变差，你需要知道是不是 prompt、模型、参数、检索资料或下游解析变了。

记录运行日志

Prompt 管理不仅是管理文本，还要管理运行结果。

建议记录：

prompt_id
prompt_version
model
input_hash
output_status
latency_ms
token_usage
cost
error
user_feedback
created_at

不要随意保存用户隐私原文。如果需要排查，可以做脱敏、采样或只保存 hash 和摘要。

有了运行日志，你才能分析哪个 prompt 成本高、失败多、用户反馈差。

一个最小可用方案

独立开发者可以这样做：

1. 建一个 /prompts 目录
2. 每个 prompt 一个 Markdown 或 YAML 文件
3. 记录名称、版本、用途、输入、输出、示例
4. 重要 prompt 准备 20 条测试样本
5. 改 prompt 前先复制新版本
6. 发布时记录变更说明
7. 输出失败时记录 prompt_id 和版本
8. 每月清理废弃 prompt

这套方案很轻，但能让 prompt 从“聊天记录”变成“可维护资产”。