先写验收契约，再写 Prompt

如果“更好”没有定义，Prompt 讨论很快会变成审美争论：有人要更短，有人要更多提醒，还有人期待每项结论都带证据。验收契约应该在讨论措辞之前解决这些分歧。

验收契约不是一段更长的 Prompt，而是一张供业务负责人、评审者和开发者共同使用的判定表。它回答的不是“模型应该怎么想”，而是“什么结果可以进入下一步”。先把这个判断写清，后续才知道该补资料、改流程还是调模型。

先区分硬门槛与偏好

把要求放进两列。硬门槛一旦违反就拒收，例如遗漏订单号、引用了非授权资料或擅自执行账户操作；偏好则允许取舍，例如句子更短、标题更生动或要点顺序不同。若把所有偏好都写成硬门槛，系统会为了格式牺牲任务结果，评审也会被大量低价值告警淹没。

可以用三个问题确定一条规则是否属于硬门槛：违反后是否会改变决定，是否会伤害用户或产生合规风险，后续环节是否无法低成本修复。三个问题都是否定答案时，它更可能只是偏好。

合格输出包含五类规则

• **必备内容：**不能缺少的字段、问题或决定。
• **证据规则：**哪些资料可以支持结论，怎样展示来源。
• **表达规则：**篇幅、结构、语气和术语。
• **不确定性规则：**证据缺失或冲突时必须怎样说明。
• **拒收规则：**出现什么情况时，整份结果都不能使用。

每条规则都要让两位复核者能够独立执行。“写得专业”不是检查项；“不写寒暄、只用三点、必须说出账户和未解决问题”才是。

案例：研究摘要

必备内容是一句结论、三项支持发现和一个尚未解决的问题。每项发现都要引用允许使用的来源并标注日期；只有在原始措辞重要时才直接引用；互相冲突的证据不能被合并成一个确定答案。

中心结论没有来源、资料超出要求的时间范围却没有提示，或者把两个不同口径的指标混在一起，都会触发拒收。文章再顺畅也不能抵消这些问题。

案例：客服回复

回复必须确认具体问题，只给经过验证的步骤，标记需要客户同意的账户操作，并以一个明确问题结尾。语气可以友好，但不能承诺政策里没有的退款和处理时间。

如果账户状态缺失，正确输出是询问信息，不是编造诊断。这个不确定性规则比“不要产生幻觉”更能指导行为。

用样例做契约测试

给契约配一份通过样例、一份接近通过的样例和一份明确失败的样例，并标出各自满足或违反哪条规则。样例是测试，不是装饰。

契约稳定以后，再判断应该修改指令、补充上下文、增加结构化输出和校验，还是更换模型。

可复制的验收契约

先为一个真实任务填写下列内容，不要从通用模板库拼装：

契约字段	要写下的内容	复核证据
使用场景	谁在什么决定前使用结果	任务简报或流程节点
必备内容	缺少哪项就无法继续	字段逐项勾选
允许证据	可用资料、版本和时间范围	引用片段与资料日期
表达约束	接收系统真正需要的格式	schema 或通过样例
不确定性	缺资料、冲突、低置信时的动作	停止、追问或转人工记录
拒收条件	必须阻断的错误	失败样例及规则编号

再用三条输入走查契约：一条资料完整的常规案例、一条信息缺失的边界案例，以及一条看似合理但应当拒绝的诱导案例。若评审者无法仅凭契约得出一致结论，问题还在规则，不在 Prompt。

把契约接入发布流程

契约应有编号、负责人和变更原因。修改字段定义、资料来源或下游动作时，旧案例需要重新执行；只改变无关语气时，不必触发整套回归。上线记录至少保留契约版本、测试输入、实际输出、复核结论和未解决分歧。

不要只记录总通过率。把失败归到具体规则，才能看见“引用正确但字段缺失”与“格式漂亮但越权承诺”是两种不同修复。如果一条规则长期没有拦住任何风险，也没有服务下游消费，就应考虑删除它。

常见问题

契约和结构化输出 schema 是一回事吗？ 不是。schema 只能检查字段和类型；证据是否真的支持结论、何时必须停止，以及语气是否越权，仍需契约表达。

先有 Prompt 还是先有契约？ 可以先用一个粗略 Prompt 探索任务，但在比较方案和宣布“效果更好”之前，必须先固定验收规则。

每个场景都要一份契约吗？ 共享相同决定、风险和下游格式的场景可以共用。只要任一项发生实质变化，就应拆开，避免一份大而含糊的契约覆盖所有请求。

不适用边界

不要让验收本身比原工作更昂贵。保护真正影响决定的部分，允许无害的表达变化。如果复核者持续意见不一，先修契约，不要继续调模型。