retro

把已完成的周期转化为下一周期真正能用上的经验。

目标

retro 从工作周期中提炼可长期复用的经验，而不为产出该成果的过程辩护。一个周期可能顺利推进、测试通过，但最终做出来的仍可能不是正确的东西。输出不是变更日志，也不是情绪记录，而是本地的、有证据支撑的记录，说明哪些做法有效、哪些进展误导了构建，以及下一轮必须通过什么关卡。

当成果已经完成、失败、令人失望，或情况模棱两可，以至于下一位 Agent 比起延续当前势头更需要了解本周期的经验时，请使用 retro。

工作流

1. 阅读最初的目标、最终成果、QA 证据、用户投诉，以及任何本地规划笔记。
2. 区分有效资产与误导性进展：找出值得复用的契约、架构、测试、服务、术语和示例，以及那些看起来很有成效、实则无益的 UI、面板、脚手架或抽象。
3. 将每项失败归纳为反模式，而不是情绪。
4. 将反复出现或影响重大的失败转化为下一轮的质量关卡。
5. 将模糊的用户指引转化为架构术语，供新 Agent 使用。
6. 为本周期编写或更新本地文档：记录经验的回顾，以及规划下一周期契约、关卡和术语的计划。
7. 验证仅凭这些文档，从零开始的 Agent 就能避免重蹈覆辙。

规则

• 不要为成果辩护。如果它没有满足产品要求，就明确指出哪里不符。
• 不要写变更日志。文件清单和工作量总结不是经验教训。
• 保留负面案例集。失败路径也是训练数据。
• 优先设置硬性关卡，而不是给出建议。
• 引用本周期的证据：目标、文件事实、QA 输出、截图、转录记录、差异或用户反馈。
• 如果下一位 Agent 无法据此采取行动，它就还算不上经验教训。
• 将溯源信息保留在本地；已交付的成果不应讲述自己的伤痕。

验证

完成前：

1. 每条经验都能追溯到本周期观察到的证据。
2. 每个反模式都指出具体的失败模式，以及能够捕获该问题的关卡。
3. 新 Agent 无需通读整个旧会话，就能判断哪些内容该保留、哪些该舍弃，以及应该先测试什么。