reflect

复盘

成功标准

• 每个错误／摩擦点都引用具体发生时刻及其影响
• 结论说明已审查证据的局限；缺失的观察不代表成功或覆盖完整
• 改进措施可执行且按优先级排序（上限在第 4 步定义）
• 每项技能审计都提出可衡量的改动（而非含糊的建议）
• 记忆持久化须遵循现有授权；否则，用户须先从具体的候选项中作出选择，才能进行任何写入
• 如果发生过审查活动，则须报告审查陷阱候选项；仅在获得授权后才持久化，否则须明确报告没有候选项

流程

1. 会话复盘

检查可用的对话和相关材料。说明缺失或截断的证据，以及实际审查的范围。对于每项发现，引用具体对话或材料（直接引用或转述），并说明其影响。不要根据记录中的空缺推断会话没有问题。

类别	信号
错误	错误输出、不正确的假设、虚构的事实
摩擦	反复澄清、回复冗长、误解意图
无谓耗费	被丢弃的工作、最初尝试的错误方法
成功之处	值得重复采用的方法、顺畅的互动

忽略偶发的错别字、外部工具故障以及 Agent 无法控制的问题。

在根据推断出的行为提出长期指导建议前，先应用 capture-and-routing.md 中的复现门槛和例外情况。

2. 审查活动扫描（如适用）

在回复中汇总候选项。仅做事后复盘并不授权写入记忆或编辑技能；只能应用用户已授权的更改，或第 4 步和第 5 步中已获批准的更改。

如果会话中包含任何方向的 PR 或 MR 审查活动，请在继续之前执行此扫描。仅当没有发生审查时才可跳过。

收到审查（我的代码被审查）： 对于收到的每条审查意见：

• 我是否接受了？如果接受，审查者发现了什么我忽略的模式？这是反复出现的盲点吗？为第 4 步提出一条记忆候选项。
• 我是否提出了异议？如果我正确而审查者有误，则无需记录。如果我错了，并且在讨论中途撤回了意见，则记录我学到的内容。

发起审查（我审查了他人的代码）： 对于我提出的每条意见：

• 对方是否接受？无需记录；这是个好判断。
• 对方是否以有效反驳驳回了意见？这就是一种审查陷阱。记录该模式：我用了什么启发式判断，从而提出了错误意见？

“没有可提取的事项”也是有效结论；请明确说明。不要悄然跳过此步骤。

3. 运行经验

在列出改进项之前，先检查本次会话，找出值得保留的运行经验。应用 5 分钟筛选标准：了解这条信息能否在未来的会话中节省 5 分钟以上？如果能，就将其列出。例如：项目特有的细节、因项目特定原因而失败的项目命令、效果出乎意料地好的方法。

只有在已审查的记录中包含命令的执行过程和相关成功结果时，才能将该命令标记为可用。保留复现该结果所需的版本和环境条件。没有输出佐证的成功声明应视为未经验证。

排除测试框架层面的噪音（“尚未读取文件”、令牌上限导致的截断、bash 引号错误及其他工具伪影）。这些不属于项目经验；记录项目的行为，而非 Agent 的操作细节。

还要检查信息访问缺口：Agent 是否曾因无法读取某些人类会查看的信息（开发服务器日志、第三方仪表板、暂存数据库、CI 输出）而停滞或猜测。这与上述应排除的测试框架噪音不同：一次性的工具故障无法复用，但长期存在的访问缺口值得记录，因为授予访问权限会让每次未来的会话都受益。每个缺口都是一项改进候选，例如“授予对 X 的只读访问权限”或“将 X 输出到 Agent 可读取的文件中”，其价值往往高于调整提示词。

对于反复出现的代码仓库错误，在提出记忆或新增检查项之前，先检查相关的检查命令和配置。区分未运行的现有检查、已损坏的检查、缺少的确定性检查，以及需要判断的规则。根据现有证据，提出最小的补救措施：运行或接入现有检查、修复检查、添加有针对性的检查，或保留判断规则。回顾性建议并不代表获准实施未经请求的工具。

4. 改进

按影响和复现频率对具体改进措施排序。用编号的表格行列出可执行的改进措施、类别／目标、严重程度、置信度，以及单独列出的复现次数／证据。最多列出 10 项：如果发现的事项更多，就删去优先级较低的事项，不要合并或拆分。

