To be confirmed 01
To be confirmed
大多数复盘失败不是因为没有做，而是因为做完了什么都没变。这篇笔记的目的是定下一个标准：复盘问什么、怎么做、怎么让它真正积累到下一次。
为什么大多数复盘没用
三个常见失败原因：
1. 只说"做得好"和"做得不好"，没有追问原因
"测试没做到位"是现象，不是原因。原因是"每步完成时没有强制要求汇报测试结果"。只找现象，下次还会重蹈。
2. 洞察停留在脑子里，没有落进系统
复盘出来的东西，如果只是"我以后要注意"，基本等于没用。人脑不可靠，系统才可靠。洞察必须变成文档、规则、或者流程的改动。
3. 没有后续检验机制
这次复盘出来的改进，下次有没有真的做到？没有人检验，改进就是一句空话。
复盘的两个层次
层次一：这件事本身（项目复盘）
这次做了什么、哪里出问题、下次怎么改。
层次二：我们怎么合作（协作复盘）
AI 和我之间的配合哪里顺、哪里卡、规则是否需要更新。
两个层次都要做，缺一个都是不完整的。
标准复盘问题清单
项目层面
关于结果
我们设定的目标是什么？最终做到了吗？
哪些做到了预期，哪些没有？
关于过程
哪个环节卡住了？为什么？（追问到根本原因，不停在现象）
有没有哪步做了很多次才对？原因是什么？
有没有本可以更简单的做法，但我们绕了弯路？
关于决策
哪个决策现在看来是对的？为什么？
哪个决策现在看来是错的？当时为什么做了这个决定？
协作层面
关于启动
开始前，需求有没有说清楚？AI 有没有真正理解我要什么？
计划有没有写出来？计划够不够细？
关于执行
AI 有没有每步都汇报测试结果？还是只说"完成了"？
有没有遇到 AI 给出方案但我无法判断对不对的情况？
有没有遇到来回修改同一个问题超过两次的情况？（超过两次说明根因没找到）
关于规则
SOP 里有没有哪条规则这次没遵守？为什么？
有没有遇到 SOP 没有覆盖到的情况？需要新增规则吗？
有没有哪条规则这次证明是有效的，应该强化？
复盘产出必须是这三样之一
复盘结束，洞察必须落地成：
1. 更新 SOP
如果发现了一个可以避免的问题，就把对应的规则加进 SOP。这是最重要的产出。
2. 更新 CLAUDE.md
如果是这个项目特有的改进，更新项目的 CLAUDE.md，下次 Session 自动生效。
3. 写进复盘笔记
如果是一个更大的认知或模式，写进笔记，加入知识网络。
没有这三样产出之一的复盘，等于没有复盘。
怎么让复盘真正积累
短期：每次 Session 结束做小复盘
不需要很长，三个问题就够：
这次哪里做得好，值得保留？
哪里卡住了，下次怎么避免？
有没有需要更新 SOP 或 CLAUDE.md 的地方？
写进 Session 交接里，存入 Build Log。
中期：每个项目结束做完整复盘
用上面的完整问题清单过一遍，重点看：
这个项目里反复出现的问题是什么？
有没有值得写进通用 SOP 的新规则？
长期：定期回顾 SOP
每隔一两个月，重新读一遍 SOP：
哪些规则真的在用？
哪些规则从来没执行过？（说明要么不实用，要么需要强化执行机制）
有没有新的经验需要加进来？
复盘的核心原则
原则一：追问原因，不停在现象
每个问题问完，再问一次"为什么"。直到找到可以改变的根因为止。
原则二：洞察必须进系统，不能只在脑子里
想到了但没写下来，等于没想到。
原则三：改进必须具体，不能是"以后要注意"
"以后要注意测试"没用。"每步完成时，我会说：给我看测试命令和输出结果"——这才有用。
原则四：不要在状态差的时候做复盘
复盘需要清醒的头脑和相对客观的视角。情绪低落时看什么都是问题，那时候的复盘结论不可靠。
原则五：复盘的目的不是自我批评，是提取模式
不是"我哪里做错了"，而是"这件事有没有可以学到的规律"。前者消耗能量，后者积累能量。
这次复盘的样本
今天我们复盘了 Navi Site 项目的协作过程，产出了：
发现的问题：
进度不可见（没有实时清单）
测试执行不彻底（没强制要求汇报结果）
Session 断档（交接不够细）
来回修改太多（没有先追问原因）
落地的产出：
更新了 SOP（加了 11 条规则，含 Bug 修复顺序、对齐设计概念等）
建了 CLAUDE.md（规则自动在每次 Session 生效）
写了工作流笔记（方法论本身可以复用）
还不完美的地方：
- 复盘本身也经历了多次来回，说明"怎么复盘"本身还需要标准——这篇笔记就是为了解决这个问题。
从复盘到 SOP：什么值得写进去
复盘结束后，不是所有经验都该进 SOP。进 SOP 的标准是三条，缺一不可：
1. 重复性 — 这个问题会不会在下个项目里再出现？
只出现一次的特殊情况不值得进 SOP，写进项目笔记就好。
2. 可预防性 — 这个问题能不能靠一条规则提前避免？
如果是外部原因（比如 API 突然挂了）无法预防，就不用写。
3. 可验证性 — 这条规则有没有执行，能不能检验？
"以后要注意沟通"无法验证，不算规则。"每步完成后说出测试命令和结果"可以验证，是规则。
三条都满足 → 进 SOP。只满足部分 → 写进复盘笔记留存。
写进 SOP 的格式要求：
说清楚做什么，不说"要注意 X"
说清楚什么时候做，触发条件要明确
说清楚怎么验证，执行了没有能被检查
让系统自我延续：三个必须有的环节
SOP 写好了不代表它会被用。系统要能自我延续，需要三个环节都在：
入口：新项目怎么启动系统
每次开新项目，有没有一个固定的触发动作？
通用标准：
读 SOP，确认这个项目适用哪些规则
建项目专属的 CLAUDE.md，把适用规则和项目信息写进去
建 Obsidian 项目笔记，创建阶段清单和专属 DoD
没有固定入口，系统就是摆设——每次都要重新想"我应该做什么"。
容器：规则和进度存在哪里
运行中，AI 怎么随时知道规则是什么？
通用标准：
CLAUDE.md 放在项目根目录，Claude Code 自动读取
Obsidian Build Log 记录每次 Session 进度和交接
两个地方分工明确：CLAUDE.md 存规则，Build Log 存进度
出口：项目结束怎么写回系统
结束时，有没有一个固定动作把新经验写回去？
通用标准：
做完整复盘，用本笔记的问题清单过一遍
符合三条标准的经验 → 更新通用 SOP
项目特有的经验 → 写进项目复盘笔记
Session 结束 → 写交接，存 Build Log
三个环节缺任何一个，系统就会断。
新项目开始
↓
入口：读 SOP → 建 CLAUDE.md → 建项目笔记
↓
容器：CLAUDE.md（规则）+ Build Log（进度）
↓
出口：复盘 → 更新 SOP → 写交接
↓
下个项目站在更高起点上开始
相关笔记
- [[一个值得复用的 AI 学习工作流（2026-05-02）]] — 复盘在整个工作流里的位置和作用
记录于 2026-05-02
复盘不是终点，是让每次经历变成资产的机制。