娱乐 · 熟练
把《艾尔登法环》塞进《我的世界》，只用了四小时
不是重写引擎，是让两个游戏同时跑
2026 年 9 月底开始，游戏圈冒出一批看起来很离谱的视频：在《使命召唤》的图里滑板 · 哥谭上空荡索的蜘蛛侠 · 用 Minecraft 的角色去打艾尔登法环的 Boss。做法说出来很简单 —— 不是把两个游戏合并成一个，而是让两个游戏同时跑：一个负责设定世界，另一个负责操作与战斗，中间用一个直通式（passthrough）mod 把两边接起来。写这些代码的是 AI agent —— 你说需求、试构建、指出错、让它修，代码本身由它写。单次合并大概 3~4 小时，作者也承认第一版通常很糙。同时社区已经吵起来了：有 modder 直斥这是「slop」（AI 写的 hacky 代码，创作者自己看不懂也 debug 不了），也有人认为它真正推翻的其实是modding 的编程门槛。这一页把这件事拆成可复现的步骤，并写清它的能力边界 —— 哪些部分它真能做，哪些部分它做不了、得你自己接。
方法 · 一图看懂
1
先想清「谁管世界、谁管人」 — 双进程结构里，一个游戏提供场景与规则，另一个提供操作与战斗；这个分工定错，后面全乱
2
用「试构建 → 指出错 → 让它修」的循环推进 — 别一次描述完整个方案；每轮只解决一个可见的错误
3
把「能跑」和「能玩」分开验收 — 第一版能起来不等于可玩；手感 / 平衡 / 崩溃是第二轮之后的事
4
认下三条它做不了的 — 懂不了原引擎内部、改不了发行商的资源格式、也保不住你后面能不能维护
原理 · 为什么有效
为什么这条路突然能走通：modding 一直卡在人力成本上 —— 把两款游戏的运行时接起来，以前是熟练 modder 几周的活，现在变成「描述需求 + 调试几轮」的几小时。变的不是游戏引擎，是谁在写胶水代码。但要知道它的原理是旁路而不是融合：两个进程各自跑自己的世界与规则，AI 写的只是中间那层转移与映射。⇒ 三个直接推论：① 它不能创造原本不存在的能力 —— 想做的东西必须在某一侧已经实现过 ② 两边的状态不会自动一致（碰撞、物理、存档各归各的）③ 代码可读性差是结构性的，不是模型不够聪明 —— 这也是社区反弹的真正落点。
适用场景
适合：① 你想做的是「两个已存在的游戏/玩法之间」的桥接，而不是从零造一个游戏；② 你手上有能跑得动的机器（双进程同时跑，资源开销基本翻倍）；③ 你只是想玩、想拍点东西，接受粗糙的第一版。
⛔ 不适合：① 指望它替你改引擎、做真正的机制融合；② 打算长期维护、或要发布给别人装（第一版代码的可维护性很低，且涉及发行商授权）；③ 上线商用 —— 版权与 DMCA 风险是真实的，同批里已有视频因版权申诉被下架。
自测 · 5 问
我要做的东西，在某一侧游戏里已经实现过吗？（没有 ⇒ 这条路做不出来）
两个进程的资源开销我算过吗？（画面 + 内存基本翻倍）
「能跑」与「可玩」我分开验了吗？还是看到画面出来就以为成了？
我接受这版代码大概率看不懂、也不打算维护吗？
涉及发行商素材与授权，我知道这条线在哪吗？
怎么上手 · 验证步骤
上手路径：第一步先确认可行性 —— 找一段两侧都有现成实现的玩法（例如「在 A 的地图里做 B 里已有的机动动作」），别挑一个需要新机制的点子。第二步只做一件事：让两个世界同时起来、且能各自响应输入；这一步跑通，后面的映射才有意义。第三步再谈「怎么把 A 的输入翻译给 B」，一轮只修一个可见错误（画面糊了修画面、按了没反应修映射、崩了看日志尾巴）。第四步才是手感与平衡 —— 前面都过了再说。
自检动作：让 agent 把它写的中间层代码用一段话讲清楚「数据从哪来、到哪去、变了什么」 —— 如果它讲不出（或者讲出来你发现它自己也不确定），那这版代码你就没法维护，趁早决定「只当玩具」还是推倒重来。另一条更硬的验证：把两个游戏各关掉一个，看另一个能不能独立起来 —— 起得来说明结构清楚；崩了说明两侧耦合已经烂成一团。