Retrospective (Alibaba)

---
name: retrospective
description: 任务完成后的反思与经验沉淀。仅在任务非平凡且出现调试、失败修复、反复试错、明显误判或可复用教训时使用；简单执行、查询、常规 CI 通过等无新增经验的任务可跳过。
metadata:
  origin: Alibaba
---

# 任务反思与经验沉淀

> **触发条件**：非平凡任务完成后，且存在可沉淀经验：debug、失败修复、反复试错、明显误判、流程缺口，或用户显式要求。
>
> **跳过条件**：简单执行、查询、格式调整、常规 CI 通过等没有新增教训的任务，无需执行此 skill。
>
> **服务对象**：所有 skill。本 skill 的产出是对其他 skill 文件的更新，不产生代码。

## 核心原则

### 🚨 对结果要有定力，不要自我欺骗

最大的风险是"觉得差不多了"的幻觉——结果不达标时，找外部原因搪塞然后降低要求宣布完成。

**常见的自我欺骗模式：**
- **功能任务**：输出不正确时归因于"量化精度不够"、"模型太小"、"这是预期的退化"，而不是继续排查实现 bug
- **性能任务**：优化没有效果时归因于"编译器已经优化得很好了"、"已经接近理论极限"，而不是继续尝试其他方案

**正确做法：**
- 测试目标在开始前就定好，不能中途降低标准
- 通过标准必须具体、可验证（"差不多能用"不算通过）
- 功能任务：人工验证不通过就是没通过，继续排查实现细节
- 性能任务：没有达到预期提升就继续优化，用数据证明已到极限而不是猜测

### TDD 思维：先定测试再写代码

每个子任务开始前明确三件事：
1. **通过标准是什么？** — 具体的预期输出
2. **怎么测？** — 可执行的测试命令
3. **什么不算通过？** — 明确列出容易自我欺骗的边界情况

## 执行流程

### 1. 识别教训

- 走了哪些弯路？错误假设是什么？
- 根因是什么？为什么没有第一时间找到？
- 方法论问题？跳步了？过早下结论了？把 bug 归因为外部原因了？

### 2. 判断归属

| 教训类型 | 更新位置 |
|---------|---------|
| 某个 skill 流程中的陷阱 | 该 skill 的 `common-pitfalls` 或步骤文件 |
| 通用工作方法论 | 该 skill 的 SKILL.md 顶层注意事项 |
| 跨 skill 通用经验 | memory 系统 |

### 3. 写入原则

- **只写方法论，不写单次任务的具体细节。** 可以附最小测试示例说明如何验证。
- **放在最显眼的位置。** 关键教训放 SKILL.md 顶部，不要埋在子文档末尾。
- **增加的同时审视现有内容。** 显而易见的、能从代码直接推出的指导删掉或精简。单个步骤文件不超过 500 行。