用途
retro 用于把一个已完成、失败、令人失望或结果模糊的工作周期，转化为下一轮真正可用的经验。它的核心判断是：一个周期可以正常运行、通过测试，却仍然是错误的方向。因此 retro 的输出不是变更日志，也不是情绪化的复盘笔记，而是一份本地化、有证据支撑的记录，说明什么有效、什么误导了构建过程、下一轮必须通过什么门禁。
当产物已经完成、失败、令人失望，或者模糊到下一个智能体更需要这一轮的经验而非其惯性时，就适合使用 retro。
主要能力
- 从工作周期中提取可长期保留的经验，而不为产生该产物的过程辩护。
- 区分可复用资产与误导性进展：契约、模式、测试、服务、词汇和示例中哪些值得复用，对比 UI、面板、脚手架或抽象中哪些只是看起来有产出。
- 把每个失败命名为具体的反模式，而不是描述成一种情绪或氛围。
- 把重复出现或高影响的失败转化为下一轮的质量门禁。
- 把模糊的用户方向转化为新智能体可使用的架构词汇。
- 为当前周期编写或刷新本地文档：一份 retro 记录经验教训，一份 plan 记录下一轮的契约、门禁和词汇。
- 验证一个从零开始的智能体仅凭这些文档就能避开同样的失败。
使用方式
工作流程如下：
- 阅读原始目标、最终产物、QA 证据、用户投诉以及任何本地规划笔记。
- 区分可复用资产与误导性进展。
- 把每个失败命名为反模式，而不是情绪。
- 把重复或高影响的失败转化为下一轮的质量门禁。
- 把模糊的用户方向转化为架构词汇，供新的智能体使用。
- 编写或刷新本地文档：retro 记录经验，plan 记录下一轮的契约、门禁和词汇。
- 验证一个从零开始的智能体仅凭这些文档就能避开同样的失败。
规则
- 不要为产物辩护。如果它偏离了产品目标，就说明哪里偏离了。
- 不要写变更日志。文件列表和工作量总结不是经验教训。
- 保留负面语料。失败的路径也是训练数据。
- 优先使用硬性门禁，而不是建议。
- 引用周期中的证据：目标、文件事实、QA 输出、截图、记录、差异或用户反馈。
- 如果下一个智能体无法据此行动，那它就还不是一条经验。
- 保持来源本地化；已交付的产物不应叙述自己的伤痕。
验证
完成前需确认：
- 每条经验都能追溯到观察到的周期证据。
- 每个反模式都命名了具体的失败模式以及能捕获它的门禁。
- 新的智能体无需阅读整个旧会话，就能判断该保留什么、丢弃什么、先测试什么。
适用场景
适用于构建、QA 等周期结束后的复盘，尤其是产物已完成、失败、令人失望或结果模糊的情况。目标是让下一轮工作能直接继承经验，而不是重复同样的错误。
限制
资料未提供关于收费、价格、平台支持、具体安装命令或集成方式的说明，这些信息暂未提供。