项目做完，质量怎么持续提升
上一节做完了一个端到端项目。这一节讲复盘与质量提升——做完不是终点，复盘才能让下一个项目更好、质量更高。
复盘的目的是：把这次的经验，变成下次的资产。
file-lib 的 v2.0「文件监听」功能做完了，但这趟「总攻」里一定有不少卡壳和返工的地方。这一节我们给这次端到端开发做一次正式复盘：找出哪步最慢、哪步返工最多、质量上有什么遗憾，然后把改进沉淀成「审查清单 / 提示词模板 / 拆解模板」这些可复用的资产，让 file-lib 的 v3.0、v4.0 一次比一次顺。复盘三问
做完项目，问自己三个问题：
- 哪一步最慢/最纠结？ —— 下次怎么避免
- 哪一步返工最多？ —— 是不是任务没拆好 / 提示词不清
- 质量上有什么遗憾？ —— 有哪些「应该更早发现」的问题
诚实回答，别只报喜。对 file-lib 的 v2.0，回想一下这趟开发：
- 是「拆解任务」阶段花了太多时间，还是「CLI 接入」联调最纠结？
- 是「监听引擎」返工了好几次，还是「测试」写得不顺？
- 有没有「目录不存在时崩溃」这种，本该在审查阶段就抓住、却拖到联调才发现的问题？
把这三问想清楚，复盘的原料就有了。
从复盘到改进
复盘不是记流水账，要落到改进动作：
| 复盘发现 | 改进动作 |
|---|---|
| 拆解不够细导致返工 | 下次先画拆解清单再动手 |
| 提示词没给验收标准 | 每个子任务都写验收 |
| 跨文件范围失控 | 动手前划清文件边界 |
| 审查漏了边界问题 | 加「边界/调用链」审查角度 |
每个问题，配一个「下次怎么做」的动作。 对应 file-lib v2.0 的实际复盘，可能是这样：
| 复盘发现 | 改进动作 |
|---|---|
| CLI 联调最慢（事件回调对不上） | 下次在拆解阶段就把「回调签名」定死写进 API 定义 |
| watch 监听引擎返工最多 | 提示词四要素没给全，下次每个子任务都带验收标准 |
| 「目录不存在」边界拖到联调才发现 | 审查清单补一条「非法输入」检查项 |
提交时差点用 git add . |
固定「逐个加文件」的习惯，写进 CLAUDE.md |
把改进沉淀成「资产」
好的复盘，产出的是可复用的东西：
- 提示词模板：把「高质量提示词四要素」固化成模板
- 审查清单：把常漏的审查角度写成清单，下次照着查
- 拆解模板：把拆解思路固化成模板，复杂任务直接套
沉淀成模板/清单，比「记住经验」可靠得多。 对 file-lib，把这次复盘的教训写进 CLAUDE.md：
## file-lib 开发复盘沉淀（v2.0 更新）
### 审查清单（每次提交前过一遍）
- [ ] 非法输入（空、null、不存在的目录/文件）
- [ ] 回调签名与 API 定义是否一致
- [ ] 大量数据下会不会漏事件 / 内存增长
### 提示词要求
- 每个子任务必须带验收标准
- 回调签名等接口约定要先写进 API 定义再动手
写进 CLAUDE.md，下次 Codex 开工就自动带着这套「沉淀」，file-lib 越做越稳。
质量提升的持续循环
项目做完 → 复盘 → 找问题 → 定改进 → 沉淀成资产
→ 下个项目用上资产 → 再复盘 → …
每做一个项目，质量工具就升级一次。 这是质量提升的常态。file-lib 的每个版本都走这个循环：v1.0 沉淀出「拆解模板」，v2.0 沉淀出「watch 审查清单」，到 v3.0、v4.0，你的工具库（审查清单、提示词模板、拆解模板）会越来越厚，Codex 的产出质量也会跟着水涨船高。
一个复盘模板
# 复盘：file-lib v2.0 文件监听
## 做得好
- 拆解清晰，监听引擎一次做对
## 做得痛
- CLI 联调时回调签名对不上，返工
→ 下次：API 定义阶段就把回调签名写死
## 质量遗憾
- 「目录不存在」边界审查时才被发现
→ 沉淀：审查清单加「非法输入」
## 沉淀
- 更新了 CLAUDE.md 审查清单，加了边界角度
- 新增「提示词必带验收标准」约定
把每次复盘都填进这个模板，累积起来就是你的「项目经验库」。
CLAUDE.md（比如更新审查清单、加「提示词必带验收」约定）。②怎么判断做对了：每个复盘发现都有对应的改进动作（不是只记流水账）、至少沉淀出 1 条能被下次 Codex 自动读到的规则、CLAUDE.md 里能看到这次的更新。③卡住了怎么办：如果不知道哪步返工多，翻 git log 看看哪些提交反复修改过同一个文件；如果改进动作定不出来，把复盘三问丢给 Codex 让它建议「下次怎么做」，再人工筛选。常见坑：复盘变成「报喜会」，掩盖真问题
复盘的死穴是只记「做得好」，跳过「做得痛」。人会本能地给自己的失败找借口：「那一步卡住是因为需求没说清，不怪我」「返工是因为 Codex 不行」。结果复盘成了自我安慰，真正的改进机会全被掩盖，下个项目照样踩同样的坑。
避坑办法：复盘时先只写「做得痛」，写满意的事放后面。而且给每条「痛」都配一个归因到自己的改进动作，而不是甩锅：
做得痛：CLI 联调卡了 2 小时
归因（而不是甩锅）：
- 我拆解时没把「回调签名」写死 → 改进：拆解阶段就定死接口约定
- 不是「Codex 不行」，是我没把约定写进提示词
把「痛」归因到自己可改的动作上，复盘才有价值。 甩锅给外部，复盘就只是个情绪发泄，质量不会进步。诚实面对「痛」，是质量提升真正的起点。
小结
- 复盘三问：哪步最慢？哪步返工？质量遗憾？
- 每个问题配一个改进动作
- 把改进沉淀成模板/清单，比记经验可靠
- 持续循环：复盘 → 沉淀 → 下个项目用上
到这里，Codex 进阶课结束。下一门课进入生产级工程：自定义 Agent、CLI 自动化、CI/CD、规模化。