复盘驱动的 AI 使用改进

你有没有发现，和 AI 合作总在重蹈覆辙？

你让 Claude Code 帮你写一份报告，它洋洋洒洒写了三千字，但格式全是错的——你明明上次就纠正过。你让它重构一段代码，它又把你上周刚修好的那个边界情况搞坏了。你让它分析数据，它又选了你不喜欢的图表样式。

每一次，你都在对话里纠正它。每一次纠正都有效。但下一次新对话开始，一切回到原点。

这不是 AI 的"记性差"。这是因为 Claude Code 的每次对话是独立的——它没有跨会话的记忆机制（或者更准确地说，你没有主动建立这个机制）。你的纠正、你的偏好、你踩过的坑，全部停留在上一次对话的上下文里，随着会话结束而消散。

问题不在 AI，在于你用完就走，从不复盘。

从"用完即走"到"持续改进"

大多数人使用 AI 的方式是这样的：

Copy遇到任务 → 打开 Claude Code → 对话完成 → 关闭 → 下次重来

这像什么？像一个公司每天招临时工，干完活就走，第二天再招新的。每个临时工都不知道前一个人踩过什么坑、老板有什么偏好、项目有什么特殊要求。效率永远停在同一个水平线上。

而高效的使用方式应该是这样的：

Copy遇到任务 → 打开 Claude Code → 对话完成 → 复盘这次交互 → 把经验沉淀下来 → 下次 Claude 自动遵守

区别在于最后两步：复盘和沉淀。复盘让你发现"哪里做得不好"，沉淀让这些发现变成 Claude Code 下次会自动遵守的规则。

这不是一次性的动作，而是一个循环——每次使用后复盘、沉淀，下次使用质量提升，再复盘、再沉淀……你和 Claude Code 之间的默契就是这样一轮一轮建立起来的。

复盘的第一步：发现返工点

复盘不是泛泛地回顾"这次对话怎么样"。有效的复盘聚焦于一个核心问题：这次会话中，哪些地方你纠正了 Claude？

每一次纠正都意味着一次返工——Claude 的输出没有达到你的预期，你不得不花时间指出问题、等待修正。返工是 AI 协作中最大的效率损耗，也是最有价值的改进信号。

你可以在会话结束前，直接告诉 Claude Code：

Copy回顾这次会话中所有我纠正你的地方，整理成一份返工清单，
分析每个返工的根因，并判断哪些可以通过规则避免。

Claude 会遍历对话历史，找出你每一次"不是这样的"、"格式不对"、"这里应该用 XX 方式"的纠正，整理成结构化的返工根因表。

这个方法的关键在于：不是你自己去回忆"我好像纠正过什么"，而是让 Claude 自己分析自己的失误。它能看到完整的对话历史，比你的记忆更准确。

经验沉淀：三层持久化体系

发现了返工点，分析了根因，下一步是把这些经验"写下来"，让 Claude Code 在未来的每次会话中都能看到。

Claude Code 提供了三个层级的经验沉淀机制，分别适用于不同类型的经验：

CLAUDE.md——项目级稳定指令

CLAUDE.md 是 Claude Code 每次启动时最先读取的文件。写在这里的内容具有最高的执行优先级。

适合写入的内容：

• 技术栈和架构约定（"本项目使用 TypeScript + React 19"）
• 编码规范（"所有 API 返回统一的 { success, data, error } 格式"）
• 团队协作约定（"不要修改 core/ 目录下的文件，这是另一个团队维护的"）

特征：稳定、很少变动、适用于整个项目的所有任务。就像一本员工手册——内容很少更新，但每个新员工入职都要读。

Rules——主题式行为规则

Rules 文件放在 .claude/rules/ 目录下，每个文件聚焦一个特定主题。

适合写入的内容：

• 特定文件类型的处理规范（"编辑 .mdx 文件时，保持 Frontmatter 字段顺序与模板一致"）
• 重复出现的错误模式（"不要在 Docker COPY 中依赖 pnpm 的符号链接"）
• 特定工作流的行为约束（"修 bug 时必须先定位根因再动手，不能靠猜测反复尝试"）

特征：模块化、按主题组织、可以带路径作用域。就像岗位操作手册——不是人人都要读，但碰到相关工作时必须遵守。

Memory——跨会话学习记忆

Memory 是 Claude Code 在多次会话中自动积累的学习记录，存储在 ~/.claude/projects/<项目>/memory/ 目录下。

适合写入的内容：

