retro

复盘

回顾刚刚完成的工作。

这项技能用于了解：

• 出了什么问题
• 哪些事情耗时过长
• 哪些 token 或精力被浪费
• 出现了哪些死胡同
• 哪些做法确实奏效
• 下次应该做出哪些改变

目标不只是列出错误。

目标是找到根本原因，并提出能提升未来表现的改进措施。

适用场景

用户提出以下要求时，启用这项技能：

• 做一次复盘
• 回顾出了什么问题
• 找出任务耗时过长的原因
• 发现低效之处或精力浪费
• 了解反复出现的失败模式
• 改进下次的工作流

回顾输入

审视所有影响结果的上下文：

• 聊天记录
• 用户指令
• 使用过的技能
• 仓库或任务背景
• 工具表现
• 所采取决策的先后顺序

如有相关内容，也请审视：

• 错误输出
• 重试
• 放弃的方案
• 不明确的交接
• 任务过程中用户意图的变化

交互模式

不要假定每次复盘都应该一次完成。

酌情判断：

• 如果上下文已清楚显示失败模式，直接进行复盘。
• 如果原因不明确、存在争议、涉及情绪，或更深入的操作人员见解可能有帮助，先与用户进行简短的迭代式复盘。

采用迭代模式时：

• 提出少量重点明确的问题
• 根据回答完善根因分析
• 然后给出最终复盘

好的问题应聚焦于：

• 用户注意到了什么而 Agent 没有注意到
• 哪个问题影响最大
• 问题出在技能、提示词、工具、工作流还是判断
• 用户希望在系统中落实哪些长期改进

不要为了拖长复盘而提出宽泛或重复的问题。 只有在能实质性改善最终的持久性改进时才提问。

关注事项

1. 错误与失误

找出：

• 错误假设
• 工具使用不当
• 遗漏指令
• 事实或流程错误

2. 效率低下

找出：

• 浪费 token 的冗长探索
• 重复工作
• 不必要的重试
• 可以避免的浏览或搜索
• 原本用简单工具或脚本就能更好处理的环节

3. 死胡同

找出：

• 无助于解决问题的调查方向
• 因上下文不清而陷入的循环
• 本该更早放弃的重复尝试

4. 做得好的地方

保留有效做法。

找出：

• 用户提供的有用框架
• 有效的技能
• 得当的工作流步骤
• 行之有效的捷径
• 值得保留的良好经验法则

不要提出会意外破坏这些优势的改进措施。

根因分析

不要停留在表面症状。

针对每个重要问题，依次追问：

1. 发生了什么？
2. 为什么会发生？
3. 是什么因素导致它得以发生？
4. 背后更深层的模式是什么？

根因通常包括：

• 用户请求的表述不清
• 技能指令缺失或不完善
• 技能边界不合理
• 缺少共享术语
• 仓库或上下文可见性不足
• 缺少处理重复任务的轻量工具
• 工作流顺序不当
• 缺少检查点或审核关卡

优先找出少数真正的原因，而不是罗列大量浅层问题。

如果采用迭代模式，请根据用户的回答检验初步的根因分析，然后再定稿。

输出

复盘应包含以下部分：

复盘摘要

• 任务内容
• 整体执行情况
• 主要问题
• 主要优势

出现的问题

• 具体的失误、错误、延误或死胡同

根因

• 问题背后的根本原因
• 区分症状与原因

做得好的地方

• 值得保留的良好做法
• 这些做法奏效的原因

建议的改进

提出下次可以落实的具体改进。

这些改进必须实用且持久，不能只是提醒大家“更仔细”或“做得更好”。

**绝不要将复盘经验保存到记忆中。**唯一有效的输出产物是：

• 技能——更新现有技能或创建新技能（SKILL.md 文件）
• 文档——提交到代码库的 Markdown 文件（操作手册、检查清单、参考文档）
• 脚本——提交到代码库的确定性辅助工具

记忆不是保存复盘结果的有效位置。如果一条经验不值得写入技能、脚本或代码库文档，就不值得持久保存。

有效的改进包括：

• 更新现有技能的说明或检查清单
• 创建新技能
• 在代码库中添加 Markdown 格式的检查清单或操作手册
• 创建并提交 CLI 脚本
• 在技能、脚本或操作手册中添加审核关卡
• 调整技能或代码库文档中的工作流顺序

对于每条建议，请说明：

• 应进行哪些更改
• 这样做为何有帮助
• 这是高影响力改进还是可选改进
• 应更新哪种产物（技能、脚本或代码库文档）
• 应修改的确切文件路径

最具影响力的下一步

最后提出最值得优先实施的一项改进。

这必须是对技能、脚本或代码库文档的一项具体更改，例如：

• 更新某个特定技能的 SKILL.md
• 在代码库中创建辅助脚本
• 在技能或操作手册中添加审核或验证关卡
• 在代码库中编写或更新操作手册或检查清单 Markdown 文件

不要以“更仔细”“更频繁地检查”“加强沟通”或“下次做得更好”等模糊建议作结。

所选的下一步必须是对技能、脚本或代码库文档的更改，绝不能是记忆。

如果使用了迭代模式，输出应体现与用户交流后发生的变化，而不是忽略用户补充的信息。

良好做法

• 诚实，但不喧宾夺主
• 着眼于未来改进，而非追究责任
• 保留已有的有效做法
• 优先采用结构性改进，而非一次性权宜之计
• 提供足够具体的信息，让读者能够实际落实建议
• 所有建议都必须落实为对技能、脚本或代码库文档的更改，绝不能写入记忆
• 如果用户的观察能实质性地改善复盘结果，应在定稿前简短征求他们的意见