企业官网建设流程全解析

1. mod到底改的是什么：先搞懂文明六的"外部世界"与"内部世界"

1.1 玩了一百小时，我为什么突然想改数据

文明六玩到一定阶段，很多人的体验应该是相似的：城市发展到中期，总觉得纪念碑只给文化不够用；或者在某个版本更新之后，某文明强得离谱，某建筑又鸡肋得没人造；再或者你玩的是一个自己特别上头的套路，恨不得给侦察兵多两条腿，让开拓者跑得再快一点。

这些问题在游戏里是"机制"，但在 mod 视角下，它本质上就是一个数字、一个表、一行记录的事。我第一次产生"想做 mod"的念头，不是因为看了什么教程，而是因为一局游戏里反复被同一批蛮族骚扰，实在忍不住想"把蛮族侦察兵的血量调低一点行不行"。后来真的动手才发现，这个念头背后牵涉到的事情没有想象中复杂，但也不是打开一个文件改个数字那么简单——你需要先理解文明六的数据到底是怎么被组织起来的。

这篇文章面向的读者，是已经玩过不少文明六、但完全没碰过 mod 的玩家。我会按照自己实际走过的路径来分享：从理解游戏内部的数据结构开始，到准备工具，再到做出第一个能直接看到效果的 mod，最后聊聊那些让无数新手卡住的排查过程。目标不是给你一个"万能框架"，而是让你在读完之后，能自己打开数据库、找到目标行、改出一个属于自己的 mod。

1.2 引擎世界：SQLite、XML、Lua三兄弟

文明六作为一个策略游戏，它的架构其实比很多人想象的要"透明"。从 mod 的角度看，整个游戏内部大致可以分为四个层：

第一层是数据库层，也是最常见、最好上手的修改入口。建筑、单位、科技、市政、文明特性、改良设施、城邦、伟人、宗教信条等几乎所有玩法数值，都存放在一个 SQLite 数据库文件里。这个文件通常叫Gameplay.sqlite，位于游戏安装目录下的Base/Assets/Gameplay/Data/文件夹中。你玩到的每一个产出、成本、战斗力、移动力，绝大多数都是数据库里某一行的一个字段。

第二层是文本层，负责显示。游戏里所有界面上的文字，包括建筑名、领袖描述、文明图鉴、政策文本，都存在文本表里。mod 要新增内容时，通常需要同时补上文本数据，否则游戏界面会显示一串类似LOC_BUILDING_XXX_NAME的原始标签。

第三层是逻辑层，也就是 Lua 脚本。比如某些特殊单位触发的事件、某些政策在特定条件下的效果、UI 的交互逻辑，很多都由 Lua 脚本动态处理。对新手来说，Lua 属于进阶内容，但知道它存在很重要，因为有些效果你在数据库里翻破天也找不到对应字段，它其实写在脚本里。

第四层是美术资源层，包括模型、贴图、图标。文明六的图标资源常用 dds 格式，这一层是最麻烦的，涉及专门的图像处理工具和资源打包流程。我的建议是：前几个 mod 尽量避免触碰美术资源，优先做纯数据修改。

理解这四个层的分工之后，你会清楚地意识到一件事：你想做的 mod 属于哪一层，决定了它的难度和工具链。改数值是最轻的，新增建筑会稍微麻烦一点，自定义文明则要同时碰数据库、文本、美术，所以新手不该从"做一个新文明"开始。

1.3 一个最小mod，在启动时做了什么

你还需要理解一个关键概念：mod 不是去修改游戏安装目录里的原始数据库文件，而是游戏启动时，额外给内存中的数据库打补丁。这两者的区别非常重要。

游戏启动时会读取玩家文档目录下的Mods文件夹，看你启用了哪些 mod，然后按顺序执行每个 mod 里声明的"动作"（Actions）。最常见的动作是UpdateDatabase，它会把 mod 里的 SQL 或 XML 文件实时地应用到游戏的内存数据库上。也就是说，原始安装文件完全不用动，你的修改是叠加进去的。

这个机制带来两个好处。一是游戏一旦更新，官方文件被覆盖也不影响你的 mod，因为你的修改是独立存在的补丁；二是你可以放心大胆地改数据，改坏了把 mod 文件夹删掉就行，不会弄坏游戏本体。

