为何"修改提示词"是根因谬误：为 AI 系统打造无责事后复盘

你的 LLM 功能开始返回胡言乱语。值班工程师呼叫 ML 团队。他们看了看输出，和提示词本应产生的结果对比了一下，不到一小时就关闭了工单："提示词有问题——已调整并重新部署。"事件关闭，事后复盘完成，行动项：改进提示词工程流程。

两周后，同类故障再次发生。不同的提示词，不同的功能——但是同样隐性的根因。

"修提示词"的反射动作，是 AI 工程领域版本的"甩锅给最后一个碰过这个文件的开发者"。它给事后复盘一个干净的结局，却无需任何人真正理解到底是什么出了问题。而与传统软件不同——那里这种反射动作只是懒散——在 AI 系统中，它在结构上是危险的：因为非确定性系统的失败方式，是提示词修改无法解决的。

为何传统事后复盘文化有效，而 AI 又将其打破

SRE 中的无责事后复盘文化存在一个具体原因：当人们害怕受罚时，他们会隐藏信息。隐藏信息阻止学习。不从失败中学习的系统会重蹈覆辙。Google 的 SRE 手册将其正式化为实践，业界也基本采纳——不是因为这感觉很好，而是因为当工程师能够说"以下是我们搞坏的东西和原因"而不必担心职业风险时，系统就会改进。

然而，无责模型隐含一个微妙的假设：存在一个离散的、可重现的故障事件供分析。服务在 14:23 UTC 崩溃。一次配置推送引入了空指针。一次数据库迁移删除了一列。这些故障有法证轨迹。你可以重放事件序列。你可以高置信度地建立因果关系。

LLM 故障不是这样运作的。同样的输入在不同调用中可能产生不同的输出。上周二出现在 3% 响应中的问题，本周可能在没有任何部署的情况下出现在 8% 中。故障事件不是离散的——它是一次分布漂移。而这正是传统事后复盘模板失效的地方。

当你的事后复盘表格问"事件发生前发生了什么变化？"而诚实的答案是"我们没有部署任何东西——模型漂移了"，想要关闭工单的工程师就会抓住最近的可用解释。提示词永远在那里，永远不完美，永远可以被甩锅。

提示词修改无法解决的五类故障

对 LLM 系统故障的研究揭示，大多数生产事件并不源于提示词质量。一项针对开源 LLM 故障的实证分析发现，环境故障（基础设施耦合、依赖失败）占故障的约 46%，用户配置故障占 25%，而以模型为中心的问题——提示词修改实际上会有帮助的——占少数。

以下是 AI 系统的一个可用故障分类体系：

基础设施与环境故障。 推理层与外部依赖之间的刚性耦合、来自上游负载增长的上下文窗口耗尽、导致生成中途超时的嵌入检索延迟峰值。这些都不是提示词问题。

数据与检索故障。 RAG 语料库中的过期文档、知识库中的模式漂移、使存储向量失效的嵌入模型更新。模型在给定所传递内容的情况下正确地完成了工作——被传递的内容本身是错误的。

模型退化故障。 提供商侧的模型更新（相同的模型名称，不同的权重）、微调模型的目标分布已经漂移的概念漂移、模型更新后悄无声息的嵌入空间变化。你的事后复盘中没有部署事件可以指向，因为变化发生在黑盒内部。

Agent 协调故障。 在多 Agent 系统中，故障分为三层：Agent 层（LLM 做出了糟糕的决策）、结构层（编排逻辑在 Agent 之间传递了错误状态）和平台层（运行时未能正确处理部分结果）。将结构层故障归咎于提示词，就像将网络层的竞态条件归咎于应用代码。

安全面故障。 提示词注入攻击——其中检索文档或用户输入中的恶意内容覆盖了系统指令——在 Agent 系统中的攻击成功率为 84%，而单 Agent 系统中为 50%。每一次 Agent 间的交接都是一个注入面。这需要特定于安全的响应手册，而不是提示词编辑。

了解事件属于哪个类别，决定了你实际修复什么。没有分类体系，每个事件看起来都像是提示词问题，因为提示词是工程师们认为他们能控制的唯一事物。

为非确定性系统构建无责框架

将 SRE 事后复盘文化适配到 AI 系统，需要改变调查过程和文档格式。心理安全原则保持不变——害怕受责的工程师会隐藏信息——但技术方法需要考虑概率行为。

用"什么发生了漂移？"替代"什么发生了变化？"

传统的五个为什么分析以变更事件为锚点。对于 AI 事件，你需要一个并行轨道：什么分布发生了漂移？对你的系统进行仪表化，不仅记录请求是否成功，还要记录输出的分布——置信度分数、响应长度分布、拒绝率、与预期响应的语义相似度。当你能够随时间绘制这些数据时，漂移就变得可见，无需部署事件。

