用四项明确约定减少提示词输出漂移

大多数关于“prompt engineering”的建议都在讨论措辞。真正的问题是，人们写 prompt 就像写邮件一样，用一段普通文字交代需求，然后又对模型在不同运行之间出现“漂移”感到意外。

生产环境中的 prompt 不是普通文字，而是契约。契约必须明确规定四件事，否则模型就会用统计上最可能的内容填补空白——这恰恰就是你看到的漂移。

任何需要在两次运行中保持一致行为的 prompt，都应该回答这四个问题：

• Role——由谁来回答，优先优化什么？
• Task——唯一的交付物是什么？（不是一串任务，只交付一样东西。）
• Constraints——哪些事情绝不能发生？
• Output contract——有效答案的确切结构是什么？如果输入无法满足要求，应该怎么办？

prompt 只要缺少其中任何一项，模型就会猜。猜测是稳定性的敌人。

You are a helpful assistant. Summarize the following customer review and tell me
if it's positive or negative and maybe what the main complaint is. Be concise.

这段 prompt 会随着输入不同，以五种不同的方式失败，而你无法预测会出现哪一种。

ROLE
You extract structured feedback from customer reviews. You optimize for accuracy,
not for making the review sound better.

TASK
Given one review, produce a single JSON object classifying sentiment and listing
complaints.

CONSTRAINTS
- Never invent a complaint that is not present in the text.
- Never output anything except the JSON object. No preamble, no markdown fence.
- If the review is not about a product, set "relevant": false.

OUTPUT CONTRACT (strict)
{
  "relevant": boolean,
  "sentiment": "positive" | "neutral" | "negative",
  "complaints": string[],   // verbatim or closely paraphrased, [] if none
  "confidence": number      // 0..1
}
If you cannot comply, output {"error": "<short reason>"}.

第二段 prompt 更长，这正是关键。每增加一行，就是把一个决定提前做定，而不是让模型在每次运行时做出不同的决定。

输出契约是大家最容易跳过的部分

没有退出机制的 schema 会导致一种特定的失败：当输入无法适配时，模型会编造内容来满足 schema。它宁愿返回一个形式上有效、内容却不符合实际的对象，也不愿承认无法完成。因此，一定要明确规定失败时的输出结构（{"error": ...}），并对输出进行校验：

import json

REQUIRED = {"relevant", "sentiment", "complaints", "confidence"}

def validate(raw: str) -> dict:
    obj = json.loads(raw)              # raises -> caller retries/fails over
    if "error" in obj:
        raise ValueError(obj["error"])
    missing = REQUIRED - obj.keys()
    if missing:
        raise ValueError(f"missing keys: {missing}")
    if obj["sentiment"] not in {"positive", "neutral", "negative"}:
        raise ValueError("bad sentiment")
    return obj

这样，“漂移”就会变成一个明确暴露、可以捕获的错误，而不是悄无声息地传到下游第三个系统，才成为一个错误答案。

真正能改变行为的约束

约束这一部分，是你真正能把效果做好的地方。弱约束没什么作用，比如“保证准确”；强约束则能消除具体的失败模式：

• “绝不编造原文中不存在的投诉” → 阻止模型生成幻觉细节。
• “不加开场白，不加 Markdown 代码围栏” → 阻止模型把 JSON 包在 json ... 之类的内容里。
• “只交付一个结果” → 阻止模型回答三个你根本没问的问题。
• “如果发生 X，就执行 Y” → 给模型一个符合规则的退出路径，从而减少编造。

注意，这些约束都是禁止式或条件式的。“提供帮助”无法证伪；“绝不编造”则可以测试。

测试契约，而不是凭感觉判断。 保留 20–50 组输入与预期结果，每次修改 prompt 都运行一遍。一个“感觉更好”的 prompt 改动，可能会悄悄破坏 10% 的用例。

不要过度约束推理。 如果任务需要思考，就给模型留出思考空间；只要别让这些思考泄漏到输出里就行。（使用两次调用的模式：一次负责推理，一次负责格式化。）

像管理代码一样管理 prompt 的版本。 prompt 是一项依赖。如果它没有纳入 git，也没有 changelog，发生回归时你就无法回滚。

所有提供商都使用同一份契约。 如果你需要在模型之间切换来应对故障，输出契约就是保证它们的响应可以互换的关键。

演示用 prompt 与生产用 prompt 的差距，在于要求是否明确。能够校验的契约，才能成为真正可以上线、监控和调试的 prompt。其余的做法，都只是在碰运气。

我整理了 32 个这样的生产级 system prompt，分为六个类别，每个都有严格的输出契约，还附带 JSON schema 和一个仅依赖标准库的 validator CLI，可在配套产品页面获取。

另外，还有一个规模更大的 prompt 模板库，面向内容创作者和电商场景，采用自由定价，最低 $1。

欢迎反馈——尤其是，如果你有某条约束，能够稳定消除我没有列出的失败模式。

如需采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。