retrospective

name	retrospective
description	任务完成后的反思与经验沉淀。审视本次执行过程，将教训更新到对应 skill 中，驱动所有 skill 持续进化。

任务反思与经验沉淀

触发条件：任何非平凡任务完成后（尤其是经历了 debug 的任务），主动执行此 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 行。