核心 GUIDE
Capability 不等于 Guarantee
模型在 Example 或 Benchmark 中表现出某种 Capability，并不保证每个 Production Input 都会稳定产生同样行为。可靠性需要在概率能力之外建立 Contract、Evidence 与 Control。
核心心智模型
Capability 问的是模型在某些条件下“能不能做”；Guarantee 问的是整个系统能在明确 Distribution、Failure Budget 与 Consequence Level 下“承诺什么”。二者之间的差距，就是 Production Engineering 开始的地方。
为什么重要
AI Demo 很容易把一次成功 Output 变成隐含承诺，导致产品脆弱，因为模型行为会随 Input、Context 与 Runtime Condition 波动。区分 Capability 与 Guarantee，可以避免把 Model Confidence 当成 SLA，并把工程注意力转向 Evaluation、Fallback、Human Review 与 Deterministic Enforcement。
01
把 Capability 转成有边界的 System Claim
先定义关心的 Behavior、Input Distribution 与 Consequence，再在 Representative 与 Adversarial Case 上测量 Performance，识别不可接受 Failure，并通过 Validation、Fallback、Approval 或 Hard Constraint 把风险压到可辩护范围。系统承诺应建立在可观察、可执行的条件上，而不是“模型通常好像能做到”。
02
示例：“模型会引用来源”被误写成产品保证
模型在 Demo 中经常能正确生成 Citation，于是产品直接承诺“每个回答都有来源支撑”。上线后却出现 Citation 缺失或与 Claim 无关。只有当应用要求 Structured Citation、验证 Source 存在且真正支持 Claim，并在 Evidence 不足时 Block 或明确标记，Guarantee 才开始可辩护。
常见失败模式
- 把一次 Successful Demo 直接升级成 Universal Reliability Promise。
- 用 Benchmark Average 替代高后果 Edge Case 的保证。
- 认为 Model Self-confidence 可以取代 External Validation。
工程启发
- 每个强 Product Claim 都明确背后的 Input Distribution 与 Failure Budget。
- 用 Evaluation 测 Capability，用 Runtime Control 限定 Guarantee。
- 只有 Surrounding System 能验证或执行的 Behavior，才适合做 Hard Promise。
关键结论
- 01Capability 是概率 Evidence，不是 Contract。
- 02Guarantee 属于整个 System，而不是 Model 单体。
- 03Production Engineering 的核心工作之一，就是给两者之间的 Gap 建边界。
阅读记录
这里只记录你真实做过的动作，不代表掌握、熟练或认证。
用于这些学习路径
这个 Concept 会在多个 canonical 学习路径中复用。
来自 Knowledge Graph 的相关知识点
这些关系直接来自 canonical graph，不维护第二套 Guide 分类体系。