用 Codex 把老模组拉到了现代版本

最近突然想和朋友们一起玩Minecraft，基本上大家都是在1.6-1.7这个游戏模组生态爆发时代的玩家，想玩的也都是老项目了，不可避免的遇到了一些还在更新而另一些基本是完全停滞/中止开发了的问题，于是尝试干了一件挺有意思的事情：把一些大家想玩的很老的 Minecraft 模组，比如暮色森林、拔刀剑，还有一些和风相关的模组，尝试在最新的1.21.1版本里跑起来，而且当然不能是只是能启动，是能正常玩、还能一起用的那种。

自己慢慢改体验太差了而且肯定不符合我和朋友们性质偶尔上来想怀个旧的需求（等自己改完大家早都不想玩了）所以我这次让 Codex 直接接管这项工作，看看目前它能做到什么程度，一开始很担心，因为跨版本迁移基本得变成重写工程，尤其是 Forge 那一套东西换来换去之后，很多老代码直接就是“时代遗物”，连编译都过不了，AI上下文长度和能力又有限，不确定会不会做没多久就得疯狂撞墙，不过还是觉得有必要试一试。

一开始就是把准备玩的版本，不兼容的模组们，尽可能齐全但是过时的依赖和目标丢给它：

然后开 agent 模式，让它自己往前推。

最开始的阶段其实挺像一个人类开发者在熟悉项目：扫一遍代码、看用的 API、找原始项目仓库，标出哪些地方肯定会炸，改改测试下哪些确实炸了等，基本全中枪，事件、注册、渲染相关的东西几乎都得动。

真正关键的一步，是它决定走 Forgified Fabric API 这条路。

这个选择其实挺聪明的。与其硬把 Forge 的东西一条条改成 Fabric，不如找一个“中间语言”，让旧代码有个可以落脚的地方。Forgified Fabric API 在这里就有点像一个翻译层，把老的调用方式接到新环境里，不过想要放上就能用还是差不少工作量的。

AI没有直接去“重写模组”（不过也不能完全这么说，但是至少没有全量重写），而是开始生成一层类似补丁的东西，大部分适配逻辑被挪到了外面。

比如一些已经不存在的 API，它会在 bridge 里补一层实现；
一些注册方式变了的地方，就在中间做一次转发；命名空间打架、资源覆盖、Mixin 冲突、甚至 classloader 级别的问题也不用靠人肉一个个修了，Codex 在补丁层统一处理这些差异，等于是把冲突往外隔了一层。

整个过程大概跑了五个小时左右。

我这边其实没怎么写代码，主要是在做测试——
能不能启动、哪里崩了、哪些功能缺失跑起来不对了。

每次把问题描述给它，它基本都能自己找日志，定位问题然后改。我只负责说“这里不对”，它就继续往下修。到后面其实也就挺顺的了只要不是具体到精确操作的测试，进图这种codex自己就能自动跑，基本进入一个循环：启动 → 崩溃 → 扔日志 → 修 → 再来一次。

直到最终，它真的跑起来了达到了既定目标，暮色森林能进维度，拔刀剑能正常挥，和风那套东西也没有乱。

这件事做完之后，我最大的感受其实不是“效率提升了多少”，而是整个问题的性质好像变了。以前这是一个很重的工程问题，需要人去理解每一个 API、每一段逻辑，然后一点点改。

但这次只需要我一个对代码世界理解很浅的人去“引导一个系统去完成迁移”。

我只需要：

• 给它目标
• 告诉它哪里不对
• 决定整体方向

至于具体怎么改代码，它自己会去找路径。

还有一个挺明显的变化是，“补丁层”这种做法比直接改源码舒服太多了（就是不太符合之前的模组更新逻辑，但是确实是契合了我们想要朋友间玩玩的目的）。

源码保持原样，兼容逻辑都在外面，一方面好维护，另一方面也更容易复用。

如果说有什么遗憾，大概就是这个过程现在还不算完全“傻瓜式”。还是得知道大概在发生什么，不然很难判断它是不是在往正确的方向走，而且我发现AI挺喜欢偷懒的，动不动就想要重新定义目标把本来你让他适配的模组禁用掉直接达到能跑/让用户自己换旧游戏版本。

总的来说还是挺有意思的体验。

有点像在做一件本来应该很麻烦、很耗时间的事情，但现在只要站在旁边不断纠正方向，最后AI会替我把事情做完。

这比“把老模组跑起来”本身更让人感慨，算是感受到了Agent的能力了，比之前对着3.5聊天找思路和自己试错的时候进步真的太多了。

不过嘛，最终因为想玩的模组突然又变多了而AI修起来又要加5-10小时的工作量，我和朋友们最终还是选择了用旧版本游戏来玩了，不知道这算不算我再次辜负了AI的一片苦心让它白费了一番功夫。

以及这篇的草稿也是5.4帮我打的，自己从头组织语言还是太困难了，只是做个记录我就不去追求写出多么富有人味感天动地的文章了。

另外如果你感兴趣，prism的游戏包我放 这 了（如果你有度盘会会员，那就是 这 ），我们最终放弃继续扩张的整合包，你可以玩玩看，不过就不提供任何提出BUG的机会啦x