讨论 关于近期B站很火的Forbric加载器的个人观点

[公孙芳芸]

[MD] B站视频（非广）：https://www.bilibili.com/video/BV1wSaR6gE5F 仓库链接：https://github.com/Ray-T-r/Minecraft-Forbric-mod-loader 原文如此：https://github.com/Ray-T-r/Minecraft-Forbric-mod-loader/issues/39 实际体验：https://github.com/Ray-T-r/Minecraft-Forbric-mod-loader/issues/59 --- ### 事先声明： - **本人仅对此项目提出建议和作出评价与批评**，并详细探讨本项目的相关内容，同时依据个人对于各个游戏的Mod开发与ML开发的微薄见解进行下列评析 - **无脑攻击任何一个项目都是不合适的**，应该依据某个项目"做了什么"和"做不到什么"与'"没做什么"等去多维度评价项目，即便项目开发者的作为可能令人不适，项目的实现效果可能不尽人意，也请先论事再论人，这二者不是对等的关系，并且如果项目实在一言难尽，可以先品鉴完再开骂，无脑的直接开团放在任何场合任何情况下都是不合适的 - 若项目开发者或者其他的路人看到了这份帖子，**请不要使用AIGC内容去进行回复**，否则一律无视，请自行组织语言去思考与回复 - **本帖子下的后续讨论会补充/追加一些关于本项目的分析内容**，可以在看完主帖子后再看后续的细化讨论，且会随着事件进展不断发布新讨论和修改主帖子的内容 - **请不要回复无关的内容**，这会导致有价值的反馈和讨论被淹没 - 如遇到了不适当或显著违反MineBBS规则的回复，**请在回复中寻找举报按钮并进行举报** --- 首先，这个项目的初心是好的（~~但是初心好≠做的好，想扣帽子的请看完后文再给我扣帽子~~），也就是尝试对当前分裂的JEML社区进行统一，但是有很多问题都需要斟酌，我会分成多个维度去说： Mojang以及Microsoft对于社区ML的态度一直都是不明不白的，只不过近年来出现了松动的趋势及相关行为，但是纵观全局来看，二者其中任意一者从未表态过支持ML对于游戏的修改行为甚至对于ML本身的开发行为，Forge自从2009年起立项，Fabric自从2018年起立项，全都是社区自发进行的，Mojang没有任何官方的API，只是把混淆后的字节码摆在那里让社区自己逆向（后面推出了映射表让社区看得懂），Mojang并未起任何的承诺，包括每次的Minecraft版本更新，也是社区神力同步推进更新，而Mojang却还是什么都不说（正如DeepSeek V4 Pro在八月灰测时期表现如此强劲，0813正式上线实测评价为拉完了，人们都在骂DeepSeek，但是它却并未承诺过什么，即便是出了问题，社区也只是无处出气），只是一种类妥协的态度，但还是不对ModAPI进行任何背书行为 再来说说Minecraft游戏本身，Minecraft拥有几十个Release大版本和数百个非Release版本，一个ML仅仅针对一个版本进行支持或针对一个小范围的版本进行支持，社区若有更好的选择，那么新的加载器到最后仍会被废弃，而ML进行跨版本兼容不是一件容易的事情，首先是ML自身数年代码沉淀导致的历史遗留问题降低了维护性，然后就是版本变动导致的签名更改以及其他各类关键变动也需要仔细斟酌，因此每个版本都需要小心维护才行，绝对不是随便写两笔就可以跨版本的，而这份工作若交给一个大团队去做，那么虽然很难，但是最起码能做完且做的"差不多"，但是如果交给一个独立开发者，并且还是对ML原理懂的不明不白的一个人去做，即便拥有Agent进行辅助编码，那么无论烧多少钱调用API都是不现实的，再强力的Agent目前（主力）只能做到本地静态分析与本地CI和静态测试，而针对复杂的动态调试行为是难以做到的，即便拥有computer-use技能也不行，这一步是必须要人工去做的，盲目交给Agent不可行，最终只能得到一个不明不白的项目，从头到尾许愿机，把自然语言进行编码，以此来维护一个巨大的项目，然后还不求进行全量测试，那么一辈子都上不了生产，只能作为一个玩具或者说值得研究的项目存在 那么说到这里就可以探讨这个项目本身了，这个项目正如上文所说，初心确实不错，但是过于理想化了，Forge/Fabric/NeoForge三者对于Mod的加载行为和对游戏本身的修改行为存在差异，我们可以从ML的字节码工具角度来分为两大类，一类是Fabric的Mixin，一类是Forge系列的ModLauncher+ASM，二者的修改形式不同，Mixin做的是编译时声明+运行时注入，可以对原始字节码进行高度的自定义修改，而ModLauncher+ASM则是在底层这一层面实现"替换"操作（即通过Java的底层API进行运行时动态修改），而如果连这些都不理解和测试，纯粹让Agent去算命，那就是纯粹的扯淡，没有任何的情面和让步空间可言，这不亚于DeepSeek的灰测模型那么牛逼是梁文锋给达里奥塞了可以窃取Claude思维链的刚赛 再说回来这个项目最大的问题在于不是Mixin没做好，相反做的还算是比较完善的，但是问题在于项目没有MixinEnvironment，这意味着这个项目不对Mixin进行动态测试，混入成什么样子就纯粹算命，炸了我都说它不响，扒拉源码可以看得出来IMixinTransformer是Proxy假实现，没有一点屁用，并且Agent进行本地测试的断言全是Mixin输入端（换句话说就是一点输出端测试都没有，纯粹的能跑就行思想），然后项目所用Agent的测试报告也说了方法冲突高达1000个，1000个是什么概念各位应该是清楚的，然后就是项目本身有118个Injector去兜底，但是Injector也没测试，这就好比给人装人工心脏不测泵血数据只测能不能泵血，装了个备用电源防心脏褒姒结果备用电源线没接是一样的，这也足以证明这个项目基本上是Full Vibe的，人工调试的痕迹是真没看出来有多少，Mixin对于ML而言重要性是极其大的，但是这个项目对最关键的东西不测试就很难绷了（我自己Review的时候给我自己都看的绷不住），到时候就是随机崩，加载期直接让Minecraft客户端飞起来，加载完成看Mod列表发现放进去四个Mod报出来八个Mod加载失败，然后用户直接原地眩晕瘫坐，不知道是破绷了还是似掉了 然后话说到测试就可以讲讲这个项目的测试注水问题了（还有第二关），这个项目的src/test中有263个文件是含assumeTrue的，而assumeTrue的意思就是Fail2Skip（JUnit SKIP行为，即测试条件不满足就跳过），Gradle本身把Skip行为当作测试成功，就跟你Github CI看起来结果是绿但是仔细一看是全Skip也算通过一样，也就是这个项目的CI测试和棍木一样，有测试但是有测试不太可能，再说有测试的部分，53个Gate和33个Canary还得Agent手动暴力跑，CI只去做Boot构建，测试分组乱的实在是看不下去，然后项目本身README也写了，构建成功≠能运行，那我寻思我BUILD SUCCESSFUL都信不过了我还玩个蛋，有时间用Forbric加载11个ForgeMod45个FabricMod和14个NeoForgeMod出了1919810个运行时错误还不如熬通宵边吃巧乐兹边喝雪碧然后第二天出去跑3公里COS张雪峰，自己的测试不但做不好而且还不保证可以顺利运行，若提到兼容性我可以理解，但是这本身就降低了Forbric的可信度不是吗 然后我自己也是做了加载测试的，单Mod严格成功差不多是88%的通过率，但是如果全混装直接0%通过率，在隔离后是86%的通过率（测试采用抽样测试的方法，涵盖多种类型对游戏本体进行修改的Mod，并且复杂度和加载器类型也不相同），那也是够神秘的了，这个项目自身的跨ML兼容特性就直接在测试中被证伪了，那用户的心情不亚于低价用到了GPT 6 Astra调用后发现是Qwen3 0.5B，一个看起来很牛逼的项目结果在测试阶段就砸掉了自己的招牌，那确实需要深思一下了（顺带一提，这个项目的Mod加载测试其实是面向结果编程，为什么这么说呢，举一个例子，Agent用Forbric加载了Mod.jar但是加载失败了，Agent就针对这一个错误去修，直到加载这个Mod不再报错，除非是实在修不了的才放弃，然后就这么针对其他测试样例进行迭迭迭迭迭迭迭迭迭迭迭迭迭迭迭迭迭代，项目本身所统计的89%成功率就是这么来的，也就是针对测试样例进行适配调优，但是这不代表所有的Mod都会像这一批测试样例可以在适配后加载，因为是个人类开发者都知道所有的Mod不可能都只用这一小部分测试样例所使用的API，这么做无疑是令人难绷的，那么项目自身对于这一部分的测试其实也就是棍木了 再说到ML本身，Forbric选了最难走的路，也就是兼容三加载器并做成独立的新加载器，选最难走的路确实可以体现出来技术的优势（源码也确实可以看得出来），但是这么做不亚于为了让自己爽一爽低价约了个生化母体完事褒姒一样，也就是只考虑自己”要做什么“和“做什么有什么意义”，而不考虑更长远的东西，目光实在过于短浅，那么话说回来，这个项目本身存在三大问题： 第一是维护性，上面也说了，这个项目基本上就是纯抽奖机，我不管项目开发与维护用的是什么LLM，豆包也好Claude也好，你自己不去Review不去动态测试不去深挖问题不去考虑复杂边界情况不去做DaaU（Developer as a User）工作，那么就注定了这个项目上不了台面，也就是让玩具项目走进生产环境的唯一大门就这么被自己焊死了，如果是小项目这些工作偷偷懒可能就算过去了，但是这个项目200K行的源码你不做上面的工作不亚于偷天换日给别人当日本人整，建议自己买点瓜子给自己吃 第二是兼容性，上面我也说过，开发者自己也测试过（虽然更多是Agent做的），显然这个兼容性是一大坨，而且远比测试所报告的要离谱，举个例子，10月2日我在某个QQ群看到有人用Forbric加载自己常用的127个纯FabricMod都直接炸了，那么还有什么可说的呢，连单ML多Mod都能炸更别提跨ML加载不同Mod了，甚至我在测试的时候发现NeoForge分支的钠在Forbric还需要Fabric API加载（好小众的文本组合），然后Fabric API还不兼容Forbric一加载就爆炸，这么搞有点令人难以理解了，测完大脑皮层变光滑不说血管还爆了几根 第三是持续性，结合到我上面说的跨版本问题而言，再看看这三个加载器的老屎山，虽然是屎但是都是经过时间校验的屎，其相关特性都可以得到保障，而这个项目把三坨屎搓成一个大屎（本身一坨屎就够让维护者飞起来了，三坨更是超级叠叠乐），那么相关特性可以说是完全不信任的状态（不亚于自签SSL证书拿去给自己的网站搞HTTPS然后用户端的浏览器直接原地红温），并且暂时还锁一个版本而不是容纳一定范围的版本，这就注定了这个项目最终会死亡的结局，维护难度不亚于从沙子手搓单晶硅造芯片，如果后续要保证项目不死亡，这就不是钱不钱的问题，而是个人精力和可实现性的问题，前者是有限的，后者更是复杂，可以牵涉到生态，兼容，理念，路径等等一大堆问题，反正依据我的个人观点来看，最后这个项目大概会火一阵子然后开发者+钱包+项目三个一起褒姒了 然后再把视野放宽一点，这个项目的本心是给社区ML统一，但是做出来的事情反而是分裂社区ML，因为它本身就是一个新的ML，到时候就变成了三个稳定社区ML和一个四不像ML，Architectury做了开发层统一，Sinytra Connector和Kilt做了运行时兼容，但是Forbric两个都不占还引出了新问题，这也需要好好反思一下了，统一反做分裂事，收益负大于正 最后我做个总结，这个项目本身实力确实有，内核也是真东西，但是测试不充分，兼容性极差，维护许愿机，不在意社区，这几条直接给这个项目踹飞了，项目本身可以做出来当实验性项目探讨新的兼容路径或者优化现有的兼容路径，但是绝对上不了生产且只会永久停留在当前这个阶段，并在之后被掩埋在时间之中 [/MD]

 

