这周命题是「换模型要重写多少 prompt」。说实话问题问歪了——该问的不是重写多少，而是哪些东西在锁你。硬格式确实要重写，工具调用的表述、输出约束的写法，各家就是不一样。但真正让你迟迟不肯动手的，往往是那撮你攒了半年的失败样本。
换模型那天晚上，改的全是格式
上次从 Claude 换到 GPT-5，光是 function calling 的参数风格就调了两天。OpenAI 这边工具定义更接近 JSON Schema 的写法，Anthropic 那边习惯在自然语言里描述参数，连个 enum 都要换个说法。输出约束更折腾，一个说"用 JSON mode"，另一个说"给我 schema 就行"，实际跑起来谁都不完全信谁的。
这不是偶发。ExtractBench 这个 benchmark 把 schema-guided extraction 单拎出来评，还专门打分 value accuracy 和 record completeness——这类东西开始被当成一等公民认真测，本身就说明大家都在被输出格式折磨。业务代码里真正难改的从来不是模型调用那行，是下游解析器。你 prompt 里写"日期转成 YYYY-MM-DD"，换了个模型它给你输出"Mar 3, 2026"，解析器当场崩给你看。
真正锁人的是评测集，不是 API
换模型最费劲的不是改 prompt，是那一堆 regression cases。我们每个业务 prompt 背后都挂着一撮历史失败样本：某次抽取把金额和账户搞混了、某次多轮对话把上下文跟丢了、某次输出 JSON 里多了个注释。这些样本攒了大半年，比 prompt 本身值钱多了。
换模型那天，第一件事不是改 prompt，是把评测集跑一遍。你会发现之前修好的问题有一半回来了。你说它能力弱吧，它是真不会；你说它能力行吧，它就是理解不了你那段绕了三层的条件约束。问题不在模型，在 prompt 是你跟旧模型磨合出来的——换一个人也这样。
我的做法：业务逻辑和模型技巧分开
现在写 prompt，我一律分成两层。业务逻辑那层全是稳定的：要抽什么字段、输出什么格式、哪些情况算失败、强约束还是弱约束。这层跟模型无关，基本半年不动。
模型技巧那层才是会变的：few-shot 示例的写法、思考格式的引导、工具说明的口吻、system prompt 里对格式的强调方式。这层迁到新模型时重写，范围小，半天能搞定。
这个思路跟 ExtractBench 在做的方向一致——schema 是稳定的，跟随 schema 的行为是模型相关的。把 schema 定清楚，换模型时至少知道哪些东西不该动。
抽得太干净，prompt 反而没人敢动
但这里有个反面，我得替它说两句。过度抽象会让 prompt 变得非常难读。有次我把这些分层做成了一套"框架"，起了一堆接口，同事接手时对着 system 和 user 之间的 adapter 看了半天，最后还是直接往一个 system prompt 里堆。
这周 Handbook.md 那篇论文的结论我深有体会——长 policy document 不能可靠地约束 agent 行为。你把规则拆成模块、加上命名空间、每层写注释，抽象是干净了，但模型读到的还是拼接后那坨文本。prompt 是给模型读的，不是给 IDE 做重构的。
安全边界也一样。那个"Frontier Lab Agent Intrusion"的时间线看得人后背发凉——agent 被外部输入诱导后能绕开多少规则层。你抽得再干净，也守不住被注入的攻击面。所以我的结论是：抽到「能读」为止，别抽到「漂亮」。反正每个模型拿到手都要重调，抽象省下的时间，未必抵得过调试抽象层本身花的时间。
按我现在看，换模型这事，一半是体力活，一半是重新认识自己的 prompt 里到底写了什么。也许过半年 prompt 工程范式变了，回头会被这段打脸。那就到时候再说。