复盘模板

复盘写四件事：做了什么、为什么这么做、遇到了什么、下次怎么做；再加一节 Harness 反馈：这次的问题，该改 agent 工作环境里的哪个地方（CLAUDE.md、hook、权限、检查脚本、文档指针），才不会再犯。事故之后、项目结束、工具试用期满都写一篇。单仓产品放 docs/retros/，组织放 ops 仓的 retros/，命名 YYYY-MM-DD_<event>.md。

为什么要单列 Harness 反馈复制本节链接

我一年写了 70 多篇复盘，教训写得很勤，但大部分停在“下次注意”，很少回流到 agent 每次开工都会读到、或者会被机械执行的地方。同一个坑踩第二次，才发现上次的教训只活在一份没人再打开的文档里。

这对应双环学习（Chris Argyris 和 Donald Schön）：单环是修好这一次的错，双环是改掉产生这个错的规则本身。对用 agent 干活的人来说，“规则本身”就是 harness：agent 读到的说明、它能用的工具、拦住它的检查。

模板复制本节链接

# 复盘：<事件>

- 日期：YYYY-MM-DD
- 类型：事故 / 项目 / 试用期评估
- 影响：（谁、多大范围、持续多久）
- 相关：（PR、spec、告警的链接）

## 做了什么
（按时间顺序，事实，不带评价）

## 为什么这么做
（当时的判断和依据，包括当时不知道的信息）

## 遇到了什么
- 时间线：
- 根因：（一直问"为什么"，问到环境和规则层面）

## 下次怎么做
| 行动 | 负责人 | 截止 | 状态 |
|---|---|---|---|

## Harness 反馈
| 类别 | 这次的问题 | 改哪里 | 状态 |
|---|---|---|---|
| 导航 | | | |
| 自动检查 | | | |
| 规则与审查 | | | |
| 权限与护栏 | | | |
| 工具与开销 | | | |
| 信息获取 | | | |

## 数据（试用期评估时填）
| 日期 | 任务 | 引擎 | 返工轮数 | 审查发现（高/中/低） | PR 合并周期 | 跳过流程 | 备注 |
|---|---|---|---|---|---|---|---|

示例：Harness 反馈复制本节链接

假设“待办标签”上线后，待办超过 1000 条的用户筛选明显变慢：

## Harness 反馈
| 类别 | 这次的问题 | 改哪里 | 状态 |
|---|---|---|---|
| 导航 | agent 花了很久才找到筛选逻辑在哪个文件 | CLAUDE.md 的"文档在哪"加一行指针 | 已完成 |
| 自动检查 | 没有任何测试覆盖 1000 条以上的列表 | CI 加一个大数据量的筛选测试 | 进行中 |
| 规则与审查 | 审查没问"数据量大了会怎样" | REVIEW.md 的"每次都要检查"加一条 | 已完成 |
| 信息获取 | agent 看不到线上慢查询日志，只能猜 | 给一个只读的日志查询入口 | 待定 |

Harness 反馈怎么写复制本节链接

🧪试用中 这一节的写法我还在试，分类参考了 /mattpocock-skills:retro 检查 agent 工作环境时用的维度：

三条原则：

• 能机械执行的，就不要只写成文字。 规则写进 CLAUDE.md 只是提醒；做成 hook、CI、权限规则才是拦截
• 同一个坑出现两次，就起草一个 hook。 第一次可以是意外，第二次说明 harness 有缺口
• 每一行都要落到一个具体文件或配置。 “改哪里”那一栏写不出文件名，说明这条还没想清楚

/mattpocock-skills:retro 会读你指定会话的记录，按严重程度列出这几类改进建议，可以用它起草这一节。注意 gstack 也有一个 /retro，那是按周统计的工程复盘，是另一回事。

每一节怎么填复制本节链接

要公开分享的复盘，先删掉客户、同事、服务器、账号这些信息，只留通用的教训。

相关复制本节链接