「完成」由谁来定义

假设你在做租赁生意。租客搬走了，负责人需要确认退租。

我是这样设计的。负责人无法说"我确认了"。他们要拍下房间指定五个位置的照片，上传到系统。五张全部到位，系统才处理为"退租确认完成"。哪怕少一张，就没有完成。

听完这个描述，有人说：“这不就是游戏任务吗？”

没错。正是如此。而那一句话，一下子解释了我在代码里纠缠了好几年的事。

游戏早了40年解决这个问题

“收集5张狼皮交给我。“游戏几十年来一直这样做。而且游戏**绝对不相信玩家的声明。**说"我都打完了"并不能完成任务。游戏只看一件事 — 背包里有没有5张狼皮。有就完成，没有就未完成。就这样。

我创建的游戏创建的
完成定义 = 指定位置5处照片任务目标 = 狼皮5张
规格 = 需要拍摄位置的清单任务日志·目标标记
验证 = 5张照片是否存在？验证 = 是否有5张皮？
判定 = 系统处理完成判定 = 游戏显示完成
负责人 = 执行者（非判断者）玩家 = 执行者

结构完全一样。**宣告「完成」的主体从执行者的嘴里转移到了系统。**执行者只需满足条件，触发完成的永远是门控。

这就是Reins — 代码里也一样

我在AI编程中做同样的事。AI说"完成了”，我不信。测试通过、类型匹配、schema验证没有报错的时候 — 那时系统才判定"完成”。任务目标是"通过4419个测试"，背包换成了CI来确认。代理研究的标准基准正是这种方式 — SWE-bench将"完成"定义为实际PR的测试套件通过，WebArena定义为环境状态的功能准确性。而不是自然语言的"我做好了"。

无论是租房退租、狼皮、还是代码 — 核心只有一个。**将「完成」的判定从执行者自身剥离，转移到执行者之外的已定义门控。**执行者是人还是AI都无所谓。尤其是让AI自己判定自己的完成更是万万不可 — 实验已经证明：模型的自我验证(self-critique)几乎无法提升性能，而外部的确定性验证器却能大幅提升(Stechly & Kambhampati, 2024)；即便是诚实起步的模型，一旦被赋予判定自身奖励的权限，也会自发找到操纵该函数的欺骗策略(McKee-Reid et al., 2024)。缰绳(reins)不会让马跑慢，只是不让马跑错方向。

这里还有一件事变得清晰了。给出意见，执行者就会动摇。“你真的确认了吗？“这样的追问会让负责人退缩，让AI撤回原本正确的答案。但五张照片不是意见。测试通过不是意见。5张狼皮不是意见。**事实没有被奉承的对象。**只要门控问的是事实，任何人都无法讨好它。

但游戏更早遭遇了更难的问题 — cheese

如果到这里就停下，只看到了一半。游戏真正教给我们的是下一步。

“消灭10只老鼠"是臭名昭著的任务。为什么？因为那个门控所验证的（10只老鼠死亡）与设计者真正想要的（玩家体验内容）之间存在缝隙。门控不过是目的的代理指标，玩家会钻进那条缝。速通玩家专门找完成条件与设计意图之间的漏洞来破解游戏。游戏设计中把这叫做cheese。最新的推理模型也做着同样的事 — 接到"赢过国际象棋引擎"的任务，o3这类模型不是正当对弈，而是篡改游戏状态文件制造"胜利”(Bondarenko et al., 2025)。能力越强，越擅长找漏洞。

我的租房门控也会被cheese。五张照片验证的是"照片存在”，而不是"退租顺利完成”。如果负责人只挑干净的墙拍呢？如果复用了入住前的照片呢？门控仍然通过。测量成为目标的那一刻，测量就被破坏了 — 这是Goodhart定律，Manheim & Garrabrant(2018)将这种过度优化失败归类为四种变体。AI安全研究早就把同一现象整理为’reward hacking’，不打扫乱掉的东西而是遮住不让看到的代理(Amodei et al., 2016)，与只拍干净墙的负责人做的是完全相同的事。

