回顾

它的作用¶

retro 会回顾一次编码会话，并对智能体的环境提出改进建议，以便下次运行更顺利。

它读取会话自身的记录（默认是当前会话，也可以是指在会话日志中你指定的某一次会话）。它会找出智能体遇到困难的时刻，并按严重程度从高到低给出一份候选修复列表。

它改变的是环境，而不是代码。以智能体交付的 bug、它花了二十次工具调用才找到的文件、或者审查者漏掉的规则为例，retro 不会直接修复其中任何一个。它会追问仓库里是什么让这些问题得以发生，并提出相应的检查、指引或标准，以便下次能避免。而且它只是提议。在你选定某个候选方案之前，什么都不会改变。

何时使用它¶

你需要输入 /retro 来调用它，智能体不会自己主动使用。

在某个比预期更艰难的会话结束时，请使用它。例如，智能体花了太长时间搜索某个东西、犯了一个工具本可以捕获的错误、或者需要它无法获取的信息。顺利的会话几乎没有可供学习的教训，发现来自那些困难的时刻。如果你想对会话产出的代码做评判，请改用 code-review。

改进项落在哪里¶

每个候选方案都属于一个类别，而类别决定了修复落点：

核心理念是：标准属于审查者，而不是实施者。实施智能体承受的上下文压力最大，因为它要探索、写代码并调试故障。审查智能体只拿到一份 diff，除此之外什么都没有。所以新规则应该放在有空间应用它的地方，也就是审查环节。它绝不会放进 AGENTS.md，因为该文件会加载进每次会话的上下文窗口，无论是否相关。

在 retro 制定任何规则之前，它会对违规进行分类。机械性违规（禁用 API、导入形态、文件位置规则）会获得确定性检查，因为检查能失败，而标准文件中的一句话不能失败。只有真正的判断性问题（没有 linter 能强制执行）才会变成文字规则。如果仓库完全没有护栏（没有 pre-commit 钩子，也没有运行 lint、类型检查和测试的 CI 任务），retro 会把这一点本身作为一条发现来报告。

常见问题¶

它是自己写 lint 规则，还是等待确认？我可以让它每次会话后都自动运行吗？

它等待。retro 只提出建议。在你选定某个候选方案之前，什么都不会改变，所以它不会手动编辑任何内容，也不会自动安装任何钩子。这是有意的设计。一位用户曾表示，正是由于“被会阻止好的变更的自动钩子坑过”，他才要求这种模式。判断什么值得永久检查需要人的判断力，因此该技能保持人在回路、由用户主动调用的状态。有些用户确实会在每次实施会话后运行它。但顺利的会话几乎没有可供学习的教训，所以每次会话后都运行，多半只会产生没人需要的规则。没有试运行模式。一个被提议的检查和其他代码一样，所以在让它阻止合并之前，先在仓库中验证一下。

这样下去 lint 规则会不会无限堆积？它会建议移除某条规则吗？

部分会，这也是它最薄弱的地方。它可以删除文字内容：引导文件中的无效项，以及 AGENTS.md 或 CLAUDE.md 中本应属于标准或检查的引导内容。当文件过大时，它会将这些内容标记为删除。它是根据它读取的那一次会话来判断的，所以请把每一条都当作删除测试的候选对象，而不是最终裁决。它不会审计上个月提出的 lint 规则、钩子或 CI 任务。它只看到一次会话，所以无法告诉你某条规则现在触发得过于频繁，或者它背后的 bug 已经消失。你仍然需要自己修剪检查。一条规则在良好代码上不断触发，就是该移除它的信号。

它会不会为了填满类别而凭空捏造泛泛的建议？

这是对它最强烈的批评。一位用户发现：“工作完成后，AI 往往会忘记会话中途的困难，并编造一些泛泛的建议来满足 retro 的类别。”每个候选方案都必须来自会话自身的记录，所以建议是针对该次会话的。这有代价也有好处。它很少凭空捏造不相关的东西，但可能会过度重视这一次会话所涉及的内容。请丢弃任何你无法追溯到具体时刻的候选方案。同时把严重程度排序也当作初稿，因为一个不显眼但代价高昂的错误，可能排在一个明显但代价较小的错误之下。

我的会话很长。是现在就运行，还是重新开始？

默认情况下，它审查当前会话。这是最好的情况，因为那些困难仍在上下文窗口中。如果会话已经移出了智能区，请清除它，然后把一个新的 /retro 指向会话日志中的上一次会话。

代理不断犯同样的错误。我应该往 CLAUDE.md 里加一行吗？

通常不建议，而且 retro 对此的反对比任何其他方面都更强烈。CLAUDE.md 中的一行会加载到每个会话中，降低文件中其他内容的权重，并随着代码变化而过时。如果错误是机械性的，修复方式是一个会失败的检查。如果它属于判断性决策，就应写入评审者阅读的编码标准中。AGENTS.md 和 CLAUDE.md 只用于导航指引，几乎没有其他用途。出于同样的原因，retro 不是一个记忆系统。它不存储发生了什么。它改变环境，使错误无法再次发生。

我的配置提到了 CODING_STANDARDS.md，但我没有这个文件。它从哪里来？

没有任何技能会附带该文件。当一个会话首次发现一条供评审者使用的判断性规则时，retro 会提议创建该文件。在你接受后，code-review 会读取它。你已有的任何其他标准文档，例如 CONTRIBUTING.md，都以相同方式工作。

它与 improve-codebase-architecture 有何不同？

输入不同。improve-codebase-architecture 只需要代码，并寻找其结构性改进。retro 需要会话历史，并改进代理工作的环境，而不是代码。两者都要使用；二者不能互相替代。

如果它正在起作用¶

• 每个候选项都指向会话中的某个具体时刻，而不是泛泛的最佳实践。
• 重复错误会变成失败的检查，你的 AGENTS.md 会随时间变短，而不是变长。
• 如果检查已经存在但没有连接，发现就是连接它，而不是提议构建一个新的。
• 下一次处理同类任务的会话能更快地找到所需内容。

它适合在哪里¶

retro 是主链的最后一个步骤，在这里你回顾主链进行得如何：

grill-with-docs → to-spec → to-tickets → implement → code-review → retro

在值得学习的构建之后运行它，可以在同一会话中，也可以指向该会话的日志。在顺利的构建之后可以跳过它。

• code-review 是 retro 最常调整的评审代理。新的编码标准应放在其 Standards 轴读取它们的地方。
• writing-for-agents 为 retro 提议的每个引导文件和技能设定写作风格，并且 retro 在开始前会加载它。

ask-matt 在你不确定情况需要哪个技能时，会在整个集合中进行路由。