Prompt 版本管理与评估
prompt 一旦进入生产系统，就会像代码一样持续变化。业务规则会变，模型会升级，知识库会更新，用户输入会出现新模式，安全策略也会补洞。如果没有版本和评估，团队很快会陷入一种状态：每个人都能改 prompt，但没人知道改完以后整体质量是变好了还是变坏了。
Prompt 版本管理与评估要解决的不是“怎么写出满分 prompt”，而是如何让每次 prompt 变更可解释、可比较、可回滚。它把 prompt 从个人经验变成团队资产。
提出问题：客服回复 prompt 为什么越改越不稳
假设客服回复助手上线三个月后，团队发现几个问题。客服反馈某些回复太生硬，运营同学加了语气规则；法务要求避免承诺解决时限，产品同学加了限制；知识库团队新增引用要求，工程师又改了输出格式。每次改动单看都合理，但线上开始出现新问题：有些回复变长，有些问题过度拒答，有些本来能回答的场景开始要求转人工。
输入仍然是用户工单、知识库片段、用户状态和客服补充说明。输出仍然是客户可见回复草稿。但 prompt 已经从最初的 20 行变成 120 行，中间夹着风格要求、合规要求、格式要求、引用要求和各种例外。
没有评估时，团队通常靠人工试几个样例。如果这几个样例表现不错，就直接上线。最常见样本被反复测试，真正容易失败的样本却没有覆盖：资料不足、知识冲突、用户情绪激烈、要求退款、涉及合同、含有攻击指令、旧模型和新模型差异。
真正的问题不是 prompt 不够长，而是缺少工程化变更流程。
分析问题：评估要覆盖质量、边界和成本
客服回复助手的 prompt 变化会同时影响多个维度：事实正确性、证据使用、语气、长度、拒答率、结构稳定性、安全边界、成本和延迟。只看“这条回答好不好”是不够的。
适合交给模型评估的部分包括：初步判断回答是否遵循格式、是否引用证据、是否包含明显禁用语、是否和参考答案语义接近。应该由程序处理的部分包括：结构化字段校验、敏感词检测、引用 ID 存在性、成本统计、延迟统计、版本记录。必须人工确认的部分包括：高风险业务结论、客户可见承诺、法务和合规边界。
评估样本至少要分成四类。
第一类是常见样本，代表线上主要流量，用来防止平均质量下降。
第二类是边界样本，包括资料不足、上下文冲突、用户要求越权、复杂套餐条件和情绪化输入。
第三类是回归样本，来自过去线上事故或人工差评，用来防止修过的问题复发。
第四类是安全样本，包括 prompt injection、敏感信息诱导、要求泄露 system prompt 和要求绕过人工确认。
评估指标也要分层：格式通过率、证据引用率、事实一致性、拒答准确率、人工可用率、编辑距离、成本、延迟和安全拦截率。不同业务不需要一次上齐所有指标，但必须知道当前上线依赖哪些指标兜底。
列举方案：从手工对比到发布门禁
Prompt 版本与评估可以从轻到重建设。
第一层是变更记录。每次修改 prompt 都记录版本号、修改人、修改原因、影响范围和回滚方式。适合刚开始治理的团队。
第二层是样本库。把典型问题、边界问题、线上失败问题和安全攻击问题沉淀成固定输入。样本库是评估的基础，不是上线后再补的文档。
第三层是人工评分表。定义好结果、可接受结果和必须拦截的坏结果。人工评分适合复杂语义判断，但成本高、速度慢。
第四层是自动评估。用程序校验格式、引用、禁用词、长度、成本和延迟；用模型评审辅助判断事实一致性和风格。自动评估适合回归门禁，但要抽样复核。
第五层是 A/B 或灰度。prompt 变更先在小流量、低风险用户或内部队列验证，观察人工采纳率、编辑率、差评率和异常率。
第六层是发布门禁。设定最低通过条件，例如结构化输出通过率不能下降，安全样本必须全拦截，关键回归样本不能失败，平均成本不能超过预算。
第七层是线上反馈闭环。把人工编辑、拒用、用户投诉、客服标注和异常日志回流到样本库，形成下一轮评估。
简单 prompt 足够的条件是：低风险、低频、人工一定会复核，并且 prompt 很少变化。只要 prompt 高频迭代、多人维护、影响对外输出或下游系统，就应该至少有版本、样本库和基础回归测试。
决策判断：如何选择评估强度
评估决策要避免三个误区。
第一，不要只优化平均分。平均分上升但安全样本失败，不能上线；常见样本变好但高价值客户场景变差，也不能简单判定成功。
第二，不要把模型评审当成唯一真相。模型评审可以提高效率，但高风险样本、争议样本和合规样本仍需要人工标注或专家复核。
第三，不要把 prompt 版本和模型版本分开看。一次质量变化可能来自 prompt、模型、检索、上下文、工具或参数。日志里必须记录完整运行配置。
常见反模式包括：在线直接改 prompt 没有版本；用生产用户当测试集；只保留成功样例，不沉淀失败样例；上线后只看投诉，不看人工编辑率；模型升级没有回归；评估集长期不更新，无法覆盖新业务。
结论收束：prompt 变更必须可比较
Prompt 版本管理与评估的推荐方案是：从变更记录和样本库起步，把常见、边界、回归和安全样本纳入测试，再根据风险增加自动评估、灰度和发布门禁。这个方案成立的前提是团队愿意把 prompt 修改视为生产变更，而不是随手调参。
如果场景低风险、低频、人工完全复核，可以降级为轻量记录和手工检查；如果 prompt 影响客户可见输出、业务判断、工具调用或安全边界，就必须升级到回归评估和发布控制。
上线前至少检查：
- 版本记录：prompt、模型、参数、schema、检索配置是否有版本号。
- 变更说明：本次修改解决什么问题，可能影响哪些样本。
- 样本覆盖：是否包含常见样本、边界样本、历史失败样本和攻击样本。
- 质量标准：好结果、可接受结果和必须拦截的坏结果是否明确。
- 自动指标：格式、引用、拒答、成本、延迟和安全拦截是否可统计。
- 人工评审：高风险样本是否有人类标准答案或专家判断。
- 发布门禁：哪些指标下降会阻止上线。
- 灰度策略：是否先小流量验证，是否能对比旧版本。
- 可观测性：线上是否记录 prompt 版本、输入摘要、输出、错误和人工反馈。
- 回滚恢复：出现退化时是否能快速恢复旧版本。