把 Prompt 变成
可靠的系统契约

Demo 成功，不等于系统可靠

可靠性问题不是“提示词写得不够好”，而是系统没有建立行为契约。

这一节解决三个生产问题

核心结论：模型不稳定并不可怕，可怕的是系统没有定义哪些不稳定可以接受、哪些必须被阻断。

从一次模型调用，到一个可靠系统组件

核心结论：可靠性不是来自某一句“神奇 Prompt”，而是来自模型外部一层层可执行的控制。

Prompt Contract 管的是行为，不是措辞

核心结论：Prompt 的价值不是写得像不像专家，而是能否清楚定义输入、输出、证据边界和失败行为。

写 Prompt 前，先回答五个系统问题

不要让业务系统消费“看起来正确”的散文

核心结论：自然语言是否通顺是体验指标；字段是否稳定、含义是否明确才是系统接口指标。

{
  "sentiment": "negative",
  "entities": ["ACME"],
  "risk": "high",
  "next_action": "check_refund_eligibility"
}

结构化输出不是一句“请返回 JSON”

核心结论：JSON 只保证语法可解析，Schema 才能保证字段、类型和业务含义满足契约。

四类常见错误，需要四种明确判断

结构化客户反馈抽取器

核心结论：基础案例虽然小，但已经包含生产系统最小闭环：候选生成、验证、失败阻断和回归测试。

Bad 和 Good 的差异可以被程序观察

BAD  > 客户似乎不满意，建议尽快跟进。

GOOD > {
  "prompt_version": "feedback-extractor.v2",
  "sentiment": "negative",
  "entities": ["ACME"],
  "risk": "high",
  "next_action": "Open a support ticket..."
}

校验失败以后，系统具体怎么办？

核心结论：失败策略必须在开发前定义。无限重试会增加成本，也可能重复触发有副作用的业务动作。

关键词重合，不代表证据支持

核心结论：事实核查要比较 Claim 中的完整事实关系，而不是统计 Claim 和 Evidence 共享了多少词。

事实核查的核心是证据状态机

核心结论：系统需要的是可分流的证据状态，不是模型给出的一个模糊“可信度分数”。

置信度不能替代证据。证据不完整时，正确结果是暴露缺口。

让每个判断都能解释、分流和追责

核心结论：Verdict 负责流程分支，Evidence 负责审计，Missing Evidence 负责指导下一步。

Prompt 修改必须进入发布流程

核心结论：Prompt 的文字变化可能改变大量下游行为，因此必须像代码变更一样经过评测、审批、发布和回滚。

Prompt as Code 的重点不是“放进 Git”，而是行为变化可评测、可阻断、可回滚。

Fact Checker Prompt Harness

核心结论：Harness 是包围模型调用的控制层，把 Prompt、证据规则、Schema、评测和审计组织成一个可交付组件。

不是测“回答好不好”，而是测风险边界

核心结论：平均分会掩盖致命错误。高风险场景必须逐条通过，不能被大量简单样例抵消。

一个可用评测集，至少覆盖四个象限

Harness 不能解决所有可靠性问题

核心结论：Prompt Harness 只负责模型行为约束；知识、工具、流程和运行时仍需要独立治理。

Prompt Harness 是可靠系统的一层，不是整个系统。后续课程会继续补齐 RAG、工具、Agent Loop 和 Runtime。

从机制理解到工程交付

核心结论：实战不是照着命令运行，而是亲手制造失败、补充门禁，再证明失败不会进入生产流程。

上线前，至少回答这六个问题

核心结论：只要有一个问题无法回答，这个模型调用就仍然是 Demo，而不是可交付的系统组件。