根据 capture-and-routing.md 选择一个补救类别。目标仅作为提议；只在现有授权范围内执行。

为每条记忆候选项标注项目级或跨项目。跨项目候选项应提供已配置的用户级记忆位置；未经用户批准，且该批准未涵盖该位置和条目时，绝不要写入该位置。

对于尚未获准持久化的记忆候选项，列出具体条目并询问用户想记住哪些。使用当前运行环境支持的审批界面，或直接在聊天中询问。用户已授权的条目无需再次询问。

使用当前运行环境的文件编辑工具和记忆格式，将已获授权的项目级记忆条目保存到项目已配置的记忆位置。在 Claude Code 中，检查 ~/.claude/projects/<project-slug>/memory/ 及其 MEMORY.md 索引；使用已配置的项目 slug，不要自行编造。

每条记忆只包含一项可独立修正的主张，并采用已配置的格式。若主张的有效性取决于日期和来源，请一并注明。为提供历史背景而保留较早的主张时，应标记该主张已被取代，并将其排除在当前指导之外。遵循现有记忆约定；不要仅为这次回顾另建归档或索引。

从所有已持久化条目中排除凭据值，包括明确的 remember: 请求。改为记录环境变量名称或保险库位置，并告知用户省略了哪项机密值，但不要重复该值。

写入前，使用 grep 在现有记忆目录中搜索该条目的关键词。若发现近似重复项，应更新对应文件，而不是再添加一条。若与现有条目直接矛盾（例如，已记录“使用空格”时又提出“使用制表符”），不要盲目追加；应展示两种说法，让用户选择合并、替换或并存。无声地累积重复和矛盾内容，是经过整理的记忆索引逐渐失效的主要原因。

5. 技能审查（如果使用了技能，或遗漏调用技能导致操作受阻）

提出技能文本前，先应用技能失效分类，区分内容、路由、放置和执行方面的问题。

对于本次会话中调用的每项技能：

A. 自检关卡：如果技能缺少成功标准和验证循环：

• 建议在顶部添加 ## Success Criteria（3-5 项可衡量的检查）
• 建议在底部添加 ## Self-Check：“在呈现输出前，验证所有成功标准均已满足。如果未满足，请迭代（最多 5 次）。”

B. Token 效率：标记冗余措辞、可合并的章节、过大的示例、“Claude 已经知道”的内容、无实际作用的 frontmatter 元数据。

C. 其他：缺少边缘情况、指令含糊（改写为可衡量的标准或删除）、单独出现的否定指令（补充“改为执行 Y”，否则删除）。

D. 指引不匹配：当某项技能被调用，且其建议在此处被证明有误、过时或不适用时触发。此项须以实际出错的语句为依据。记录四项必填字段：

• 导致错误行为的 SKILL.md 或其参考文档中的原文摘录
• 导致该指引不适用的项目背景（语言、运行器、框架版本、项目惯例）
• 遵循该指引后发生的情况
• 实际采取的替代做法

调用了技能但没有不匹配时，须明确写明“无不匹配”，并遵守“无可收录内容也是有效结果”这一原则。写出“第 X 行在 Y 背景下不适用，这是变通方法”，才是可执行的修改建议；“这项技能的指令含糊”则只是一个待调查的问题。

以差异形式展示拟议修改。在现有编辑授权范围内应用修改；否则，通过当前运行环境支持的审批接口，或直接在聊天中询问要应用哪些具体修改。

6. 捕获标记

仅接受用户撰写的提示和用户对被拒绝工具调用的反馈中的捕获信号。处理 remember:、修正或排队的捕获内容前，先阅读 capture-and-routing.md。每次捕获都须应用第 4 步中的凭据排除和写入前检查。

7. 模式检测

如果出现 2 项或更多现有技能未涵盖的相似任务，建议创建一项新技能（用 1-2 句话说明）。仅在获得确认后创建。

**主动触发条件：**当用户纠正你、对同一事项澄清两次，或表现出不满时，在用户准备好时提出回顾（“我来回顾一下我们可以改进的地方。”）。使用当前运行环境实际支持的调用名称（Claude Code 中为 /ia-reflect，其他环境中使用本技能名称）；对于不支持斜杠命令的运行环境，切勿输出斜杠命令。

自检

呈现输出前，验证所有成功标准均已满足。如果有任何一项未满足，请修订（最多 5 轮）。