AI 干完活自己复盘改进，7 次测试只有 2 次真解决问题

编码任务做完，让 AI 回头复盘刚结束的工作，列几条修改建议，由人决定采不采纳。这是 /retro 这类 skill 做的事。类似的自我进化机制还有不少：AI 干完活，看自己哪里卡住，提议修改 Skill 文件，下次不重复同样的弯路。不用重新训练模型，改改配置和文档就行。

听起来很美。但一直有人怀疑，没有清晰标准的话，自我优化很难靠谱。完全靠人把关也累，一方面对人的要求高，另一方面每次都过一遍不现实。

有篇论文专门测了这件事。《How Do Coding-Agent Harnesses Self-Evolve? An Empirical Study of Retrospective Adaptation》，作者是新加坡管理大学的 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 还会不会做那个本想避免的动作。

工具是 Claude Code，模型是 Opus 5.5。

四个发现

大部分建议有依据，但不是全部。 125 条里 101 条针对的是任务中真实发生的事。剩下 19 条的理由跟当次任务无关，其中 18 条是建议加代码格式检查。原因之一是 /retro 的指令本身规定，项目没有提交前检查、没有自动化流程，就算一个发现。作者把其中一条“提交前自动跑格式检查”配置好再测，5 次里 AI 一次都没读它，也没运行它。

13 次测试里只有 7 次原设置真的碰到了目标问题。 这 7 次里，彻底解决问题的有两项。

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

另一项是给 Astropy 写了一份“本来就会失败的测试清单”。以前 AI 遇到测试失败，会在没改过的原始代码上再跑一遍做对比，确认失败是不是自己造成的。有了清单，这种对比从 5 次里的 3 次降到 0 次。

剩下 5 项改动，没覆盖下一个任务的实际场景。 比如清单里列的失败测试和下次碰到的不是同一批。这 5 项里只有 1 项让对比次数从 5 次降到 2 次，另外 4 项没变化。

有的改动反而增加工作量。 Sphinx 项目那份失败清单写着“不在清单里的失败，都当成是你自己的修改造成的”。结果在一个不相关任务上，5 次里有 4 次 AI 额外做了对比检查，原来是 0 次，用时中位数从 82 秒涨到 245 秒。前面那份有效的 CLAUDE.md 还顺带加了句“完成前运行格式检查”，AI 每次都照做，用时中位数从 88 秒涨到 156 秒。

至于最终能不能修好问题，每组 5 次里的成功次数最多差 1 次，看不出成功率有提高。

能留下的是什么

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

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

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

一个更根本的问题

宝玉在推文里提过一个判断：只有能程序自动验收的 Skill 才谈得上自我进化。比如优化代码性能，性能可测量可量化，给测试样例去迭代，能越来越好。写作这种没有明确验收标准的，AI 自己打分和真人感受差距不小，AI 打高分的稿子真人看可能一股 AI 味。真想写好 Skill，还得人来用、人来指出方向。

有网友 Hongliang 把这个现象说得更直接：这在优化理论里叫 proxy overoptimization，对代理目标的过度优化。代码评审这类任务，代理目标离真实目标近；写作、审美这些任务，真实目标是人偏好，AI 自评只是代理。如果根据这个评分去优化，AI 会迎合“AI 觉得好”的标准，输出越来越怪。

也有团队在尝试把这件事做得更工程化，比如微软联合几所高校的 SkillOpt，用类似训练的框架去评估和优化 skill，设验证门来控制编辑方向。思路是对的，但前提仍然没变：得有可量化的验收标准，否则验证门本身就成了摆设。

回到最实际的问题。AI 复盘提建议这一步不稀缺，稀缺的是判断哪条建议该留。125 条建议里真正解决问题的只有 2 项，这个比例不算意外。没有验收标准，复盘很容易变成自我安慰；有标准，也只是一部分任务能自动跑通。剩下的，还得人来看。