把提示词当代码管：版本、评测集与回归

有件事我拖了很久才动手：我的提示词一直是散落在代码里的字符串常量。

改一句话，凭感觉；效果好不好，凭印象；改坏了，下次才发现。同一套系统里，Python 代码有版本控制、有测试、有 CI，而真正决定产出质量的那几段文字，什么都没有。

这半年我把它补上了。做完之后回头看，收益比我预期的大得多。

第一步：把提示词从代码里搬出来

很简单但必须先做。每个提示词一个文件，带元信息：

prompts/
  script-parse/
    v1.md          # 历史版本留着，不删
    v2.md
    v3.md          # 当前
    meta.yaml      # 当前指向哪个版本、适用模型、最后验证日期

只是搬了个位置，但立刻带来两个好处：diff 能看了，以及改动会进 git 历史。以前我完全无法回答「三个月前这段提示词是什么样」，现在一条命令就知道。

提示词改了，效果是好是坏，得能测。

我给每个提示词建了一个小评测集：15–30 条输入，覆盖典型情况和已经踩过的坑。每条输入配一份判据——不是「标准答案」，而是「必须满足什么条件」。

判据分两类，这个区分很重要：

机械判据（代码判定，占七成以上）

主观判据（模型判定，占不到三成）

七成能用代码判，这个比例是我做完之后才知道的，一开始我以为绝大部分都得靠模型评。能用代码判的千万别交给模型——快、免费、结果确定，而且不会自己犯错。

流程固定成这样：

第 4 条救过我好几次。有几次我确信自己的修改是对的——逻辑上更清楚、表达上更精确——但评测集告诉我通过率掉了。硬着头皮回滚，后来才发现被我「优化」掉的那句啰嗦的话，恰好挡住了一个边界情况。

直觉在提示词这件事上非常不可靠。它不是代码，你没法通过阅读推断行为。

这是评测集帮我发现的最大问题。

有个环节我要求输出必须满足一个密度约束。提示词里写得非常清楚，还给了例子。评测集显示：通过率只有六成左右。我换了两家的模型，都是六成上下。

两个不同厂商的模型给出同样的失败率，这说明问题不在模型，在我的要求本身对模型来说不自然。

解法不是继续调提示词，而是加一个后处理函数：把不达标的输出机械地补到刚好过线。函数是幂等的，已经达标的输入不会被改动。

通过率从 60% 到 100%，我一句提示词都没再改。

这件事之后我形成了一条判断标准：

如果同一个要求在两个不同的模型上都有相似的失败率，别再调提示词了，那是个应该用代码兜住的机械问题。

反过来，如果换个模型就好了，那才是模型能力问题。

版本漂移。以前我在本地调好一段提示词，忘了同步到线上，两边不一致，排查问题时对着不同的文本猜半天。现在提示词是文件，跟代码一起部署，不存在漂移。

「上次那个改法」找不回来。以前想恢复某个改动，只能靠回忆。现在历史版本都在，而且每个版本都有当时的评测通过率记录，我能看到质量的演化曲线。

诚实说一下代价：

第三条是真正的长期成本。一个过期的评测集比没有评测集更危险，因为它会给你虚假的安全感。我现在每个评测集文件顶上写一行「最后验证日期」，超过两个月没动过的，先核实再采信。

一句话总结这三个月：提示词是这个系统里最软的部分，所以它最需要硬的流程去托住。

代码写错了会报错，提示词写坏了只会让质量悄悄下降一档——而这种下降，人是很难靠印象察觉的。