我大概半年前开始接一个偏“大世界观”的创作项目前期是按传统方式写设定文档结果写到两三万字时彻底失控了角色关系前后矛盾、时间线对不上、不同区域的地名拼写互相打架。反复修改几轮之后我决定换个思路——把整套奇幻世界设定当成一个“软件工程”来做用 AI Coding 工具辅助完成从框架搭建、内容生成到交叉校验的全流程。这篇文章就是我当时那份从立项到两万字级别产出的完整实践记录包含试过的具体方法、踩过的坑以及为什么不建议再用“问一句答一句”的方式拼凑大型设定。先把结论摆在这儿AI Coding 工具对“生成故事片段”这件事帮助有限但它对“搭建一套内部自洽的设定系统”帮助极大。你想要的不是一段漂亮散文而是一套能持续扩展、并且每加一个新设定都能自动回溯检查是否和旧设定冲突的“知识系统”。这刚好是工程思维的强项。1. 项目由来我为什么把奇幻设定做成了“软件工程”1.1 传统写作模式下世界观崩溃是迟早的事很多人写奇幻设定都经历过这个过程刚开始灵感充沛主线世界观、魔法体系、几个核心种族写起来非常顺畅。但随着内容量增长问题开始出现。我当时的项目里有一个细节某个中立商团在第二章里被描述成“由半身人主导的联合商会”但十几份资料之后我又在另一个区域的设定里写成了“人类贵族的幕后产业”。这种互相矛盾在传统文档写作里几乎无法避免——因为你不可能把每一份新增设定都和已有内容做即时比对。后来我试着做“设定集整理”把分散的文档按种族、地理、势力、编年史分类人工维护关联关系。这个方法在小规模下还能用一旦超过一定量级就会崩盘。原因很简单单人写作时维护不了那么多“关联规则”而且人脑对模糊一致性的容忍度很低经常会出现“我记得已经写过了实际没有”或“这里应该差不多实际已经变了”的判断偏差。1.2 为什么选择用 AI Coding 思维来重新定义“写设定”我真正开始转变思路是把“写设定”重新定义成“搭建一个带约束的内容系统”。用代码写作类比写小说像是在一个空白画布上自由作画而搭一个奇幻世界设定更像是写一套大型软件。软件需要定义数据结构、接口规范、模块边界还需要有自动检测机制确保不同模块之间互相兼容。设定文档本质上也是这个道理——种族卡是数据结构地区名是资源标识符编年史是时间线数据魔法体系是一套业务规则。AI Coding 工具擅长的事情恰恰是帮你搭出这套“骨架”再在这个骨架基础上做有序扩展。它不只是给你生成内容而是能帮你维护一套“项目结构”让新生成的内容自动归类到对应模块并对明显与既有设定冲突的点给出提示。虽然市面上主流的 AI Coding 工具更常用于写代码但我当时的实际感受是它们用来做结构化长文项目同样好使。某些 Agent 模式甚至能帮你拆分任务、分层产出、执行本地脚本做校验这比通用聊天窗口的交互形态更适合大工程量的内容生产。1.3 这里说的“AI Coding 工具”到底指什么为免混淆先明确一下我这次实践里用到的工具范围。我用的不是某个单一的聊天问答入口而是一套具备以下能力的辅助环境能理解项目上下文而不是每次从零开始能按照我指定的目录和文件结构生成内容能执行我给出的本地脚本或命令例如批量扫描文档、生成索引、检查重复命名能在连续多次的会话里维持同一个“项目状态”。当时的方案来自 GLM Coding Plan这个工具链在长上下文管理和 Agent 式任务拆分上做得比较顺滑比较适合中期项目。如果你平时用的是其他偏工程化的 AI 编程平台思路也是通用的不必拘泥于某一款。2. 设定系统的整体设计与“文档即代码”方案2.1 先搭模型还是让 AI 自由发挥直到真正动工前我都在纠结一个核心问题这个设定工程应该“自顶向下”设计还是“自底向上”生长传统做法往往是自顶向下先定义整个世界观的运转规则再逐步细化到具体种族、地点、人物。好处是宏观一致性有保障坏处是前期框架一旦设计得不够合理后期发现遗漏就得大改。AI 自由发挥式的自底向上看似轻快问题是生成量一大风格和定义都会漂移最后你得到的是几百段漂亮的“碎片”而不是一个能相互咬合的体系。我最终选择了一条折中路线先让人工定义“最小核心骨架”再让 AI 在这个骨架内做大量扩展最后用脚本自动检查扩展内容是否越界或冲突。这个骨架不需要特别细但必须把那几条“不可动摇”的设定定死。例如在我的奇幻项目里核心骨架包括世界分为五个大陆板块大陆之间通过季节性风暴海连接魔法来源来自一种统一能量场不同文明只是调用方式不同精灵族不能使用高熵魔法这是种族设定里的硬性限制编年史体系从“断刃历”开始纪年之前的时期统称“混沌纪元”。你可以把这几条理解成代码里的“底层常量”。后期不管生成多少内容一旦和常量冲突都应该被识别出来并打回重写。2.2 我如何设计设定文档的文件结构确定“底层常量”后下一步是设计这套设定文档的目录结构。类似代码工程的目录设计这里也要把“模块边界”划清楚避免多个文档反复描述同一个对象。我当时搭的项目结构如下笔记文件名示意worldbook/core/constants.md # 底层常量定义禁止冲突cosmology.md # 世界观与宇宙结构magic_rules.md # 魔法规则硬约束modules/races/ # 种族库children_of_ash.mddeep_elves.md...regions/ # 区域地理northern_wastes.mdsea_of_storms.md...factions/ # 势力组织trade_compact.mdimperial_court.md...timeline/ # 编年史assets/name_registry.json # 命名注册表避免地名/人名重复term_glossary.json # 术语对照表统一译名与概念定义scripts/check_conflicts.py # 自动冲突检测脚本build_index.py # 生成条目索引核心特征是把设定按领域拆分而不是按“文档篇幅”拆分。每个模块有明确的职责边界种族模块只管种族相关的生理、文化、特殊能力地区模块负责地理环境和聚落势力模块记录组织结构和外交关系时间线只做编年记录。如果在地区模块里发现大段种族背景介绍这就不是一个内容补充问题而是一个“模块职责越界”信号应该拆出来归位。2.3 设计“受控词表”与命名锚点大型设定最常见的混乱源是命名和术语不统一。同一个种族可能在不同早期文档里出现过三个叫法某座城市在不同势力的眼里也有不同称呼。这在文学作品里可能有叙事意图但在工程化设定里就是明显的 bug。我的做法是建一个命名对照表类似代码项目里的“资源注册中心”。每个关键实体有唯一编码同时允许存在多个口头别名但文档里第一次出现时必须挂到唯一编码上。用 JSON 管理这个表非常顺手名称北境灰烬族名称英文/别称Ashkin, Cinderfolk如果做多语版本会用唯一IDrace.ashkin分类humanoid/offshoot冲突条件不允许与其他种族主线混血后正常繁殖所有 AI 生成的新内容里一旦出现“另一个半身人种族来自北方高原”脚本就能在术语表里检索到冲突关键词并标记出来问项目方你到底是想新建种族还是这个词指向已有条目这种检测机制放到传统写作流程里大概需要一个人专门花大量时间逐页比对效率和准确性完全不可比。3. 实操记录从搭建骨架到产出万字级完整设定3.1 第一轮让 AI Coding 工具生成“模块模板”我不是直接让 AI 写最终设定正文而是先让它生成一套“模块模板”。这一步很重要——模板先行能保证所有后续扩展都遵循同一套格式后面的脚本校验才有意义。我的做法是给工具一段完整提示要求它先产出几个种族条目的模板样例。以种族卡为例模板结构大致长这样# 种族名Ashkin灰烬族 ## 基础信息 - 所属分类Humano? - 外貌体征两句以内 - 平均寿命数值 - 发源地必须引用 regions 模块中的已有条目 ## 生理与能力 - 核心种族能力一条主能力 - 种族限制必须列出没有则写“无” - 魔法亲和魔法亲和等级 ## 社会与文化 - 典型聚落形式 - 主要信仰/哲学 - 与哪些势力关系密切引用 factions 模块 ## 已知冲突与禁制 例如不能和其他种族繁衍或不能从事某些职业AI Coding 工具按这个模板生成种族卡的时候往往比自然语言聊天更稳定因为模板本身就是结构约束。它也知道每次输出都该往哪个字段填内容而不是忽然放飞写成一段散文。从这一步开始生成内容就不只是“内容资产”也变成了“可校验数据”。我们可以像检查代码规范一样检查哪些字段缺失、哪些引用不是有效锚点。3.2 第二轮按“模块优先顺序”逐步扩展模板齐了之后我没有让 AI 一口气生成所有模块的内容——那个量大到上下文窗口根本撑不住很容易把一个后期人物的性格写成前期反派的样子。取而代之的方式是把整个项目拆成几个可并行、可回归的阶段按“依赖顺序”扩展。我的扩展顺序是种族库优先。因为很多地区、城市、势力都建立在种族分工基础上先把各主要种族生理和文化基线定义好后面区域设置就能直接引用不需要重复描写种族属性。地理与区域第二。划清楚山川河流、主要城邦与交通线确保后期编年史和势力扩张有地图坐标可依附。这里的“地图坐标”不一定是像素级地图但至少要在文本层面有相对位置关系。势力与组织第三。势力的兴衰、冲突、结盟都依赖种族能力和地理条件放在第三位顺理成章。编年史最后。前面三层等于“资源系统”编年史则是在这个系统上运行的“状态迁移”。大部分早期冲突后面都能在编年史里找到对照位置不会莫名冒出没有前因后果的大事件。每完成一个模块就运行一次索引构建脚本。生成的索引文件不是给读者看的而是给我和 AI 工具自己看的。后续新内容想引用旧设定时工具可以先查索引直接用准确条目名而不是凭模糊记忆瞎编。这样做最大的收益是所有设定内容都可以被“追溯”后期内容产量上去了也不会逻辑断裂。3.3 写一个轻量冲突校验脚本到了这个阶段我需要的是自动化检查手段而不是纯靠肉眼或对话纠错。代码工程里这叫“测试”我把它搬到了文档项目里。我用本地脚本实现了几个基础检查核心逻辑很简单import json, re, pathlib TERM_REG json.load(open(assets/name_registry.json)) def check_unregistered_names(directory): for md_file in pathlib.Path(directory).rglob(*.md): text md_file.read_text(encodingutf-8) for possible_name in TERM_REG[aliases]: if possible_name not in text: continue registered TERM_REG[canonical][possible_name] # 如果文档里只出现别名但未挂接规范ID记录警告 if f[{registered}] not in text: print(f{md_file}: 出现别名 {possible_name}但未在开头引用规范ID)这段代码的思路很直白定义一套“规范名-别名”映射表每个设定文件都必须在自己归属的模块里声明主条目 ID。如果文档里出现某个规范 id 的别名但上下文没有建立锚点脚本就会告警。实际第一轮跑下来它帮我揪出了二十多处命名不一致。比如我原来设定里有一座城市叫“白塔港”但在某个后期势力文档里被描述成了“银港”——AI 生成时显然是根据某种语义联想换了一个名字。如果没有这条约束检查这两个名称会持续混用在后续内容里到最终成稿时又得花大代价统一。当然脚本并不能检查“叙事好不好看”或“设定是否有趣”这类主观问题它能识别的是确定性冲突。即便如此这项能力在长线项目中释放的劳动力已经非常可观。3.4 控制内容的“信息密度”而不是凑字数“万字级”听起来很唬人但实际操作里最需要警惕的是为了拉长篇幅无意义注水。AI 有个倾向你用模糊提示词让它扩展它会用一堆华丽形容词填补结构位置输出看着多实际有效信息密度很低。我做过一个测试同样一个“灰烬族与北境矮人的联盟关系”条目不加约束提给 AI产出了两千字风景描写和双方关系背景的泛泛陈述加上明确的“须包含起始年份、导火索、关键协议、对当代格局的影响”之后同样篇幅能覆盖四到五条实质信息量。所以我在生成指令里大量使用了必填字段和字数配额比如“用总计 800 到 1000 字描述该地区的自然环境和交通路线。必须提至少两条可被编年史利用的通路边界。”“这段不要重复‘魔法能量场’这条规则重点写它如何在该区域被仪式化利用。”“新角色卡必须填满所有模板字段。若某些字段暂不确定写 TODO不要编造虚假设定。”不要以为只有代码才需要 TODO设定文档同样需要。让 AI 明确地留出占位符比让它硬编一个将来很可能改的细节要聪明得多。我用这种方法防止了“过早优化”一个在早期阶段随意定下的数字后期可能成为卡住整个区域发展史的错误约束。3.5 四小时推进的实测进度简单汇报一下当时实际推进的节奏方便你建立一个数量级直觉第一小时搭建目录与核心常量文档人工审阅。AI 生成模板和三个样例种族卡我逐一改定了格式与措辞风格。 第二小时继续扩展剩下十多个主要种族并在每个区域文档里引用对应种族卡。 第三小时填充地理模块和两座主要城市的内部设定中间运行了两轮命名冲突脚本修复了十几个错误。 第四小时生成第一版势力关系网络和粗颗粒度编年史总字数达到约两万字框架文本。这个速度远超我之前纯人工方式的速度。更重要的是产出不是“一坨两万字文本”而是拆好类和索引的“两万字素材库”后续无论往哪个方向写长故事都有了一个调取快捷、验证方便的底层系统。4. 常见问题与排查技巧实录4.1 AI 总是“发明”新的地名人物怎么办这个问题几乎必然出现。AI 生成大量内容时即使你定义了命名表它还是会在具体行文里基于上下文“顺手”创造一两个新词。这不一定是坏事新地名也可能是有效的创意补充。但问题是它根本没有判断这个“新”是否有必要。我的处理方式是区分命名表的严格等级第一类核心实体大陆、主要种族、主神、关键城市禁止 AI 直接新建必须通过人工审批。第二类次要实体村庄、次级组织、非主线人物AI 可先拟名并登记到一个“备选词库”但不默认成为正史。第三类细节描述中无意带出的风物名允许存在但要在后期统一审校时决定是否保留。只有第一类实体才需要完全锁定。让 AI 在第二类、第三类保持一定自由度反而有助于丰富世界只是必须控制好它们的“权限边界”。4.2 风格总是不统一前后读起来像不同人写的这是 AI 写长文最明显的问题之一。同一个工具在不同批次生成内容时语气和详略分配会有偏差。比如前一个模块写得像编年史突然下一模块变成了轻小说口气放在一个设定集里特别扎眼。这里我用了一个“风格锚定文本”的办法。在项目根目录放一个 style_guide.md里面放一段从我自己已确认满意的内容里摘出来的样板并附上几条风格规则设定文风是干冷、审慎的叙事体不带现代网络用语。不使用偶然的俚语情感描写克制不加夸张抒情。句子平均长度中等大段设定优先拆成列表和短段落标题层级清晰。之后每次让 AI 扩展新模块我都会在提示词的开头放上“请参考 style_guide.md 中定义的行文风格”以确保上下文一致。实测这个方法比在对话里反复提醒“上次的口吻不错继续延续”有效得多因为样板是稳定锚点不受对话上下文漂移影响。4.3 输出了过时甚至与核心常量冲突的内容即便有了常量文件和校验脚本冲突仍然可能发生——通常并不是 AI 没读到常量而是它把冲突处理成了“例外”。例如你明确写了“灰烬族不能使用高熵魔法”但在一个英雄角色卡里它依然给角色配置了高熵禁术因为角色在剧情里看起来“很强”才算合理。这种冲突单靠“禁止”两个字很难拦住。我在实际做法里加了一层冗余约束constants.md 是底线同时新建了一个规则追加文件叫 restrictions.md把它与其他字段联动起来。例如“魔法亲和”字段填写时如果有“灰烬族”则最高只能到二级。提示词里规定每个角色卡的“能力来源”字段必须显式引用魔法规则模块的对应条目。最后跑一次 lint 脚本扫描是否出现“灰烬族高熵魔法”这种二元组合。有制度才谈得上执行。不要把检查全挂在AI的“自觉”上。4.4 上下文太短项目本身太长工具顾头不顾尾很多 AI Coding 工具在项目不大的时候能有效管理上下文但东西一多单次对话内部的注意力也会被稀释。如果硬要在一次超长会话里让 AI 从头保持同一套状态难度极大。我的解决办法是“分批次提交”。把每个模块的生成拆成独立的会话每次会话只给工具三项东西一个简短的“项目状态摘要”谁是谁、当前模块用到哪些锚点本次要扩展的具体文件内容上一版草案和要修改的字段本次任务的目标和验收标准不要让同一个会话无限延续也不要在一次会话里要求它同时产出种族、地理、势力和编年史内容。工具不是人但它的有效工作记忆也有限把任务切成“足够小但结构完整”的提交单位是提高质量的关键。4.5 这些经验对“纯写故事”有没有用有一个常见误解是AI Coding 工具只适合程序员和偏技术的人。实际上只要你的目标是管理一套复杂的知识系统它就能发挥作用。奇幻世界设定天然就是小型知识图谱实体、关系、事件、规则相互交织。任何需要反复引用、交叉验证、版本演进的文本项目都可以从这套工程方法里受益。换句话说这不是码农专属玩法而是一种“知识工作”的效率升级。唯一的要求是你愿意把内容当数据看而不是当“一次性灵感”看。5. 个人经验想做同样尝试的人我建议先留意这三点如果这篇文章能给你留下一件事我希望是不要把 AI Coding 工具理解成“更快帮我写完整篇文字”的机器而是“帮我管理大规模复杂内容系统”的协作对象。前者会把你带到数千字就因不可维护而返工的困境后者则能让设定素材像代码模块一样不断堆叠而逻辑不倒。具体操作时比较实用的三条建议是控制好“底层常量”的数量。不要把几百条信息都写成不可触动的设定。一旦常量过多扩展的灵活空间会被堵死AI 也会频繁触发冲突警示。一般来说三条到五条最硬性的规则就够了。坚持给输出建档。AI 批量生成的所有模块化内容务必让它们自动写入对应文件并登记索引哪怕牺牲一点生成速度。否则散落在聊天记录或临时文档里的高产内容是没办法被后期校验的。给自己留出“人工打磨”阶段。技术帮你解决规模和一致性问题它不会替代对世界独特性的判断。哪些内容让人惊叹、哪些体系足够自洽、哪条隐藏伏笔会牵动未来主线这些审美决策还是由人来主导更靠谱。这次项目做到后期我发现最有成就感的时刻不再是 AI 快速产出大段文字的时候而是跑完校验脚本后系统安静地告诉我“全部通过无冲突”的那几秒钟。它意味着眼前这套数万字的虚拟宇宙正在像一个精密仪器一样稳定运转。最后分享一个小操作如果你也想在类似项目里导入这套工作流先把以前写得最满意的一段设定找出来提炼成模板和风格锚点然后用“代码生成器”的方式让 AI 为每个模块按字段补全。别急着追求一天内铺完整个世界那是传统输出逻辑里最容易翻车的原始冲动。按模块推进、按批次生成、按脚本校验后面你会回来感谢这套流程的。