摘要
传统系统的事故通常有清晰的因果链：某个服务挂了、某个配置错了。AI 系统的事故往往模糊得多——用户说"答错了"，而系统看起来一切正常：没有报错、延迟正常、日志完整。从"答错了"追到根因，需要的不是更聪明的推理，而是更完整的留痕与一套固定的定位流程。本文拆解四类常见根因、复盘必须依赖的三类数据、定位的标准路径，以及把结论变成防线的四个动作。2026 奇点智能技术大会（11 月 20-21 日 · 北京万达文华酒店）将讨论 AI 工程实践与可靠性。
一、AI 事故的四类根因
把常见事故归类，根因通常落在四类之一。
| 根因类别 | 典型表现 | 定位难度 | 常见触发 |
|---|---|---|---|
| 输入侧 | 用户给了模糊/异常输入 | 低 | 边界输入、多语言混杂 |
| 上下文侧 | 关键信息被截断或污染 | 中 | 上下文管理策略缺陷 |
| 模型侧 | 模型换代或参数漂移 | 中 | 升级未做充分回归 |
| 集成侧 | 解析失败、工具错误、缓存串味 | 高 | 上下游契约不一致 |
第四类定位最难，因为问题不在 AI 组件本身，而在它与周边系统的接缝处。而接缝恰恰是最少被监控的地方。
二、复盘依赖的三类留痕
没有数据，复盘就只能靠猜。三类数据必须留存：
第一类：完整调用记录。包括调用方标识、模型版本、提示词版本、路由决策、实际使用的参数（temperature 等）、耗时、token 消耗。缺任何一项，都可能让复盘卡住。
第二类：输入输出内容。在合规允许范围内留存原始输入与输出，用于复现。只存摘要或指标，事后无法还原现场。
第三类：中间步骤。对智能体系统尤其关键：每一步的工具调用、返回结果、以及模型的中间判断。没有中间步骤，就无法定位是哪一步走偏。
留痕完整度自查： · 能否还原某次请求使用的确切提示词？ · 能否看到当时模型返回了什么？ · 能否知道中间调用了哪些工具、返回了什么？ ↑ 任一为否，复盘就只能靠运气三、定位的标准流程
建议固定为五步，避免复盘变成自由讨论。
第一步：复现。用留痕数据重放请求，确认问题可复现。如果无法复现，先解决留痕不足的问题——这也是一条重要结论。
第二步：定位层级。判断问题出在哪一层：输入、上下文、模型、还是集成。方法是从两端往中间排查：先看最终输出是否异常，再看中间步骤，最后看输入。
第三步：确定触发条件。是个例还是一类？找出共同特征——某类用户、某类输入、某个时间段、某个模型版本。
第四步：追到机制。不只要知道"发生了什么"，还要知道"为什么会发生"。例如"上下文截断导致关键信息丢失"比"模型答错了"更有价值。
第五步：评估影响面。有多少请求受影响？是否持续？是否需要通知用户？
defreplay(request_id,store):"""复现示意：按留痕还原一次完整调用，用于定位。"""rec=store.get(request_id)return{"prompt":store.prompt_version(rec.prompt_id),"model":rec.model_version,"params":rec.params,"steps":store.tool_calls(request_id),"output":store.output(request_id),}四、把结论变成防线
复盘的价值在于防线，不在于报告。四个动作：
动作一：加监测。针对根因加一个可观测的指标。例如根因是"上下文截断"，就加一个"截断发生率"指标。能被观测的问题，下次会被更早发现。
动作二：加拦截。在问题发生前拦住它。例如输入侧问题，加输入校验与提示改写。拦截优于告警。
动作三：加用例。把这次的问题加入回归测试集。这是防止复发的成本最低手段。
动作四：改设计。如果同一类问题反复出现，说明设计有缺陷，需要结构性调整，而不是继续打补丁。
防线的有效性排序：改设计 > 加拦截 > 加用例 > 加监测 ↑ 越靠前越根本，也越难做到五、三个常见误区
误区一：把事故归因于"模型不稳定"。这是一个无法行动的结论。模型行为确实有随机性，但大多数事故背后都有具体机制——参数、上下文、集成。归因到"模型就这样"，等于放弃改进。
误区二：只修现象不修机制。例如发现答错了就加一条提示词约束，而不去查为什么这条约束原本缺失。补丁会越来越多，系统越来越难理解。
误区三：复盘不跟踪。报告写完、改进项列出，然后没有跟进。改进项必须有责任人与期限，并在下次评审时回顾。
六、一份精简的复盘模板
建议固定包含六项：
- 现象：用户侧看到了什么
- 影响：范围、时长、严重程度
- 时间线：从发生到发现到恢复的关键节点
- 根因：机制层面的解释，不是现象描述
- 改进项：具体动作、责任人、期限
- 遗留风险：本次未解决、需要持续观察的部分
第六项常被省略，但它决定了下次复盘是否需要从头开始。把已知但未解决的问题记录下来，是团队积累的关键。
七、复盘文化的三个前提
复盘机制能否持续，取决于文化而不只是流程。三个前提值得建立。
前提一：对事不对人。如果复盘会变成追责会，参与者会隐藏信息，复盘结论就会失真。明确"不复盘个人失误，只复盘系统缺陷"，是机制可持续的前提。
前提二：允许暴露不确定性。很多时候根因无法一次查清。允许记录"暂时无法确定"并持续跟踪，比强行给出一个结论更诚实也更有用。
前提三：改进项必须闭环。每次复盘开始时，先回顾上次改进项的完成情况。这一条动作能显著提升改进项的实际完成率。
复盘的敌人：追责氛围、强行结论、有始无终 复盘的支撑：完整留痕、固定流程、改进闭环八、读者问答
问：小事故也需要复盘吗？可以按轻量流程处理，但值得记录。很多大事故在发生前都有过小的先兆，只是没有被记录。
问：复盘要花多长时间？一次中等复杂度的复盘通常一到两小时，加上准备时间。超过这个时长往往说明留痕不足，导致大量时间花在还原现场上。
问：如何判断复盘是否有效？看两个信号：同类事故是否重复发生、改进项是否按期完成。两个信号都不好，说明复盘流于形式。
问：没有事故时还需要演练吗？需要。定期演练能验证留痕是否足够、定位流程是否顺畅。等到真事故发生才发现留痕缺失，代价太大。
九、留痕的合规与隐私边界
留痕是复盘的前提，但留痕本身也带来风险。三个边界需要明确。
其一是留存期限。不同数据的合理留存期不同：调用元数据可以留较久，输入输出内容应设较短期限。无限期留存既没必要也不合规。
其二是脱敏规则。个人标识信息在写入日志前应脱敏，但要保留可用于定位的结构信息。完全脱敏会让日志失去复盘价值，需要在两者之间取得平衡。
其三是访问权限。事故复盘需要访问原始内容，但这类访问应当受限并可审计。权限不加控制的日志系统，本身就是风险源。
defredact(payload,rules):"""脱敏：保留结构与类型信息，替换敏感值。"""out={}fork,vinpayload.items():ifkinrules.pii_fields:out[k]=f"<{type(v).__name__}:{len(str(v))}>"# 保留类型与长度else:out[k]=vreturnout保留"类型与长度"是一个实用技巧：它足以支撑大部分复盘判断，又不会保留原始敏感内容。
十、读者问答
问：复盘需要保存全部输入输出吗？
不需要，也不应该。建议全量保存元数据，输入输出按比例采样或按异常条件保存。异常样本的全量留存价值最高。
问：留痕会不会影响性能？
同步写入会有影响，建议异步落盘并接受极少量丢失。复盘需要的是统计意义上的完整性，不是绝对不丢。
问：日志系统与追踪系统的关系？
日志回答"发生了什么"，追踪回答"经过哪些环节"。AI 系统两者都需要——只有日志时无法定位链路，只有追踪时无法还原内容。
问：如何验证留痕是否够用？
定期做一次"盲复盘演练"：随机选一次历史请求，尝试仅凭留痕还原现场。还原不了的地方，就是留痕的缺口。
十一、最后几个问题
问：复盘结论需要对外公开吗？
视组织文化而定。至少应在团队内公开并归档，只对内可见的复盘也能积累价值，关键是持续。
问：AI 事故与传统事故的处理有何不同？
最大的不同是"看起来正常但结果错误"这类情况没有明确告警信号，需要依赖质量指标发现。
问：如何降低事故发生的概率？
三个方向：缩小变更粒度、加强变更前验证、以及保留快速回退能力。第三项在 AI 系统里尤其重要。
十二、衔接大会专题
问：复盘报告应该保存多久？
至少一年。历史复盘是最有价值的知识库，能让新成员快速理解系统曾经的失败模式与应对方式。
问：没有造成损失的事故需要复盘吗？
值得。未遂事故往往揭示了系统的真实脆弱点，且成本为零——这是最便宜的学习机会。
问：复盘能否外包给工具自动完成？
工具可以自动生成时间线与指标变化，但根因判断与改进决策仍需人来做。自动化的价值在于准备材料，不在于替代判断。
11 月 20-21 日，北京万达文华酒店，2026 奇点智能技术大会将讨论 AI 工程实践、可靠性与可观测性；C++ 及系统软件技术大会则从故障定位、日志与追踪角度给出底层方法论。
带着"我们的系统能不能还原任意一次请求的完整现场"这个问题的答案去参会，会立刻知道复盘能力处在什么水平。
大会信息
2026 奇点智能技术大会 + C++ 及系统软件技术大会
时间：2026 年 11 月 20-21 日
地点：中国·北京万达文华酒店
大会报名：点击报名，领取大会PPT资料
立即报名，锁定 Lukasz Kaiser Keynote 与 70+ 场演讲完整资料！
