速评：9 月 11 号 arXiv 上挂了篇论文，编号 2609.12742，归在 cs.AI，三个作者，讲的是怎么自动合成、自动优化仓库里的 SKILL 文件。
全文最值钱的那句话不在摘要里，在作者自己拆自己台的那一段。
一百来 KB，PDF、HTML、源码全给齐，正经投稿的配置，不是挂个 preprint 卡位抢首发那种操作。SKILL 文件本身不新鲜，跟代码一起进版本管理的 Markdown，这个角色以前是 README 在演。新鲜的是有人开始拿优化器去打它——文档从给人看的备忘，变成了一个可以被度量、被迭代的构建产物。
这活儿原本的做法挺讨巧：拿一个公开的基准去优化文档，优化到什么程度有明确的目标函数。问题是基准不长在仓库里。你优化出来的文档，最后服务的是那个基准，不是那个仓库。作者没去修这道缝，直接换了套思路——从仓库自己的历史里挖题。
具体是这么干的：把已经合并的 pull request 回退到一个固定的基础提交，看智能体能不能把这个 PR 重新做一遍。有文档时做得比没文档时好，这个差值就是文档的分数。
这套装置很聪明，我承认。它绕开了一个死结——你造的合成任务，能力强的模型闭着眼全对，一点区分度没有；拿仓库历史上真被提过、真被维护者合进去的 PR 当题，难度起码是真的。但它顺手也埋了个雷：你测的其实是"文档能不能把 git 历史里发生过的那段事讲明白"，这跟"文档能不能帮 agent 干未来的新活"，隔着一层。
结果：三个 Kotlin 仓库，GEPA 优化出来的文档，平均把分数抬了 4.9 个百分点；另一个优化器 SkillOpt 基本白干，0.1 个百分点。
4.9 对 0.1，按常规写法这儿该来一句"后者几乎无效"，然后再分析两个优化器的差别。但论文没往这个方向走，它回过头，先把 4.9 给撤了。
大意是：这个提升，跟同一个智能体逐次运行之间的波动，区分不开。
这是整篇里最诚实也最扎心的一句。翻译一下：我跑了，我数了，我算出来的差异小到我不敢说它是差异。作者接着往下推了一步——要搞清楚这 4.9 到底是真是假，需要的任务数量会超过单个仓库历史所能提供的规模。
死结就在这儿。要任务真实，只能用这一个仓库自己的历史，样本量天生有限；要样本量大，就得回去合成任务，而合成任务强模型又能刷满。两条路，一条通不到显著，另一条通不到区分度。论文两边都试了，两边都撞墙。
我不是说这套装置没用。它是我目前见过最接近"拿真任务考文档"的做法，只是它顺手把自己逼进了墙角——测出来的差异小到不敢认，恰恰说明它测得挺认真。
我不太确定这是不是作者写这篇的初衷。也可能本来是想证明"自动合成的文档有用"，跑到一半发现证明不了，干脆把这个发现写成了论文。这剧本，眼熟——这种论文我见过几篇，通常比结论漂亮的那些更值得读。
然后是这篇里最有人味的一段。其中一个仓库的维护者说，这些文档里包含的是只有真正在项目里干过活