8.0
热点
AI SCORE
技术实践2026-08-08 05:39
AI 功能复盘：非确定性使传统方法失效
dev.to · AI#AI复盘#工程管理#故障分析
Editor brief · 编辑速览
AI 失败因非确定性、依赖变化和渐进退化而难以复盘，需要新的复盘思路——证据在出问题前就需记录。
本文不是一份事后报告，而是教你如何写一份事后报告——后者更有用，因为 AI 功能事后报告最常见的无用原因是：它所需要的证据从未被记录——而这其实是一个在问题发生前好几个月就做出的决定。
传统的事后报告有明确的时间线、触发事件和修复方案。它之所以有效，是因为系统是确定性的：相同的输入加上相同的代码，会产生相同的结果，所以根本原因可以通过重构来发现。
AI 功能同时打破了这三个假设。输出是不确定的，所以"它产生了这个结果"这件事无法复现——同样的请求再次运行可能得到一个正常的结果，但这不能作为问题已消失的证据。依赖项会在你没有参与的情况下发生变化，所以行为变化可能与你的代码改动没有任何对应关系。而失败往往不是一个有明确起止时间的事件：质量在下降，或者从来就没好过，"事件"本身是一个"决定停止"的决策，而非一次宕机。
最后一点最为重要，因为这个领域最有价值的事后报告往往是关于那些没有崩溃的功能——它们被构建、发布、维护，却始终无法证明自己的成本是合理的。这类情况在 incident 追踪系统里没有记录，也不会触发告警，但它是最值得理解的失败。
六个类别。将它们命名是有价值的，因为每种类型的补救措施完全不同——如果一份事后报告被归错了类别，就会产生一个针对团队实际上并不存在的问题的修复方案。
其中两个——成本和无人使用——几乎从不被写进报告，因为两者都不会产生 incident。它们应该被记录，而且这种复盘值得在第六个月和第十二个月主动安排，而不是等到出了问题再处理。
这一节是让你今天就采取行动，而不是等到失败之后。下面每个字段都是事后无法重建的；如果当时没有记录，相应的问题就永远无法回答。
每个请求 回答的问题
模型 ID + 版本 "provider 改了什么东西吗？"
提示词 ID + 版本 "是我们的改动还是他们的？"
输入哈希 + token 数量 "输入有变化吗？"
验证结果 "当时能检测出它是错的吗？"
降级层级 / 降级方案 "这部分流量已经降级了多少？"
成本 "一个成功输出的代价是多少？"
延迟（TTFT 和总时长） "是慢了，还是错了？"
每个输出结果
用户后续行为 接受、编辑、忽略、撤销
审核结论 + 修正 这是你唯一能免费获得的 ground truth
定期
一个固定的 canary 集合，按计划运行，保留结果
"行为是什么时候变化的？"
—— 没有时间序列，这个问题永远无法回答；
线上日志不能替代它，因为线上流量本身也在变化
canary 序列是人们最后悔没有做的。线上流量指标混淆了两个变量——系统变了，输入也变了——而每周运行一次固定集合可以将它们分离，这就是"行为在某一天或某几天发生了变化"和"质量似乎在某段时间内有所下降"之间的区别。前者是一份有价值的事后报告，后者只是印象。在机制上，这属于捕获 provider 端的变更，而运行它的真正原因是：它让后续的调查成为可能。
设计结构时，要让真实的回答容易给出，而回避性的回答会明显地缺失。
它本应做什么——用当时的原话表述原始声明，以及它本应影响的指标。引用原始表述而非转述，这才能让文档的其余部分难以被美化。
实际发生了什么——观察到的数字，注明来源和样本量。如果某个数字无法提供，就说明无法提供，并说明是缺少哪种instrumentation 导致了这一点。这一行往往是文档中最具可操作性的内容。
属于哪个类别——从上面的分类中明确选择。对类别的争论实际上是对原因的争论，在这一节里争论比在解决方案部分争论更有价值。
决策点——不是事件的时间线，而是列出每一个存在其他选择的关键时刻：功能被定稿的时候、没有做 eval 就发布的时候、成本模型没有被建立的时候、指标被搁置一个月无人查看的时候。这一节产生的是可迁移的经验；症状的时间线不会。
哪些是真且仍然成立的——有效的部分。一份全盘否定该功能的事后报告会丢失那个本来没问题的提取管道，而下一个团队会把它重新建出来。
需要改变什么——流程改进，不是表态。"我们会在发布前做评估"是一个表态。"功能必须有一套在 CI 中的 case 才能通过 review"是一个改变。
有一条从传统事件实践中值得整体借鉴的纪律：将发生了什么与是谁做的分开，让文档的写法是：一个当时拥有同等信息的理性人会做出相同的决定。在这个领域里，这通常在字面意义上就是真的——当时可用的信息就是一个 demo，而整个练习的意义就是改变下次可用的信息。
关于不成功的 AI 功能的公开复盘文章比成功案例更罕见，也更有价值，但阅读时需要两个调整。
首先，用模型代际来核对日期，并检查实际归因的是什么。"模型无法做 X"这种形式的结论可能经过两代模型就站不住脚了；而"我们没有办法判断输出是否正确"这种形式的结论是关于系统设计的，不会过期。后者可以迁移；前者往往不能，大多数关于公开失败案例的分歧来自于把两者混为一谈。
其次，找分母。"它出错了"如果没有错误率、样本量以及与先前方案的对比，就只是一个印象。一份说明了评估方法的报告抵得上十份只描述体验的报告，同样的标准也适用于你正要写的这一篇——这也是尽早建立评估集的最实际的理由：它让你日后能够对自己的功能说出真实的话，无论结论是好是坏。