但同样的机制也带来一个问题：mod 之间是有"加载顺序"的。假如你写了一个 mod 把纪念碑产出从 +2 改成 +3，另一个 mod 也改了同一个值，后加载的那个会覆盖前一个。这也是很多"我的 mod 没生效"的隐藏原因之一。理解这个加载机制后，再看后面的实际操作就会顺畅很多。

2. 我的入坑工具清单：三样必备，两样可选

2.1 真正绕不开的只有三样

很多人一想到做 mod，第一反应是找某个官方编辑器。但以我的亲身体验，做最基础的数值 mod，你真正需要的东西非常朴素：

• 一个文本编辑器。VS Code 或者 Notepad++ 都可以，主要用来写 SQL 和 XML。VS Code 免费且插件多，我建议装一个 XML 格式化插件，能帮你快速发现标签没闭合的问题。
• 一个 SQLite 数据库浏览器。我常用的是 DB Browser for SQLite，界面直白，能直接浏览表、看字段、执行 SQL 查询。没有它，你连"纪念碑现在的产出到底存在哪张表"都没法确认。
• 游戏本体。这个不用多说，任何 mod 都需要在游戏里测试。

可选工具里，最重要的可能是官方 ModBuddy 工具，以及一个能处理 dds 图片的软件（比如 GIMP 加 dds 插件）。ModBuddy 主要用于生成项目模板、打包发布，我用了很久之后依然觉得，新手时期手写文件比依赖它更容易理解底层原理。图形工具则是在你决定做新建筑、新单位的图标时才需要碰。

下面是我个人比较推荐的工具体检表：

2.2 ModBuddy到底要不要用

先说结论：可以晚点用，但最好别一开始就死磕它。

ModBuddy 是官方提供的 mod 编辑器，它的优势很明显：新建项目时会自动生成一堆模板文件，你不用手动写 modinfo，也不用担心 GUID 格式、依赖声明这些细节。打包发布时也能直接生成 civ6mod 文件，方便上传创意工坊。

但它也有一个很现实的问题：对新手来说，它把太多细节藏起来了。一旦你的 mod 出了问题，你看不到背后的结构，反而更难定位问题。我自己早期有一次用 ModBuddy 创建项目，生成出来的项目路径默认不在我的文档目录下，结果游戏里怎么都找不到这个 mod，折腾了半天才发现是路径不对。

所以我给出的路线是：前两个 mod 完全用手写文件夹的方式来做，把每个文件、每个标签弄明白；第三个 mod 开始，再把项目交给 ModBuddy 管理。这样即使以后遇到问题，你也清楚它背后到底在做什么。

2.3 动手之前，先在你的文档目录里搭一个"实验台"

文明六的玩家 mod 目录位于系统"我的文档"下的My Games/Sid Meier's Civilization VI/Mods文件夹。你在这个目录下创建的每个子文件夹，都是一个独立的 mod。

搭建一个实验台只需要三步：

1. 在Mods目录下新建一个文件夹，比如MyFirstMod。
2. 在文件夹里分别建好data和text两个子目录，用来放数据文件和文本文件。
3. 创建一个最简的 modinfo 文件，让游戏能识别这个 mod。

这个"实验台"的意义在于，它把未知因素压缩到最小。你不需要理会官方编辑器生成的一堆配置，只需要知道一个 mod 的基本结构就是：一份描述文件（modinfo）+ 若干数据文件（SQL/XML）+ 若干文本文件（XML）。后面写第一个 mod 时，你会看到它们各自是如何协作的。

3. 第一个mod实战：让纪念碑多产出1点文化

3.1 目标选择：为什么是纪念碑

我第一次认真做数值 mod 时，从"蛮族侦察兵"一路看到"英雄时代"，最后选了一个最简单也最直观的目标：让纪念碑多产出 1 点文化。

选择它的理由有三个。第一，纪念碑是非常早期的建筑，几乎每局游戏都会造，验证成本低；第二，它的产出清晰，一是文化，没有任何复杂触发条件；第三，这个建筑的数据在数据库里结构简单，非常适合作为入门案例。

