Wiki Notes

Appearance

AI项目复盘案例专题 ​

版本：v1.2

最后更新：2026-07-08

适用对象：正在做 LLM 应用、RAG、Agent、多模态系统和企业内部 Copilot，需要把“做过一次项目”沉淀成“下次能少踩坑”的产品、研发、平台、交付与运营同学

很多团队做 AI 项目时，复盘最后会滑向两种极端：

  • 只讲结果，不讲过程
  • 只讲技术，不讲决策

结果就是：

  • 经验沉淀不下来
  • 下次还会踩同样的坑
  • 团队无法形成可复用的方法论
  • 事故似乎“修过了”，但系统并没有真正更稳

OpenAI 当前 Production best practices、Evaluation best practices、Build an Agent Improvement Loop with Traces, Evals, and Codex，以及 Google SRE 关于 postmortem culture、example postmortem、postmortem analysis 的一手资料，在 2026-07-08 复核时指向一个很清楚的共识：

  • 复盘的目标不是解释过去，而是把一次失败、一次取舍、一次修复，变成下一次不会再重复犯的系统能力。

所以这篇专题不会只给一份“会议纪要模板”，而是补成三层内容：

  1. AI 项目为什么比传统项目更需要复盘
  2. 一份真正能落地的 AI 复盘应该怎么写
  3. 复盘怎样回流到 eval、trace、runbook、发布门禁和下一轮项目治理

1. 为什么 AI 项目比传统项目更需要复盘 ​

传统功能出错时，很多问题可以比较直接定位：

  • 状态码异常
  • 某个服务挂了
  • 某个接口超时

AI 项目经常不是这样。

更常见的情况是：

  • 接口返回 200，但答案已经业务失败
  • 模型、检索、工具、审批、状态机一起影响结果
  • 质量退化不是立刻爆炸，而是缓慢漂移
  • 某些失败只在特定租户、特定角色、特定场景才暴露

这意味着复盘不能只回答：

  • “有没有做出来”

而要回答：

  • 为什么当时这样做
  • 哪些边界被忽略了
  • 哪些假设后来被证明不成立
  • 哪些修复只是止血，哪些修复真正沉淀成了能力

2. AI 项目复盘最容易漏掉的不是技术细节，而是决策背景 ​

很多复盘会写：

  • 模型效果不稳定
  • 检索质量下降
  • Agent 调用了错误工具

这些描述通常只是在说“现象”，还没触到真正的复盘价值。

真正更应该被写出来的是：

  • 为什么当时允许这个风险带着上线
  • 当时有哪些资源、时间、权限和数据约束
  • 为什么会选择 A，而不是 B
  • 为什么原来的验收标准没能发现问题

没有这些内容，后面的读者往往很难判断：

  • 这是一次纯实现失误
  • 还是一次在有限条件下做出的合理但有代价的取舍

3. 一份好的 AI 复盘至少要回答哪些问题 ​

更可执行的版本，建议至少覆盖下面 12 个问题：

  1. 这次项目或事故对应的业务目标是什么
  2. 原本的成功标准和红线是什么
  3. 当时的系统结构和版本状态是什么
  4. 上线前用了哪些评测、样例和门禁
  5. 上线后实际表现如何
  6. 最早的异常信号是什么
  7. 影响范围有多大
  8. 根因是什么，分几层
  9. 临时止血做了什么
  10. 永久修复做了什么
  11. 哪些动作要进入 runbook / checklist / eval
  12. 下次怎样更早发现同类问题

很多复盘会在第 8 步前后草草结束，写成一句：

  • “后来修好了”

真正有价值的部分，恰恰是后面那几步。

4. 一份更适合 AI 项目的复盘结构 ​

更推荐的结构可以写成：

text
背景
 -> 目标与约束
 -> 方案与取舍
 -> 上线前评测
 -> 线上表现
 -> 触发信号与影响面
 -> 根因分层
 -> 临时止血
 -> 永久修复
 -> 回流动作
 -> 负责人与截止时间

这个结构的价值不在于好看，而在于它能帮团队把问题拆成几类：

  • 业务目标问题
  • 数据与知识问题
  • workflow / prompt / tool 问题
  • 可观测性问题
  • 发布与治理问题
  • 组织协作问题

5. 复盘里最值得单独写出来的四层信息 ​

5.1 背景层 ​

这一层回答：

  • 系统面向谁
  • 任务是什么
  • 哪些指标最重要
  • 这次变更前后的环境是什么

5.2 证据层 ​

这一层回答：

  • 真实失败样例是什么
  • 哪些 trace、日志、引用、审批记录能证明问题
  • 指标是从什么时候开始变差的

5.3 决策层 ​

这一层回答：

  • 为什么当时这样设计
  • 为什么会接受这个风险
  • 为什么没有更早上 guardrail、eval 或审批