先分类，再分析。

在任何根因分析之前，先根据你的分类体系对事件进行分类。分类决定了你的调查路径。如果是环境故障，你在调试基础设施。如果是检索失败，你在审计你的语料库。如果是模型退化，你在检查提供商更新日志并针对之前的检查点设置影子测试。从分类开始可以防止"最近可用解释"的失效模式。

记录故障分布，而不是故障实例。

传统的事后复盘记录"系统在应该返回 Y 时返回了 X"。AI 事后复盘需要记录"系统在 P 时间段内对该端点的 N% 请求中返回了 X，而预期基线为 M%"。这种重新表述很重要：它防止团队说服自己这个事件是一个孤立的边缘案例，而实际上它是一次系统性漂移。

将"发生了什么"与"修复什么"分开。

AI 辅助事后复盘工具对于繁重工作越来越有用：总结事件时间线、跨日志关联信号、生成影响部分的初稿。但根因分析——从症状到结构性原因的"为什么"链条——无法被自动化。产生事件的系统无法可靠地诊断自身的故障模式。对因果链的人工审查是必须的。

每个团队都发现太晚的手册缺口

传统 SRE 拥有成熟的基础设施事件手册：重启服务、扩展资源池、回滚部署。AI 系统需要一套大多数团队在被坑过之前不会构建的并行手册。

一个最小的 AI 事件手册库至少需要四个条目：

• 模型回滚程序：如何切换到之前的模型检查点或回退到基于规则的基线。谁来批准？对延迟有什么影响？
• 检索隔离程序：如何在调查数据质量问题时将特定文档或整个语料库排除在检索之外。你的系统支持热排除还是需要重新索引？
• 输出分布告警阈值：什么拒绝率或语义漂移值触发告警？p95 退化与完全中断的响应协议是什么？
• 注入面审计清单：对于 Agent 系统，哪些信任边界是经过验证的，哪些是隐式的？外部内容在哪里可以影响 Agent 行为？

缺少这些手册不是流程失败——它是一个信号，表明团队还没有正式定义其 AI 系统的"可靠性"意味着什么。这种正式化是成熟事后复盘流程的真正产出。

可观测性是诚实事后复盘的先决条件

"修提示词"的反射动作部分是一个合理化问题，部分是一个仪表化问题。当工程师没有更好的证据时，他们就抓住提示词解释。如果你没有输出分布仪表盘，你就无法证明漂移。如果你没有检索日志，你就无法追踪哪些文档影响了一个糟糕的响应。如果你的 Agent 工作流中没有逐步追踪，你就无法区分 Agent 层故障和编排层故障。

2025 年的可观测性数据很有说服力：62% 的生产 AI 团队将可观测性列为其首要改进重点，而不到三分之一的团队对其当前解决方案感到满意。这一差距很重要，因为文档处理和面向客户的 AI（最高容量的生产用途）将错误直接暴露给用户——这意味着在后端系统中可能隐藏的故障会立即成为可见的事件。

技术要求比传统应用监控更苛刻。记录 LLM 请求成功几乎不能告诉你任何事情。你需要追踪每个 Agent 步骤，在线监控输出质量分布，捕获检索结果与生成响应的对应关系，并将业务指标（转化率、解决率、用户升级）与随时间变化的模型行为相关联。

没有这种仪表化，你的事后复盘将永远止步于"模型行为"——不是因为这是真正的根因，而是因为那是你能看到的最后一件事。

成熟的 AI 事件文化是什么样的

已经超越"修提示词"反射动作的团队有一些可观察到的共同特征。

他们像对待延迟退化一样对待模型漂移：有仪表盘、告警阈值和与业务影响挂钩的响应手册。他们区分输出质量 5% 的退化（调查，不呼叫）和 30% 的退化（呼叫，执行手册）。他们为模型行为定义了 SLI，而不仅仅是基础设施正常运行时间。

他们对故障分布运行事后复盘，而不是故障实例。一个孤立的糟糕输出是噪声。三周内输出落在质量阈值之外的比率发生 2% 的漂移是信号——即使没有用户提出投诉，它也会有自己的事后复盘。

他们像代码一样对提示词进行版本管理，有完整的部署历史，所以"发生了什么变化？"有真实的答案。他们接受有些事件不会有干净的根因——在一批输入分布下模型行为异常，分布不寻常，没有任何部署——他们如实记录这一点，而不是编造一个叙事。

无责事后复盘文化的目标从来不是让工程师对失败感觉良好。它是创造诚实调查所需的心理安全感。在 AI 系统中，诚实调查需要承认：故障分类体系比"提示词有问题"更复杂，可观测性要求比传统日志记录更苛刻，手册需要在事件发生之前写好，而不是在事件期间。

提示词几乎从来不是根因。但它会一直被甩锅，直到团队构建出让他们能看到真正根因的系统。