AI Coding工具被念叨了好几年但绝大多数讨论都只盯着“它能不能把代码写好”。前阵子我突发奇想拿AI Coding工具去做了一件很多人觉得不搭界的事生成一套完整的奇幻世界设定目标是一万字左右的体量要把世界观、地理、种族、历史、魔法体系、势力冲突全部串起来同时保证模块之间不打架。这篇记录就是这次实验的全程复盘适合正在做小说设定、游戏世界观或桌游模组的朋友参考。1. 项目初衷为什么拿AI Coding工具写世界设定1.1 一次针对上下文管理能力的压力测试做这个实验的理由很实际。我平时帮游戏团队搭世界观框架也给一些作者做长篇设定的咨询大家最头疼的从来不是没灵感而是灵感前后打架。一个角色在一个文档里三十岁在地图文档里变成三百岁一种魔法在规则文档里写明是稀有资源在剧情提纲里却人人都会。这类问题的本质不是单次写得好不好而是跨片段的记忆和一致性管理。AI Coding工具恰好是处理这类问题的强项。你仔细想想写代码的时候最怕什么最怕函数改了调用方不知道、全局变量偷偷被篡改、模块之间的依赖关系一团乱麻。为了对付这些问题程序员发明了文件、函数、接口、版本管理、自动化测试。AI Coding工具被训练出来的工作方式就是在多文件的项目环境里反复读取、修改、校验。这套模式放在长文本创作上等于天然支持“把设定集当作代码库来管理”。我的做法是不把设定集当成一篇“超长文章”让AI一口气写而是当成一个“软件开发项目”来拆。核心规则独立成文件各模块独立成文件模块之间通过统一的术语表和事实表来同步。这个思路看着机械但实验做下来效果比在纯聊天窗口里手动续写要稳得多。聊天窗口最致命的问题就是你续写三千字以后模型早就把你最初设下的“七天一次雾潮”忘干净了但在文件系统里它每次动笔前都能真正读到这些规则。这篇记录会把整个实验从目标、工具选型、实操流程到翻车现场完整复盘一遍。如果你准备做自己的小说设定、桌游战役背景或者只是好奇AI Coding Agent能不能干点代码之外的正经事这篇内容应该能给你一个可以直接上手的答案。1.2 验收标准与“万字”到底怎么定义先把“万字”这件事说清楚。我这里说的不是模型输出字数的上限而是最终交付设定集的实际阅读体量。我定的验收范围是正文8000到12000个汉字不包含文件目录、术语表、提示词这类元内容。为什么不定得更长因为一万字左右正好是一个中大型世界设定的合适剂量既要覆盖必要的模块又不至于膨胀到失去控制。我当时做的项目代号叫“雾海群岛”。主题是一句非常简练的话在年复一年的雾潮中人类依托巨型灯塔和锈蚀魔法生存每个灯塔都是一个孤立的微型王国。按这个主题我要求整个设定集至少包含以下模块世界底层规则雾海的形成原因和运行规律潮汐周期、雾对魔法的影响地理与聚落群岛分布灯塔的坐标、规模、资源特点种族与身份人类分支、近海种族、灯塔共生体每个种群的文化与禁忌科技与魔法体系锈蚀魔法的获得方式、代价、限制势力关系主要阵营、目标、冲突点历史时间线从“旧大陆崩塌”到“灯王议会成立”再到当代危机故事钩子至少10个可以直接发展成小说或跑团模组的事件线索验收标准有三条。第一一致性。所有模块里的关键设定不能互相矛盾我用术语表来索引。第二可读性。不是梗百科式的条目堆砌而是每个条目都落在一个具体场景里。第三可扩展。新加的设定不能推翻旧设定这是我后续实际写作时要用的公共底座。这里面有个容易忽略的点用AI Coding工具做创作时你必须在项目最开始就把“验收标准”写进提示词文件。否则Agent很容易在追求完整性的过程中给你生成一堆正确但毫无灵魂的百科全书条目。这个细节我在第三节会具体演示怎么约束它。2. 工具选型与流程设计把写书变成“开发任务”2.1 我为什么选择AI Coding Agent而不是普通聊天AI很多人可能会说“用ChatGPT也能写啊为什么非要用AI Coding工具”我之前也这么想但比较过之后就发现普通对话式AI和编码Agent在面对一万字长内容时根本不是同一个物种。普通对话式AI适合一次性完成短篇幅创作比如一篇文章、一封邮件、一段剧情梗概。你要它续写它确实能写但超过几千字后它只能依赖上下文窗口里的碎片记忆。这个体验做过长篇辅助的人应该都有你明明在第一轮告诉过它的“主角不能使用冰系魔法”到第五轮它突然写了个冰冻魔法阵出来你还得专门纠正再往下写它又忘了。AI Coding工具的核心差别在于它不是一个“回答你问题”的聊天框而是一个“能操作项目文件”的Agent。它可以打开项目里的其他文件把已经写好的设定读进来再基于这些内容生成新模块。换句话说它把“记忆”从模型上下文里搬到了磁盘上。模型可能还会忘事但文件不会忘。只要Agent每次动笔前被要求先读设定总表它写出来的内容就大概率不会跑偏。我手头常用的编码Agent是带有Plan模式的GLM Coding Plan用起来比较顺手的一点是它会在改动前先形成一个任务清单我再勾选确认然后才动手。这套“先规划、再执行”的流程做代码时能防止Agent乱改文件做设定集时也很有用我能清楚看到它在哪个模块上打算怎么写而不是直接把整个文件覆盖掉。当然工具不是关键你用其他支持文件读写和多轮规划的Agent也行核心思路完全通用。对比维度普通对话式AIAI Coding Agent上下文记忆主要靠对话历史靠读文件历史可落盘长内容的一致性容易在数千字后失忆每次可加载相同规则项目结构单线问答多文件、可规划、可审计回滚能力基本没有配合Git可任意回滚适用规模短篇、单次输出万字以上、多模块协作2.2 把创作流程“开发化”模块边界、依赖与版本记录这部分是整个实验的骨架。我建议你先在项目目录里建好一个清晰的目录哪怕只有你一个人在用。目录本身就是给Agent看的“项目地图”。我当时建的目录大概长这样mist-archipelago/ ├── project_brief.md # 项目目标、验收标准、写作规范 ├── world_rules.md # 世界底层规则最关键的一个文件 ├── terminology.md # 术语表所有人名地名世界观名词 ├── geography.md # 地理与聚落 ├── races.md # 种族与身份 ├── magic_system.md # 魔法体系 ├── factions.md # 势力关系 ├── timeline.md # 历史时间线 ├── story_hooks.md # 故事钩子 └── CHECKLIST.md # 修改进度与校验清单每个文件的职责边界要提前定义好谁也不能越界。比如“锈蚀魔法是否依赖灯塔信号”这条写世界规则的人决定写魔法体系的人不能绕过规则自己去发明一个新答案。所以在提示词里我会专门要求Agent在修改前先读world_rules.md和terminology.md只有这两个文件是“必须遵守的上级规则”其他文件之间如果冲突以它俩为准。这与软件开发里的依赖关系非常像。把world_rules看作全局配置把terminology看作公共接口把其他文档看作各个模块。模块之间不允许直接引用未注册的术语这样遇到冲突时你只需要改上层配置下游模块同步刷新就行。这个隐喻在写作领域也完全成立。版本记录我也按代码项目的习惯做了。每完成一个模块我会手动执行一次Git提交或者让Agent生成一个快照版本。这么做最实际的好处是当Agent在某个文件里自作主张改掉一个设定导致后续内容逻辑崩坏时我能直接回到上一版而不是重新生成一遍。编码工具的项目化能力在写作里的价值就是从这些看起来很小、但极其频繁的失误中体现出来的。在生成开始之前我还往project_brief.md里写了一段“创作规范”。包括所有种族名称首次出现时需要标注音标和别称每个地理条目至少包含一个具体的“人物视角”描述魔法体系里每种能力的代价必须明确。这一页纸就是给Agent的验收标准。后续每次生成新模块我都会让它先读一遍规范再干活。3. 实操过程从一句主题词到万字设定集3.1 先用15分钟生成世界骨架整个流程的第一步不是让Agent直接开写而是让它在规范文件的基础上产出“世界骨架”。骨架是一份偏概括的设定大纲它不负责最终的文采只负责锁定所有关键决策。我用的初始指令大概是这样的你是本项目的主编助理。请基于project_brief.md先输出一份“世界骨架” 1. 一句话世界观 2. 5条世界底层规则 3. 7个主要地理区域 4. 5个主要种族/群体 5. 魔法体系的核心机制 6. 3个历史纪元 7. 10个故事钩子的关键词列表 每一条都要在三行以内写清楚不要展开。输出后我会逐一确认确认后才允许进入正式写作阶段。这样做的用意是让关键设定快速固定下来避免Agent在详细写作时反复横跳。骨架从生成到确认我只花了十五分钟左右。我的初始主题句只有一句话但Agent基于project_brief里的约束把它扩展成了一组可靠的基础设定。举例来说世界底层规则里它生成了一条“雾潮每七年一次大潮持续九个月期间所有蚀刻魔法失灵灯芯必须靠青铜火匣维持。”这个设定被固定在world_rules.md后后续所有与魔法、历法、历史相关的模块都必须无条件遵守。在第四节我会讲到有次我没盯紧故事钩子模块差点写出“大潮前夜灯芯突然失灵”这句话因为按规则大潮期间灯芯本来就不靠“正常魔法”工作这里应该写“火匣供应中断”而不是灯芯失灵。世界骨架定下来之后我在CHECKLIST.md里把每个模块的预期字数标记为800到1500字之间总目标定在1万字左右。这里有几个关键点不要让AI一次性生成整个文档单独一次生成所有模块很容易让模块之间的关联设定彼此冲突而且字数一多模型输出质量会明显下降。3.2 逐模块生成每次只让它“写一段”骨架确认完就进入了密集的模块生成环节。一次只让Agent生成一个模块顺序上我做了刻意安排世界规则、地理、种族、魔法、势力、历史、故事钩子。这里的逻辑是“依赖先行”地理可以和世界规则互相印证种族需要地理做舞台魔法依赖种族和生产方式势力冲突依赖历史背景故事钩子又依赖前面全部模块。每一步都只基于已经稳定下来、锁进文件的内容来写极大减少出尔反尔。我用的模块指令通常长这样请阅读world_rules.md、terminology.md、geography.md然后完成races.md的写作。 要求 - 主文件正文1500字左右中文 - 列出至少4个种族/群体每个种族包含文化、禁忌、代表性人物 - 每个条目不少于150字必须包含具体场景 - 不得引入terminology.md中不存在的专有名词除非你同时申请新增新增时先提交术语登记特别注意“不得引入术语表里不存在的专有名词”这句话。这是我事后总结的最有效的一条约束。没有这句约束的时候Agent每写一个模块都会顺手发明好几个地点和人物名字而这些名字只在这个模块里出现一次后续模块根本不会提及造成大量无用信息。加了约束之后它会把新名字作为“待登记项”放在文件末尾方便我决定是否保留。生成的时候我还会手动控制节奏。每个模块写完后我会让Agent输出一个“本次关键设定变更摘要”比如新增了哪些术语、沿用了哪些旧设定、有没有刻意引用旧文件里的内容。然后我把这个摘要贴回CHECKLIST.md。这样每次进入下一轮Agent即便没有自动读取所有文件也有一份手动汇总在手边。虽然这一道工序看起来像是“人工给AI当助手”但实际操作中能省掉大量返工。等到七个模块全部写完文档树里已经积攒了超过1万字的正文另外还有术语表、规则文件、检查清单等辅助内容。打开每个文件正文长度都在预期区间内。有了这些素材后面无论是写小说还是做游戏内容都可以直接当作公共设定来调用。3.3 用审校清单做一致性收尾正文生成完之后还远远没有到能交付的程度。接下来我会开启一个新的Agent会话不给它任何前面对话历史只让它读取全部文件然后做一次“交叉审校”。这种“断例会话语境”的做法很关键它强迫模型完全依赖文件内容来判断而不是依赖对话记录里那些不完整、可能有偏差的记忆。审校时我给的指令是请逐一读取mist-archipelago目录下的所有.md文件找出以下问题 1. 同一个专有名词在不同文件中的定义是否存在冲突 2. 时间线是否与“七年大潮”等世界规则冲突 3. 魔法体系的代价是否在不同模块中被省略或改变 4. 是否有明显重复的段落或信息 请输出一个“问题清单”按严重程度排序并标注具体文件与建议修改方式。这一步跑完它会输出一份很有价值的问题清单。我遇到的数量通常在十到十五个左右其中真正严重的冲突会有两三个。比如种族文件里写了“灯塔人平均寿命可达三百岁”但术语表里同一个种族的寿命写的是“一百二十岁”这种直接矛盾如果不查根本发现不了因为两个文件不会同时出现在同一个视野里。拿到问题清单后我会逐条确认然后让Agent生成对应的补丁版本。改动可能会连带到其他文件比如寿命改掉历史时间线里那个角色“在位一百五十年”也需要同步调整。所以我修完以后会再跑一次交叉审校直到问题清单为空。这一轮是纯人工监督流程没有捷径。4. 踩坑实录四个最典型的翻车现场这个项目做完我踩过的坑可以单独开一篇文章。这里挑四个最典型的几乎每个想用AI Coding工具做长文本创作的人都会遇到。4.1 输出的不是设定文而是“梗百科”第一次生成时我犯了一个新手错误没有在模块指令里规定“每条内容的最少字数”和“需要包含具体场景”。结果世界观条目被写成了类似“雾海雾海是群岛周围的海域每年有九个月被雾覆盖雾气会干扰魔法。”这样的百科条目。技术上没有错但作为设定集它没有任何画面感也没有人文气息。这个问题在编码Agent上比普通对话式AI更严重原因在于Agent更习惯按“任务清单”执行天然倾向用最简洁、最格式化的方式完成任务。你要让它写出有质感的文字就必须把要求给足。我给每个条目设置了“不低于150字”和“必须包含至少一个角色场景或物件细节”的硬约束才逐步扭转回来。具体来说我给races.md里“灯奴”这个群体写的示范条目是“灯奴不是奴隶制意义上的奴工而是自愿与灯芯共生的一群人。他们右臂上带着与塔芯同源的蚀刻纹路每逢大潮前三天纹路会自发亮起青色微光此时他们能听见塔芯的低频音但代价是牙齿会逐渐变脆。他们多数活不过五十岁却坚持认为这是最体面的一种活法。”这一类细节模型本来就能写得出来关键是你要把它逼出来。4.2 两个模块之间互相打架这是所有长文本创作者最痛的问题。我有一次在factions.md里写了一座城市叫“铜冠港”设定它是灯王议会的驻地但在geography.md里同一座城市被写成了“灯王议会象征意义上的旧都”议会实际已经迁到别处。两个文件分开看都对合在一起就矛盾。排查下来原因很直接生成地理模块时模型还只读过世界规则没有读到势力模块的规划所以它按照自己的理解给城市安排了身份。解决方式就是我前面提到的术语表与交叉审校。把“城市-政治地位-所属势力”这种关系写进terminology.md后续生成任何文件时都要求以术语表为准矛盾就会大幅减少。4.3 开场输出惊艳后期质量明显崩坏如果你在一个Agent会话里连续生成太多内容会出现一个现象前几个模块文笔和逻辑都在线越到后面越敷衍。它不是变笨了而是上下文累积越来越长加上部分平台会自动压缩早期信息模型能参考的有效内容越来越少于是只能靠模板化输出凑数。我最后采取的应对策略是“化整为零”。每个模块单独开一个会话生成但每次让Agent启动前先读取world_rules.md、terminology.md、以及与该模块相关的上游文件。这样每次会话的上下文都保持干净模型不需要记住一大堆历史只要每次读取当前最新文件即可。这个方法的效果在我个人对比下非常明显尤其是最后一个“故事钩子”模块如果放在同一个会话里连续写到第十个钩子时质量会明显下滑单独会话生成时十个钩子都能保持至少相近的水平。4.4 重复段落和“幻觉新词”还有两个小而高频的坑。一个是重复Agent会在同一个文档里用几乎一样的表述反复描述同一种现象比如“锈蚀魔法需要消耗使用者的生命力”在magic_system.md里出现了三次。这通常是因为在连续生成时它不确定自己是否已经写过了。我一般会用文档处理软件的统计替换功能快速扫描或者直接给Agent下指令“统计并删除完全重复或高度重复的段落”。另一个是“幻觉新词”。它会突然在历史时间线里发明一个术语表里没有的种族名“潮栖民”而事实上这个种族在races.md里叫“雾居者”。这种问题单独看完全没有问题你甚至觉得这个词很有画面感。但前后文一对照读者会立刻觉得设定不严谨。我用术语登记机制来约束如果确实想用新词必须先写入terminology.md获得“登记”否则默认使用已有术语。这样能挡掉大部分无意识发明。5. 可复制的经验如何用AI Coding工具做长文本创作5.1 什么是合适的场景什么是过度包装经过这个实验我比较确定AI Coding工具在长文本创作里是有真实价值的但价值有边界。它最适合的场景是那些模块化强、一致性要求高、总字数在几千到几万字之间的内容。典型的有游戏世界观设定集、小说创作蓝图、跑团模组背景、方法论手册、产品说明书的初稿。这些内容天然适合拆成多个文件而且都有“不能前后矛盾”的硬要求。不太适合的场景是那些必须依赖作者独特语言风格、叙事节奏和情绪的纯文学作品。AI Coding工具本质上更适合做“项目管理型”的长文本而不是“风格表演型”写作。如果你要写一篇需要强烈个人声音的散文那用普通对话式AI也要谨慎因为它同样会给你套上模板语气。但至少Agent能在结构和一致性上帮你兜 把写作当开发：AI Coding Agent的万字世界观实验
AI Coding工具被念叨了好几年但绝大多数讨论都只盯着“它能不能把代码写好”。前阵子我突发奇想拿AI Coding工具去做了一件很多人觉得不搭界的事生成一套完整的奇幻世界设定目标是一万字左右的体量要把世界观、地理、种族、历史、魔法体系、势力冲突全部串起来同时保证模块之间不打架。这篇记录就是这次实验的全程复盘适合正在做小说设定、游戏世界观或桌游模组的朋友参考。1. 项目初衷为什么拿AI Coding工具写世界设定1.1 一次针对上下文管理能力的压力测试做这个实验的理由很实际。我平时帮游戏团队搭世界观框架也给一些作者做长篇设定的咨询大家最头疼的从来不是没灵感而是灵感前后打架。一个角色在一个文档里三十岁在地图文档里变成三百岁一种魔法在规则文档里写明是稀有资源在剧情提纲里却人人都会。这类问题的本质不是单次写得好不好而是跨片段的记忆和一致性管理。AI Coding工具恰好是处理这类问题的强项。你仔细想想写代码的时候最怕什么最怕函数改了调用方不知道、全局变量偷偷被篡改、模块之间的依赖关系一团乱麻。为了对付这些问题程序员发明了文件、函数、接口、版本管理、自动化测试。AI Coding工具被训练出来的工作方式就是在多文件的项目环境里反复读取、修改、校验。这套模式放在长文本创作上等于天然支持“把设定集当作代码库来管理”。我的做法是不把设定集当成一篇“超长文章”让AI一口气写而是当成一个“软件开发项目”来拆。核心规则独立成文件各模块独立成文件模块之间通过统一的术语表和事实表来同步。这个思路看着机械但实验做下来效果比在纯聊天窗口里手动续写要稳得多。聊天窗口最致命的问题就是你续写三千字以后模型早就把你最初设下的“七天一次雾潮”忘干净了但在文件系统里它每次动笔前都能真正读到这些规则。这篇记录会把整个实验从目标、工具选型、实操流程到翻车现场完整复盘一遍。如果你准备做自己的小说设定、桌游战役背景或者只是好奇AI Coding Agent能不能干点代码之外的正经事这篇内容应该能给你一个可以直接上手的答案。1.2 验收标准与“万字”到底怎么定义先把“万字”这件事说清楚。我这里说的不是模型输出字数的上限而是最终交付设定集的实际阅读体量。我定的验收范围是正文8000到12000个汉字不包含文件目录、术语表、提示词这类元内容。为什么不定得更长因为一万字左右正好是一个中大型世界设定的合适剂量既要覆盖必要的模块又不至于膨胀到失去控制。我当时做的项目代号叫“雾海群岛”。主题是一句非常简练的话在年复一年的雾潮中人类依托巨型灯塔和锈蚀魔法生存每个灯塔都是一个孤立的微型王国。按这个主题我要求整个设定集至少包含以下模块世界底层规则雾海的形成原因和运行规律潮汐周期、雾对魔法的影响地理与聚落群岛分布灯塔的坐标、规模、资源特点种族与身份人类分支、近海种族、灯塔共生体每个种群的文化与禁忌科技与魔法体系锈蚀魔法的获得方式、代价、限制势力关系主要阵营、目标、冲突点历史时间线从“旧大陆崩塌”到“灯王议会成立”再到当代危机故事钩子至少10个可以直接发展成小说或跑团模组的事件线索验收标准有三条。第一一致性。所有模块里的关键设定不能互相矛盾我用术语表来索引。第二可读性。不是梗百科式的条目堆砌而是每个条目都落在一个具体场景里。第三可扩展。新加的设定不能推翻旧设定这是我后续实际写作时要用的公共底座。这里面有个容易忽略的点用AI Coding工具做创作时你必须在项目最开始就把“验收标准”写进提示词文件。否则Agent很容易在追求完整性的过程中给你生成一堆正确但毫无灵魂的百科全书条目。这个细节我在第三节会具体演示怎么约束它。2. 工具选型与流程设计把写书变成“开发任务”2.1 我为什么选择AI Coding Agent而不是普通聊天AI很多人可能会说“用ChatGPT也能写啊为什么非要用AI Coding工具”我之前也这么想但比较过之后就发现普通对话式AI和编码Agent在面对一万字长内容时根本不是同一个物种。普通对话式AI适合一次性完成短篇幅创作比如一篇文章、一封邮件、一段剧情梗概。你要它续写它确实能写但超过几千字后它只能依赖上下文窗口里的碎片记忆。这个体验做过长篇辅助的人应该都有你明明在第一轮告诉过它的“主角不能使用冰系魔法”到第五轮它突然写了个冰冻魔法阵出来你还得专门纠正再往下写它又忘了。AI Coding工具的核心差别在于它不是一个“回答你问题”的聊天框而是一个“能操作项目文件”的Agent。它可以打开项目里的其他文件把已经写好的设定读进来再基于这些内容生成新模块。换句话说它把“记忆”从模型上下文里搬到了磁盘上。模型可能还会忘事但文件不会忘。只要Agent每次动笔前被要求先读设定总表它写出来的内容就大概率不会跑偏。我手头常用的编码Agent是带有Plan模式的GLM Coding Plan用起来比较顺手的一点是它会在改动前先形成一个任务清单我再勾选确认然后才动手。这套“先规划、再执行”的流程做代码时能防止Agent乱改文件做设定集时也很有用我能清楚看到它在哪个模块上打算怎么写而不是直接把整个文件覆盖掉。当然工具不是关键你用其他支持文件读写和多轮规划的Agent也行核心思路完全通用。对比维度普通对话式AIAI Coding Agent上下文记忆主要靠对话历史靠读文件历史可落盘长内容的一致性容易在数千字后失忆每次可加载相同规则项目结构单线问答多文件、可规划、可审计回滚能力基本没有配合Git可任意回滚适用规模短篇、单次输出万字以上、多模块协作2.2 把创作流程“开发化”模块边界、依赖与版本记录这部分是整个实验的骨架。我建议你先在项目目录里建好一个清晰的目录哪怕只有你一个人在用。目录本身就是给Agent看的“项目地图”。我当时建的目录大概长这样mist-archipelago/ ├── project_brief.md # 项目目标、验收标准、写作规范 ├── world_rules.md # 世界底层规则最关键的一个文件 ├── terminology.md # 术语表所有人名地名世界观名词 ├── geography.md # 地理与聚落 ├── races.md # 种族与身份 ├── magic_system.md # 魔法体系 ├── factions.md # 势力关系 ├── timeline.md # 历史时间线 ├── story_hooks.md # 故事钩子 └── CHECKLIST.md # 修改进度与校验清单每个文件的职责边界要提前定义好谁也不能越界。比如“锈蚀魔法是否依赖灯塔信号”这条写世界规则的人决定写魔法体系的人不能绕过规则自己去发明一个新答案。所以在提示词里我会专门要求Agent在修改前先读world_rules.md和terminology.md只有这两个文件是“必须遵守的上级规则”其他文件之间如果冲突以它俩为准。这与软件开发里的依赖关系非常像。把world_rules看作全局配置把terminology看作公共接口把其他文档看作各个模块。模块之间不允许直接引用未注册的术语这样遇到冲突时你只需要改上层配置下游模块同步刷新就行。这个隐喻在写作领域也完全成立。版本记录我也按代码项目的习惯做了。每完成一个模块我会手动执行一次Git提交或者让Agent生成一个快照版本。这么做最实际的好处是当Agent在某个文件里自作主张改掉一个设定导致后续内容逻辑崩坏时我能直接回到上一版而不是重新生成一遍。编码工具的项目化能力在写作里的价值就是从这些看起来很小、但极其频繁的失误中体现出来的。在生成开始之前我还往project_brief.md里写了一段“创作规范”。包括所有种族名称首次出现时需要标注音标和别称每个地理条目至少包含一个具体的“人物视角”描述魔法体系里每种能力的代价必须明确。这一页纸就是给Agent的验收标准。后续每次生成新模块我都会让它先读一遍规范再干活。3. 实操过程从一句主题词到万字设定集3.1 先用15分钟生成世界骨架整个流程的第一步不是让Agent直接开写而是让它在规范文件的基础上产出“世界骨架”。骨架是一份偏概括的设定大纲它不负责最终的文采只负责锁定所有关键决策。我用的初始指令大概是这样的你是本项目的主编助理。请基于project_brief.md先输出一份“世界骨架” 1. 一句话世界观 2. 5条世界底层规则 3. 7个主要地理区域 4. 5个主要种族/群体 5. 魔法体系的核心机制 6. 3个历史纪元 7. 10个故事钩子的关键词列表 每一条都要在三行以内写清楚不要展开。输出后我会逐一确认确认后才允许进入正式写作阶段。这样做的用意是让关键设定快速固定下来避免Agent在详细写作时反复横跳。骨架从生成到确认我只花了十五分钟左右。我的初始主题句只有一句话但Agent基于project_brief里的约束把它扩展成了一组可靠的基础设定。举例来说世界底层规则里它生成了一条“雾潮每七年一次大潮持续九个月期间所有蚀刻魔法失灵灯芯必须靠青铜火匣维持。”这个设定被固定在world_rules.md后后续所有与魔法、历法、历史相关的模块都必须无条件遵守。在第四节我会讲到有次我没盯紧故事钩子模块差点写出“大潮前夜灯芯突然失灵”这句话因为按规则大潮期间灯芯本来就不靠“正常魔法”工作这里应该写“火匣供应中断”而不是灯芯失灵。世界骨架定下来之后我在CHECKLIST.md里把每个模块的预期字数标记为800到1500字之间总目标定在1万字左右。这里有几个关键点不要让AI一次性生成整个文档单独一次生成所有模块很容易让模块之间的关联设定彼此冲突而且字数一多模型输出质量会明显下降。3.2 逐模块生成每次只让它“写一段”骨架确认完就进入了密集的模块生成环节。一次只让Agent生成一个模块顺序上我做了刻意安排世界规则、地理、种族、魔法、势力、历史、故事钩子。这里的逻辑是“依赖先行”地理可以和世界规则互相印证种族需要地理做舞台魔法依赖种族和生产方式势力冲突依赖历史背景故事钩子又依赖前面全部模块。每一步都只基于已经稳定下来、锁进文件的内容来写极大减少出尔反尔。我用的模块指令通常长这样请阅读world_rules.md、terminology.md、geography.md然后完成races.md的写作。 要求 - 主文件正文1500字左右中文 - 列出至少4个种族/群体每个种族包含文化、禁忌、代表性人物 - 每个条目不少于150字必须包含具体场景 - 不得引入terminology.md中不存在的专有名词除非你同时申请新增新增时先提交术语登记特别注意“不得引入术语表里不存在的专有名词”这句话。这是我事后总结的最有效的一条约束。没有这句约束的时候Agent每写一个模块都会顺手发明好几个地点和人物名字而这些名字只在这个模块里出现一次后续模块根本不会提及造成大量无用信息。加了约束之后它会把新名字作为“待登记项”放在文件末尾方便我决定是否保留。生成的时候我还会手动控制节奏。每个模块写完后我会让Agent输出一个“本次关键设定变更摘要”比如新增了哪些术语、沿用了哪些旧设定、有没有刻意引用旧文件里的内容。然后我把这个摘要贴回CHECKLIST.md。这样每次进入下一轮Agent即便没有自动读取所有文件也有一份手动汇总在手边。虽然这一道工序看起来像是“人工给AI当助手”但实际操作中能省掉大量返工。等到七个模块全部写完文档树里已经积攒了超过1万字的正文另外还有术语表、规则文件、检查清单等辅助内容。打开每个文件正文长度都在预期区间内。有了这些素材后面无论是写小说还是做游戏内容都可以直接当作公共设定来调用。3.3 用审校清单做一致性收尾正文生成完之后还远远没有到能交付的程度。接下来我会开启一个新的Agent会话不给它任何前面对话历史只让它读取全部文件然后做一次“交叉审校”。这种“断例会话语境”的做法很关键它强迫模型完全依赖文件内容来判断而不是依赖对话记录里那些不完整、可能有偏差的记忆。审校时我给的指令是请逐一读取mist-archipelago目录下的所有.md文件找出以下问题 1. 同一个专有名词在不同文件中的定义是否存在冲突 2. 时间线是否与“七年大潮”等世界规则冲突 3. 魔法体系的代价是否在不同模块中被省略或改变 4. 是否有明显重复的段落或信息 请输出一个“问题清单”按严重程度排序并标注具体文件与建议修改方式。这一步跑完它会输出一份很有价值的问题清单。我遇到的数量通常在十到十五个左右其中真正严重的冲突会有两三个。比如种族文件里写了“灯塔人平均寿命可达三百岁”但术语表里同一个种族的寿命写的是“一百二十岁”这种直接矛盾如果不查根本发现不了因为两个文件不会同时出现在同一个视野里。拿到问题清单后我会逐条确认然后让Agent生成对应的补丁版本。改动可能会连带到其他文件比如寿命改掉历史时间线里那个角色“在位一百五十年”也需要同步调整。所以我修完以后会再跑一次交叉审校直到问题清单为空。这一轮是纯人工监督流程没有捷径。4. 踩坑实录四个最典型的翻车现场这个项目做完我踩过的坑可以单独开一篇文章。这里挑四个最典型的几乎每个想用AI Coding工具做长文本创作的人都会遇到。4.1 输出的不是设定文而是“梗百科”第一次生成时我犯了一个新手错误没有在模块指令里规定“每条内容的最少字数”和“需要包含具体场景”。结果世界观条目被写成了类似“雾海雾海是群岛周围的海域每年有九个月被雾覆盖雾气会干扰魔法。”这样的百科条目。技术上没有错但作为设定集它没有任何画面感也没有人文气息。这个问题在编码Agent上比普通对话式AI更严重原因在于Agent更习惯按“任务清单”执行天然倾向用最简洁、最格式化的方式完成任务。你要让它写出有质感的文字就必须把要求给足。我给每个条目设置了“不低于150字”和“必须包含至少一个角色场景或物件细节”的硬约束才逐步扭转回来。具体来说我给races.md里“灯奴”这个群体写的示范条目是“灯奴不是奴隶制意义上的奴工而是自愿与灯芯共生的一群人。他们右臂上带着与塔芯同源的蚀刻纹路每逢大潮前三天纹路会自发亮起青色微光此时他们能听见塔芯的低频音但代价是牙齿会逐渐变脆。他们多数活不过五十岁却坚持认为这是最体面的一种活法。”这一类细节模型本来就能写得出来关键是你要把它逼出来。4.2 两个模块之间互相打架这是所有长文本创作者最痛的问题。我有一次在factions.md里写了一座城市叫“铜冠港”设定它是灯王议会的驻地但在geography.md里同一座城市被写成了“灯王议会象征意义上的旧都”议会实际已经迁到别处。两个文件分开看都对合在一起就矛盾。排查下来原因很直接生成地理模块时模型还只读过世界规则没有读到势力模块的规划所以它按照自己的理解给城市安排了身份。解决方式就是我前面提到的术语表与交叉审校。把“城市-政治地位-所属势力”这种关系写进terminology.md后续生成任何文件时都要求以术语表为准矛盾就会大幅减少。4.3 开场输出惊艳后期质量明显崩坏如果你在一个Agent会话里连续生成太多内容会出现一个现象前几个模块文笔和逻辑都在线越到后面越敷衍。它不是变笨了而是上下文累积越来越长加上部分平台会自动压缩早期信息模型能参考的有效内容越来越少于是只能靠模板化输出凑数。我最后采取的应对策略是“化整为零”。每个模块单独开一个会话生成但每次让Agent启动前先读取world_rules.md、terminology.md、以及与该模块相关的上游文件。这样每次会话的上下文都保持干净模型不需要记住一大堆历史只要每次读取当前最新文件即可。这个方法的效果在我个人对比下非常明显尤其是最后一个“故事钩子”模块如果放在同一个会话里连续写到第十个钩子时质量会明显下滑单独会话生成时十个钩子都能保持至少相近的水平。4.4 重复段落和“幻觉新词”还有两个小而高频的坑。一个是重复Agent会在同一个文档里用几乎一样的表述反复描述同一种现象比如“锈蚀魔法需要消耗使用者的生命力”在magic_system.md里出现了三次。这通常是因为在连续生成时它不确定自己是否已经写过了。我一般会用文档处理软件的统计替换功能快速扫描或者直接给Agent下指令“统计并删除完全重复或高度重复的段落”。另一个是“幻觉新词”。它会突然在历史时间线里发明一个术语表里没有的种族名“潮栖民”而事实上这个种族在races.md里叫“雾居者”。这种问题单独看完全没有问题你甚至觉得这个词很有画面感。但前后文一对照读者会立刻觉得设定不严谨。我用术语登记机制来约束如果确实想用新词必须先写入terminology.md获得“登记”否则默认使用已有术语。这样能挡掉大部分无意识发明。5. 可复制的经验如何用AI Coding工具做长文本创作5.1 什么是合适的场景什么是过度包装经过这个实验我比较确定AI Coding工具在长文本创作里是有真实价值的但价值有边界。它最适合的场景是那些模块化强、一致性要求高、总字数在几千到几万字之间的内容。典型的有游戏世界观设定集、小说创作蓝图、跑团模组背景、方法论手册、产品说明书的初稿。这些内容天然适合拆成多个文件而且都有“不能前后矛盾”的硬要求。不太适合的场景是那些必须依赖作者独特语言风格、叙事节奏和情绪的纯文学作品。AI Coding工具本质上更适合做“项目管理型”的长文本而不是“风格表演型”写作。如果你要写一篇需要强烈个人声音的散文那用普通对话式AI也要谨慎因为它同样会给你套上模板语气。但至少Agent能在结构和一致性上帮你兜