[公孙芳芸]

[MD] 人工看了3小时的源码和进行了相关测试，并少量结合Agent工具进行内容整理，最后花了1小时自己给写出来了（~~写力竭了~~） 也许是真的闲的没事罢，居然能品这么一坨项目品那么久 [/MD]

 

[公孙芳芸]

[MD] 先前看了一下[PR #47](https://github.com/Ray-T-r/Minecraft-Forbric-mod-loader/pull/47)，感觉修了个棍木，这个PR承认了滥用assumeTrue导致测试注水，并且量化了具体的注水成分，并且也加了加Ratchet和RED control，这几步本身是没什么问题，尤其是Ratchet把"测试结果模糊"变成了"测试结果清晰"是较为合理的一步，但如果把PR和本issue对照一下就可以看得出来问题所在，本Issue的核心是三条，第一是滥用assumeTrue导致测试注水，第二是Mixin最关键的输出侧是没有测试的，第三是Gate/Canary不在CI，而[PR #47](https://github.com/Ray-T-r/Minecraft-Forbric-mod-loader/pull/47)只是回应了第一条的问题所在，最严重的第二条屁都不放一个，第三个也很严重但只是提了一嘴不过并没有任何的作为 再说回来，PR自己写得也很清楚，原文为```"This does not make the skipped tests run. It makes the number public and stops it from growing silently. Running them in CI is a later PR."```，也就是说它修的是"数字不透明"而不是"测试不跑"，修的是最容易修的一条而绕开了最重的一条，这无疑是一种避重就轻，Ratchet让1010个Skip确实是公开了，但最为关键的Mixin完整测试依然屁都没有，仅仅进行静态输入测试，谁都不知道黑盒里面有什么，这一条是ML的命门同时也是一票否决这个项目可以上生产的关键点，而不是拿着数字摆出来透明度的问题，另外PR的4个commit全部Co-Authored-By: Claude Opus 5.5，描述结尾挂“🤖 Generated with Claude Code”，这我实在是没法说什么了，反向给自己证明全Vibe Coding了这是（谁家AI全权维护项目） 总的来说，Skip Ratchet是好的第一步，但是没有做到点子上，这不亚于选择性承认自己的错误所在并进行有限的改进，但是也就止步于此了，综合评价给到NPC [/MD]

 

[公孙芳芸]

这个项目似乎还是用的Kiro渠反代出来的Claude Opus 5.5降智版制作的，注释我是基本都看了一遍，就是对着源码做翻译，没有一点的深度可言，真正的注释应该解释特定源码块"是什么/不是什么""该做什么/不该做什么"和"边界是什么/需求是什么/注意点是什么"等，而这个项目它的注释就如同"这个功能是这样的，它定义什么发送什么接受什么"这样做翻译，写了一大坨的注释不知道干什么吃的，感觉如同看文言文和白话文的互相翻译，枯燥无味

更别说注释块乱插入的问题了，注释块和代码块在正常生产实践中应该是对应的关系而不是混乱排列的关系，它这种源码里import插一块，特定功能插一块，类里面外面，方法里面外面再插一块，乱的令人头大，写大体量注释本身是好事，可以让人类维护者知道源码有什么并且也知道踩了什么坑等，这样可以方便人类维护者接手维护，但是这个项目的注释就是纯粹的乱，并且内容质量极其低下，人类维护者看了之后还不如看源码，结果发现看了源码也看不懂，属实是气笑了

总结，如果维护Forge系ML的开发者是在品味巧克力味的屎，维护Fabric的开发者是在品味屎味的巧克力，那么维护Forbric的开发者则可以品尝到真正的屎

 

[公孙芳芸]

[MD] 项目开发者更新了[README](https://github.com/Ray-T-r/Minecraft-Forbric-mod-loader#forbric)，通过本Issue承认了一些问题所在，但是也仅限于承认，如果找不到真正的原因终究还是上不了台面的，同时本项目疑似构成虚假宣传问题，从本Issue发布后才承认自己的仓库是实验性的（参考原文```"This is a research project at version 0.3.0. There is no support, no roadmap"```），但是可别忘了原视频自始至终可只字未提与实验性相关的言论，不过视频已经发出去了且影响已经有了，别人看到的是Forbric这么牛逼，但是拿到手实操却和预期完全不一致，综合评价我只能给到拉完了 [/MD]

 

[公孙芳芸]

[MD] 并且各位可以看看[仓库Commit记录](https://github.com/Ray-T-r/Minecraft-Forbric-mod-loader/commits/main/)（这里是地狱啊），如果是人类开发者配合Agent辅助编码工作，那么工作速度没有那么快，并且Commit Message也没有那么规整乃至刻意（如果真有一分钟六次Commit的人类开发者那么人类可能就玩几把蛋了），不过有一个更为合理的解释（也就是一直在提的一点）就是这个项目没有任何的人类开发者，全部靠远程微操让Claude自己编码，包括git/gh工作流甚至也是Claude做的，项目本身完完全全的就是Full Vibe，靠着统一JEML的噱头去博得视频与仓库的关注量罢了 [/MD]

 

[烤鱼之巅]

只能说地狱

 

[Amaruq·Illaujaq]

我没有特别关注这个项目，没有看过源代码，不对项目具体部分做评价，就说说这个概念吧。

这个项目出发点是好的，但还是先别出发。
加载器社区分裂确实是另玩家头疼的事情，但如果这个问题是能靠缝合一手就能解决，那么这个问题早该解决了——尤其是 Fabric 的这种设计，显而易见很容易被“嫁接”到其他地方。

很多开发者都只选择使用各种方式交叉编译，使用预编译，使用抽象层，唯独不选择直接把抽象层装到加载器上，显然这不是一个简单的工作。

或许高手憋了这么久就为了今天？
那还是很奇怪，89% 兼容率就足够奇怪了，这得是很好的抽象层处理才能解决好 Forge API 与 Fabric API 的注入冲撞与事件冲撞。

89% 这个兼容率，相当于解决了 89% 的 Forge Event Joinpoint 与 Fabric Event Listener Point 之间的冲撞。
如果是拿一堆没有任何事件的小模组来测试的话，这种小模组随便来一位会 Java 的开发者就能移植有这种跨平台加载器存在的意义吗？
这种注水测试没有台上台面的必要性。

说实话，就假设他其实没有测试注水，他真的达到了 89% 兼容率，这 Hooks 与 Plugins 恐怕已是 Java 阿鼻地狱，是疯狂的黑魔法教授正在释放强大且禁忌的黑暗魔法，是后无来者的地狱风暴。
请法师回到地狱吧，地球真的会被毁灭的，求求了。