企业官网建设流程全解析

1. 写设定写崩三次后，我在编程工具里找到套路

1.1 为什么小说设定稿总是写着写着就崩

先交代一下背景。我在写一个原创奇幻故事，世界观前期明明想得很清楚：一块名为“烬辉之世”的大陆、两套相互对抗的神系、人类与三支亚种之间的千年积怨。动笔前我花了两个晚上把设定大纲填得满满当当，感觉万事俱备。可真到开始写详细设定稿时，问题就来了——第一章说某王国始建于“裂穹历 217 年”，到了第六章随口又写成“217 年”。某个角色在第一幕是 32 岁，第四幕已经过去了 40 年，他还是 32 岁。更离谱的是，我第三稿里把北方冻土上的游牧民族叫“凛齿”，到第五稿因为打字顺手，变成了“银鬃”，两个名字交替出现，自己压根没反应过来。

这不是态度问题，是纯纯的容量问题。当设定内容从零散几百字膨胀到上万字，人的工作记忆根本装不下所有约束。写的时候很爽，回头一查全是对不上的账。

我试过用表格、用思维导图、用专门的写作软件做设定集，效果都比裸写强，但依然解决不了一个根子上的麻烦：散文式的设定文档，本质上是“非结构化文本”。你的关键信息埋在长句里，修改时要靠肉眼去检索，AI 帮你补内容时也没法稳定地参考它们。改着改着，约束就丢了。

1.2 AI Coding 工具真正擅长的，是“约束下的生成”

真正让我有启发的，是我平时写代码时用的那款 AI Coding 工具。它最日常的场景是你给它一个函数签名、几行注释、一个已有的代码文件，它帮你把剩下的函数体补完。这里面有个很关键的东西——它不是在自由发挥，而是在一个被类型、接口、变量名、已有逻辑层层锁死的约束空间里做生成。

我忽然意识到，写代码和写设定，在“不要让前后矛盾”这件事上简直是同一个问题。代码里的类型定义相当于设定里的“设定速查表”；函数的参数约束相当于角色必须遵守的年龄线；git 提交相当于每个阶段设定改动的快照。我用这工具写过那么多次大型重构，它很少让我失望，不是因为它聪明，而是因为我给了它一套能自我检查的上下文。

那如果我直接把整个世界观定义成一份“数据结构”，让 AI Coding 工具像维护代码库一样维护我的设定库呢？

1.3 这次实践到底想验证什么

说白了，我想验证三件事：

1. 能不能通过结构化的“类型定义 + 上下文分片”，让 AI 在一次对话里产出逻辑自洽的万字设定，而不是虎头蛇尾或前后矛盾。
2. 在成稿之后，能不能像跑测试用例一样，用一批“断言式 prompt”自动查出设定里的冲突。
3. 这套方法有没有可复用性——换句话说，我能不能把整个流程沉淀成一组模板，以后换一个世界观也能直接套。

所以有了这篇实践记录。我讲的不是“AI 帮我写字”那么玄的事，而是“如何把内容创作当成一个软件工程项目来做”。接下来我会把每一步的关键思路、落地的 prompt 长什么样、中间踩了哪些坑，全部摊开来讲。

2. 先建模再动笔：把世界观当成一套严格的数据结构

2.1 给神明、种族、魔法都定义一份“接口文档”

项目启动后我没有直接让 AI 写任何成段的设定文字，而是先拉着它把“烬辉之世”的顶层模型列成了一组 TypeScript 风格的接口定义。为什么用 TypeScript？因为它的类型系统够严格，字段能不能为空、值是数字还是数组、是否可选，写得一清二楚，AI 看到这种格式，会下意识地按“严谨枚举”而不是“散文发挥”来思考。

我当时定义的几个核心接口是这个样子：

// 神系定义 interface Deity { deityId: string; // 唯一标识，如 "LK-01" name: string; // 神名 domain: string[]; // 权柄领域，可多个 alignment: "秩序" | "混沌" | "中立"; symbol: string; // 标志物符号 worshipRegion: string[]; // 主要信仰区域 relatedDeities: string[]; // 相关神祇 ID conflictDeities: string[]; // 敌对神祇 ID } // 种族定义 interface Race { raceId: string; // 唯一标识，如 "R-01" name: string; // 种族名 homeland: string; // 主要聚居区域 lifespan: [number, number]; // 寿命范围 [最小, 最大] subraces: string[]; // 亚种/分支 cultureKeywords: string[]; // 文化关键词 relations: Record<string, "盟友" | "敌对" | "中立">; } // 魔法体系定义 interface MagicSystem { sourceId: string; // 力量来源 name: string; energyUnit: string; // 能量单位，如 "辉烬" limitation: string[]; // 核心限制条件 costDescription: string; // 代价描述 }