在标准规则下，纪念碑基础产出通常是 +2 文化。我们的目标就是做一个 mod，让它变成 +3 文化。不要小看这一点的变化，光是走完"理解目标 -> 查表 -> 写补丁 -> 写描述 -> 进游戏验证"这条完整链路，你就已经把文明六 mod 制作的核心流程跑通了。

3.2 查表：先确认你要改的那一行真实存在

很多新手容易犯的一个错误是：不看数据库结构，凭感觉写 SQL。实际上，文明六的数据库表结构可能跟你在网上看到的教程有细微差别，尤其在不同资料片、不同更新版本下，列名和表名都可能变化。所以第一步永远是用数据库浏览器打开真实的Gameplay.sqlite，确认你要操作的对象。

打开Base/Assets/Gameplay/Data/目录下的Gameplay.sqlite后，你会看到一大堆表。与建筑产出直接相关的表叫Building_YieldChanges，它是连接建筑表Buildings和产出类型表Yields的关联表。你需要做两件事：

1. 在Buildings表里搜索BUILDING_MONUMENT，确认建筑类型的主键写法。
2. 在Building_YieldChanges表里搜索同一个值，找到纪念碑当前文化产出的那一行，记录它的YieldType和YieldChange。

这一步看起来只是"看一下"，但它能避免后面一半的怪问题。比如你猜的字段名写错了，或者你压根不知道这个建筑是否已经有文化产出行，这些问题在动手之前发现，成本几乎为零。

3.3 写SQL补丁：更新与插入的区别

确认目标行存在之后，就可以写 SQL 了。在data目录下新建一个IncreaseMonument.sql文件，内容如下：

UPDATE Building_YieldChanges SET YieldChange = 3 WHERE BuildingType = 'BUILDING_MONUMENT' AND YieldType = 'YIELD_CULTURE';

这段 SQL 的逻辑很清楚：找到所有建筑类型为纪念碑、产出类型为文化的行，把产出值改成 3。

这里要理解UPDATE和INSERT的区别。UPDATE是修改已有行，适合调整现有数值；INSERT是新增行，适合给某建筑增加一个新的产出类型。如果你想把纪念碑从一个冷门建筑改成"文化与金币都产出"，就需要用INSERT再插入一行YIELD_GOLD。

还有一个值得注意的点：如果之前某个 mod 已经改了纪念碑的文化产出值，你这个UPDATE会把所有匹配行覆盖成 3。这就是 mod 的"覆盖"特性，它能让你修正别人改过的值，但也意味着你在依赖加载顺序。尽量让补丁短小精确，你的 mod 就越容易被理解和维护。

3.4 写modinfo：把补丁告诉游戏

SQL 文件本身不会被游戏自动识别，你需要用 modinfo 文件把它"声明"给游戏知道。在你的MyFirstMod文件夹里，创建一个名为MyFirstMod.modinfo的文件，内容如下：

<?xml version="1.0" encoding="utf-8"?> <Mod id="MyMonumentPlus" name="Monument Plus" version="1.0"> <Properties> <Name>Monument Plus</Name> <Description>让纪念碑多产出1点文化。</Description> </Properties> <Actions> <UpdateDatabase id="GameDatabase"> <Items> <File>data/IncreaseMonument.sql</File> </Items> </UpdateDatabase> </Actions> <Files> <File>data/IncreaseMonument.sql</File> </Files> </Mod>

我来逐段解释一下这个文件在干什么。

<Mod id="...">是整个 mod 的唯一标识。官方格式一般要求填一个 GUID（全局唯一标识符），避免两个 mod 撞 id。我这里为了演示写了一个可读字符串，实际发布时建议用在线 GUID 生成器生成一个随机值。

<Properties>里是显示在游戏"额外内容"界面上的名称和描述，它只负责让人看清，不影响游戏数据。

<Actions>是整个 modinfo 的灵魂。它声明了 mod 启动时要执行哪些动作。这里我声明了一个UpdateDatabase动作，指向data/IncreaseMonument.sql，意思就是"游戏启动时，把这个 SQL 文件执行到数据库里"。

<Files>则负责把文件内容打包进 mod 文件列表中。在 mod 开发过程中，这个列表很容易被忘记，如果你发现文件存在、但游戏完全没加载它，先检查是不是忘了加这一步。

