Factorio 推荐MOD选择方法｜用途别框架

在 Factorio 2.0 过渡期开始安装MOD时，最不容易失败的选择方法不是"列出看起来流行的东西"，而是反向思考"自己在困扰什么"。
本文基于目前的 2.0 系进行写作，但请务必结合官方博客（Factorio Friday Facts / 官方博客）和 Mod Portal 的分发页面来确认 2.0 的正式规格变更点和 MOD API 的兼容性。
本文针对想从原始游戏中更进一步的玩家，或计划包含 Space Age 进行游玩的玩家，按用途整理 MOD 的思考方式。

我最初也是"看起来方便"就一口气装了10多个，结果启动出错了。
后来改成在新存档上只试1到3个 UI/QoL 类MOD之后，额外功能的稳定性立刻提升了。
导入的顺序是 UI/QoL → 建设辅助 → 物流·生产 → 改造类，这样比较稳妥。
在分发页面（Mod Portal）上务必先确认支持的游戏版本、依赖关系和最后更新日期。
关于"存档兼容性"，分发页面有时不会明确标注，因此强烈建议用 Discussion 或 Forum 的内容来补充信息。

Factorio 的推荐MOD应该按用途来选择，不容易失败

按用途筛选的优势和失败模式

Factorio MOD选择中不容易摇摆的轴线是"哪个最出名"不如"想让什么变得更轻松"。
比如，如果信息难以看清导致判断延迟让人不满，那就选 UI/QoL 类；如果想更快地展开和放置蓝图，就选建设辅助类；如果想减少基地内的移动和物流堵塞，就选物流·移动类；如果想掌握生产的瓶颈，就选生产管理类。
从烦恼出发思考，安装的MOD数量会自然地被限制住。
排行榜形式容易导致"因为流行就试试"的情况，但从用途入手的话，可以用"现在的我需要吗"来划分界限，游玩的核心就不会摇摆。

这种思考方式之所以有效，是因为 Factorio 的MOD即使是相同的"便利类"，使用者的层次也不同。
UI/QoL 类容易在操作和视认性上见效，不会大幅改变游戏进行本身。
而建设辅助和设计支援会相当大地改变基地建造的手感。
进一步到大型改造类，连配方结构和进行思路都会改变，已经不是"原始游戏的延伸"而接近于另一款游戏的玩法了。
如果把同样的东西都放在一个框子里作为"推荐MOD"来看，初学者向的轻度改进和熟练者向的大改造就会混在一起。

初学者容易犯的失误也来自这种混在一起的情况。
典型例子是仅凭"看起来方便"的印象就一口气大量导入。
我最初就是把看起来不错的、在海外话题里出现的、说明文吸引人的都一起启用了，结果在启动时就停住了。
追溯原因，主要是忽视了依赖关系、功能相似的MOD之间的冲突，以及最重要的是"没有自己搞清楚这个MOD到底改变了什么"。
同时装10个的话，出现问题时的排查视野一下子就变得极其糟糕。

相反地，每个用途只装1到3个这样的导入单位的话，故障发生率和理解的容易程度都会大幅改变。
只装 UI/QoL，或者只装建设辅助，然后观察游戏体验如何改变。
按照这个顺序的话，"变得方便了"的实感会非常清晰，也能立刻去掉不需要的东西。
特别是 Factorio 这款游戏，即使只是稍微改善视认性或减少操作，思考的流畅度也不容易中断。
仅仅 UI/QoL 的轻度导入，也能增加用于规划怎样配线、瓶颈在哪里、怎样展开蓝图的脑力余裕。
从我的体感来说，仅仅这个阶段工厂运营的压力就会大幅减少，火箭到达后常见的"有事要做但感觉像在干活"的停滞感一下子淡薄了。

这里重要的是把MOD看作是对游玩过程中卡壳的处方，而不是性能比较。
鼠标操作繁琐就选 UI/QoL，地块整理和线路重新铺设很烦就选建设辅助，想理顺列车和搬运的流向就选物流·移动，数字看不清看不出改进点就选生产管理。
这样切分的话，导入的理由就有了说法。
一旦有了说法，就不容易装过头的MOD，判断是否删除也会变快。

用途别框架和比较轴

即使按用途选择，仅靠分类还是太粗糙，实际上用4个比较轴来看的话会更容易整理。
这4个轴是学习成本、原始感、导入风险、扩展性。
用这4个要素来看的话，"我现在想要舒适化，还是想要新的游戏体验"就会变得相当清晰。

以下表格是在考虑导入顺序时的大致参考。

