模组作为设计方法

本章命题：官方从社区吸收内容的标准是类型而非质量——增加动词（活塞）、增加可误用物理（马的骑乘）、增加分发格式（数据包）的东西适合进正作；完整系统（工业、魔法）与内容包留在社区。若官方收编一套完整系统而模组生态因此更繁荣，本命题就是错的。

1问题

每个 Minecraft 论坛都有一个常年置顶的月经帖：「这个模组做得这么好，为什么不直接加进游戏？」——配的可能是某个工业模组的截图，某套画质增强，或某个把战斗彻底重做的整合包。帖子的潜台词是一个看似公允的标准：好的就该收。

官方十四年的收编史（卷一第 4 章按史实梳理过：活塞进了，工业模组一次没进）说明这标准不是官方的标准。本章把官方没说出口的那份方法论整理出来——因为对开发者，这份方法论比收编史本身值钱：它回答的是一个通用问题，**当你的产品有一个繁荣的第三方生态时，你该从生态里吸收什么、留什么、以及怎么吸收才不杀死它。**这也是「模组作为设计方法」这个题目的两层含义：模组是社区的设计实践；而模组（作为现象）反过来成了官方的设计方法——官方通过决定「吸收什么」来设计正作。

2「好模组为什么不直接进游戏」错在哪

先拆那个月经帖。它的第一个错误：把质量当成了收编的充分条件。质量确实是必要条件——收进正作的活塞、马，都是被验证过的好东西——但「好」在模组语境和在正作语境里是两回事。一个模组的优秀，往往依赖它的自由身：它只服务自选它的玩家（受众天然是爱好者），不必对几亿新玩家负责，不必为每个兼容场景买单，坏了可以弃坑。同一套东西进了正作，就要背上十年兼容、新手引导、平衡性、本地化的全套负担——收编不是发奖，是把一件作品的维护成本国有化。

第二个错误：无视挤出效应。社区的创造热情不是无限的，但它的流向会跟着生态位走：官方做了什么，社区就渐渐不再做什么——既然官方会做，何必白费工。这一条反过来读才是官方的立场：**官方每留白一块，就给社区保留一块自留地。**工业、魔法这些大系统留在社区手里，它们就是几万人十五年的事业；一旦被官方接管，事业变成日程表上的几行更新公告，作者与玩家的关系从合伙变成投喂。卷一第 4 章说过「不禁止」是成本最低的治理，本章补上另一半：不接管，是成本最低的激励。

第三个错误最隐蔽：它假设正作和模组在竞争同一个赛道。实际上它们的分工在卷一已经写清——正作负责把最小动词集维持在人人都学的地步，模组负责把表达力推到爱好者愿意追的地步。这个分工要求正作保持小。收编一堆大系统，等于让正作去做模组的工作——正作一旦臃肿，它自己的部分（新手能学会的那部分）反而被淹了。

3加系统与加内容：两种模组，两种命运

把市面上的模组按一个轴分开：加系统的和加内容的。

加系统的模组动的是语法：工业模组引入「能量」这个原版没有的概念层，存储模组重新定义「物品放在哪」，铁路模组把运输变成一门工程。它们的共同特征：卸载它们，建立在其上的玩法会整层坍塌——玩家不是「少了些东西」，是「做不成一类事」。

加内容的模组动的是词汇：新方块、新生物、新维度皮肤。词汇当然也创造乐趣，但它挂在原语法上——卸载之后玩法不塌，只是少了些点缀。

这个区分直接预测了两种模组的生态命运：系统模组之间会互相咬合——工业模组发的电驱动机械模组的机器，物流模组的管道连接两者的仓库（第 1 章讲过：继承原语的模组免费获得社区语法）——于是围绕系统模组长出了整合包、教程、专有黑话，长成了文明；内容模组则大多各自灿烂、互不相干，更新一断就迅速过时。系统是可积累的，内容是易耗的——这不仅是模组圈的规律，回头也是对官方「收编什么」的提示：收编内容，得到一堆迟早过时的词条；收编动词与规则，得到的是会被社区继续开采的语法。

4整合包：策展即设计

系统模组的咬合之上，长出了第三层作者（卷一第 4 章提过，本章展开它的方法论意义）：整合包作者不写一行模组代码，却完成了货真价实的游戏设计。

一个整合包是什么？几十个系统模组，被挑选、排序、削改、调和：禁掉破坏平衡的配方，改掉互相冲突的合成路线，用数据包重写进度线，给整包定一个主题与节奏——「从石器时代艰难起步的拟真生存」，或者「人人都有喷气背包的工业乌龙」。成品是一个玩家数以百万计的「新游戏」，而它的设计过程基本不碰 Java：选模组是选演员，改配方是改剧本，平衡是导演功。

这证明了一件对本书很要紧的事：**设计可以整个发生在数据层。**不必动引擎、不必写系统，仅在「允许什么、禁止什么、贵多少、多难」的层面上调度，就能长出截然不同的游戏体验。官方其实早就收到了这份证明并签收了——数据包系统（第 8 章）让每个普通玩家都能做整合包作者在做的事，就是官方对这层设计实践的正式承认。策展即设计，这不是比喻，是这个生态里一门养活了大量人口的工种。

