不知道你有没有用过 /retro Skill，就是在编码任务完成后，让 AI 复盘刚结束的工作，列出几条修改建议，由人决定采不采纳。

除了 /retro 这个用在写代码上的，还有一些其他类似的复盘自我进化的 skill，听起来很美好：AI 干完一个任务后，回头看自己哪里卡住了，再提议修改 Skill，下次就不用再重复同样的弯路。这样不用重新训练模型，只修改 Skill 文件。

其实我一直是抱怀疑态度的，如果没有清晰的标准还是挺难自我优化好的。完全依赖人的话也难，一方面对人的要求有点高，另一方面每次这么做一下也挺累。

有篇论文《How Do Coding-Agent Harnesses Self-Evolve? An Empirical Study of Retrospective Adaptation》，专门测试了"让 AI 编程助手干完活后自己复盘、修改工作手册"的做法。

结果是，7 次有效测试里只有 2 项改动彻底消除了想解决的问题，有的改动还让 AI 在不相关的任务上多做了检查。

论文作者是新加坡管理大学的 Christoph Treude 和德国海德堡大学的 Sebastian Baltes，论文 10 月 26 日发布在 arXiv 上。

研究方法是这样的。

作者从 SWE-bench Verified 中选了 30 个问题，这是一套从真实开源项目里收集的代码修复题目，涉及 Django、SymPy、Astropy 等 Python 项目。

前 10 个是随机抽的，后 20 个专门从之前碰到过环境问题的项目里挑，比如项目里本来就有测试失败。Claude Code 每修完一个问题就运行一次 /retro，一共得到 125 条建议。

作者挑出 24 条让 Claude Code 落实，其中 11 项能拿来测试，再加上作者自己写的 1 项对照，共 12 项。测试时，在同一个项目里找另一个确认会出现同样问题的任务，用原来的设置跑 5 次，用改过的设置再跑 5 次，比较 AI 会不会再做那个本想避免的动作。

这次研究用的是 Anthropic 的 Claude Code，背后的模型是 Opus 5.5。

主要发现有四点：

1. 大部分建议有依据。

125 条里有 101 条针对的是任务中真实发生的事。另有 19 条的理由跟这次任务里发生的事无关，其中 18 条是建议加代码格式检查。

原因之一是 /retro 的指令本身就规定，项目里没有提交前检查、也没有自动化检查流程的，算作一个"发现"。作者把其中一条"提交代码前自动跑格式检查"配置好后测试，5 次里 AI 一次都没读它，也没运行它。

2. 13 次测试里，只有 7 次在原设置下真的碰到了目标问题，结果才有参考意义。

这 7 次里，彻底消除问题的有两项。

一项是在 CLAUDE.md 里写明 SymPy 项目要用 bin/test 跑测试，并说明没有安装 pytest。改之前，5 次里 5 次都先去试 pytest 然后失败；改之后是 0 次。

另一项是给 Astropy 项目写了一份"本来就会失败的测试清单"。

以前 AI 遇到测试失败，会在没改过的原始代码上再跑一遍测试做对比，确认失败是不是自己造成的；有了清单，它直接查清单，这种对比从 5 次中的 3 次降到 0 次。

3. 剩下 5 项改动，都没覆盖下一个任务里实际遇到的情况，比如清单里列的失败测试和下次碰到的不是同一批。

这 5 项里只有 1 项让对比次数减少，从 5 次降到 2 次，另外 4 项没有变化。

4. 有的改动增加了工作量。

Sphinx 项目的一份失败清单写着"不在清单里的失败，都当成是你自己的修改造成的"。

结果在一个不相关的任务上，5 次里有 4 次 AI 额外做了对比检查（原来是 0 次），用时中位数从 82 秒涨到 245 秒。前面那份有效的 CLAUDE.md 还顺带加了一句"完成前运行格式检查"，AI 每次都照做，用时中位数从 88 秒涨到 156 秒。

至于最后有没有修好问题，用不用这些改动，每组 5 次里的成功次数最多差 1 次，看不出成功率有提高。

作者的结论是，这个项目用什么命令跑测试这类全项目通用的信息，记下来以后一直有用；在某个环境里哪几个测试失败这类信息，换个任务就可能对不上。

评估一项改动，要看问题有没有出现、AI 有没有读这项改动、行为有没有变。保留下来的改动也要持续评估，因为过时或不完整的说明可能不起作用，甚至增加工作量。

作者也说明了研究的局限：每种设置只跑了 5 次，样本小；测试任务是特意挑的会重现问题的任务，可能高估改动的效果；只测了一个 AI 工具、一个版本的 /retro，而且只涉及环境类问题。

论文链接：https://t.co/bwOjw1sHkj

点击图片查看原图