先说结论：这篇《FORGE》最值钱的地方，不是它提出的那个框架，是它自己承认的一句实话——局部合理的修复代码，救不了互锁装配。
标题我多看了两眼。Fault-Oriented、Executable、Interlocking，三个限定词叠在一块，第一反应是又一篇定语加满、正事没说的 cs.AI 投稿。这类标题我一周能刷到十几篇。
这次是我判断错了。
Executable 在这儿不是装饰。它说的是：返工程序最后必须把一个受约束的装配状态带回经过验证的正确配置，不能停在“看着像修好了”。
这条要求立得住。
反过来看，这也正是绝大多数「AI 写代码修复」演示最不愿意面对的约束。报错贴进去，模型吐一段补全，跑通，剪进视频，收工。至于装回去之后整台东西还能不能拆、下一步动作走不走得通，没人提。
它把翻车方式讲清楚了
论文列了三种失效。我原样复述一下意思：修复程序看起来局部合理，但把阻塞依赖关系破坏了；或者漏掉必需的恢复步骤；或者跑完停在一个错误的状态配置上。
这三种，一句“模型代码能力不够”解释不了。
真正的原因是，模型根本不知道“装回去”在互锁装配里意味着什么。
写代码这件事，模型早就会了。真问题是：一个拆卸动作会改掉哪些零件之间的可拆路径？装回去的时候，这些路径还能不能重新走通？
这是状态空间里的可达性问题。不是补全一段语法正确的函数就能解决的。
作者把任务定义成「以故障为条件的可执行返工生成」。干净：模型要同时推理结构性失效，还要生成能把状态恢复正确的程序。
干净到我读完第一遍就在想——定义这么清楚，后面大概率拿不出同等分量的方法。
结果没猜错。
两阶段拆分，是工程上的习惯做法
FORGE 把返工生成拆成两段：一段叫返工结构化，负责刻画故障引发的恢复依赖；一段叫动作落地，负责把依赖关系转换成以状态为条件的可执行动作。
说白了，先想清楚要恢复什么，再写出怎么恢复。
FORGE-Bench: 4000 tasks / 26 类互锁装配结构 / 其中 5 类 hold out
框架两阶段: 返工结构化 → 动作落地
版本: v1 2026-11-02 / v2 2026-11-10
这个拆法本身有道理。但我不打算把它算成方法层面的贡献。
“先规划再执行”这个说法比大模型本身还老，搜一下就知道。八位作者署名的论文，拿一半篇幅给一个 pipeline 的两个阶段各起一个名字——这届文案的常规操作，算不上创新。
真正花功夫的地方在 FORGE-Bench：4000 个任务、26 类互锁装配结构。这种活又脏又累，跑起来也不上镜，但它是别人能接着往下踩的那块地基。
这笔账里有一处我不满意：26 类结构，留 5 类做未见结构的泛化测试，不到两成。而且这 5 类是怎么挑的，我目前没看到交代。
要是挑的正好是最简单的那 5 类，「泛化到未见结构」这句话的分量就得打折。
这条我还没查完，先别信我这半句。
隔了八天，第二版就上来了
11 月 2 日提交，11 月 10 日出第二版。八天两版这种节奏，通常说明第一版被审稿人或同行指出了问题，正在补。这不是坏事，比挂上去半年不动一下要好得多。
顺手扯句题外话。上个月我看某个工具的 changelog 写着「重大更新」，点进去发现只是改了个弹窗文案。看多了那种东西，再看一篇八天就更一版的论文，反而觉得踏实。
但这篇有个我没法验证的短板。
摘要层面，恢复成功率的数字没露出来。
一篇以 benchmark 为核心资产的论文，最关键的那个百分比如果只躺在正文表格里，读者就只能信它给出的定性结论——那句「仅生成局部合理的修复代码无法可靠完成装配恢复」。
这句话我信。三种失效模式摆在那儿，逻辑上说得通。
可「无法可靠完成」里的“可靠”是多少？60%？还是 12%？
差一个量级，这句话的锋利程度完全不同。benchmark 类论文把最要紧的数字藏进正文深处，读者只剩“信”或“不信”两个选项，那这面照妖镜就只能照到一半。
锐评评分卡
这时间值不值得花？
值得，但得挑着看。
FORGE-Bench 的构造方式、26 类结构的划分、5 类 hold-out 的设计思路，这部分值得仔细看。它是这篇论文真正沉下来的东西，也是别人能接着用的东西。
至于那个两阶段框架，读个摘要就够了。剩下的是拿标准的学术表述，把工程上的习惯做法重新包装了一遍。
「颠覆性」？这稿子里本来就没这个词，我也不打算替它加上。它老老实实承认了“局部合理没用”——在一堆把 demo 剪成科幻短片的投稿里，这已经算克制的了。
下次再看到标题里限定词叠满的 cs.AI 投稿，我还是会先划走。
但划走之前，会多看一眼它有没有自己的 bench。