上线和复盘是最容易暴露团队是否真的把 AI 用进工作流的场景。因为这里不是“会不会问模型”的问题，而是“有没有一套标准化输入，让 AI 帮你更快整理事实、生成检查单、压缩时间线，并把改进动作回灌到流程里”。这一课的重点，就是把 AI 放在证据组织和模板沉淀的位置，而不是让它替你决定是否上线。
真实研发场景
发布前最常见的问题不是“完全没检查”，而是“检查靠人脑”
一个版本要上线时，团队往往知道自己应该做很多事：确认改动范围、看测试结果、确认关键依赖、关注监控、回顾已知风险。但如果这些动作没有统一清单，就会退化成口头提醒和个人记忆。有人会看日志，有人会看测试，有人会看环境，但没人能确定有没有漏项。
故障复盘也一样。事故发生后，聊天记录、日志、监控、手工操作、补救步骤都很丰富，可一旦没有结构化组织，这些材料就很难变成可复用的结论。
本课真正要建立的是“检查单、事实表、时间线”三类资产
AI 很适合在发布和复盘阶段帮助你整理这三类资产：
- 发布检查单：这次上线前到底要确认什么
- 事实表：监控、日志、变更、测试结果分别说明什么
- 事故时间线：问题是如何被发现、确认、修复和验证的
这些都是“高信息密度但整理成本高”的工作，正是 AI 发挥价值的地方。
传统做法的痛点
发布与复盘经常被三种低质量动作拖慢
| 低质量动作 | 表面现象 | 长期后果 |
|---|---|---|
| 检查靠记忆 | 每次都有人提醒几句 | 漏项不可见，经验不可复制 |
| 摘要靠人肉 | 告警很多但没人愿意先整理 | 团队决策延迟 |
| 复盘写空话 | “加强沟通”“避免类似问题” | 没有流程回灌价值 |
发布和复盘的难点，不在于没有信息，而在于信息没有变成可操作结构。
AI 参与这一环节最常见的三个问题
- 让 AI 直接判断“能不能上线”
- 不区分事实、推测和结论，导致复盘被合理化叙事污染
- 复盘写完就结束，没有回灌到清单、规范或自动化资产
AI 能提效到哪一步
AI 最适合承担的动作
- 生成发布检查单草稿
- 汇总监控指标、日志异常和测试结果
- 整理故障时间线和处置步骤
- 起草复盘结构和改进项分类
不能交给 AI 拍板的动作
| 动作 | 为什么必须人工承担 |
|---|---|
| 是否允许上线 | 需要承担业务和事故责任 |
| 哪个原因是最终根因 | 必须基于证据验证 |
| 哪些改进项优先做 | 涉及资源与风险取舍 |
一个重要规则是：AI 可以帮助你更快组织证据，但最终结论必须由团队基于证据承担。
推荐工作流
发布前先准备一份“上线事实包”
推荐至少包含：
- 这次改动范围
- 关键测试或 eval 结果
- 已知风险和注意事项
- 相关日志、指标或健康检查入口
- 如需回滚或排查时首先看哪里
五步发布与复盘闭环
| 步骤 | AI 产出 | 人工要做什么 | 验证方式 |
|---|---|---|---|
| 1. 收变更事实 | 发布事实摘要 | 补关键遗漏 | 是否能说清本次上线改了什么 |
| 2. 起检查单 | 上线前检查草稿 | 删除无关项、补高风险项 | 是否能逐项执行 |
| 3. 整理异常 | 指标、日志、告警摘要 | 标注哪些是事实、哪些仍待验证 | 是否减少排查分歧 |
| 4. 组织时间线 | 事故时间线或发布记录 | 校正事件顺序和责任边界 | 是否可被复述和审计 |
| 5. 回灌改进 | 改进项、清单更新点 | 写进流程或模板 | 下次是否更稳 |
一个适合复盘阶段的输入模板
变更范围：
测试 / eval 结果：
监控与日志事实：
关键时间点：
已采取动作：
请输出：
1. 发布检查单或复盘结构
2. 事实 / 推测 / 结论分层
3. 可执行改进项
与仓库代码和模板的映射
- 最小回归资产：
../demo/evals适合说明上线前不只看单元测试，也要看关键能力是否仍然成立。 - 请求日志：
../demo/src/main/java/com/example/ainative/ops/logging/RequestLogFilter.java适合观察发布后排查最基础的证据该长什么样。 - 指标聚合：
../demo/src/main/java/com/example/ainative/ops/metrics/AiMetricsFacade.java适合说明没有指标快照就很难做监控摘要。 - 环境脚本：
../demo/scripts/start-infra.sh、../demo/scripts/load-sample-data.sh适合纳入发布和故障复现前的环境准备检查。 - 基础设施定义：
../demo/docker-compose.yml适合帮助团队快速回看依赖服务组成。 - 对应练习：
../课后练习/第10课/练习.md
常见误用与风险
误用一：让 AI 替团队宣布“可以上线”
上线是带责任的工程决策，不是摘要任务。
误用二：复盘不区分事实、推测和结论
这样最容易把一次偶然现象写成确定原因。
误用三：改进项写成空话
“加强沟通”不是可执行动作，清单更新、监控补齐、测试补齐才是。
误用四：复盘结果不回灌流程
如果清单、模板和自动化资产都没变化，下次还会重复踩坑。
课后练习
建议直接在 ../课后练习/第10课/练习.md 中完成本课练习，并使用 ../课后练习/通用提交模板.md 保留 AI 输入、人工删改和验证结果。
如果你只做最小版交付，也至少保留四样东西：结构化输入、AI 产出摘要、人工判断记录、最终验证结果。
基础题
针对一次模拟上线，写一份最小发布事实包和上线前检查单。
进阶题
给一组日志、指标或模拟故障信息，让 AI 先做事实摘要，再人工补上待验证项。
挑战题
输出一份带时间线的复盘草稿，并明确哪些改进项要回灌到测试、检查单或团队规范里。