再学 AI
第 29 课 / retro
实验性阅读 → 对照 → 问答 → 场景

从一次执行中改进 Agent 的工作环境

复盘的对象是环境和规则:哪些信息难找、哪些错误本可自动抓住、哪些说明只增加负担。

还不清楚 Skill、Agent、安装和调用?先读 从零开始的6节入门课

实验性技能

作者将它放在 in-progress,未作为稳定插件内容推广。先理解原理,实际使用前核实版本和依赖。

在关系图中查看 retro 与其他技能的关联 →

先把必要的概念讲清楚

回顾的对象是 Agent 的工作环境如何帮助或妨碍执行。它不是对 AI 说“下次认真一点”,而是把一次实际失败转成更可持续的改进。

下面是老师补充的入门说明;原作者的要求保留在中英对照正文中。所有例子均为帮助理解而构造的教学情境。

context|Agent 当前可用的上下文

模型这一轮实际能使用的请求、对话、指令和已读文件内容。它不是电脑上所有资料,也不是永久记忆。文件存在但没被读到,就不一定参与推理。交接文档应指明当前目标、进度、关键证据位置和下一步,让新会话能够恢复必要背景。

context pointer|上下文资料指引

告诉 Agent 在什么条件下去读哪份材料的短指引。例如“新增或修改数据写入时,先读权限规则文档”。它同时承担地址与触发条件两项作用。只有“见文档”太模糊,可能找不到或不知道何时需要;一股脑放入所有内容又会占用上下文。

CI|持续集成检查

把修改提交到共享流程时,自动运行测试、类型检查等约定检查,尽早发现集成问题。绿灯表示配置的检查通过,不代表所有需求都正确;红灯也可能由环境故障导致,应看具体证据。需要先检查“配置了什么”,才能解释绿灯的意义。

refactoring|重构

在保持约定外部行为的前提下改善内部结构,例如合并重复逻辑、调整职责归属。用户仍能完成同样操作,但代码更容易理解和修改。重构不等于顺便加新需求;测试帮助证明外部行为未被意外改变。

读原文,理解每一步为什么这样做

左右内容按小节对应;窄屏先中文、后英文。两种语言均完整展示,对应讲解紧接在小节之后。译文传达原文要求;老师讲解补充概念、原因、例子与适用边界。

中文译文English · 英文原文
中文译文
name: retro
description: "对一次编程会话进行回顾。"
disable-model-invocation: true
English · 英文原文
name: retro
description: "Conduct a retrospective on a coding session."
disable-model-invocation: true
中文译文

用户要求复盘编程会话。你的任务是提出 Agent 工作环境的改进,使之后执行得更好。

English · 英文原文

The user has asked for a retrospective. You are suggesting improvements to the coding agent's environment to improve future runs.

中文译文

步骤

  1. 调用 writing-for-agents,获取面向 Agent 的写作指导。
  2. 阅读用户指定会话的一手记录,可能需要查本机日志。未指定时复盘当前会话。
  3. 从下面几类寻找改进候选:
  • 导航:找到文件是否困难,是否存在隐藏依赖,增加资料位置引用是否有帮助。寻找信息花太久时重点检查。
  • 自动检查:本次错误能否被 lint、类型、测试或文件结构检查发现。
  • 编码规范:审查者漏掉错误时,是否需要增加、删除或澄清某条规则。
  • 全局 AGENTS.md:文件过大时,是否有内容应移到编码规范或自动检查,仓库级和全局级都要考虑。
  • 工具成本:有没有昂贵调用可以简化,自定义 CLI 或 MCP 是否返回太多内容、浪费 token。
  • 不起作用的说明:指导文件庞大时,找出不会改变行为的文字。
  • 信息获取:关键事实不可见时,能否提供开发日志同步输出或第三方只读访问。
  1. 按严重程度向用户展示候选。
English · 英文原文

Steps

  1. Call the Skill tool with writing-for-agents for the writing style guide.

  2. Read the primary sources for the session the user specifies. This may mean searching through session logs on this machine. If the user doesn't specify a session, default to the current one.

  3. Look for candidates for improvement in these categories.

  • Navigation: how easy was it for the agent to find the right files? Are there hidden dependencies between files? Would a navigation pointer make it easier? Use when the session took a long time to find a piece of information.
  • Automated checks: are there automated checks that could catch errors the agent made? Linting, typing, tests, filesystem linters? Use when the agent made a mistake that could have been caught by an automated check.
  • Coding standards: should the reviewer agent be given a new rule to enforce? Should an existing rule be removed or clarified? Use when the reviewer agent failed to catch a mistake.
  • Global AGENTS.md: are there any steering instructions that should be moved to coding standards (or automated checks) instead? Use when the AGENTS.md file is particularly large - in the repo OR the user's global scope.
  • Tool economy: did the agent make expensive tool calls that could be streamlined? Is there any custom tooling (CLI's, MCP's) that is particularly token-inefficient? Use when the agent made an expensive tool call.
  • No-ops: look for instructions in steering files that don't modify the agent's behavior. Use when the steering files are large and unwieldy.
  • Information access: look for opportunities to increase the agent's access to information. Teeing dev server logs, readonly access to third-party services. Use when a crucial piece of information was not available to the agent.
  1. Present these candidates to the user, in order of severity.
老师讲解 · 对应上方原文 · 含教学举例

从会话证据找改进,不凭印象加规则

先读相关会话的一手记录,区分耗时在哪里、缺什么资料、发生什么错误。查了很久才找到文件,可能需要导航指引;反复漏同一种格式错误,可能更适合自动检查。