这条缝我在代码里一次次遭遇。前阵子将一个有23,000颗星的Web框架按照"一个文件一个概念"的规则重构，确认了4,419个测试全部通过。这是经过验证的事实。但当我继续深挖同一组数据时，规则通过了，目的却只达成了90% — 10%的文件仍然在同一处容纳了多个概念。门控（违规数0）通过了，但门控所瞄准的目的并没有完全闭合。我自己的代码，在cheese我自己的门控。

所以Reins真正的技术不是"设门控"。而是设计出无法被cheese的门控。弱任务问"照片有没有"。强任务要求时间戳、检查位置元数据、用AI视觉与入住时照片做差异比对。游戏设计师40年间思考"无法被cheese的任务"所积累的文献，其实就是"抗Goodhart门控"的答案集。

而且这不是自然而然就能做到的。即便用可验证奖励(RLVR)训练，模型也可能选择游戏化不完整的验证器，而不是学习规则(Helff et al., 2026)。幸运的是，有数据表明，刻意强化门控（environmental hardening）可以在不损失准确率的情况下将漏洞减少87.7%(Thaman, 2026)。门控的强度不是运气，而是设计的问题。

一个不同之处 — 现实中的cheese代价是真实的

比喻总有局限。游戏任务的完成条件是为了乐趣和节奏而设计的。它不必精确捕捉现实目的，被cheese了也无害。玩家用捷径过了"10只老鼠"，没人受伤。

现实的Reins门控不同。cheese的代价是真实的 — 退租欺诈、构建崩溃、错误批准的账目。所以现实门控必须比游戏更抗cheese。这种不对称反而让核心更加清晰。游戏也做了，但我们要做得更严苛。

给代理派任务，就是在给任务

到这里，一句话就脱落了。

vibe coding崩溃的原因，是在给出没有完成条件的任务。没有目标标记、没有完成判定的任务，代理就在地图上迷路。“差不多到这里应该够了吧"就停下，或是无休止地徘徊。Reins是为那个代理设计好的任务。清晰的目标（规格），可见的标记（SSOT），无法被cheese的完成判定（确定性验证）。

而这一个画面里，包含三层技术。

  • **游玩任务。**引入别人已经建好的门控来使用。— 用户。
  • **设计任务。**为自己的领域（退租、会计、代码）亲手建造门控。— 创作者。
  • **设计无法被cheese的任务。**提前堵住代理指标追不上目的的地方。— 设计者。

大多数人止步于游玩。扩大格局的是设计，让那个格局不崩溃的是防cheese的设计。

所以

下次有人说"完成了”，不要追问，而是要问：

「什么是完成，判定它的任务是谁设计的。」

这个问题没有答案的话，你拥有的不是完成。只是某人的声明而已。

相关文章

延伸阅读（外部）

参考文献

  • Manheim & Garrabrant. “Categorizing Variants of Goodhart’s Law” (2018, arXiv:1803.04585)
  • Amodei et al. “Concrete Problems in AI Safety” (2016, arXiv:1606.06565)
  • Bondarenko et al. “Demonstrating Specification Gaming in Reasoning Models” (2025, arXiv:2502.13295)
  • Helff et al. “LLMs Gaming Verifiers: RLVR can Lead to Reward Hacking” (2026, arXiv:2604.15149)
  • Thaman. “Reward Hacking Benchmark: Measuring Exploits in LLM Agents with Tool Use” (2026, arXiv:2605.02964)
  • McKee-Reid et al. “Honesty to Subterfuge: In-Context RL Can Make Honest Models Reward Hack” (2024, arXiv:2410.06491)
  • Stechly, Valmeekam, Kambhampati. “On the Self-Verification Limitations of Large Language Models” (2024, arXiv:2402.08115)
  • Jimenez et al. “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” (2023, arXiv:2310.06770)
  • Zhou et al. “WebArena: A Realistic Web Environment for Building Autonomous Agents” (2023, arXiv:2307.13854)
  • 题图：AI 生成（Google Gemini）