5结构空洞：官方的克制清单

卷一第 4 章列举过三个结构空洞：没有能量（于是有工业模组）、合成无「发现」（于是有魔法模组）、成长曲线太短（于是有 RPG 模组）。本章把它们重新命名一下：结构空洞是官方的克制清单——每一块留白，都是一次「官方不做，让生态来做」的自觉或幸运。

这份清单的妙处在于它随时间变化。官方每收编一个动词（活塞、马、命令方块），生态就腾出一块新空地（活塞门美学、马场玩法、命令方块地图）；官方每自创一个系统，就有可能填掉一块空地（也挤掉一块事业）。十五年来这份清单大体是扩张的，原因不是官方无为，而是官方守着上一章那条立法分层：**物理层官方做，玩法层社区做，官方只在两层之间搬运动词。**空洞清单因此成了社区产业的地图——每个洞里都有几万人的事业，这是把生态当合伙人而不是当外包的人才舍得画的地图。

6收编原则与反例

现在把卷一的史实升格为可执行的判据。收编四原则：

1. **收编动词，放过系统。**被收编的应当是「玩家可以拿去组合的新动作」（活塞推拉、骑乘驯化、命令执行），而不是自成体系的完整玩法（能量经济、法术体系）。前者给全社区发杠杆，后者给全社区发剧本。
2. **收编格式，放过内容。**数据包、资源包这类「分发与扩展的容器」值得官方化——它们让所有人更容易创作，却不与任何人竞争。反过来，收编某个具体模组的具体内容（某套装备、某个生物群系的设定），等于官方下场和自己的社区抢同一张桌子。
3. **收编已被自然状态验证十年的机制。**活塞在 Infiniminer 里被验证过，马在 Mo' Creatures 里被验证过¹——进正作之前，它们已经在社区里跑了多年，乐趣与代价都有公开记录。官方不应当用收编替社区试错，只应当替社区转正。
4. **收编时保全生态位。**活塞的作者被写进制作名单，马的作者参与适配（卷一第 4 章）——收编的姿态决定生态的反应：署名与协作让社区看到「转正是荣誉」，无声的吞并会让下一个人不敢再开源。

四条反例（违反原则的典型姿势）：

1. 按质量收编：「这个模组千万人下载，应该进正作」——质量最高的模组往往是最深的系统（如画质与性能类的顶级方案），收编它等于官方接管一个自己未必养得动的工程，还向所有同类作者宣布天花板已到。真实的对照是：官方对性能与画质类增强走的是自研吸收路线——把社区验证过的方向用自己的实现慢慢做进版本，而让原模组继续存在。这提醒我们「吸收」不只有「收编」一种姿势。
2. 按热度收编内容：「这个生物模组最火，加进游戏」——内容的收编是一次性交易，买断一个词条；而热度会转移，生态的感情却记仇。
3. 替社区试错：把一个社区里刚刚冒头、尚未被时间验证的新系统直接搬进正作——万一它是错的，错的从此是官方的，且十年改不掉。
4. 无声吞并：不署名、不协作、不解释地把社区作品的做法搬进正作——短期省事，长期让作者席的门关上一半。

还有一道必须处理的考题，来自备忘里那类容易混淆的案例：运行时编辑工具（WorldEdit 这类选区工具、客户端的建筑编辑器）算「加系统」吗？按本章框架，它们是工种工具——服务特定身份（建筑师、地图作者）的专业器械，不是新的世界权限。第 4 章的结论在这里复用：工具可以很强，但不能顶替创造当居住权限；Bedrock 版近年也在做官方的编辑器工具，其官方定位同样是「工具而非游戏模式」。工具层的繁荣是服主与创作者的真实需求（多人实时预览、工地协作），它的存在不构成对创造模式定位的否定——收编原则在这类案例上的应用是：收编「格式与接口」（选区、蓝图的数据格式），放过「具体工具」，让工种工具留在迭代最快的社区手里。

7这一章留下什么

• 爱好者：你喜欢的那些模组没有「进游戏」不是委屈——它们留在社区里，才可能长成生态、结成整合包、养出作者；进正作的只有活塞和马，而它们身后站着整个没有进来的世界。
• 开发者：能抄走的是收编四原则——动词进、系统留，格式进、内容留，只转正被时间验证的，收编时保全作者席。抄不走的是留白的底气：官方敢把工业、魔法这些最大的人口留在门外，是因为它确信自己的正作不靠它们成立——你的产品若不确定自己成立什么，就不敢留白。

注释

1. Minecraft Wiki，《Piston》（Hippoplatimus 的活塞模组于 Beta 1.7 收编进正作，作者以「额外编程」列入制作名单），minecraft.wiki，检索于 2026-09-18；见 https://minecraft.wiki/w/Piston ↩