UI/QoL 类适合首次MOD导入。
理由很简单，要学的东西少，而且触碰的瞬间效果就容易看到。
菜单视认性、状态确认的轻松程度、细微点击次数的削减这类改进，都能在不破坏工厂设计思想的情况下见效。
原始感也容易保持，所以"喜欢 Factorio 本身，但想稍微舒适一点"的人很适合。

建设辅助·设计支援类在下一阶段见效。
这里便利度更大，和游戏的距离感会略微改变。
线路铺设和蓝图周边变强之后，单调工作会减少，但设计的节奏本身会改变。
如果把原始游戏的不便也看作一种风格的人，可能会觉得有点太周到了。
但如果有朝向大型基地发展的想法，价值就很高。
学习成本比UI/QoL类更高，所以为了避免"装了但用不来"，进一步缩小用途会更匹配。

物流·移动改善类是当基地开始扩大时容易提升满足度的领域。
减轻步行和物资搬运压力的类型，能提升整体游玩节奏。
不过这种类型容易影响工厂设计和路由的思考方式，装上的话前提也会改变。
"移动变舒适了"之外，容易感觉到"基地的组法也改变了"。

生产管理，也就是信息可视化类经常被忽视，但实际上是非常强大的分类。
Factorio 既是制造缺少物品的游戏，同时也是"看清缺什么的游戏"。
只是让生产量、消费、库存、瓶颈这类信息更容易读出来，改进的着手点就会更早显现。
这种类型原始感也容易保持，同时能提升思维的质量，所以实际上在 UI/QoL 之后试也容易满足，是个很安全的领域。

大型改造类是完全另一类。
这里需要的不是舒适化，而是新的学习体验。
配方连锁、资源处理、研究进行、必需设备的思考方式都会改变，比较的对象不是"方不方便"。
应该看的是"想解多少新问题""即使离开原始游戏也能享受多少"这样的轴。
大型类直接跳进去之所以危险，不是难度问题，而是期望容易偏差。
想要舒适化，结果实际上开始了难度较高的另一款游戏，这种偏差容易发生。

用这4个轴来看的话，初学者最容易接触的是 UI/QoL 类，其次是生产管理类，之后是建设辅助和物流·移动类，充分习惯后才是大型改造类。
这不仅仅是难度顺序，而是什么不改，什么改变的顺序。
从保持原始游戏乐趣同时舒适化的层开始，就能更容易看清对自己来说"MOD的恰好程度"。

版本和DLC的区分

用途选择的思考方式同样重要的，是最初就要区分开是什么环境的问题。
本文基于目前的 Factorio 2.0 系进行说明，但具体的兼容性和实现差异必须在官方博客（https://www.factorio.com/blog/）、Mod Portal（https://mods.factorio.com/）的分发页面和 Forum 的作者评论中必然确认。
是仅玩原始游戏还是包含 Space Age，MOD 的匹配度会改变。

Space Age 的有无特别重要，不仅仅是追加内容的差异，而是关乎进行设计和接触要素的重心。
作为原始游戏舒适化而优秀的东西，在 Space Age 环境下价值可能淡薄，反之 DLC 环境下恩惠特别大的分类也有。
所以在后续的推荐整理中，自然地分开"2.0原始游戏中想装的"和"Space Age 搭载状态下想考虑的"。
这不仅仅是兼容性问题，而是压力点会因游玩组成而改变。

追踪外部的一手信息时，这个区分也是前提。
比如分发源『Factorio Mod Portal』的中心是确认对应游戏版本和依赖关系，2.0 和 DLC 周边的规格改变的背景用『Factorio Friday Facts / 官方博客』看的话才容易抓到文脉。
原始游戏基本规格和用语的整理用 Factorio Wiki 的话反而追踪起来容易。
与其说看的地方不同，不如说确认想要的内容根据内容窗口不同的感觉。

这里要记住的是，版本标记和 DLC 前提不统一的介绍，即使内容看起来不错，作为判断材料也会很弱。
比如只有"方便""定番""流行"这样的评价，对想在 2.0 系上问题不出地运行的人，也对想和 Space Age 并用的人，都不是足够的信息。
我自己查找MOD时，派头的说明文之前先看"作为什么环境的话题被说的"。
用这个顺序的话，就能避免候选太多。

后续的章节也会一边分开2.0原始游戏适配还是应该考虑搭载 Space Age，一边整理。
仅用用途来筛选就能减少失败，但加上版本和 DLC 的区分，就能相当程度地防止"看起来方便但不适合我的环境"。

首先确认的MOD选择前提条件

对象版本·DLC的确认步骤

