提示词其实是一个"接口"
提示词常被当成"一段文本" ✔，于是改起来随意、测起来困难 ✔。
把它当接口看 ✔：有输入契约、输出契约、版本与兼容性 ✔ —— 很多混乱自然消失 ✔。
一、输入契约（模板的"参数表"）
变量名 ｜ 类型 ｜ 是否必填 ｜ 约束 ｜ 缺失时的行为
doc string 必填 ≤ 20000 字 截断并标注
lang enum 可选 zh/en 默认 zh
要点：
- 变量必须显式声明 ✗→✔（不要在模板里凭空引用 ✔）；
- 缺失时有明确行为（报错 / 用默认值 ✔ —— 不要静默留空 ✗）；
- 约束写在模板里（长度、枚举 ✔）并在代码里也校验 ✔（见约束变校验 ✔）。
二、输出契约（模板承诺产出什么）
- 格式（JSON schema / Markdown 结构 ✔）；
- 必含字段（如"必须给出引用" ✔ —— 见结构化输出那篇 ✔）；
- 不确定性表达（置信或状态字段 ✔ —— 见不确定性传递 ✔）；
- 内容约束（不得出现某类表述 ✔ —— 见文案审校 ✔）。
输出契约要与"校验"一致 ✗→✔：模板说"必须给引用"，校验就得查引用 ✔ —— 两边不一致等于没有契约 ✔。
三、版本与兼容性
- 变量增删 = 破坏性变更 ✔（调用方要同步改 ✔）；
- 只加可选变量 = 向后兼容 ✔（推荐方式 ✔）；
- 改语义（同名字段含义变了）= 破坏性 ✗（最难发现 ✔ → 要写进变更说明 ✔）。
四、接口化的三个好处
- 可测（输入契约固定 → 可以构造用例 ✔ —— 见边界用例库 ✔）；
- 可复用（同一模板被多处调用 ✔ —— 见提示词库 ✔）；
- 可替换（换模型/换实现，只要契约不变，下游不受影响 ✔）。
五、一份最小契约文档
模板名 / 版本 / 负责人
输入：变量表（类型、必填、约束、缺失行为）
输出：格式、必含字段、内容约束
变更历史：日期 / 变更类型（兼容 / 破坏）/ 影响面
一条判据
一个新同事能否只读契约就正确调用这个模板 ✔（不问作者 ✔），并知道输出该怎么校验 ✔？
不能，说明提示词还只是一段文本，不是接口 ✗。