3.5 启动验证：从勾选到看到+3文化

文件都写完以后，启动游戏。在游戏主菜单找到"额外内容"（也翻译为"模组"），你会在列表里看到Monument Plus，勾选它，然后开始一场新游戏。

为什么强调"新游戏"？因为文明六的数据库在游戏启动时已经构建完成，加载旧存档不一定能完整反映数据修改，新开一局可以排除这个干扰。

游戏进入后，找到任何一个城市，查看建造列表里纪念碑的预览信息。如果一切正常，它的产出应该从 +2 文化变成了 +3 文化。如果没变，不要着急，下一节就是专门的排查过程。

4. mod没生效时，我按这个顺序排查

4.1 日志是第一手证据

很多新手在 mod 不生效时的第一反应，是在游戏里反复开关界面、或者直接删掉 mod 重来。但我建议你先去看日志。文明六会把 mod 加载和数据库操作的记录写到"我的文档"下的My Games/Sid Meier's Civilization VI/Logs文件夹里，其中最有用的是Modding.log和Database.log。

Modding.log记录的是 mod 整体的加载情况：哪些 mod 被识别、哪些被启用、哪些在加载时被跳过。如果你在日志里没看到自己的 mod 名，那就不是 SQL 的问题，而是 mod 压根没有被加载。常见原因：文件放错了目录，或者"额外内容"里没勾选。

Database.log记录的是数据库操作。每一个UpdateDatabase动作执行了什么文件，有没有报错，都会写在这里。搜索你的 mod 名或 SQL 文件名，看到ERROR字样后，后面通常会跟着具体的错误信息。

这个排查习惯极其重要。日志能让你把问题定位到"加载环节"还是"数据库执行环节"，而不是靠猜。我自己后来做复杂 mod，有至少一半时间都花在读日志上，这比反复进游戏测试要高效得多。

4.2 "能加载"不等于"改到了"

有一种情况非常让人沮丧：日志显示 mod 正常加载，SQL 也执行了，但游戏里数值就是没变。这时候问题几乎不在"加载"，而在"执行效果"。

最常见的原因是你的WHERE条件没有匹配到任何行。SQLite 对表名和列名的大小写并不敏感，但字符串值（比如'BUILDING_MONUMENT'）是严格区分大小写的。如果你在查表时看到的类型名是BUILDING_MONUMENT，而你写成了building_monument，UPDATE 会安静地执行成功，但影响 0 行，游戏数据自然毫无变化。

另一个可能，是另一个 mod 的加载顺序在你后面，把你改的值再次覆盖掉。数据库日志里能看出来执行的先后顺序，如果你发现某个官方 DLC 或其它 mod 也改过同一行，就要考虑在 modinfo 里声明依赖关系，让加载顺序变得可控。

如果你担心UPDATE没命中，可以使用更"霸道"的写法：

INSERT OR REPLACE INTO Building_YieldChanges (BuildingType, YieldType, YieldChange) VALUES ('BUILDING_MONUMENT', 'YIELD_CULTURE', 3);

这个写法会尝试插入一行；如果存在相同的BuildingType + YieldType组合，就替换成新值。它的前提是你知道主键列名，所以再次强调：查表这一步不能省。

4.3 报错关键词速查

Database.log里的报错信息虽然常是一整段英文，但关键错误类型其实就那么几种。我把实际遇到过的整理成一个速查表：

我教你一个笨但有效的排查办法：把 SQL 文件里每一句语句单独拆开，每句只做一件事。就算某一句报错，你也立刻知道是哪一个环节出了问题。

4.4 缓存与版本：两个"看不到的敌人"

还有一个经常被忽略的问题：缓存。

文明六会在"我的文档"目录下生成Cache文件夹，里面缓存了一些游戏数据。理论上，数据库相关的修改不需要清缓存，但如果你同时改了文本或图标资源，而界面显示的还是旧内容，那就有可能是缓存没有刷新。这时可以退出游戏，备份并清空缓存目录，重新启动游戏测试。注意只动"我的文档"下的缓存目录，安装目录的文件不要碰。