MOD 选择中最初要看的，不是功能说明而是这个MOD前提的游戏环境是什么。
本文的前提是 Factorio 2.0 系，但实际导入判断中需要区分"是否2.0适配"，进一步到"是否考虑搭载 Space Age"。
这个地方模糊的推荐文，即使看起来方便，作为判断材料也会变弱。

看的顺序很简单。
首先在『Factorio Mod Portal』的个别页面找到 Game version 标记，看自己的环境是否噙合。
其次不仅靠说明文和屏幕截图判断，还要看是否涉及 Space Age 前提的追加要素，还是作为原始游戏适配的调整来制作的。
DLC对应不仅是"能启动吗"，进行和UI前提是否噙合也要看，否则使用感会大幅改变。

2.0 过渡期，同一种"便利类"中容易混入以前的旧前提还留着的东西。
我也曾装过更新停了1年多的小型便利类，启动本身通过了，但警告增加了，过了一阵子在别的场景就不稳定了。
表面上看起来能动，但内部前提和现在的环境错位的例子并不罕见。
从那之后换到最新更新的别的MOD，同一用途也稳定得多了。

想先把原始游戏规格和用语整理到脑子里的时候，Factorio Wiki 派上用场。
2.0 和 Space Age 周边什么改变了这个背景用『Factorio 官方博客』追的话更容易理解。
MOD页面的对应标记只看的话，看不到"为什么这个MOD在现在的环境里容易摇摆"这种深层原因，追踪后就能串联起来。

依赖关系·兼容性的读法

对应版本之后最重要的是Dependenci的读法。
跳过这个的话，容易踩到"自己装的MOD看起来很有魅力，结合起来却动不了"这种典型事故。
特别是 Factorio 的MOD，有的独立完成，有的要靠别的库或前提MOD才能成立。

Mod Portal 的个别页面 Dependencies 看的话，能抓到这个MOD需要什么的入口。
这里要读的，不仅是名字一览。
什么是前提，什么影响相性要看。
比如看起来只增加UI显示的MOD，内部也许依赖别的共通部件。
大型改造类前提本身就大幅改变，周边MOD的兼容性连锁改变。

兼容性的看法中重要的是，不要把"有依赖"本身当成危险。
危险的是依赖的地方连带停更或前提版本错位这种状态。
也就是说，不是单独看一个MOD，而是整个小束要追的感觉。
便利系和建设辅助系，这个束通常比较小。
大型系的话一下子就重了。

这里派上用场的是『Factorio Forums』。
Mod Portal 的标记单独看，看不完已知不具合和"这个组合会出警告""Space Age 环境下一部分功能冲突"这样的实运用话题，这些在作者主题和不具合报告的流里面有。
特别是有在意的MOD时，看作者最近是不是在 Forum 上有回应就能大幅提高兼容性判断的精度。

依赖关系的确认实际上接近"风险地图制作"而不是"可否判定"。
读完之后，"这个能单独试""这个要搭配关联MOD考虑""这个在现在的构成里容易冲突"这样整理下来就够。
有这个视点的话，导入本数增加也不容易崩。

最后更新日期·维护状况的判断

MOD页面容易忽视的是最后更新日期的意义。
比起便利的说明文、下载数、定番感的名字，先看这个MOD有没有向现在的环境施加影响会更实用。
特别是2.0系迁移后，越是出名的旧MOD，越容易"名字是出名的，但更新间隔空了"。

Mod Portal 上更新日的确认是出发点，但单看日期不够。
要看的是更新日和 Game version 是否噙合，进一步看 Forum 上最近有没有不具合或修复方针。
即使更新日新，本文或主题里看不到兼容性话题的话要慎重。
反之，日期有点旧但作者一直在持续追踪状况的话，判断就有点不同。

从我的感觉来看，更新停了很久的便利类特别要注意。
因为不做功能追加，看起来"枯了所以稳定"，但2.0迁移这种内部API前提改变的时点，那份沉默有时就直接表示放置不管。
实际上表面操作没问题，但警告日志增加了，或者配合其他MOD时只在特定场景出现奇怪的不整合。
这种类型，同一用途最近还在细致维护的代替候选会更好用。

维护状况要深入挖的话，官方博客的更新文脉也起作用。
掌握游戏侧大改变的时间点的话，那个前后更新停了的MOD的意义就更容易读出来。
看更新日的工作很无聊，但导入后的故障回避上很见效的判断轴。

存档兼容性和安全的测试环境