5.4 行动层 ​

这一层回答：

  • 临时止血是什么
  • 永久修复是什么
  • 哪些动作进入工程体系

如果少了这四层里的任意一层，复盘很容易变成：

  • 有人记得发生过什么
  • 但系统本身没学到什么

6. 根因分析不要只写一个“最终根因”，更适合分层写 ​

AI 项目尤其不适合把根因只写成一句：

  • “模型不行”

更实用的做法通常是分层。

6.1 触发层 ​

直接引发问题的变化。

例如：

  • prompt 改版
  • rerank 参数变更
  • guardrail 阈值调整
  • 工具 schema 更新

6.2 系统层 ​

让问题得以放大的系统条件。

例如：

  • 没有 regression dataset
  • 没有 trace grading
  • 没有审批负载监控
  • 没有 step / retry budget

6.3 组织层 ​

让问题没有被更早识别和阻止的组织因素。

例如：

  • 责任人不明确
  • 发布 checklist 不完整
  • 业务、平台、安全三方信息没同步

这样写的价值是：

  • 你不会把复杂问题误缩成一个“模型差”

7. 临时止血和永久修复必须分开写 ​

这是复盘里最常见也最重要的区分之一。

7.1 临时止血常见动作 ​

  • 回滚模型
  • 缩小流量
  • 提高人工审核比例
  • 关掉高风险工具
  • 降低 top-k
  • 暂停某条 workflow

7.2 永久修复常见动作 ​

  • 新增回归样例集
  • 补齐 trace 维度
  • 增加 tool schema 校验
  • 调整权限模型
  • 增加审批分层
  • 建立发布门禁

回滚通常只是止血，不是长期修复。

如果复盘不把这两类动作分开，团队很容易误以为：

  • “问题已经解决”

但实际上：

  • 系统只是暂时不继续出血

8. 一份真正能落地的 AI 复盘模板 ​

下面这个模板比泛泛的“复盘五步法”更适合 AI 项目：

8.1 基本信息 ​

  • 项目 / 事故名称
  • 时间范围
  • 业务域
  • 责任团队
  • 涉及模型 / workflow / prompt / tool 版本

8.2 业务目标与成功标准 ​

  • 原始目标
  • 关键指标
  • 红线指标

8.3 方案与关键取舍 ​

  • 为什么选这个模型
  • 为什么这样设计检索或 workflow
  • 为什么当时接受这些限制

8.4 上线前验证 ​

  • 用了哪些 eval
  • 样本集覆盖了什么
  • 哪些场景没有覆盖

8.5 线上表现 ​

  • 实际指标
  • 异常开始时间
  • 首个异常信号

8.6 影响范围 ​

  • 影响了哪些用户、租户、角色、场景
  • 是否涉及高风险动作

8.7 根因分层 ​

  • trigger
  • system cause
  • organizational cause

8.8 止血动作 ​

  • 谁做了什么
  • 效果如何
  • 残余风险是什么

8.9 永久修复 ​

  • 新增了哪些 gate、eval、guardrail、runbook、权限或 trace

8.10 回流动作 ​

  • 加入哪个数据集
  • 加入哪个 checklist
  • 加入哪个告警
  • 加入哪个审批策略

8.11 负责人和截止时间 ​

  • owner
  • ETA
  • 验收方式

9. 案例一：知识库问答上线后引用质量下降 ​

这是非常典型、也非常容易被误判的一类问题。

9.1 问题表现 ​

  • 用户反馈“答案看起来像对，但引用不准”
  • 追问率明显上升
  • 某业务域失败样例集中爆发
  • 回答仍然返回 200，没有技术异常

9.2 常见根因 ​

  • metadata 变更导致过滤异常
  • rerank 改动后排序变差
  • prompt 鼓励“尽量回答”
  • chunk 选择偏长，关键证据被淹没

9.3 这类复盘里最该写出来的不是一句“检索有 bug” ​

更应该写的是：

  • 为什么引用质量没有独立基线
  • 为什么变更前没覆盖这个业务域
  • 为什么线上没对引用质量做分桶监控

9.4 更应该回流的动作 ​

  • 把失败样例加进回归集
  • 给引用质量独立打分
  • 把 metadata / rerank 变更拉进发布门禁

10. 案例二：Agent 工具循环导致成本和时延放大 ​

10.1 问题表现 ​

  • 某类任务平均耗时翻倍
  • token 成本异常上升
  • trace 显示重复检索和重复工具调用
  • 部分任务并没有更高成功率

10.2 常见根因 ​

  • 没有 step limit
  • retry 上限缺失
  • tool schema 过松，模型一直修参数
  • fallback 逻辑不清

10.3 复盘最该问的不是“模型为什么这么笨” ​

而是：

  • 为什么异常长链路没有告警
  • 为什么工具失败路径没有预算上限
  • 为什么这个问题直到成本报警后才被发现

