上周在 arXiv 刷到一篇编号 2608.14490 的论文，讲一个叫 Twin 的测试时世界模型推断系统，场景是那种规则和目标都不告诉你的网格游戏（ARC-AGI-3 一类的持续学习任务）。183 个关卡清了 179 个，通过率 97.8%，其中 158 关比人类玩家玩得更省事。分数本身已经很好看了，但我想记的不是这些，是它处理“模型预测错了怎么办”的那套机制——因为这套思路可以直接搬到我们用 Claude Code 干活的流程里。
先拆开看看 Twin 在干什么。它不是给每个游戏手工建模，而是让一个前沿编码代理在玩游戏的过程中生成一份可执行的世界模型——一份能跑的代码，不是一段自然语言描述。关键在后面两步：第一，它在一个孪生世界模型里做回放验证，程序必须先完整复现出之前所有观察到的游戏状态转换，才被允许执行新的动作；第二，一旦世界模型预测的结果和实际动作结果对不上，每一次不一致都会被当成一个反例，拿去修复这份世界模型。
我盯着这两条看了挺久。这个“先复现全部历史、再走新动作”的约束，本质上就是把“生成”和“执行”之间那个介入窗口写死在了机制里，而不是靠人自觉。之前我记过另一篇笔记讲迁移脚本要生成和执行分开，当时是靠自己在中间手动核对，这次看到的是同一件事的自动化版本：复现历史就是核对，核对不过就不放行。
对应到日常用编码代理，我试了一下最朴素的一版照搬。让代理先写一份它对当前模块行为的理解（输入什么、返回什么、有哪些副作用），然后写一个回放脚本，拿现有的调用记录去跑这份“模型”，对不上的地方让它自己修，修到全绿才允许动真正的代码：
1. 让代理生成 behavior_model.py（它对现状的理解）
2. 准备 replay_cases.json（历史上真实发生过的输入输出对）
3. 跑 pytest replay_cases.json 驱动的断言
4. 有失败 → 把失败案例作为反例喂回去修模型
5. 全部通过 → 才开始写新功能
顺序很重要，第 4 步修的是那份“理解”，不是直接改业务代码。我一开始把这两步混在一起了，让代理看到失败就顺手改代码，结果等于跳过了整个验证环节，白做。这个坑我也是绕了两次才躲开。
回到论文本身，还有一个对比数据值得单独拎出来。同一个基础模型，裸着去玩这些游戏，得分 7.8%；套上现成的测试时框架，61.1%；换成 Twin 的世界模型方案，93.3%，25 个游戏完成 23 个。7.8 到 61.1 那一跳说明框架有用，但 61.1 到 93.3 这一跳才是我想说的：真正拉开差距的不是“多试几次”，而是让代理对环境持有一份可执行、可被证伪的信念，并且每次被现实打脸都拿来修这份信念。裸模型缺的不是推理能力，是对世界的一个可以被反例纠正的描述。
论文里还有一条作者的观察，我个人觉得比那些通过率更有意思：他们说构建一个能用的世界模型比预想中简单，真正难的是推断游戏的目标是什么。Twin 的解法是在 156 个已清除的关卡上（约 87.2%）在拿到任何奖励之前就先把目标推了出来，剩下的关卡靠搜索兜底。这条对写 prompt 的启发很直接——我们平时让代理改代码，默认它知道“要改成什么样”，但目标描述恰恰是最容易含糊的部分。世界模型好建，“这次改动到底为了什么”不好讲清楚。所以现在我在任务开头多加了一句，让它先复述“这次改动的目标是什么、改完长什么样”，确认没跑偏再动手，算是把 Twin 里“先推目标再行动”那一步偷过来了。
顺手把那个 0 到 100 的评分方式也记一下：它同时衡量完成度和行动效率，对比对象是第一次玩这个游戏的人类玩家。也就是说 97.8% 的通过率不是刷出来的——158 关比一上来的人类玩家更高效，这个基准不算放水。
有一处我得老实交代：论文里“每次不一致都作为反例修复模型”这个循环，收敛性到底怎么保证的，我翻了原文也没完全看明白——是不是存在修了 A 坏了 B、反例之间互相打架的情况，文中没有展开到我满意的程度。这里我也没完全搞懂原理，但“反例驱动修复”这个方向本身，在我自己那个小实验里确实跑通了，先记下来，这条记下来了，下次应该用得上。
划重点：第一，Twin 的核心不是模型多强，是“先复现全部历史再执行新动作”这个硬约束，它把验证从自觉变成了机制；第二，预测与现实的每次不一致都是修模型的原材料，别浪费在“重试一次碰碰运气”上；第三，比世界模型更难的是目标推断，任务开头让代理复述目标这一步值得固定下来。你可以挑一个自己正在改的模块，今天就试试上面那五步的迷你版，跑通了或者踩到别的坑，欢迎回来留言，我一起补一条笔记。