• 用户偏好（"用户偏好静奢设计风格而非功能优先风格"）
• 调试经验（"这个项目的 dev server 偶尔会 CPU 飙升，需要重启"）
• 项目阶段状态（"当前处于 Phase 6B，支付功能已完成"）

特征：持续演进、Claude 自己可以读写、个人化。就像一本工作日志——随时更新，记录的是在实践中积累的经验和发现。

三层体系的选择原则

一句话概括：越稳定的写越上层，越个人的写越下层。

一个完整的改进闭环

来看一个具体场景，感受"复盘→沉淀→改进"的完整循环。

复盘前：每次都在重复纠正

小王用 Claude Code 协助完成数据分析报告。每次生成报告时，Claude 都会犯几个同样的错误：

1. 统计图表用了彩虹配色，但小王的团队要求使用蓝灰色系
2. 表格中的数字没有千分位分隔符
3. 结论部分总是写得过于"学术化"，小王需要的是简洁的商业语言

每次会话，小王都要花 10-15 分钟纠正这些问题。一周做三份报告，就是半小时的纯返工时间。更让人沮丧的是，每次纠正后 Claude 当场就改好了，但下一次新会话又从头再来。

复盘：发现返工模式

小王在一次会话结束前，让 Claude 回顾返工点。Claude 整理出了返工清单：

三个问题，根因都指向同一个方向：Claude 缺乏关于小王工作环境的背景知识。

沉淀：把经验写成规则

根据根因分析，小王在 .claude/rules/ 目录下创建了一个 report-style.md 文件：

Copy# 数据报告样式规范
 
## 图表
- 配色方案：蓝灰色系（主色 #2563EB，辅色 #6B7280，强调色 #1E40AF）
- 不使用彩虹色或高饱和度配色
 
## 数字格式
- 所有超过四位的数字使用千分位分隔符（如 12,345）
- 百分比保留一位小数（如 23.5%）
 
## 语气
- 结论部分使用简洁的商业语言，避免学术化表述
- 每个结论不超过两句话
- 先说结论，再说依据

复盘后：问题自动消失

从这之后，小王每次启动 Claude Code 处理数据报告，Claude 都会自动读取这份规则文件。图表配色、数字格式、结论语气——三个困扰了他数周的问题，一次性解决，再也没有出现过。

而且这个规则文件是 Git 跟踪的。小王的同事 clone 了项目仓库后，也自动获得了这些规范。整个团队的 Claude Code 都在按相同标准输出报告。

复盘的更高价值：从修补到预防

上面的例子是最直接的应用——发现重复犯的错，写成规则。但复盘的价值远不止于此。

发现工作流的结构性问题。有时候返工不是因为 Claude "不知道规则"，而是因为你给它的任务拆解方式有问题。比如你发现每次让 Claude 一次性完成"数据清洗 + 分析 + 可视化 + 报告"四步时，后面的步骤质量总是很差——这说明任务太大，需要拆分为四个独立步骤。这种洞察比修一个配色规则更有价值。

积累 Prompt 模式库。复盘多了，你会发现某些 Prompt 的写法效果特别好。比如"先列出你的理解，确认后再动手"这种模式，几乎在所有复杂任务中都能显著减少返工。把这些好用的 Prompt 模式积累下来，就是你自己的"AI 协作方法论"。

建立质量反馈闭环。复盘 → 沉淀 → 验证 → 再复盘，这个循环运转几次之后，你会发现自己和 Claude Code 的协作效率呈阶梯式上升。不是因为 AI 变聪明了，而是因为你把自己的经验系统地注入了它的工作环境。

开始你的第一次复盘

不需要等到一个"完美的时机"才开始复盘。今天你和 Claude Code 的下一次对话结束时，试试在关闭前说一句：

Copy回顾这次会话，列出所有我纠正你或你做得不好的地方，分析根因。

看看 Claude 给出的返工清单，挑出其中重复出现的问题，写一条 Rules 文件。就这么简单。

一条规则解决一个问题。十条规则之后，你的 Claude Code 就已经和别人的完全不同了——它知道你的偏好、你的标准、你项目的特殊约束。这就是"越用越好"的真正含义。

进阶阅读

这篇文章只覆盖了复盘改进的基本理念和最简单的实践方式。如果你想要深入学习完整的复盘方法论，包括：

• /insights 内置命令——分析最近 30 天的使用数据，自动生成 CLAUDE.md 改进建议
• /session-review 复盘命令的配置和定制
• 返工根因分析的系统化方法
• 三层持久化体系的进阶用法和选择决策
• 从"被动修补"到"主动预防"的心智转变

请参考 复盘沉淀——我们在实战课程中提供了完整的操作指南。