把 temperature 从 0.7 调到 0.1，输出可能更一致，但这不代表系统更可靠。可靠性是“在约束内持续产出可执行结果”，不是“句式更稳定”。
低温能解决什么，不能解决什么
| 低温能改善 | 低温不能解决 |
|---|---|
| 输出随机性下降 | 事实错误与工具误用 |
| 格式更稳定 | 权限越界与策略失守 |
| 复现更容易 | 上下文遗漏与流程缺陷 |
低温是参数调优，不是治理体系。
可靠性的真正来源
- 明确的 Prompt Contract
- 可执行的工具 schema 与权限边界
- 稳定的评测集与发布门禁
- 可观测、可回滚的运行控制
如果这些不完善，再低的 temperature 也只是“稳定地产生错误”。
失败案例：低温后通过率短期上升，线上投诉反增
某团队将温度下调后离线格式通过率提升，但线上投诉增加。原因是系统仍缺少边界约束，低温让错误更一致地重复出现。后续通过 policy 层拦截和评测集补洞才恢复稳定。
可靠性 Checklist
- 不把 temperature 当唯一可靠性手段
- 高风险场景有独立策略约束
- 评测门禁覆盖真实用户样本
- 发布后监控 FRHR 与接管率
- 出现一致性错误时优先查流程而非参数
延伸阅读：