10.4 更高价值的回流动作 ​

  • 新增 step / retry budget
  • 新增 trace grader 检查异常长链路
  • 把这类 case 加入 regression dataset

11. 案例三：审批链路积压，业务误以为模型变差 ​

11.1 问题表现 ​

  • 用户体感变慢
  • 审批等待时长飙升
  • 值班一开始误判成模型时延问题

11.2 常见根因 ​

  • guardrail 阈值过紧
  • route 变更把大量低风险流量打进审批
  • 审批人力没有随流量同步
  • 审批积压没有进入一级监控

11.3 这类复盘真正要写的是什么 ​

  • 为什么业务先归因给模型
  • 为什么审批指标没成为主监控面板
  • 为什么系统没有更早触发升级或降级

11.4 更值得沉淀的动作 ​

  • 审批等待时长进主看板
  • 风险分层路由加发布回归
  • 低风险动作恢复自动化路径

这类案例很能说明：

  • AI 项目里的“质量问题”有时其实是流程问题

12. 案例四：实时语音系统被认为“不自然”，其实根因不在模型 ​

12.1 问题表现 ​

  • 用户抱怨系统抢话、打断处理差
  • 工具调用时对话节奏很怪
  • 首字延迟和总时长看起来都不算太差

12.2 常见根因 ​

  • turn detection 不稳
  • interruption 只停播，不停动作
  • 会话摘要和上下文压缩策略差
  • 部分实时任务其实应该改成异步

12.3 复盘中真正需要写的 ​

  • 是否把会话状态拆层管理
  • 是否有语音事件流与 trace
  • 是否把 request-based 和 realtime 场景分开治理

12.4 更值得回流的动作 ​

  • turn / interruption 评测集
  • 事件流回放
  • 实时语音主观体验指标看板

13. 复盘怎样真正进入工程体系 ​

高价值复盘不应该只停在文档。

至少要回流到下面这些地方中的几个：

  • eval 数据集
  • trace grader
  • 发布 checklist
  • runbook
  • guardrails
  • 审批策略
  • 路由策略
  • 监控与告警

如果这些地方都没有变，复盘大概率只是在“写纪要”，不是在“改系统”。

14. 一份好的复盘，最好能把版本和证据绑定起来 ​

AI 项目里，如果复盘里没有版本上下文，很多结论很快会失效。

建议至少记录：

  • model version
  • prompt version
  • workflow version
  • tool schema version
  • retrieval config version
  • eval dataset version

这样你后面才能真正回答：

  • 这次问题到底从哪个版本开始出现
  • 修复后到底是哪次变更把它真正收住了

15. 复盘不要只写“做错了什么”，还要写“为什么之前没发现” ​

这一步特别重要，因为它决定了系统能不能变得更早发现问题。

一个更好的问法通常是：

  • 为什么现有 eval 没拦住
  • 为什么现有 trace 没暴露
  • 为什么现有门禁没挡住
  • 为什么现有告警没升级

这类问题比单纯批评某次实现更有价值，因为它会推动你补的是：

  • 系统级防线

而不是：

  • 某个人的一次手误

16. AI 复盘特别适合采用无责风格 ​

Google SRE 当前关于 blameless postmortem 的资料非常强调：

  • 复盘应聚焦于原因和改进，而不是归咎个人

这在 AI 项目里尤其重要，因为 AI 项目往往有大量不确定性：

  • 模型行为有波动
  • 供应商能力会变
  • 数据分布会漂移
  • 安全边界比普通功能复杂

如果复盘风格变成：

  • “谁写错了”

团队很容易回避暴露问题。

如果复盘风格是：

  • “当时在什么信息下做了什么判断，系统为什么允许这个风险穿过去”

团队更容易沉淀真实经验。

17. 常见反模式 ​

  • 只写“效果不错”或“后面修好了”
  • 把问题简单归因于模型不行
  • 没有具体失败样例和证据链
  • 不区分临时止血和永久修复
  • 没有负责人、截止时间和验收方式
  • 没有把复盘结果回流到工程体系
  • 没有记录当时的约束和取舍背景

18. 推荐搭配阅读 ​

19. 重点官方资源 ​

以下入口在 2026-07-08 复查时可访问：

20. 落地检查清单 ​

  • 是否明确记录了业务目标、成功标准和红线
  • 是否记录了模型、prompt、workflow、tool、retrieval 的版本上下文
  • 是否有真实失败样例、trace、指标和审计证据，而不是只有抽象总结
  • 是否把根因分成 trigger、system cause、organizational cause
  • 是否区分了临时止血与永久修复
  • 是否明确了哪些动作要回流到 eval、trace grader、runbook、checklist 或 guardrail
  • 是否写清了为什么现有门禁、监控、评测没有更早发现问题
  • 是否有 owner、截止时间和验证方式