下游要的是"要不要信"，不是"答案是啥"
很多人把 AI 输出当成一个确定性结果传给下游 ✗：自动写库、自动发信、自动审批 ✔。
但 AI 的输出天然带不确定性 ✔，如果不把它传下去，下游就只能靠猜 ✗。
把不确定性显式传出去，下游才能做正确的事：人工确认、降级、或者拒绝 ✔。
一、不确定性怎么表达（三种粒度）
| 粒度 | 形式 | 适合 |
|---|---|---|
| 粗 | confidence: high/medium/low | 大多数业务流（简单可用 ✔） |
| 中 | uncertainty: {level, reasons[]} | 需要知道为什么不确定 ✔ |
| 细 | 每个字段带置信或区间 | 抽取/数值类任务 ✔ |
建议：从"粗"开始 ✔。high/medium/low 三档 + 理由列表（资料不足 / 多源冲突 / 时间久远 / 数值推算 ✔），
下游就能写规则 ✔，比塞一个 0.73 的分数更可用 ✔（分数没人知道阈值该定多少 ✗）。
二、该显式区分的四种状态
- 有依据的结论（可引用原文 ✔）；
- 合理推断（基于常识，无原文 ✔）—— 必须标注为推断 ✔；
- 未找到（资料里没有 ✔）—— 明确说"未找到"，不给替代答案 ✗；
- 拒绝（越权/合规/能力外 ✔）—— 给原因与替代路径 ✔。
下游规则的写法：状态 1 → 可自动；状态 2 → 需人工确认；状态 3/4 → 不写库 ✔。
三、数值要给区间（不是单点）
- 抽取到的金额/日期/数量，若非原文直引，就要给区间或"约" ✔；
- 推算值必须标注推算方法 ✔（"按每页 500 字估算" ✔）；
- 下游对数值执行范围校验（见接线那篇 ✔）。
四、拒答怎么写才对下游友好
{ "status": "not_found",
"message": "资料中未包含该型号的参数",
"what_would_help": ["提供型号全称", "指定文档版本"] }
给"怎样能让它成功" ✔ 比单纯说"没有"有用得多 ✔（下游可以提示用户 ✔）。
五、三个反模式
- 用分数糊弄 ✗（下游拿 0.68 不知道怎么办 ✔）；
- 把推断当结论 ✗（下游无法区分 ✔，错误会静默传播 ✔）；
- 拒答时返回空字符串 ✗（下游无法区分"空"与"没有" ✔）。
一条判据
给下游一个只看输出结构的程序员 ✔，他能否在不问 AI 团队的情况下写出正确的处理规则 ✔？
不能，说明不确定性还没传出去 ✗。