如果你手里有一套AI编程辅助工具，除了写代码，它其实还非常适合做另一件事：生成一部万字级的奇幻世界设定。我最近用某款AI代码编辑器里的编程助手（下文简称CA，纯粹是为了叙述方便，不构成任何工具推荐），花了差不多三个晚上，把原本零散在脑子里的种族、地理、神系设定，整理成了一份有目录、有索引、可校验的完整世界观文档。整个过程下来，我的体会是：世界设定本质上是一个需要持续维护、保证内部一致的信息工程，而这恰好是AI Coding工具最擅长的领域。这篇实践记录就把完整思路和步骤拆给你看，适合那些想用AI做小说设定、跑团战役背景，或者游戏世界观构架的创作者参考。1. 为什么拿代码工具来写世界设定：可管理、可校验、可回滚1.1 从“聊天式写作”到“工程化写作”：状态从无到有最早我用AI聊天窗口写设定，发现一个很要命的问题：AI没有记忆。上午刚确定精灵王子的名字叫“凯尔萨”，下午再开一个新对话，它就给你写成“凯尔洛斯”；你问它上一版设定里某个城邦在哪里，它一脸茫然。原因很简单，聊天窗口里没有项目文件，每一次对话都是无状态的，AI只能依赖你临时塞给它的那点上下文。把同样的事情挪到AI Coding工具里，逻辑完全变了。你生成的所有设定都以文本文件的形式存在于同一个项目目录下，AI生成新内容之前，会自动扫描项目内的相关文件，把它当作参考上下文。这相当于代码仓库里所有模块共享一套类型定义，不会各写各的。我后来的工作方式就变成了：不是在聊天，而是在维护一个持续演进的设定仓库。每一次生成、修改、删除，都有文件层面的记录，随时可以翻看、回滚、对比。1.2 世界设定最大的敌人不是灵感，是内部矛盾写过一个长篇奇幻设定的人都知道，开头灵感迸发时是最爽的，但写到两万字之后，真正的噩梦不是“没东西写”，而是“对不上号”。某个角色在第一纪元建立了一座城邦，到第三纪元的时候，你又让他以“年轻的旅人”身份登场；前文明确说某种魔法只能由精灵使用，后文人类主角却莫名其妙施展了出来。这种问题，和代码里的全局变量被意外修改、接口定义前后不一致，本质上是同一回事。我见过很多创作者用Excel表格来管理设定，这比聊天强得多，但表格只能管“存在的事实”，管不了“矛盾的事实”。比如人物状态从“活着”变成“死亡”之后，还继续在后续事件中出现，这种逻辑冲突靠肉眼很难发现。AI Coding工具提供了一条新的解决路径：用脚本扫描。把设定转成结构化数据之后，写一个简单的检查脚本就能快速找出时间线冲突、人物状态冲突和名词重复定义。这种“代码级校验”的能力，是普通聊天AI和笔记软件给不了的。1.3 工具选型对比：代码编辑器凭什么赢过笔记软件有人可能会问：我直接用在线笔记软件管理设定不行吗？当然可以，但如果你需要大规模生成和长期一致性维护，代码编辑器的优势非常明显。对比维度AI Coding工具（CA）普通笔记软件内容形态纯文本/Markdown文件，可批量处理、全文检索富文本为主，批量处理能力弱规则约束项目规则文件自动生效，AI每次生成都遵守无类似机制，靠人工提醒校验手段可以编写脚本扫描矛盾，自动定位问题基本靠人工通读版本管理直接接入git，任意版本可回滚多数没有版本记录，改错难恢复我并不是否定笔记软件在头脑风暴阶段的作用，说实话，前期收集灵感、随手记碎片，我用得最多的还是笔记工具。但进入“生成万字设定”这个阶段之后，信息量一大，笔记软件的维护成本就开始失控。而AI Coding工具，本质上把设定变成了一个可编译的项目：有依赖、有约束、有测试。这一点，决定了它能扛住万字规模。2. 写设定之前先做四项工程化准备2.1 目录结构：把设定文件当代码模块来组织决定用AI Coding工具之前，我先花了一个小时设计目录结构。这步看起来基础，实际上决定了后续AI能不能准确找到需要的文件。我最终采用下面这个结构，供你参考：worldbook/ ├── rules.md ├── index.md ├── 00_总纲/ │ ├── 世界概述.md │ ├── 纪元年表.md │ └── 基础规则.md ├── 01_地理/ │ ├── 大陆地图.md │ ├── 主要城邦.md │ └── 气候与资源.md ├── 02_种族/ │ ├── 精灵.md │ ├── 矮人.md │ └── 人类诸国.md ├── 03_超凡/ │ ├── 神系.md │ ├── 魔法体系.md │ └── 禁忌仪式.md ├── 04_势力/ │ ├── 王国与联盟.md │ └── 秘密结社.md ├── 05_人物/ │ └── 人物关系.md ├── 06_事件/ │ └── 关键事件.md └── scripts/ └── check_consistency.py数字前缀是我刻意加的，作用是让文件夹按顺序排列，AI在项目里浏览文件列表时，能一眼看出主次关系。内部关联采用“一处定义、处处引用”的做法，这个原则直接借用了代码里的DRY。比如精灵的寿命是800年，这个事实只写在02_种族/精灵.md里，其他文件需要提及时就写明“见02_种族/精灵.md”，而不是复制一份数据。复制意味着将来可能改一边漏一边，AI最擅长在这种地方制造矛盾。2.2 规则文件：相当于给AI一份“编码规范”AI Coding工具普遍支持在项目里放一个规则文件，比如社区里常说的rules文件，作用是让AI在每次生成前自动加载这些约束。我一开始没意识到这东西有多重要，直到AI连续两轮都写出了带现代感的对话，才明白必须把规则写死。我那份rules.md是这么写的：# 世界设定生成规则 - 所有名词以术语表为准：瑟兰迪尔只指代一座城市，不指任何人物。 - 禁止出现现代词汇：不得出现“手机”“互联网”“血压计”等。 - 年份一律采用“光复历 XXX年”格式，不得使用“前XX年”的模糊表述。 - 每个文件开头必须包含状态标记：draft（草稿）、confirmed（已确认）、archived（已归档）。 - 涉及人物状态时，必须与05_人物/人物关系.md保持一致。这个文件的价值在于，它把每次对话前手打一段要求的工作自动化了。你不需要每次重新跟AI强调“不要用现代词汇”，它自己就会读到规则文件并按规则执行。这就像给AI发了一份编码规范，虽然不能保证它百分之百不犯错，但能把低级错误率压到很低。2.3 总索引与术语表：让每个名词只有一个真实含义设定生成到后期，最怕的就是名词混乱。同一个地名，前面叫“白塔城”，后面变成“白塔堡”；同一个角色，前面叫“艾琳·光语”，后面被AI缩写成“艾琳”。解决这个问题的办法，是建立一个总索引和一个术语表。总索引就是index.md，相当于代码工程里的路由表。AI生成新文档时，第一步就是看这个文件，找到它应该参考哪些相关文档，避免漏掉重要上下文。术语表我用表格记录，结构很简单：名词类别一句话定义状态瑟兰迪尔城市精灵文明的首都，光复历前已存在confirmed艾尔德兰世界核心舞台大陆，周边有破碎群岛confirmed铁砧议会势力矮人诸部联盟的最高议事会confirmed状态列是关键。凡是画了confirmed的词条，就意味着这个定义已经锁死，任何人或AI都无权擅自修改。后续如果确实要调整，必须先更新术语表，再同步所有引用位置。这实际上就是代码工程里的“唯一数据源”思想。2.4 JSON设定卡：结构化数据才是校验的基础散文能提供阅读快感和氛围感，但它不适合做校验输入。AI生成一万字的长篇设定后，如果全是段落文本，你很难用脚本去检查里面有没有矛盾。所以我在项目里做了一个让步：让AI把核心事实抽成JSON设定卡，散文另存为描述文档。举个例子，一座城市的事实部分长这样：{ "name": "瑟兰迪尔", "category": "city", "founder": "艾琳·光语", "founded_year": 312, "population": "unknown", "status": "active", "notes": "精灵文明的首都，光复历后成为外交中心" }散文负责讲故事，JSON负责记事实。后续写检查脚本时，只需要读取所有JSON文件，就能做字段完整性检查、跨文件引用的矛盾检测。我承认让AI同时输出两种格式会多一点工作量，但相比后期人工通读几万字挑矛盾，这点成本非常划算。3. 从零生成万字世界设定的四步实操流程3.1 第一步：先写设定总纲，再谈万字输出我见过很多朋友一上来就扔给AI一句“帮我生成一个奇幻世界”，结果得到的是一篇极其无聊、充满了古早味元素的万金油设定。原因很简单：AI是概率模型，你的输入的约束越少，它输出的平均值就越平庸。我的做法是先手写一份设定总纲，把最关键的内容定死，不给AI太多自由决定的余地。总纲不用长，几百字就够，重点说清楚世界观基调、核心冲突和当前时间点。# 设定总纲（输入给AI的版本） - 世界名：艾尔德兰 - 基调：低魔、近现代、大陆破碎、旧神与凡人议会并存 - 核心冲突：旧神回归试图重塑世界 vs 凡人议会维持现有秩序 - 当前纪元时间：光复历 842年 - 自然法则：六大元素封印稳定存在，高阶魔法需要议会许可 - 文明形态：精灵偏保守，矮人重工业，人类处于议会联盟阶段这份总纲写完之后，再让AI先生成“纪元年表”。年表是整个世界观的时间骨架，后面的所有事件都要挂到这条时间线上，所以这个文件必须工整、严谨、可追溯。3.2 第二步：分批生成子文档，一次只做一件事很多人输就输在贪多。让AI一次性生成“全部世界观”，它会在同一段输出里出现两种巨龙体系、三种魔法来源，而且互相根本对不上。正确的做法是分批次生成，每批只产出一个子文档，并且明确告知AI的任务边界。我当时按这个顺序推进：总纲 → 纪元年表 → 地理 → 种族 → 神系/魔法 → 势力 → 人物关系 → 关键事件。每批给的提示词大概长这样：请阅读 00_总纲/纪元年表.md 和 01_地理/大陆地图.md，然后生成“主要城邦”文档。 要求： 1. 每个城邦包含：名称、位置、人口规模、统治者、与总纲核心冲突的关系。 2. 禁止新增总纲中没有的大陆。 3. 年份采用“光复历 XXX年”格式。 4. 输出完成后，在每座城邦的名称旁标注其所属地理区域。这样做的原因是，AI Coding工具的上下文窗口有限，任务边界越窄，它输出的质量越稳定。而且分批生成还有一个好处：每生成完一个文档，你都可以立刻检查，发现问题当场修正，不会把错误累积到后面。3.3 第三步：写一个设定矛盾扫描脚本这是整套流程里最有“工程感”的一步，也是普通AI聊天完全替代不了的一步。既然设定已经转成了JSON卡，就可以用脚本来自动检查矛盾。我写了一个不算复杂的Python脚本，核心逻辑有几条：重名检测、状态冲突检测、年份顺序检测。import json from pathlib import Path people = {} cities = {} for file in Path(".").rglob("*.json"): data = json.loads(file.read_text(encoding="utf-8")) if data.get("category") == "person": people.setdefault(data["name"], []).append(data) elif data.get("category") == "city": cities.setdefault(data["name"], []).append(data) # 1. 重名检测 dup_people = {n for n, items in people.items() if len(items) > 1} dup_cities = {n for n, items in cities.items() if len(items) > 1} if dup_people: print("[警告] 重名人物：", dup_people) if dup_cities: print("[警告] 重名城邦：", dup_cities) # 2. 人物状态与年份顺序检测，这里只做最简单的死亡早于登场检查 for name, items in people.items(): for item in items: born = item.get("born_year") died = item.get("died_year") if born and died and died < born: print(f"[错误] {name} 的死亡年份早于出生年份：{died} < {born}")这个脚本本身需要人工去适配自己的数据格式，但它说明了一件很重要的事：校验自动化完全可行。你不需要把脚本写得多么优雅，只要能把“低级但高频”的逻辑错误抓出来，就能省下大量人工通读的时间。实测下来，这一轮检查帮我找出了一处死亡年份早于登场时间的硬伤，以及一个重名城邦。3.4 第四步：人工复核与增量修正脚本能抓逻辑错误，但抓不了风格问题、情绪问题、审美问题。所以生成完成后，我会挑几个关键文档做人工复核。重点看三件事：专有名词是否和术语表一致；人物行为是否符合之前设定的性格；整体文风是否保持了统一的史诗感。发现BUG之后的修正过程，也要遵循“代码思维”。比如脚本提示某个角色在光复历412年死亡，但后续事件中他又登场了，这时候不能只改事件文档，而是要连人物卡、时间线、甚至其他相关事件的引用一起改。修正提示词我是这样下的：发现设定矛盾：角色奥德里奇在光复历412年死亡，但06_事件/第二纪元战争.md中他在420年再次登场。 请修改该事件文档，把登场时间改为409年，或在人物卡中将死亡年份更新为430年。 修改后同步更新所有引用该角色的文件，并在文件状态中注明“已修正”。整个过程不一定一次到位，可能需要跑两三轮“修改→扫描→再修改”。但我个人体验是，用这种增量修正的方式，一套设定基本能在三个晚上内稳定下来。比起一遍遍让AI重新生成全文，效率高得多。4. 我踩过的四个设定生成坑与排查实录4.1 纪元时间线连环冲突：AI“穿越”到了1000年后第一次生成“旧神回归”事件时，AI把回归时间写成了光复历1000年。问题在于，我在生成任务里没有给它总纲中“当前时间1942年”的明确提示，AI按照自己默认的“宏大叙事”惯性，直接跳到了一个很遥远的未来。这个问题非常有代表性。解决思路是：把“当前时间”写进rules.md，并强制所有事件文档都标注“与年表关系”。我整理了一张速查表，方便对照排查。常见问题典型表现排查思路预防手段时间线冲突事件发生在当前时间之后检查事件年份与总纲当前时间在规则文件中固定当前时间人物状态冲突死亡人物后续登场检查人物卡状态与事件文档生成事件前先读人物卡地理关系矛盾城市所在大陆前后不一致检查地理文件夹中的位置标注强制所有城邦标注地理区域名词重复定义同名不同体跑重名检测脚本用术语表统一名词归属4.2 同名不同人：两个伊莎差点被AI合并成一个人我的世界观里有两个叫“伊莎”的角色，一个是精灵诗人伊莎·晨露，一个是矮人铁匠伊莎·铁砧。AI生成战争场景时，把两个角色直接当成同一个人处理，让精灵诗人拿起了铁锤上战场。这个错误非常经典，核心原因就是我没有在术语表里给相似名字做区分。后来我立了一条硬规矩：所有重名或相似名的角色，必须带姓氏或氏族名，且在术语表中标注“与另一伊莎无关”。这条规矩让AI的后续生成再也没有把两人搞混过。其实，这就是给角色加“命名空间”——和代码里同名函数用不同包名区分是同一个道理。4.3 设定漂移：AI越写越嗨，自己发明了第七封印在生成“禁忌仪式”文档时，模型居然自己编了一个“第七封印”，但我的世界观体系里明明只有六元素封印。原因是我给它的上下文太薄，它不知道“六元素封印”是这个世界的铁律，于是按照“封印应该有七个”的套路记忆自行补全了。遇到这种超纲扩展，必须当场判断是接受还是拒绝。如果接受，就要把它正式录入规则文件和术语表，让这个“临时发挥”变成唯一事实来源；如果拒绝，就让AI删掉相关内容并恢复到六元素体系。但最怕的是什么都不做，留着这种半生不熟的设定在文档里，后续生成全都会被带偏。这就是典型的“设定漂移”，放任不管的后果就是整个世界观逐渐脱离你最初的设计。4.4 上下文窗口限制：AI开始“忘记”早期设定项目文件越来越多之后，AI Coding工具的上下文窗口开始吃紧。有一轮生成人物关系文档时，它居然把我最早期确认的“夜莺家族”设定忘得一干二净，导致人物关系里出现了一个完全不同的“夜莺商团”。这种情况不是模型笨，而是长上下文的注意力本来就有限，塞进去的东西太多，AI会优先看最近的对话和当前打开的文件。对策是维护一个“关键摘要.md”，每次任务前只喂摘要加当前相关文档，不把整个项目都塞进上下文。摘要必须精简到一屏能看完，只列最关键事实：# 关键摘要（每次生成前投喂） - 当前时间：光复历842年 - 已完成文件：见 index.md - 核心冲突：旧神回归 vs 凡人议会 - 禁止改动：六元素封印数量固定 - 待办：城邦贸易路线未定 - 特别注意：铁砧议会与精灵议会关系处于冷战期这个小改动立竿见影。此后AI生成相关文档时，哪怕项目已经几十个文件，它也能先把握住全局关键信息，再深入具体文件，错误率明显下降。5. 让AI写设定更顺手的四个进阶经验5.1 把确认过的设定固化进规则文件规则文件的初始内容只是基础约束，但它应该随着项目的推进不断“生长”。每当我在人工复核阶段确认了一条新设定，就把它同步写进rules.md。比如确认“人类蒸汽技术不能突破19世纪水平”，我就把它加入规则文件，之后AI生成任何科技向内容时都会自动受约束。这相当于让AI在每次生成前先读一遍最新设计文档，不需要你再重复叮嘱。规则文件越长，生成内容越稳，但注意别让它超过一屏，否则AI又会把后面的内容当噪音忽略掉。5.2 用git给设定上一道回滚保险这个经验完全是从代码工程里借来的。我的设定项目从第一天就初始化了git仓库，每生成完一个文件就提交一次。AI有时候会“好心”帮你修改一个旧文档，但改得乱七八糟，如果没有git，你就只能手动把它慢慢改回去。git init git add . git commit -m "初始设定：总纲与纪元年表"后续每次批量生成完成后，再提交一次。万一AI改坏了，用git checkout回退到某个稳定版本就行。哪怕不习惯命令行，也可以用代码编辑器的图形面板操作。这个习惯在生成到第三天时救了我一次，当时AI把某个种族的历史时间线整体改歪了，我花了不到一分钟就回到了前一天的稳定版本。5.3 用随机抽问代替逐字校对万字级别的设定集，逐字阅读是不现实的。我的做法是让AI自己考自己：随机抽几个人物，问他们当前年份应该在哪个位置、在做什么事情，然后和人物卡、事件文档对照。比如抽问“光复历842年，精灵诗人伊莎·晨露在哪个城市、在做什么”，AI会去项目里寻找相关文件，给出的答案再与人物关系文档交叉验证。抽问10个点，如果全对，那么这个体系基本是可信的；如果错了，就根据具体错误反推是哪一层文档出了问题。这个方法配合脚本扫描，比我人工埋头硬读效率高太多。5.4 诚实边界：这套流程不适合所有创作场景最后也得说点实话。这套工程化流程不是万能的，如果你只是随手写一个小短篇背景，几百字就可以讲完，完全没必要折腾目录、规则文件和JSON设定卡。如果你的创作过程极度依赖随机灵感、抗拒结构化约束，这套流程甚至会让你觉得束手束脚。它真正适合的是那些“规模大、角色多、要求长期一致”的项目，比如系列小说、跑团战役、游戏原型世界观。在这些场景下，一致性就是生命线，工程化不是负担而是保障。最后再分享一点个人体会。用AI Coding工具写设定，最大的收获不是字数快速涨到一万，而是它逼着我把灵感变成了结构。以前我构思奇幻世界时，满脑子都是漫无边际的脑洞；现在我会先问一句：这个设定放在哪个文件、由谁维护、和什么后续内容互相影响。听起来像在做软件工程，但奇幻世界本身就是要长期维护、反复扩展的系统。如果你正打算用AI生成一套长篇世界观，我建议你从目录结构和规则文件开始，哪怕第一版只有三四个文件，也比直接在聊天窗口里猛冲要靠谱得多。至少在我自己反复踩坑之后，这是目前唯一能让AI写设定写得不散架的办法。
如果你手里有一套AI编程辅助工具，除了写代码，它其实还非常适合做另一件事：生成一部万字级的奇幻世界设定。我最近用某款AI代码编辑器里的编程助手（下文简称CA，纯粹是为了叙述方便，不构成任何工具推荐），花了差不多三个晚上，把原本零散在脑子里的种族、地理、神系设定，整理成了一份有目录、有索引、可校验的完整世界观文档。整个过程下来，我的体会是：世界设定本质上是一个需要持续维护、保证内部一致的信息工程，而这恰好是AI Coding工具最擅长的领域。这篇实践记录就把完整思路和步骤拆给你看，适合那些想用AI做小说设定、跑团战役背景，或者游戏世界观构架的创作者参考。1. 为什么拿代码工具来写世界设定：可管理、可校验、可回滚1.1 从“聊天式写作”到“工程化写作”：状态从无到有最早我用AI聊天窗口写设定，发现一个很要命的问题：AI没有记忆。上午刚确定精灵王子的名字叫“凯尔萨”，下午再开一个新对话，它就给你写成“凯尔洛斯”；你问它上一版设定里某个城邦在哪里，它一脸茫然。原因很简单，聊天窗口里没有项目文件，每一次对话都是无状态的，AI只能依赖你临时塞给它的那点上下文。把同样的事情挪到AI Coding工具里，逻辑完全变了。你生成的所有设定都以文本文件的形式存在于同一个项目目录下，AI生成新内容之前，会自动扫描项目内的相关文件，把它当作参考上下文。这相当于代码仓库里所有模块共享一套类型定义，不会各写各的。我后来的工作方式就变成了：不是在聊天，而是在维护一个持续演进的设定仓库。每一次生成、修改、删除，都有文件层面的记录，随时可以翻看、回滚、对比。1.2 世界设定最大的敌人不是灵感，是内部矛盾写过一个长篇奇幻设定的人都知道，开头灵感迸发时是最爽的，但写到两万字之后，真正的噩梦不是“没东西写”，而是“对不上号”。某个角色在第一纪元建立了一座城邦，到第三纪元的时候，你又让他以“年轻的旅人”身份登场；前文明确说某种魔法只能由精灵使用，后文人类主角却莫名其妙施展了出来。这种问题，和代码里的全局变量被意外修改、接口定义前后不一致，本质上是同一回事。我见过很多创作者用Excel表格来管理设定，这比聊天强得多，但表格只能管“存在的事实”，管不了“矛盾的事实”。比如人物状态从“活着”变成“死亡”之后，还继续在后续事件中出现，这种逻辑冲突靠肉眼很难发现。AI Coding工具提供了一条新的解决路径：用脚本扫描。把设定转成结构化数据之后，写一个简单的检查脚本就能快速找出时间线冲突、人物状态冲突和名词重复定义。这种“代码级校验”的能力，是普通聊天AI和笔记软件给不了的。1.3 工具选型对比：代码编辑器凭什么赢过笔记软件有人可能会问：我直接用在线笔记软件管理设定不行吗？当然可以，但如果你需要大规模生成和长期一致性维护，代码编辑器的优势非常明显。对比维度AI Coding工具（CA）普通笔记软件内容形态纯文本/Markdown文件，可批量处理、全文检索富文本为主，批量处理能力弱规则约束项目规则文件自动生效，AI每次生成都遵守无类似机制，靠人工提醒校验手段可以编写脚本扫描矛盾，自动定位问题基本靠人工通读版本管理直接接入git，任意版本可回滚多数没有版本记录，改错难恢复我并不是否定笔记软件在头脑风暴阶段的作用，说实话，前期收集灵感、随手记碎片，我用得最多的还是笔记工具。但进入“生成万字设定”这个阶段之后，信息量一大，笔记软件的维护成本就开始失控。而AI Coding工具，本质上把设定变成了一个可编译的项目：有依赖、有约束、有测试。这一点，决定了它能扛住万字规模。2. 写设定之前先做四项工程化准备2.1 目录结构：把设定文件当代码模块来组织决定用AI Coding工具之前，我先花了一个小时设计目录结构。这步看起来基础，实际上决定了后续AI能不能准确找到需要的文件。我最终采用下面这个结构，供你参考：worldbook/ ├── rules.md ├── index.md ├── 00_总纲/ │ ├── 世界概述.md │ ├── 纪元年表.md │ └── 基础规则.md ├── 01_地理/ │ ├── 大陆地图.md │ ├── 主要城邦.md │ └── 气候与资源.md ├── 02_种族/ │ ├── 精灵.md │ ├── 矮人.md │ └── 人类诸国.md ├── 03_超凡/ │ ├── 神系.md │ ├── 魔法体系.md │ └── 禁忌仪式.md ├── 04_势力/ │ ├── 王国与联盟.md │ └── 秘密结社.md ├── 05_人物/ │ └── 人物关系.md ├── 06_事件/ │ └── 关键事件.md └── scripts/ └── check_consistency.py数字前缀是我刻意加的，作用是让文件夹按顺序排列，AI在项目里浏览文件列表时，能一眼看出主次关系。内部关联采用“一处定义、处处引用”的做法，这个原则直接借用了代码里的DRY。比如精灵的寿命是800年，这个事实只写在02_种族/精灵.md里，其他文件需要提及时就写明“见02_种族/精灵.md”，而不是复制一份数据。复制意味着将来可能改一边漏一边，AI最擅长在这种地方制造矛盾。2.2 规则文件：相当于给AI一份“编码规范”AI Coding工具普遍支持在项目里放一个规则文件，比如社区里常说的rules文件，作用是让AI在每次生成前自动加载这些约束。我一开始没意识到这东西有多重要，直到AI连续两轮都写出了带现代感的对话，才明白必须把规则写死。我那份rules.md是这么写的：# 世界设定生成规则 - 所有名词以术语表为准：瑟兰迪尔只指代一座城市，不指任何人物。 - 禁止出现现代词汇：不得出现“手机”“互联网”“血压计”等。 - 年份一律采用“光复历 XXX年”格式，不得使用“前XX年”的模糊表述。 - 每个文件开头必须包含状态标记：draft（草稿）、confirmed（已确认）、archived（已归档）。 - 涉及人物状态时，必须与05_人物/人物关系.md保持一致。这个文件的价值在于，它把每次对话前手打一段要求的工作自动化了。你不需要每次重新跟AI强调“不要用现代词汇”，它自己就会读到规则文件并按规则执行。这就像给AI发了一份编码规范，虽然不能保证它百分之百不犯错，但能把低级错误率压到很低。2.3 总索引与术语表：让每个名词只有一个真实含义设定生成到后期，最怕的就是名词混乱。同一个地名，前面叫“白塔城”，后面变成“白塔堡”；同一个角色，前面叫“艾琳·光语”，后面被AI缩写成“艾琳”。解决这个问题的办法，是建立一个总索引和一个术语表。总索引就是index.md，相当于代码工程里的路由表。AI生成新文档时，第一步就是看这个文件，找到它应该参考哪些相关文档，避免漏掉重要上下文。术语表我用表格记录，结构很简单：名词类别一句话定义状态瑟兰迪尔城市精灵文明的首都，光复历前已存在confirmed艾尔德兰世界核心舞台大陆，周边有破碎群岛confirmed铁砧议会势力矮人诸部联盟的最高议事会confirmed状态列是关键。凡是画了confirmed的词条，就意味着这个定义已经锁死，任何人或AI都无权擅自修改。后续如果确实要调整，必须先更新术语表，再同步所有引用位置。这实际上就是代码工程里的“唯一数据源”思想。2.4 JSON设定卡：结构化数据才是校验的基础散文能提供阅读快感和氛围感，但它不适合做校验输入。AI生成一万字的长篇设定后，如果全是段落文本，你很难用脚本去检查里面有没有矛盾。所以我在项目里做了一个让步：让AI把核心事实抽成JSON设定卡，散文另存为描述文档。举个例子，一座城市的事实部分长这样：{ "name": "瑟兰迪尔", "category": "city", "founder": "艾琳·光语", "founded_year": 312, "population": "unknown", "status": "active", "notes": "精灵文明的首都，光复历后成为外交中心" }散文负责讲故事，JSON负责记事实。后续写检查脚本时，只需要读取所有JSON文件，就能做字段完整性检查、跨文件引用的矛盾检测。我承认让AI同时输出两种格式会多一点工作量，但相比后期人工通读几万字挑矛盾，这点成本非常划算。3. 从零生成万字世界设定的四步实操流程3.1 第一步：先写设定总纲，再谈万字输出我见过很多朋友一上来就扔给AI一句“帮我生成一个奇幻世界”，结果得到的是一篇极其无聊、充满了古早味元素的万金油设定。原因很简单：AI是概率模型，你的输入的约束越少，它输出的平均值就越平庸。我的做法是先手写一份设定总纲，把最关键的内容定死，不给AI太多自由决定的余地。总纲不用长，几百字就够，重点说清楚世界观基调、核心冲突和当前时间点。# 设定总纲（输入给AI的版本） - 世界名：艾尔德兰 - 基调：低魔、近现代、大陆破碎、旧神与凡人议会并存 - 核心冲突：旧神回归试图重塑世界 vs 凡人议会维持现有秩序 - 当前纪元时间：光复历 842年 - 自然法则：六大元素封印稳定存在，高阶魔法需要议会许可 - 文明形态：精灵偏保守，矮人重工业，人类处于议会联盟阶段这份总纲写完之后，再让AI先生成“纪元年表”。年表是整个世界观的时间骨架，后面的所有事件都要挂到这条时间线上，所以这个文件必须工整、严谨、可追溯。3.2 第二步：分批生成子文档，一次只做一件事很多人输就输在贪多。让AI一次性生成“全部世界观”，它会在同一段输出里出现两种巨龙体系、三种魔法来源，而且互相根本对不上。正确的做法是分批次生成，每批只产出一个子文档，并且明确告知AI的任务边界。我当时按这个顺序推进：总纲 → 纪元年表 → 地理 → 种族 → 神系/魔法 → 势力 → 人物关系 → 关键事件。每批给的提示词大概长这样：请阅读 00_总纲/纪元年表.md 和 01_地理/大陆地图.md，然后生成“主要城邦”文档。 要求： 1. 每个城邦包含：名称、位置、人口规模、统治者、与总纲核心冲突的关系。 2. 禁止新增总纲中没有的大陆。 3. 年份采用“光复历 XXX年”格式。 4. 输出完成后，在每座城邦的名称旁标注其所属地理区域。这样做的原因是，AI Coding工具的上下文窗口有限，任务边界越窄，它输出的质量越稳定。而且分批生成还有一个好处：每生成完一个文档，你都可以立刻检查，发现问题当场修正，不会把错误累积到后面。3.3 第三步：写一个设定矛盾扫描脚本这是整套流程里最有“工程感”的一步，也是普通AI聊天完全替代不了的一步。既然设定已经转成了JSON卡，就可以用脚本来自动检查矛盾。我写了一个不算复杂的Python脚本，核心逻辑有几条：重名检测、状态冲突检测、年份顺序检测。import json from pathlib import Path people = {} cities = {} for file in Path(".").rglob("*.json"): data = json.loads(file.read_text(encoding="utf-8")) if data.get("category") == "person": people.setdefault(data["name"], []).append(data) elif data.get("category") == "city": cities.setdefault(data["name"], []).append(data) # 1. 重名检测 dup_people = {n for n, items in people.items() if len(items) > 1} dup_cities = {n for n, items in cities.items() if len(items) > 1} if dup_people: print("[警告] 重名人物：", dup_people) if dup_cities: print("[警告] 重名城邦：", dup_cities) # 2. 人物状态与年份顺序检测，这里只做最简单的死亡早于登场检查 for name, items in people.items(): for item in items: born = item.get("born_year") died = item.get("died_year") if born and died and died < born: print(f"[错误] {name} 的死亡年份早于出生年份：{died} < {born}")这个脚本本身需要人工去适配自己的数据格式，但它说明了一件很重要的事：校验自动化完全可行。你不需要把脚本写得多么优雅，只要能把“低级但高频”的逻辑错误抓出来，就能省下大量人工通读的时间。实测下来，这一轮检查帮我找出了一处死亡年份早于登场时间的硬伤，以及一个重名城邦。3.4 第四步：人工复核与增量修正脚本能抓逻辑错误，但抓不了风格问题、情绪问题、审美问题。所以生成完成后，我会挑几个关键文档做人工复核。重点看三件事：专有名词是否和术语表一致；人物行为是否符合之前设定的性格；整体文风是否保持了统一的史诗感。发现BUG之后的修正过程，也要遵循“代码思维”。比如脚本提示某个角色在光复历412年死亡，但后续事件中他又登场了，这时候不能只改事件文档，而是要连人物卡、时间线、甚至其他相关事件的引用一起改。修正提示词我是这样下的：发现设定矛盾：角色奥德里奇在光复历412年死亡，但06_事件/第二纪元战争.md中他在420年再次登场。 请修改该事件文档，把登场时间改为409年，或在人物卡中将死亡年份更新为430年。 修改后同步更新所有引用该角色的文件，并在文件状态中注明“已修正”。整个过程不一定一次到位，可能需要跑两三轮“修改→扫描→再修改”。但我个人体验是，用这种增量修正的方式，一套设定基本能在三个晚上内稳定下来。比起一遍遍让AI重新生成全文，效率高得多。4. 我踩过的四个设定生成坑与排查实录4.1 纪元时间线连环冲突：AI“穿越”到了1000年后第一次生成“旧神回归”事件时，AI把回归时间写成了光复历1000年。问题在于，我在生成任务里没有给它总纲中“当前时间1942年”的明确提示，AI按照自己默认的“宏大叙事”惯性，直接跳到了一个很遥远的未来。这个问题非常有代表性。解决思路是：把“当前时间”写进rules.md，并强制所有事件文档都标注“与年表关系”。我整理了一张速查表，方便对照排查。常见问题典型表现排查思路预防手段时间线冲突事件发生在当前时间之后检查事件年份与总纲当前时间在规则文件中固定当前时间人物状态冲突死亡人物后续登场检查人物卡状态与事件文档生成事件前先读人物卡地理关系矛盾城市所在大陆前后不一致检查地理文件夹中的位置标注强制所有城邦标注地理区域名词重复定义同名不同体跑重名检测脚本用术语表统一名词归属4.2 同名不同人：两个伊莎差点被AI合并成一个人我的世界观里有两个叫“伊莎”的角色，一个是精灵诗人伊莎·晨露，一个是矮人铁匠伊莎·铁砧。AI生成战争场景时，把两个角色直接当成同一个人处理，让精灵诗人拿起了铁锤上战场。这个错误非常经典，核心原因就是我没有在术语表里给相似名字做区分。后来我立了一条硬规矩：所有重名或相似名的角色，必须带姓氏或氏族名，且在术语表中标注“与另一伊莎无关”。这条规矩让AI的后续生成再也没有把两人搞混过。其实，这就是给角色加“命名空间”——和代码里同名函数用不同包名区分是同一个道理。4.3 设定漂移：AI越写越嗨，自己发明了第七封印在生成“禁忌仪式”文档时，模型居然自己编了一个“第七封印”，但我的世界观体系里明明只有六元素封印。原因是我给它的上下文太薄，它不知道“六元素封印”是这个世界的铁律，于是按照“封印应该有七个”的套路记忆自行补全了。遇到这种超纲扩展，必须当场判断是接受还是拒绝。如果接受，就要把它正式录入规则文件和术语表，让这个“临时发挥”变成唯一事实来源；如果拒绝，就让AI删掉相关内容并恢复到六元素体系。但最怕的是什么都不做，留着这种半生不熟的设定在文档里，后续生成全都会被带偏。这就是典型的“设定漂移”，放任不管的后果就是整个世界观逐渐脱离你最初的设计。4.4 上下文窗口限制：AI开始“忘记”早期设定项目文件越来越多之后，AI Coding工具的上下文窗口开始吃紧。有一轮生成人物关系文档时，它居然把我最早期确认的“夜莺家族”设定忘得一干二净，导致人物关系里出现了一个完全不同的“夜莺商团”。这种情况不是模型笨，而是长上下文的注意力本来就有限，塞进去的东西太多，AI会优先看最近的对话和当前打开的文件。对策是维护一个“关键摘要.md”，每次任务前只喂摘要加当前相关文档，不把整个项目都塞进上下文。摘要必须精简到一屏能看完，只列最关键事实：# 关键摘要（每次生成前投喂） - 当前时间：光复历842年 - 已完成文件：见 index.md - 核心冲突：旧神回归 vs 凡人议会 - 禁止改动：六元素封印数量固定 - 待办：城邦贸易路线未定 - 特别注意：铁砧议会与精灵议会关系处于冷战期这个小改动立竿见影。此后AI生成相关文档时，哪怕项目已经几十个文件，它也能先把握住全局关键信息，再深入具体文件，错误率明显下降。5. 让AI写设定更顺手的四个进阶经验5.1 把确认过的设定固化进规则文件规则文件的初始内容只是基础约束，但它应该随着项目的推进不断“生长”。每当我在人工复核阶段确认了一条新设定，就把它同步写进rules.md。比如确认“人类蒸汽技术不能突破19世纪水平”，我就把它加入规则文件，之后AI生成任何科技向内容时都会自动受约束。这相当于让AI在每次生成前先读一遍最新设计文档，不需要你再重复叮嘱。规则文件越长，生成内容越稳，但注意别让它超过一屏，否则AI又会把后面的内容当噪音忽略掉。5.2 用git给设定上一道回滚保险这个经验完全是从代码工程里借来的。我的设定项目从第一天就初始化了git仓库，每生成完一个文件就提交一次。AI有时候会“好心”帮你修改一个旧文档，但改得乱七八糟，如果没有git，你就只能手动把它慢慢改回去。git init git add . git commit -m "初始设定：总纲与纪元年表"后续每次批量生成完成后，再提交一次。万一AI改坏了，用git checkout回退到某个稳定版本就行。哪怕不习惯命令行，也可以用代码编辑器的图形面板操作。这个习惯在生成到第三天时救了我一次，当时AI把某个种族的历史时间线整体改歪了，我花了不到一分钟就回到了前一天的稳定版本。5.3 用随机抽问代替逐字校对万字级别的设定集，逐字阅读是不现实的。我的做法是让AI自己考自己：随机抽几个人物，问他们当前年份应该在哪个位置、在做什么事情，然后和人物卡、事件文档对照。比如抽问“光复历842年，精灵诗人伊莎·晨露在哪个城市、在做什么”，AI会去项目里寻找相关文件，给出的答案再与人物关系文档交叉验证。抽问10个点，如果全对，那么这个体系基本是可信的；如果错了，就根据具体错误反推是哪一层文档出了问题。这个方法配合脚本扫描，比我人工埋头硬读效率高太多。5.4 诚实边界：这套流程不适合所有创作场景最后也得说点实话。这套工程化流程不是万能的，如果你只是随手写一个小短篇背景，几百字就可以讲完，完全没必要折腾目录、规则文件和JSON设定卡。如果你的创作过程极度依赖随机灵感、抗拒结构化约束，这套流程甚至会让你觉得束手束脚。它真正适合的是那些“规模大、角色多、要求长期一致”的项目，比如系列小说、跑团战役、游戏原型世界观。在这些场景下，一致性就是生命线，工程化不是负担而是保障。最后再分享一点个人体会。用AI Coding工具写设定，最大的收获不是字数快速涨到一万，而是它逼着我把灵感变成了结构。以前我构思奇幻世界时，满脑子都是漫无边际的脑洞；现在我会先问一句：这个设定放在哪个文件、由谁维护、和什么后续内容互相影响。听起来像在做软件工程，但奇幻世界本身就是要长期维护、反复扩展的系统。如果你正打算用AI生成一套长篇世界观，我建议你从目录结构和规则文件开始，哪怕第一版只有三四个文件，也比直接在聊天窗口里猛冲要靠谱得多。至少在我自己反复踩坑之后，这是目前唯一能让AI写设定写得不散架的办法。