本周 W33，命题「Prompt 该不该进版本库」。我的答案很直接：必须进，而且和配套的解析逻辑同一个 commit。但"进版本库"这件事得拆开看——结构化部分当代码管，纯文案部分走配置加 schema 校验。真正挡路的不是技术，是"改个错别字也要发版"的抱怨，这个能用工具解决。另外，prompt 变更必须附带评测集跑分，不然永远是各说各话。
先回答：必须进，但说法得改改
"Prompt 等于代码"这句话对了一半。代码里的 if 分支、正则表达式、工具定义，这些是逻辑，prompt 里的 JSON schema、工具参数说明、few-shot 例子，本质上也是逻辑。它们和解析代码强耦合，分开管就是埋雷。
我们踩过真实的坑。运营在配置中心改了一句 prompt，多加了需求里提到的一个字段，但后端解析代码还停留在旧版，字段被静默丢弃。用户那边的表现是"AI 突然不干活了"，排查了一晚上才想到去对比 prompt 和代码的版本——线上的 prompt 是三天前改的，代码是两周前发的。谁的问题？说不清楚，因为根本没有同一份 commit 可以回看。
这周 Anthropic 发了篇多智能体系统的模式和问题（链接），里面讲了不少失败模式。我读下来的核心感受：系统越复杂，组件之间的契约越需要显式版本化。prompt 里那些结构化定义就是契约，契约不跟代码走，等于合同不签日期。
运营会骂人，那是合理的
"进版本库意味着改文案要走发布流程"——这个抱怨真实存在。一篇文案改个错别字还要等下个发版窗口，运营不掀桌才怪。所以一刀切的"所有 prompt 都进 git"是教条主义。
折中方案不复杂：按类型分家。工具定义、输出格式、系统约束、拒绝话术的句式结构——这些属于逻辑，必须进代码库，跟着发布走。纯文案部分，比如引导语的语气、某个场景下的措辞、品牌相关的表述——走配置中心，但配置必须带 schema 校验。prompt 里引用的变量名、工具名、字段名，加载配置的时候逐项检查，不匹配直接拒绝上线。
这个 schema 校验是底线。纯文案出错最多是语气不对，但如果文案里勾了一个不存在的工具，或者引用了已经删掉的变量，就会重现我们的静默失败事故。校验写起来不难，一个 JSON Schema 加上几行加载时的检查，一两天的事。换来的是运营同学照常改文案，技术同学不担心配置把系统搞崩。
跑分是唯一能让争吵停止的东西
"我这个 prompt 改得更好"——谁说了算？你说了不算，我说了也不算，评测集说了算。prompt 变更必须附带评测集跑分对比，这个约束要写进 review 流程。
评测集不用大，两三百条典型 case 足够，覆盖正常、边界、拒绝三类场景。每一条标注期望输出，跑一轮，对比新旧 prompt 的通过率。通过率下降就拦下来，人眼再觉得好也没用。阈值自己测，不同任务不一样，别抄别人的值，用你线上的真实分布去调。
这周 Docker 发布了给 AI agent 用的隔离沙箱（链接），对这个话题的直接意义是：评测跑分终于有稳定的可复现环境了。以前"我本地跑得好好的，CI 上挂了"是日常，沙箱能把这个变量消除。评测集和沙箱配合，prompt 变更才能从"我觉得不错"变成"我测过，跑分对比过了"。
顺手说一句，OpenAI 这周发了篇 builder's guide（链接），通篇在讲怎么选模型、怎么用 Responses API。prompt 版本化这事儿一个字没提。说明官方把这块完全交给社区自己踩坑——越是没人帮你管的地方，越要自己定规矩。
工具已经很好了，别不学
有人可能觉得：用配置中心带登录审计不也挺好？说实话，我见过太多配置中心最后变成黑历史库：一万个历史 prompt 躺在里面，没人知道哪个是当前生效的，也没人敢删。Git 至少给你 blame、diff、回滚，这些能力配置中心要自建，成本比想象高得多。
prompt 进 git 不是目的。目的是让每一次 prompt 变更都被问一句："评测过了吗？"结构化部分和代码同 commit，纯文案走配置但带 schema 校验，任何变动附跑分对比。这套组合拳打下来，运营的抱怨被 schema 校验接住，技术的锅被评测集接住。
按我现在看，这是唯一能长期跑通的做法。也许半年后回头会被打脸——可能到时候 prompt 本身都被编译成别的形式了，谁说得准呢。