还要看不漏的是，是否能直接往现有存档装这种MOD的角度。
这特别对大型改造类重要，但UI和信息表示类根据改什么、改多少，安全感的触感也会改变。
不仅是追加要素，而是既存的实体或进行前提有没有手的关系是分界线。

往既有存档直接应用危险的理由是，出问题时"这个MOD单独的影响"还是"现在的工厂不噙合"容易搞不清。
新世界的话，启动、读取、研究画面、建筑、物流等基本导线能短时间确认，异常出了也容易追原因。
首次导入在新世界试，看稳定后才往本番存档移动的流程，就是因为这个切分特别轻松。

存档兼容性"启动了就安全"不一定。
Factorio 中读取能进，但过程中警告堆积，或既存设备和整合崩了，后来才当成违和感出现的情况有。
特别是进行根本有关或改变配方·实体构成的类型，和既有存档的相性要另当一回事对待更容易整理。

这个阶段，导入前看的要点能分成4个来缩小，就能避免迷茫。
对应版本是2.0系吗、Space Age 前提有吗、Dependencies 里前提MOD噙合吗、最后更新日和 Forum 上维护状况充分吗、既有存档能装吗这4点。
都不是派头的要点，但实际能稳定玩下去,很大程度上这里决定。
下一步候选选择前先把土台整齐，装完以后的错位会相当减少。

用途别推荐MOD的选法

按用途分开想，MOD选择会相当整理得轻松。
Factorio 的MOD数量多，仅凭名字或流行度看的话，"看起来方便，但和自己的烦恼有点不一样"这样的错位容易出现。
这种时候派上用场的是想让什么变轻松的分类法。
想减少操作烦恼，还是想缩短设计试错，还是想舒适地扩大已展开的工厂，还是想分析生产的堵塞，根据这个相性好的系统会相当改变。

从我的经验来说，先理顺UI系后再向建设辅助和物流改善进的时候，追加效果感觉得最清楚。
土台的操作感有点卡的话，之后装的便利系的价值都会模糊。
反过来最初稍微理顺一下视认性和操作补助，"哪个地方面倒"就会自己看清楚。
那个意义上，用途别整理不仅仅是分类，也连接到导入顺序的判断。
需要用语和原始游戏规格确认的场景，横着放 Factorio Wiki 读的话，理解不容易摇摆。

提前整齐比较轴的话，各分类的位置就更容易看清。

UI/QoL 类

UI/QoL 类是最初导入候选中最容易拿捏的分类。
让屏幕上的信息更容易看，让频繁用的操作少一步，减少确认的麻烦等等，都能在不破坏游玩根基的情况下整理"以前哪里有点不方便"。
不改变工厂机制本身，而是补助 Factorio 原本有的乐趣，让玩家顺畅进入的类型。

适合的是在推进原始游戏中感到"有不满，但不想变成另一款游戏"的读者。
比如说信息在屏幕上追不了，频繁用的操作有点费事，微妙的确认很烦，要是这样的烦恼中心，先就这系统噙合。
学习成本低，所以即使MOD还不习惯的人也不容易有违和感。

想集合总结 QoL 类的具体例子的读者，参考"QoL类总结文（制作中）"或外部 Mod Portal 的分类／标签会比较好。
首先试试用 Mod Portal 或 Wiki，把烦恼对应的候选筛下来吧。

建设辅助·设计支援类

建设辅助·设计支援类适合想让工厂成形的时间更舒服的人。
Factorio 中，组没堵的线、考虑将来扩展留空位、整顿配线和搬运这样的试错本身是乐趣所在。
但玩得越熟练，越容易感觉"想法倒是有趣，但返工手数太多"。
这系统能支撑那个。

相性好的是玩过原始游戏一阵子，皮带曲法和组装机排法出现自己特色的中级玩家。
还在摸不着北阶段的话，恩惠不容易掌握。
反之意识到基地扩大和模块化的时间点，舒适性会大幅改变。
这系统的本质是"把失败变到零"而不是"失败后的重建成本降低"。

游玩感上，脑子里想象的设计落到游戏中的摩擦感减轻。
我装这手 MOD 的时候，感觉"工厂变强了"不如"试设想的形的次数增加了"。
结果线路设计长进快了。
原始感还充分，但操作感本身会往上提升一级。
考虑为 UI 系的下一个二段目候选的话容易理解。

物流·移动改善类

物流·移动改善类是工厂越展开越见效的分类。
皮带、车辆、移动补助、基地间往返、远距离建筑作业等，游玩时间越长"目的以外的移动"越增加。
这系统减轻那个压力，保持节奏的角色。

适合的是基地开始大型化，移动和重新配置的时间开始让人在意的读者。要是