关于版本，文明六每次更新都有可能调整数据库表结构。你今天照着教程写的列名，在下一个 DLC 发布后可能就变了。应对方法只有一个：永远以你当前游戏安装目录下的真实数据库为准。网上教程、旧帖子的截图只能作为参考思路，不能当成唯一标准。

5. 从改数值到改玩法：下一步怎么走

5.1 加一栋自己的建筑，为什么先别急

当你成功改掉纪念碑之后，很容易冒出"我想给游戏多加一栋建筑"的念头。这个方向值得尝试，但我想先给你打一针预防针：新增建筑没有改数值那么省事，因为它牵涉到建筑类型定义、产出表、文本表、以及放置规则等一堆关联。

但底层流程与前面做过的完全一样，只是多几个表而已。大致步骤如下：

1. 在Buildings表插入一行，定义建筑类型、生产成本、前置区域等基础字段。
2. 在Building_YieldChanges表插入新的产出行。
3. 在LocalizedText文本文件中补上这个建筑的中英文名称和描述，否则界面会显示原始标签。
4. 处理美术资源。如果复用已有建筑模型，基础逻辑上可以跑通，但可能出现显示错位或贴图怪异，先本地实验就好，别急着发布。

这里的关键是：每一步都要重复"先查表、再写补丁"的习惯。只要你能跑通纪念碑的修改，这套流程的骨架就已经在你手里了，剩下的只是多查几个表。

5.2 用Modifiers机制抄官方作业

从"改数值"到"改规则"之间，有一道很值得跨越的门槛，就是文明六的 Modifiers 机制。很多丰富的效果，比如"所有远程单位的攻击力提升""贸易路线金币加成翻倍"，并不是简单的某个表里的一个字段，而是通过多个表组合出来的规则。

先记住三张核心表：Modifiers定义了一个规则实例，ModifierArguments给这个实例填参数，TraitModifiers把这个规则挂到某个文明或领袖特性上。它们的关系就像你用同一个"配方"，填上不同的"原料"，再放到不同的"锅"里。

很多教程会直接给你一段带MODIFIER_...类型名的 SQL，但我不建议你这么照着抄，因为不同版本、不同 DLC 里的 ModifierType 并不完全相同。更靠谱的方法，是打开数据库浏览器，在Modifiers表里搜索一个你感兴趣的官方效果关键词，比如ADJUST或ATTACK，然后顺着ModifierArguments看它传了什么参数。找到之后，把这个结构复制到自己的 mod 里，替换成你需要的新 id 和参数值。

这就是我说的"抄官方作业"。它比凭空发明规则可靠得多，因为官方效果已经经过了游戏平衡性的验证，而能触发它的挂载方式也写在TraitModifiers里供你参考。

5.3 分享与更新mod前，我固定的三道检查

等你做出一个自己满意的 mod，要分享给别人或上传创意工坊之前，我有三道固定的检查流程，算是踩过不少次坑换来的教训。

第一道：确认依赖。如果你的 mod 引用了某个 DLC 或资料片里的表、建筑、文明特性，必须在 modinfo 的依赖声明里写清楚，否则其它玩家加载时，会因为找不到对应表而直接报错。自己单机玩可能没问题，因为你自己装了全套 DLC，但别人可能只买基础版。

第二道：全新环境测试。换一台电脑，或者至少用一个干净的文档目录测试一次。我的经验是，本地开发环境里总是藏着一些看不见的缓存旧文件，而新环境能暴露最真实的问题。

第三道：写一个 README。记录这个 mod 改了什么、针对哪个版本、允许别人怎样修改。这不只方便别人，更为了方便未来的你。当你几个月后想更新一个旧 mod，翻到 README 的那一刻，你会感谢自己当初留下了这几行字。

MOD 制作这条路，越往深处走，越像在拆解一个巨大而精密的钟表。一开始你只是拧松了一颗螺丝，慢慢你会发现每个齿轮之间都有联动。如果不知道该从哪个数值下手，我的建议是去找自己最常抱怨的那个痛点：蛮族跑太快，就去单位数据里找移动力；奇观太贵，就去建筑表里找成本；伟人点数总是差一点，就去对应系统里找产出来源。改完那个数，进游戏亲眼看到变化，你才算真正从一个玩家跨进了 modder 的世界。