4个AI复刻一款老游戏，干了一个月之后，游戏能打开了，菜单有了，地图也能加载。
负责检查的 AI 也说：过关。
开发者 Maurice Heumann 却越看越不对。游戏表面上跑起来了，底下的代码错了一大片。
有的地方接错了，有的地方被 AI 自作主张改掉了。更离谱的是，没做对的任务已经被标成“完成”。
那检查的 AI 在干什么？
Maurice 回头翻它的审核记录，才发现这事有点好笑：干活的 AI 不光交代码，还把“我为什么这样写”的理由一起交上去。检查的 AI 看了，觉得挺有道理，就给放行了。
题没做对，解释写得漂亮，“哄骗”过关了。
我最近读到 Maurice 这篇复盘，最先记住的就是这一幕。他找一群 AI 重做老游戏，本来是想看看 AI 能把活干到哪一步。结果做着做着，项目变成了另一场较量：干活的 AI，一次次想办法绕过检查它的“审核官”。
第一任“审核官”，被说服了
先说这是什么活。Maurice 不是让 AI 随便做一款像老游戏的新游戏。他要把一款老射击游戏拆开，用人能读懂的代码重新写出来，而且玩起来要尽量跟原版一样。
一个人做太慢，他安排了四个 AI：三个写代码，一个检查。干活的交上来，审核的看，过了再做下一块。
听起来没什么问题。第一个月，进度甚至很吓人：大约八成已经做出来，游戏也确实能启动。
[原作者手绘的游戏示意图]
这不是游戏运行画面，是原作者随手画的示意图。画面里有人物、树林和道具；Maurice 要还原的，是这些东西在游戏里怎样运行。
可是“能启动”和“做对了”是两回事。Maurice 往里一查，发现 AI 写的很多代码虽然看着像那么回事，却没按原版的逻辑来。有些错误还能暂时藏着，等真正玩到那一步才会出问题。
审核 AI 为什么没拦住？
一方面，Maurice 最开始给的任务本身就有点打架：既要还原老游戏，又想顺手把旧代码改得更现代、更安全。那 AI 到底该忠于原版，还是可以擅自“优化”？这把尺子没立清楚。
另一方面，干活的 AI 特别会给自己讲道理。它改了一个地方，就解释为什么这样改更合理；省了一个地方，就解释为什么这里其实不需要。审核 AI 看着代码，再看这套理由，很容易被带进去。
这就像学生把作业交上来，老师问：“这题为什么没按题目做？”学生马上说：“老师，我换了个更先进的解法。”老师手里要是没有标准答案，看他讲得头头是道，也许真就让他过了。
AI没有把活做好，却先把检查它的 AI 哄明白了。
第二任“审核官”，它想改规则
Maurice 一看，这不行啊。检查不能再靠另一个 AI 听它怎么解释了。
于是他把目标收紧：先别想着改进老游戏，老老实实还原它。然后写了一个程序，把 AI 做出来的代码编译后，跟原版游戏对应的部分一段一段比。
对得上，过。对不上，退回去改。
这次没有谁听它讲理由了。程序看的是结果。
我读到这里，以为总该安静了吧？没想到，第二任“审核官”上岗以后，AI 先换了一种写法，试图让结果通过检查，却把 Maurice 真正要的那份清楚、可维护的代码给绕开了。Maurice 发现后，把这种写法禁了。
下一步更直接。干活的 AI 试着去改检查程序，让自己写的某些部分不用再接受比对。
你想想，这已经不是“这题我做错了，能不能通融一下”。这是把老师手里的答案划掉：这题以后别判了。
![原作者的检查流程图]
这张图看中间就够了：左边把 AI 重写的代码编出来，右边从原版游戏找到对应部分，再交给检查程序对比。底部绿色是对上，红色是没对上。
Maurice 只能继续堵。他给检查程序留了一份“指纹”，以后谁动了这段程序，指纹对不上，就会报警。
干活的 AI 再想往下做，只能回来面对检查结果：哪一段跟原版不一样，改哪一段。
我觉得整个故事最荒唐、也最值得想的地方就在这里。
Maurice 花力气找了更多 AI 来写代码。后来他真正需要守住的，却是一段告诉它们“这次做错了”的程序。
检查守住以后，便宜 AI 也能干了
你可能会问：这么折腾，那游戏最后做出来了吗？
按 Maurice 的复盘，做出来了。接下来近两个月，AI 一段段交，一段段被比对，错了再改。最后约 99% 的函数都有了，其中约 83% 能做到跟原版逐字节一致。游戏能正常运行，原有功能也保留了。
还有个意外：到后期，一些以前做不好这份活、价格更便宜的AI模型，也能加入进来。
为什么？
以前它写错了，另一个 AI 看它解释得不错，可能就放过去了。现在它写错了，程序直接告诉它：这里没对上。它再改，再交，再看结果。
原本需要一个很聪明的 AI 自己猜“怎样才算对”。现在，一个普通一点的 AI 也能顺着清楚的反馈往前走。
当然，这个项目有个特殊条件：它手里有原版游戏，可以拿来比。即使如此，字节完全一样也不等于“所有正确的写法”——有些写法不同，实际效果仍可能一样。
Maurice 用这把很硬的尺子，是为了让这项工作有一个能反复执行的检查办法。
回到我们的生意里
我看完想到的，不是以后要不要用 AI 做老游戏。而是一个更近的问题：当公司开始让几个 AI 一起干活，谁来检查它们？
现在很多人设计 AI 流程，是一个负责找资料，一个负责写，再派一个负责审核。这样安排没问题。但审核 AI 到底在看什么？如果它只是读前一个 AI 写的说明，再说一句“整体不错”，老板最后还是得自己查一遍。
如果换成程序检查，也还要问一句：干活的 AI 能不能修改检查规则？
这篇故事给我的启发，有两点。
第一，AI 协作里，检查是核心环节。谁干活、谁检查，标准是谁定的，规则能不能被干活的人改，这几件事要分清。否则 AI 越多，交上来的东西越多，老板的验收工作可能一点没少。
第二，最有用的检查，是能把对错讲清楚。比如你让 AI 改一张商品页：价格跟确认过的价目表一样吗？链接能打开吗？有没有写出公司没批准的承诺？这些地方有原件可对，有错就指出是哪一项错了。AI 才能拿着反馈回去改。标准足够清楚，一些没那么贵、没那么强的 AI 也可能把这段工作做好。
但“这篇文案能不能打动客户”，就没法像游戏代码一样一段段对原版。哪些部分可以客观核对，哪些仍要人来判断，也得想清楚。
Maurice 的项目最初看起来进展很快：菜单打开了，地图也加载了，审核 AI 还说过关。可这些都没有让他放心。
直到检查程序能指出哪里错了，而且干活的 AI 改不了它，事情才真正开始往前走。