你可能会问，这些字段是我先想好，还是 AI 帮我想的？其实是我给了几个粗字段，AI 补全了剩余部分。第一轮它加上了conflictDeities，这个字段非常有用，后面写神战相关场景时直接按 ID 互相引用，再也不会出现两个神明是死敌但正文里毫无交集的情况。

这里有个关键经验：字段名本身要像约束条件一样精准。比如 lifespan 我写成[number, number]的元组，AI 就知道必须填两个数字——最小值和最大值，不能只写个“很长”。我在第一版接口里让 AI 自由发挥，它给我填了个lifespan: "漫长"，我直接把它当一个 bug 打回去了。从那以后我用严格类型和示例值卡住它，它反而表现得更好。

2.2 事件与编年史：用结构化字段锁死前后因果

有了静态对象（神、种族、地理）的定义，下一步是给动态内容建模型。奇幻世界里最容易崩的其实是编年史——谁在什么时候做了什么、产生了什么影响、引发了什么后续事件。纯文字大事件表，AI 很容易在生成第 12 个事件的时候忘掉第 3 个事件里说“某人为死亡状态”。

我给历史事件设计的接口侧重在“因果链”上：

interface HistoryEvent { eventId: string; // 事件唯一标识，如 "E-04" timeline: number; // 时间坐标，以"裂穹历"纪年 name: string; location: string; // 发生地点 participants: string[]; // 参与角色ID列表 causeEventIds: string[]; // 由哪些事件导致 effectEventIds: string[]; // 引发了哪些后续事件 globalImpact: "轻微" | "区域" | "大陆" | "世界"; keyDetail: string; // 一话概括该事件的关键事实 }

有了这个结构，AI 写后续内容时就可以这样推理：如果某个事件E-07的causeEventIds是["E-04"]，那它在正文里绝不可能出现在 E-04 之前；如果参与者里有某个角色，该角色在那个时间点必须活着。

这套模型的效果立竿见影。原本我需要反复叮嘱“注意时间线!”，现在只要把接口放在上下文开头，AI 生成的草案里事件间的引用关系自然就成立了。比较省心的是，我在生成完多个事件后只跑了一次一致性检查，发现唯一的问题是一个角色被标记为“北境出身”，却在父辈事件中出生于南方的城市——这就是 location 和角色档案没关联导致的，后面会在缝合阶段统一修。

2.3 建好模型后，AI 的输出质量发生了什么变化

我把这些接口定义喂给 AI 后，用同一句 prompt 让它生成三个种族设定：一次放在结构化的模型上下文里，一次直接让它自由写。差别非常明显。

自由写版本：文字很漂亮，但种族 A 的寿命是“300 岁左右”，种族 B 和种族 A 有贸易关系，却住在完全不相邻的两个大陆板块。结构化版本：种族 A 的lifespan被严格写成了[250, 380]，与其他种族的relations字段全部枚举明确，文化关键词也控制在五个以内，没有冗余发挥。

我没有否定 AI 的文学能力，恰恰相反，结构化的目的不是砍掉文学性，而是把文学性收敛到合理的字段内。比如我在deity接口里单独留了一个lore字段，告诉 AI：“这里是神话叙事的发挥空间”。它会在那里写出很漂亮的传说段落，同时又不会乱动其他字段的约束。从这个角度看，接口就是设定集的红线，红线之内才是灵感纵马的地方。

3. 一万字不一次生成：把设定拆成可迭代的模块

3.1 分片生成与“设定速查表”

第一版做法踩了大坑。我试着让 AI “一口气写出整个世界的完整设定，约一万字”。结果前三千字确实气势恢宏，到七千字左右已经开始前后重复，一万字收尾时出现了至少四处硬冲突——这明显不是上下文窗口不够，而是单次长生成缺少中途校验节点，AI 在生成后半段时只能靠它自己的短期记忆，出错在所难免。

后来我换了一个思路：模仿代码库的模块化。把整个设定拆成几个“源文件”，一次不生成一万字，一次只生成一个文件：

src/ ├── world_config.ts // 全球设定：纪元、历法、地理总览 ├── pantheon.ts // 神系设定 ├── magic_rules.ts // 魔法体系 ├── races.ts // 种族与亚种 ├── history_core.ts // 核心编年史 ├── regions.ts // 分区域风土志 └── characters.ts // 重要角色表

每次生成新模块之前，我会把前面已经确认的关键字段拼成一张“设定速查表”放在 prompt 的最前面，告诉 AI：你只能在这个数据集里引用城市、人名、时间，不许新造。

这张速查表长这样：

【已固化设定】 - 纪元：裂穹历，当前为第 840 年 - 大陆：烬辉之世，共分四域：北境冻原、中环平原、南方裂谷、东端群岛 - 神系：双神系对位，拉克斯（秩序·辉光）与维恩（混沌·影蚀） - 种族：人类（寿命 70~100）、精灵亚种“青铸”（寿命 300~420）、矮人种“铁颅”（寿命 200~250） - 关键城市：白塔城、霜落港、烬冠王都 - 当前已写事件：E-01 霜落港建城（裂穹历 12 年）、E-02 第一次辉影战争（241~267 年）、E-03 青铸退守东端群岛（410 年）

有了这张表，AI 在生成“中环平原的区域风土”时，就不会莫名其妙地写一个跟白塔城同级别的“圣辉城”当政治中心——它清楚中环平原的政治节点是烬冠王都，而白塔城在更西边。

3.2 从速查到细化的迭代路径

这套流程的完整路径是：顶层速查 → 单模块生成 → 萃取新字段 → 更新速查表 → 生成下一个模块。听起来很像敏捷开发里的迭代流程。每轮生成完，我都会把产出里新出现的、需要固化的地名和人物甄别出来，追加进速查表。

举个例子，第一轮生成regions.ts的时候，AI 为南方裂谷新增了一个叫“烬冠王都”的城市。这个城市原本不在我的顶层速查表里，它是模型的合理发挥。我接受它，把它写进速查表。第二轮生成history_core.ts时，AI 需要提到王都的建立时间，它就不会再造一个新地名，而是直接用“烬冠王都”。

这背后的逻辑是：每轮生成的信息增量是可控的，前面轮次的成果会变成后面轮次的上下文约束。你不需要一口吃成胖子，你只需要保证每一轮的增量不冲突。累积一万字只花了我大概四轮半的生成，质量却稳定得多。

3.3 上下文控制的量化经验：多少字该开新一轮

这里分享一个我自己摸索出来的经验值。用普通长对话模型生成设定时，如果单轮产出超过三千字，后半段出现重复和矛盾的几率会显著上升。所以我现在的节奏是：单次输出控制在 1200~2000 字之间，宁可在一次对话里让它分两段生成，也不要逼着它一口气写五千字的宏大篇章。

判断“该开新一轮”的信号很简单：它开始复制前面的句子结构，或者突然冒出一个名字但我查速查表查不到。一旦出现这两种现象，我就停手，把产出跑一遍一致性检查，然后把新增的可靠字段塞进速查表，下一轮用一个更干净的上下文继续。

这个方法写起来平淡，实操时真的救大命。我认为很多 AI 写作翻车的案例，不是模型不行，是上下文策略不对——你把一堆历史输出全堆在一个对话里，模型只能靠注意力去抓重点，而设定冲突恰恰藏在容易被注意力忽略的角落。

4. 把提示词当成代码写：我用的那几个“代码思维”模板

4.1 TODO 清单：让 AI 先列计划再动手

我之前习惯直接给 AI 下写作指令：“帮我写北方冻原的详细设定，包括环境、聚落、文化、几个关键人物。”结果它一次生成了五个小节，每个小节的篇幅全靠随缘。

后来我改成“先列 TODO，再逐个实现”的写法，给 AI 一份这样的指令：

任务：编写北方冻原区域设定。 先输出一个 TODO 列表： - [ ] 地理与气候约束（不超过 200 字） - [ ] 主要聚落与命名规则（3 个聚落，必须匹配速查表内的种族分布） - [ ] 文化与禁忌（与神系信仰字段交叉验证） - [ ] 代表性角色草稿（最多 2 人，标注与编年史的关联） 确认 TODO 完成后，逐项输出，每项之间空一行。

这样做有两点好处。第一，AI 在列出 TODO 时已经完成了自我规划，它会主动把任务拆成可控的子块，降低输出互相干扰的概率。第二，因为 TODO 里有“必须匹配速查表”这类字样，它的每一小节生成都会先做一次内部核对，相当于让它在输出前自检了一遍。

4.2 常量表：把所有换算口径钉死

奇幻设定里最容易出 bug 的另一个东西是“换算口径”——时间单位里的“月”和“年”，不同种族对一年长度的理解，地理距离的丈量方式。如果这些不变，后续写战斗场面时，角色可能前一秒在国外的城市，后一秒就走到了大陆中央。

我建了一张常量表，让 AI 把这类全局换算关系钉死：

const WORLD_CONSTANTS = { CALENDAR: { YEAR_LENGTH: "360天，12个月，每月30天", CURRENT_YEAR: "裂穹历840年", SEASONS: ["枯风季", "融雪季", "丰雨季", "凝霜季"], }, DISTANCE: { UNIT: "里格（约4.5公里）", REGIONAL_TRAVEL_TIME: "平原骑马每日约15里格", MOUNTAIN_TRAVEL_TIME: "山区每日约5里格", }, MAGIC_RULE: { ENERGY: "辉烬，人体可承载上限为 3 单位", RESTORE: "自然恢复需 7 天", FORBIDDEN: "禁止时间回溯类魔法", }, };

这块常量表在后续生成中的作用非常大。AI 在写任何政变、战争移动或角色迁徙的段落时，都会默认遵守这套口径。我不需要反复强调，只需要把常量表挂在 prompt 的开头，它就自动按这套规则推理了。

4.3 断言式自查：强迫 AI 输出前后 diff

写代码的人都知道，重构完代码要跑测试。我受此启发，把“测试用例”的思想搬到了设定生成上。每生成完一个模块，我都会让 AI 做一次“断言式自查”，prompt 是这么写的：

设定审查任务： 请逐一执行以下断言，并输出 PASS 或 FAIL，如果 FAIL 请给出具体修改建议： 1. 所有角色在 E-04 事件发生时必须处于已出生状态 2. 所有神灵的信仰区域不得与其他神系重叠 3. 所有提及的城市必须存在于"设定速查表"中，不得新增 4. 所有种族的寿命范围与编年史中相关描述一致 5. 魔法能量单位必须统一使用"辉烬"

你可能想问：AI 做断言时的自检真的可靠吗？我的经验是——比人类的肉眼可靠，但也不能盲信。它最大的价值在于逼着模型再读一遍自己刚生成的内容，并用上下文里的约束去核对。很多明显的时间线 bug 它自己能查出来；但某些更深层的逻辑漏洞（比如“某人参与了某事件，但该事件发生时此人还依附于另一个阵营”），它可能检查不出来。这种情况下我会退回到人工抽检，因为设定毕竟是我们自己的东西，靠 AI 把关是省不了全部心力的。

4.4 从“写手模式”切换到“审查模式”的 prompt 模板

我最常用的一组切换 prompt 是：

【写作模式】 你是一个奇幻设定撰写者。请根据速查表，扩展【区域：北境冻原】的设定。要求：只能使用速查表已有的事实；新增信息需要体现地方特色；不要主动与其他区域设定进行横向比较。 【审查模式】 你是一个设定质检员。请阅读我粘贴的设定文本，对照速查表，找出以下冲突： 1. 时间线矛盾 2. 数值不一致 3. 命名重复或同物异名 4. 因果关系倒置 输出格式：冲突位置 / 冲突描述 / 建议修复方式。

写手模式和审查模式的提示词差异在于角色定位。如果让同一个角色“既写又审”，它容易掉进自我辩护的陷阱；分开来反而每次都很诚实。我现在的习惯是：写和查严格分轮，写完先不问“写得好不好”，只问“和既有约束冲不冲突”。

5. 一个完整案例：三天时间，把“月潮战争”从概念扩成三千字

5.1 第一步：定义事件元数据

光讲方法论有点虚，我拆一个真实案例给你看。这次实践里我选择扩写“月潮战争”——这是发生在裂穹历 780 年的一次大规模战争，起因是南方裂谷的“潮灵教团”试图推翻双神系之一的影蚀信仰。

按之前的做法，我会直接让 AI 写“月潮战争的完整始末”。这次我先在纸面上定义元数据：

事件 ID：E-09 名称：月潮战争 时间：裂穹历 780~784 年 地点：南方裂谷，重镇为“潮痕城” 起因：潮灵教团首领“瓦尔登”声称影蚀神的力量在削弱 参战方：潮灵教团 vs. 中环平原联合王国（以烬冠王都为首） 关键结果：潮灵教团战败，瓦尔登失踪，影蚀信仰在两域交界处被禁 后续相关事件：E-10 南方裂谷重新归顺王都；E-11 瓦尔登残部转入地下

这段元数据是后面所有分幕生成的骨架。你会发现，我刻意把“瓦尔登失踪”写成了一个开放口，给后续角色登场留了空间；同时把“影蚀信仰被禁”设置为该区域后续所有风俗冲突的根因。

5.2 第二步：分幕提示与场景生成

有了事件元数据后，我把它拆成了三幕，分别提示 AI 生成：战前、高潮、战后。每幕的 prompt 都包含五样东西：速查表、事件元数据、已固化的角色表、要写的这一幕的时间段、以及“不要越界描述下一幕”的禁止指令。

战前部分生成的场景是潮痕城的气氛变化：潮灵教团在港口集结，城市里的神殿被改成了军事仓库，普通商人嗅到危机开始迁移。AI 没有冒然引入新角色，而是用速查表里的既有角色——比如值守潮痕城的领主、两位影蚀祭司——来撑起前哨冲突。这比我预想的好，因为“用旧人物讲新故事”比“随手创造工具人”更能减少整个设定的混乱。

高潮部分它写了瓦尔登在城墙上的演讲和第一波潮汐魔法攻击。这段内容信息密度高，但有个问题：AI 把瓦尔登写得过于“全知全能”，他的演讲辞里包含了后续才应该出现的战局细节。这暴露了一个核心问题——分幕提示需要明确“当前视角人物的信息上限”。

5.3 第三步：段落合并与一致性过滤

生成三段完整内容后，我手动把它们粘在一起，然后跑了一遍前面说过的审查模式。审查结果里出现了两个 FAIL：第一，战争在 780 年开始，但战前场景里潮痕城领主在对话中提到了 784 年的战后重建政策——这是明显的穿越；第二，瓦尔登在战前场景使用的魔法能量单位写的是“潮汐”，而速查表里全局魔法体系规定统一使用“辉烬”。

第一个问题通过修改领主对白解决；第二个问题我把“潮汐”全部替换为“辉烬”，同时保留了一种叫“潮汐共鸣”的仪式名称——因为那是仪式名字，不是计量单位，可以共存。经过这两处修复，三段文字合成后逻辑顺畅，最终成稿约三千二百字。

5.4 回看：这套流程一共花了多少次对话

我替大家算了一笔账：整个月潮战争从元数据定义到成稿，一共用了 9 次对话。其中三次生成正文、两次做场景确认、一次跑审查模式、一次修复一致性，另外两次是拆解角色视角和调整分幕边界。

如果一次性让 AI 写，可能两三次对话就结束了，但前后矛盾修复起来花的时间，远比多生成几次要多。我自己的体验是：用工程化流程做一个三千字的战争事件，实际投入时间大约是两个半小时，其中人工写元数据占四十分钟，后续主要是把 AI 输出的模块拼起来并修 bug。如果按传统手动写，差不多的篇幅加逻辑管控，我大概需要一个下午。效率提升大约在两到三倍，质量上限更高。

6. 成稿后的“代码审查”：我用三层清障法找出所有矛盾

6.1 第一层：数值与时间线编译

整套设定初稿合并完成后，我做了一次全面的“编译检查”，相当于把设定文本当成一个大型代码仓库来跑静态检查。第一层检查的是硬性数值——所有年龄、年份、距离、人口、能量单位。

我这里给一个真实的 bug 案例。设定里人类寿命是 70~100 岁，但我在角色表里填了一个活了 180 年的人类巫师“沙维尔”。查速查表时发现，他的种族应该是“青铸”精灵亚种，只是他的人类外貌让人产生了误判。修复的方案不是把巫师改回人类，而是把他的种族字段从“人类”改为“青铸”，并补一句背景：“他隐藏精灵身份是为了融入中环平原的政治圈。”这就是改新不改旧原则的实践——保留已发表的完整设定，只修正内部矛盾。

数值冲突的排查可以交给 AI 做初筛，但最终判断得自己来。因为 AI 只能发现“数字不一致”，但到底是改数字还是改设定，取决于叙事意图。

6.2 第二层：命名与地理逻辑查重

第二层清障是针对命名和地理。这套设定里出现了很多 AI 生成的怪异名字，一旦拼写到后面，多次变形就是家常便饭。

我的查重方法是让 AI 跑一个“同物异名”扫描，prompt 很简单：找出所有看起来指代同一地点/人物却在全文中使用不同写法的地方。结果它扫出了三处：一处是“灰烬王座”与“烬冠王座”，其实就是同一个东西；两处是地名“霜落港”在不同段落写成了“霜落之港”“霜港”。

处理原则很简单：以第一次出现或速查表里的写法为准，全局替换。同时，我在速查表里增加了一个“别名表”，把所有曾经用过的旧称和官方称都登记在案，下一步生成时就不会再造新词。

地理逻辑更隐蔽。AI 在一个区域设定里写“北境冻原的商队穿越南方裂谷”，但从前面的设定速查表看，两片区域之间有中环平原作为天然缓冲，如果商队要穿越应该是“经过中环平原，抵达南方裂谷”，而不是直接穿。这类错误靠数值检查是查不出来的，要靠“地图上的可达性推理”。我的办法是给 AI 一张粗糙的“区域接壤表”，让它针对每个移动描述做可达性检查。

6.3 第三层：因果链压力测试

如果说前面两层是语法错误，第三层就是“逻辑 Bug”。这类 Bug 是：事件 A 导致了事件 B，但在正文里事件 B 发生的时间点，事件 A 其实还没有发生。

我给自己设计了一个小规模的因果链测试。选取编年史里的 8 个核心事件，把所有因果依赖关系列成一张图，然后让 AI 按时间顺序输出，并选取其中的相互依赖事件做抽查。

测试结果抓到了一个显著问题：角色“黎恩·奥尔”参与了的 E-09 月潮战争，而他本人其实是 E-08 事件的发起者之一；但 E-08 事件的时间被设定为裂穹历 782 年，而 E-09 开始于 780 年——也就是说，黎恩在还没有发动 E-08 的时候就已经参与了它引发的战争。这不对劲。最终我调整了 E-08 的发生时间，把它挪到 779 年，作为月潮战争的远因之一。这种调整在全局里影响可控，但在查出来之前，它会是一个长期潜伏的设定地雷。

6.4 配套的冲突排查表

我把整个过程整理成一张冲突排查表，后面做任何新项目都可以直接用：

这张表我自己打印了一份贴在工位边上。每次跑完一轮新生成，我都会对着表快速过滤一遍。很多人觉得设定写崩了是因为脑洞不够，实际上不是——设定崩坏的最常见原因，恰恰是缺乏一套结构化的自查机制。你把约束写清楚，把检查流程跑固定，AI 产出的稳定性会高到让你意外。

7. 最后的实在建议：版本快照与单维度修改

这整个实践做下来，留在我工作习惯里的其实不是一个神奇的 prompt，而是两个朴素的软件工程习惯。

第一个习惯是版本快照。每完成一个模块的生成，我会把速查表和这个模块的内容导成一份独立的 Markdown 文件，文件名带版本号，比如regions_v2.md、history_core_v4.md。这意味着一周后我发现某个设定填得不好想回退，随时能找到原始版本——而且我能看清楚每一次改动的具体差异。你别小看这件事，AI 生成内容很容易出现“新版不如旧版”的情况，没有快照，你就只能摊手。

第二个习惯是单维度修改。一次只改一个维度，不要同时改神系、改种族、改编年史。我吃过一次亏：某天我对四个模块同时做了调整，结果冲突排查表上立刻多了六个矛盾，我根本没法确定是哪一个改动引发的连锁反应。从那以后我严格按“一次一个维度，改完立刻跑检查”的节奏，排查成本直线下降。本质上这就是 git 哲学——每次提交只做一件事。

这套用 AI Coding 工具生成万字奇幻世界设定的方法，是我目前实践过最稳定的内容产出管线。它不负责给你灵感——灵感还是你自己的事，但它能帮你把灵感钉在不会腐坏的结构里。你负责天马行空，AI 负责在框架内补齐血肉，最后再靠审查机制把漏洞一个个堵上。这套流程跑顺了之后，写长篇设定反而变成一件减压的事：你不再担心记忆崩盘，因为每一条设定都被结构、速查表、版本快照和冲突检查环环锁住了。