系统出错后，客户最怕的往往是没消息
故障补救需要及时说明已知影响和下次更新时间，避免用未经核实的保证安慰客户。系统恢复后，还要补齐受影响的任务与结果，让客户能继续自己的工作。
TOPIC
系统可靠性.
关于「系统可靠性」的文章。
跨频道阅读同一个话题，发现值得关注的内容。
同一个AI产品，为什么要用不止一个模型？
模型路由按任务选择规则、轻量模型或更强模型，效果要靠真实样本验证。分派失误可能增加等待和成本，资料或权限不足时，也需要允许流程停止或转交人工。
AI回答更顺了，就代表它真的变好了吗？
评测集用固定样例和明确标准比较产品变化，检查真实结果而非回答是否顺眼。保留陌生样例、观察多次运行并核对评分，有助于识别改进范围与仍然存在的错误。
只改了一句提示词，产品为什么像换了个人？
提示词进入产品后会持续影响输出规则，需要记录修改原因并追踪具体版本。回滚还要与模板、字段和校验设置配合，才能还原变化并支持有效比较。
备用模型接好了，不代表产品就能扛住故障
备用服务能否在故障时接住业务，需要验证额度、格式和实际效果。降级应保留可信的核心结果，并明确等待、暂停和人工处理的边界。
产品能不能换服务，取决于连接处怎么设计
可替换性依赖清楚的模块边界，也涉及数据导出、状态含义和质量验证。集中管理供应商差异，有助于逐步迁移，减少无必要的预先设计。
可靠性也有预算，关键工作要先被保护
可靠性投入需要按客户承受失败的后果排序，优先保护关键工作。维护预算还应覆盖发现、恢复和验证，服务承诺要与实际保障能力相符。
页面没报错，为什么客户还是说“不能用”？
系统正常运行不代表客户拿到完整结果。通过任务编号串联日志、指标和处理过程，能够追查业务偏差，同时控制记录内容、访问范围和保留期限。
“服务很稳定”，到底是一句承诺还是一句感受？
服务指标描述表现，服务目标明确标准，协议约定未达标后果。衡量稳定性应贴近客户工作的时点和结果，提前统一统计口径，避免平均数掩盖问题。
按钮点了两次，为什么不该扣两次钱？
网络超时可能发生在业务已经完成之后。幂等性通过识别同一次操作，减少重试带来的重复订单、扣费和通知，同时需要核对不同步骤的实际结果。