| name | retrospective |
| description | 任务完成后的反思与经验沉淀。仅在任务非平凡且出现调试、失败修复、反复试错、明显误判或可复用教训时使用;简单执行、查询、常规 CI 通过等无新增经验的任务可跳过。 |
任务反思与经验沉淀
触发条件:非平凡任务完成后,且存在可沉淀经验:debug、失败修复、反复试错、明显误判、流程缺口,或用户显式要求。
跳过条件:简单执行、查询、格式调整、常规 CI 通过等没有新增教训的任务,无需执行此 skill。
服务对象:所有 skill。本 skill 的产出是对其他 skill 文件的更新,不产生代码。
核心原则
🚨 对结果要有定力,不要自我欺骗
最大的风险是"觉得差不多了"的幻觉——结果不达标时,找外部原因搪塞然后降低要求宣布完成。
常见的自我欺骗模式:
- 功能任务:输出不正确时归因于"量化精度不够"、"模型太小"、"这是预期的退化",而不是继续排查实现 bug
- 性能任务:优化没有效果时归因于"编译器已经优化得很好了"、"已经接近理论极限",而不是继续尝试其他方案
正确做法:
- 测试目标在开始前就定好,不能中途降低标准
- 通过标准必须具体、可验证("差不多能用"不算通过)
- 功能任务:人工验证不通过就是没通过,继续排查实现细节
- 性能任务:没有达到预期提升就继续优化,用数据证明已到极限而不是猜测
TDD 思维:先定测试再写代码
每个子任务开始前明确三件事:
- 通过标准是什么? — 具体的预期输出
- 怎么测? — 可执行的测试命令
- 什么不算通过? — 明确列出容易自我欺骗的边界情况
执行流程
1. 识别教训
- 走了哪些弯路?错误假设是什么?
- 根因是什么?为什么没有第一时间找到?
- 方法论问题?跳步了?过早下结论了?把 bug 归因为外部原因了?
2. 判断归属
| 教训类型 | 更新位置 |
|---|
| 某个 skill 流程中的陷阱 | 该 skill 的 common-pitfalls 或步骤文件 |
| 通用工作方法论 | 该 skill 的 SKILL.md 顶层注意事项 |
| 跨 skill 通用经验 | memory 系统 |
3. 写入原则
- 只写方法论,不写单次任务的具体细节。 可以附最小测试示例说明如何验证。
- 放在最显眼的位置。 关键教训放 SKILL.md 顶部,不要埋在子文档末尾。
- 增加的同时审视现有内容。 显而易见的、能从代码直接推出的指导删掉或精简。单个步骤文件不超过 500 行。