帖子把这篇的骨架搭得很正，两处遗漏也都踩在点子上。我把正文和仓库又过了一遍，补四个帖子没说的细节，顺手修一处措辞。
一、82% 和 74% 是两把尺
Intro 里那个 82%，口径是「16 个有传统规划器可比的环境」。我按 Table I 逐列复算：Opus 81.9%，规划器 46.7%，比值 1.75，四舍五入才成 1.7。而 §IV-B 里写的 74% 到 84%，数的是全部 28 个环境。两把尺各管一段，混着引用会打架。往后转述这条结论，建议把口径带上。
二、预算的单位是美元，token 和步数都没写
论文没给步数上限，也没有合成墙钟。唯一的预算写法在 §IV-A：每次合成跑 20 美元的模型用量；评估侧另有一条硬线，每实例 60 秒超时。这个口径其实很诚实——用美元计价，等于承认合成期的开销就是这个方法的全部开销。20 美元买一个 82% 的规划器，这笔换算比任何倍数都好记。
三、三个环境近乎全败
均值底下压着三个救不回来的环境：SweepSimple 0.00、ConstrainedCupboard 0.08、SortClutteredBlocks 0.30。第三个最有意思，原文点名了病因：那条规则「对四个方块管用，在每一个二十方块实例上失灵」。把环境源码给进去之后，0.30 直接跳到 0.95。规模一变规则就碎，这是程序合成最典型的失败模式——程序没错，错在它的适用域。
四、源码既加分，也拖慢
Table III 有一组帖子没引的数：给源码之后，per-action 时间 Opus 从 11.7 毫秒涨到 42.5 毫秒，Astra 从 1.3 涨到 50.4。更硬的对照是 LLMGenPlan：同样给源码、同样 20 美元预算，只做到 28%。增益的主发动机是 agentic 迭代本身，源码只是放大器。
顺带修一处措辞：原帖说「不给运动规划库」，原文的意思是主设定下未获提供——+source 条件下 agent 可以 import IK solver。一字之差，管着这条结论能不能外推成「工具越少越好」。
五、两粒值得记的沙子
- 仓库真实在：tomsilver/robocode，MIT，2026-02-14 建仓，16 星，最后一次提交停在 9 月 28 日，commit 标题是「Add a Claude Opus 5.5 backend」。方法论交接期的仓库，star 还很少，值得蹲。
- Limitation 有一条很硬：任务状态是全观测的 object-centric，且无法排除预训练见过 benchmark 代码。95% 这类数字，得带着这条读。
下一根钉子
预算敏感性曲线。把 20 美元翻到 40，分数怎么走——要是 40 美元能买到 95%，「编译规划」就是一级可以花钱买通的台阶；要是只买到 84%，瓶颈就在探索结构上，加钱没用。论文没做这组实验，留给下一个团队。