**例子:**Agent 三次使用不存在的测试命令。若真实命令在 package.json 一查即得,应改探索习惯或工具流程;不一定要把所有脚本复制进全局指令。

候选还包括评审规范、昂贵工具输出、信息访问和无效指令。按严重性呈现是帮助选择收益最大的改进,不要求一次全部实施。

复盘要改变下次工作的条件,而不只是说下次会认真

假设 Agent 为收藏功能重新写登录逻辑,后来才发现项目已有模块。先查为什么没找到:如果缺导航,一条准确的入口引用可能比复制整份源码到 AGENTS.md 更有帮助。

再假设导入路径写错。已有类型检查却没运行,与根本没有可用检查,是两种原因,改进方案也不同。建议应联系本次真实失误。

上下文压力指一次任务里需要同时处理的材料很多。将详细规范放在合适阶段读取,有助于减少拥挤。但由审查阶段重点检查规范,不代表实现时可以忽略已知约定。

可用的复盘应说明发生什么、什么环境因素导致困难、改哪里、预期怎样帮助下次,而不是增加一堆永远不查的规则。

中文译文

参考原则

English · 英文原文

Reference

中文译文
实现与审查的分工

实现者需要探索、写代码和排错,承受较大上下文压力。审查者已有差异,通常少做探索,也较少写代码或调试。作者据此主张让审查者主要承担编码规范检查。

English · 英文原文
Implementation vs Review

Remember that all work goes through two stages: implementation and review. The implementation agent has the most context pressure. They are responsible for exploration, writing code, and debugging failures.

The review agent has the least context pressure - it receives a diff, so no exploration needed. It often does not need to write code or debug.

This means that the review agent should be responsible for imposing coding standards, not the implementation agent.

老师讲解 · 对应上方原文 · 含教学举例

把要求放到最适合承担它的环节

实现 Agent 已同时处理探索、写代码和调试,上下文负担大;评审 Agent 可聚焦差异与标准。因此作者建议某些编码规范由评审阶段执行,而不是每轮都塞进实现者上下文。

这是一种分工偏好,不意味着实现时可以完全不顾安全和正确性。基本约束仍然适用,自动检查也可能在实现过程中持续反馈。

你要看改进是否真的减少同类失败。例如新增导航后找文件更快,新增检查后错误能被阻止。仅增加一份文档而没有人读,并未证明工作方式改善。

中文译文
不同文件的用途
  • CLAUDE.md / AGENTS.md 会进入仓库 Agent 的上下文,应节制使用,通常以导航引用为主。
  • CODING_STANDARDS.md 按本文安排在审查阶段读取。超过 1000 行时,增加指向文档目录的引用。
  • 其他文档作为被引用的参考资料。写新文件前先查是否已有相关内容。
  • Skills 可以承载文档,其描述帮助发现;也可以提供用户主动调用的命令。按 writing-for-agents 的建议组织。
English · 英文原文
Files

You have access to several files in the repo:

  • CLAUDE.md/AGENTS.md: these files are pushed to the context window of any agent working in this repo. They should be used incredibly sparingly, usually only for navigation pointers to other files.
  • CODING_STANDARDS.md: this file is read during review, not implementation. Add navigation pointers to docs folders if the standards file gets more than 1,000 lines long.
  • Docs: use docs as references files, pointed to by other files. Look for existing docs before writing new ones.
  • Skills: use skills for docs (since their description goes into the agent's context window), or for user-invoked commands. Follow the advice in the writing-for-agents skill.
老师讲解 · 对应上方原文 · 含教学举例

不要让每次失败都沉积成一条永久指令

AGENTS.md、编码标准、参考文档和 skill 适合承载不同信息。常驻指令尽量精炼且有导航;详细评审规则放评审材料;可由工具准确执行的规则尽量自动化。

例如一次偶发网络超时,不应直接永久规定“所有任务必须重试三次”。先判断原因与适用范围,否则新规则会在不相关任务中增加成本。

回顾应形成具体、可观察的改进候选。下一次运行提供反馈,再决定保留、修改或删除,而不是越积越多。

原作者:Matt Pocock · 中文翻译为非官方译本

来源:skills/in-progress/retro/SKILL.md ↗

固定版本:3cca18b368ae95cdbdebbff572ccafa662551015

先作答,再看参考思路

Q1 · 理解

用自己的话说明:它解决什么问题,完成后会留下什么?

请各用一句话回答。若它只做规划或解释,不要把“已开发”“已部署”写成产物。

Q2 · 判断

什么时候应该增加自动检查,什么时候只是改说明?

我已思考,查看参考思路

可确定判定、反复发生的机械错误适合检查;难以找到材料或理解约定时先改善指针和说明。之后重跑任务验证效果。

Q3 · 追问

原文中哪条要求在你的环境下可能不成立?

说出具体一句及其前提,例如工具不可用、资料缺失、已有项目约定冲突,或它只是作者偏好。把你的答案带回课堂,我们据此继续讨论。

课堂回传格式:第 29 课 / 我的理解 / Q2 回答 / 仍不理解的原句。这里是阅读教材;实时问答在我们的对话中进行。

把方法放进一个具体情境

教学案例:三次执行都找不到同一份状态定义,可以增加准确导航指针;一次偶发拼写错误不一定值得把全局 AGENTS.md 再加十条禁令。

边界与容易误读的地方

原文没有完整落实所有候选的实施流程。提出复盘建议与已验证改善要分开;不要自动把每次失败永久写成规则。

讨论后再实践:先判断上述情境是否适用,再选择真实任务。现在无需安装、运行命令或修改现有项目。

关联阅读