最可怕的不是报错，是你的 AI 悄悄换了个人
先说结论：系统崩溃不可怕，静默降级才可怕。
崩溃有报错、有告警、有明确的时间点。
静默降级什么都没有——系统看起来正常运转，产出持续交付，质量却掉了一个台阶，没有任何人收到任何通知。
然后讲一个发生在我自己系统里的事故。
事故：配置里的模型，不是跑着的模型
我的 AI 工作流里，几个子代理（负责架构审查、方案批判的那类角色）被配置了一个很强的模型，通过一个中转代理接入。
配置文件里白纸黑字。
某天做质量复盘，我发现那阵子的产出质量不对劲。
逐层排查，真相浮出来：那个中转代理某天挂了。
之后所有请求被静默切换到另一个便宜得多的模型。
没有任何报错。没有任何告警。
产出格式完全兼容，只是质量差了一截。
最扎心的还在后面：我逐条核对时间线后发现，那段时间里有两轮"由 AI 完成的架构审查"，实际是降级模型自审自。
我一直以为那段时间有高水平的质量兜底。
把关者自己就是嫌疑人。
为什么静默降级比崩溃更危险：三种假象
配置假象。配置描述的是意图，不是事实。"配置里写用什么模型"和"实际跑什么模型"之间，隔着网络、配额、重试策略、降级逻辑四五层运行时决策。把配置当事实，等于把愿望当现实。
日志假象。日志只记录代码决定记录的事。降级行为如果没有被显式标记，日志里只有一行平平无奇的成功记录。没有为降级设计日志项的系统，日志越干净越假。
抽查假象。哪怕你抽查产出也有盲区：降级模型的产出格式完好、语言通顺、乍看专业——质量差异藏在深层推理和细节准确性里。没有参照物的抽查，只是仪式。
探针设计三原则
原则一：信探针，不信自述。对关键链路部署金丝雀——定期发送答案已知的标准请求，核验质量是否在预期区间。配置说模型是 A 不算数，金丝雀答对了才算数。
原则二：降级必须是显式事件。任何降级、重试、切换行为，必须产生显式标记并进入告警统计。一句话：系统可以降级运行，但不许悄悄降级运行。这条应该写进所有第三方依赖的集成规范。
原则三：产出留痕可回溯。重要环节的产出保存版本快照。我是靠新旧产出的时间线对比才锁定降级起点的——没有留痕，漂移只能被感知，不能被调查。
推而广之：这是一种产品思维
静默降级不止发生在技术系统里。
转化率悄悄掉了三个点、留存曲线斜率缓了一分、某个渠道的量连续两周阴跌——产品数据里的静默降级遍地都是，而且同样没有告警。
产品经理对"看起来还在运转"的东西天然缺乏警惕，因为它们不吵不闹。
所以我把探针思维搬进了产品运营：核心指标配同环比变化告警，关键漏斗每周对基准回放一次，任何"应该稳定"的曲线波动超阈值就是事件。
对没有尖叫的东西保持敬畏，是运营复杂系统的基本功。
这套探针思维的完整框架见 Layer 0 控制图；同病灶的另两个案例见 变慢排查 与 配置回滚。
← 返回博客列表 · 相关阅读：Layer 0 控制图 · 配置回滚