一篇实证研究测试了让 AI 编程助手完成任务后复盘并修改工作手册的做法，效果相当有限。 新加坡管理大学的 Christoph Treude 和德国海德堡大学… · @ThanksuTrump · TwKit

@ThanksuTrump

一篇实证研究测试了让 AI 编程助手完成任务后复盘并修改工作手册的做法，效果相当有限。 新加坡管理大学的 Christoph Treude 和德国海德堡大学的 Sebastian Baltes 于 10 月 26 日在 arXiv 发布论文《How Do Coding-Agent Harnesses Self-Evolve? An Empirical Study of Retrospective Adaptation》。研究从 SWE-bench Verified 中选取 30 个真实开源项目的代码修复问题，涉及 Django、SymPy、Astropy 等 Python 项目。前 10 个随机抽取，后 20 个专门从之前碰到过环境问题的项目里挑选。使用 Anthropic 的 Claude Code（模型为 Opus 5.5）完成每个问题后运行一次 /retro，共得到 125 条建议。作者从中落实 24 条，其中 11 项可测试，加上作者自写的 1 项对照，共 12 项。测试时在同一项目找另一个确认会出现同样问题的任务，原设置跑 5 次，改后设置再跑 5 次，比较 AI 是否还会做那个本想避免的动作。 125 条建议中有 101 条针对任务中真实发生的事。另有 19 条理由与这次任务无关，其中 18 条建议加代码格式检查。原因之一是 /retro 指令本身规定，项目里没有提交前检查也没有自动化检查流程的，就算作一个“发现”。作者把其中一条“提交代码前自动跑格式检查”配置好后测试，5 次里 AI 一次都没读取它，也没运行它。 13 次测试里，只有 7 次在原设置下真的碰到了目标问题。这 7 次里彻底消除问题的有两项。一项是在 CLAUDE.md 里写明 SymPy 项目要用 bin/test 跑测试，并说明没有安装 pytest。改之前 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 次、样本小；测试任务是特意挑的会重现问题的任务，可能高估效果；只测了一个 AI 工具、一个版本的 /retro，而且只涉及环境类问题。 这类复盘后修改 Skill 的做法听起来美好，AI 干完任务后回头看自己哪里卡住了，再提议修改，下次就不用再重复同样的弯路，也不用重新训练模型。但没有清晰标准时还是挺难自我优化好的。完全依赖人的话也难，一方面对人的要求有点高，另一方面每次这么做一下也挺累。 论文链接：https://arxiv.org/pdf/2610.34938

曝光 186 · 评论 7 · 点赞 5 · 书签 1