我们注意到一个反直觉的判断：生产环境里的 LLM 应用（接入大模型的产品），防护手段可能还不如 2015 年的微服务。原因不复杂——大多数团队上线前只做功能验收和延迟压测，但 LLM 应用的外部接口不可控、输出不可预测，传统测试根本测不到真正会爆的路径。

这是什么

混沌工程（Chaos Engineering）这个概念在 Netflix 2010 年代的"猴子实验"里讲清楚了：在生产环境里故意搞破坏，看系统会不会崩。搬到 LLM 应用上，就是"给 AI 系统下毒"。 具体做三件事。第一，画出 AI 系统一定会撞到的五类故障——服务商接口挂掉、模型输出格式突变、Token（按字数计费）超限、延迟雪崩、检索结果被污染。第二，按"4 个维度 × 3 个强度"设计实验矩阵，从轻到重逐级注入故障。第三，定义 LLM 特有的稳态指标：不是"服务还活着"，而是"用户还能拿到有价值的回复"。整个实验可以用一个 200 行的 Python 中间人代理实现，不需要买企业版工具。

行业怎么看

支持的声音很直接：LLM 应用的故障路径组合远比传统服务复杂，靠单元测试和压力测试覆盖不到。一种常见的事故复盘结论是——降级方案写在代码里，但从没被触发过；备用服务商的密钥过期三个月没人发现。 反对意见值得听。一位有十年 SRE（网站可靠性工程师）经验的从业者认为，把混沌工程复杂度全盘搬到 AI 项目上是过度工程。"对绝大多数中小团队来说，一天请求量不到一万，先把监控和告警做扎实，比搞实验矩阵更现实。"他的判断：混沌工程是规模化阶段的工具，不是创业期的工具。 还有一层风险容易忽略——混沌实验本身有破坏性。生产环境里故意注入故障，隔离没做好反而制造真实事故。

对普通人的影响

对企业 IT：公司上线 AI 客服、知识库问答这类应用，文章描述的故障画像基本都会遇到。建议先从监控"沉默降级"开始——用户没报错但回复变差，这种指标比错误率更难设。 对个人职场：跟你日常工作关系不大，但企业 AI 助手偶尔"变笨"或答非所问，背后可能正是这种未被验证过的故障路径。 对消费市场：下次打开某个 AI 产品发现它答得很离谱，别急着骂产品——可能它正巧跑在某个降级链上。理解这一点，能少一点不必要的愤怒。