企业官网建设流程全解析

我大概半年前开始接一个偏“大世界观”的创作项目，前期是按传统方式写设定文档，结果写到两三万字时彻底失控了：角色关系前后矛盾、时间线对不上、不同区域的地名拼写互相打架。反复修改几轮之后，我决定换个思路——把整套奇幻世界设定当成一个“软件工程”来做，用 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.md
      • deep_elves.md
      • ...
    • regions/ # 区域地理
      • northern_wastes.md
      • sea_of_storms.md
      • ...
    • factions/ # 势力组织
      • trade_compact.md
      • imperial_court.md
      • ...
    • timeline/ # 编年史
  • assets/
    • name_registry.json # 命名注册表，避免地名/人名重复
    • term_glossary.json # 术语对照表，统一译名与概念定义
  • scripts/
    • check_conflicts.py # 自动冲突检测脚本
    • build_index.py # 生成条目索引

核心特征是把设定按领域拆分，而不是按“文档篇幅”拆分。每个模块有明确的职责边界：种族模块只管种族相关的生理、文化、特殊能力；地区模块负责地理环境和聚落；势力模块记录组织结构和外交关系；时间线只做编年记录。如果在地区模块里发现大段种族背景介绍，这就不是一个内容补充问题，而是一个“模块职责越界”信号，应该拆出来归位。

2.3 设计“受控词表”与命名锚点

大型设定最常见的混乱源是命名和术语不统一。同一个种族可能在不同早期文档里出现过三个叫法，某座城市在不同势力的眼里也有不同称呼。这在文学作品里可能有叙事意图，但在工程化设定里就是明显的 bug。

我的做法是建一个命名对照表，类似代码项目里的“资源注册中心”。每个关键实体有唯一编码，同时允许存在多个口头别名，但文档里第一次出现时，必须挂到唯一编码上。

用 JSON 管理这个表非常顺手：

• 名称：北境灰烬族
• 名称英文/别称：Ashkin, Cinderfolk（如果做多语版本会用）
• 唯一ID：race.ashkin
• 分类：humanoid/offshoot
• 冲突条件：不允许与其他种族主线混血后正常繁殖

所有 AI 生成的新内容里，一旦出现“另一个半身人种族，来自北方高原”，脚本就能在术语表里检索到冲突关键词，并标记出来问项目方：你到底是想新建种族，还是这个词指向已有条目？这种检测机制放到传统写作流程里，大概需要一个人专门花大量时间逐页比对，效率和准确性完全不可比。

3. 实操记录：从搭建骨架到产出万字级完整设定

3.1 第一轮：让 AI Coding 工具生成“模块模板”

我不是直接让 AI 写最终设定正文，而是先让它生成一套“模块模板”。这一步很重要——模板先行能保证所有后续扩展都遵循同一套格式，后面的脚本校验才有意义。

我的做法是给工具一段完整提示，要求它先产出几个种族条目的模板样例。以种族卡为例，模板结构大致长这样：

# 种族名：Ashkin（灰烬族） ## 基础信息 - 所属分类：Humano? - 外貌体征：（两句以内） - 平均寿命：（数值） - 发源地：（必须引用 regions 模块中的已有条目） ## 生理与能力 - 核心种族能力：（一条主能力） - 种族限制：（必须列出，没有则写“无”） - 魔法亲和：（魔法亲和等级） ## 社会与文化 - 典型聚落形式： - 主要信仰/哲学： - 与哪些势力关系密切：（引用 factions 模块） ## 已知冲突与禁制 （例如：不能和其他种族繁衍，或不能从事某些职业）

AI Coding 工具按这个模板生成种族卡的时候，往往比自然语言聊天更稳定，因为模板本身就是结构约束。它也知道每次输出都该往哪个字段填内容，而不是忽然放飞写成一段散文。

从这一步开始，生成内容就不只是“内容资产”，也变成了“可校验数据”。我们可以像检查代码规范一样检查哪些字段缺失、哪些引用不是有效锚点。

3.2 第二轮：按“模块优先顺序”逐步扩展

模板齐了之后，我没有让 AI 一口气生成所有模块的内容——那个量大到上下文窗口根本撑不住，很容易把一个后期人物的性格写成前期反派的样子。取而代之的方式是把整个项目拆成几个可并行、可回归的阶段，按“依赖顺序”扩展。

我的扩展顺序是：

1. 种族库优先。因为很多地区、城市、势力都建立在种族分工基础上，先把各主要种族生理和文化基线定义好，后面区域设置就能直接引用，不需要重复描写种族属性。

2. 地理与区域第二。划清楚山川河流、主要城邦与交通线，确保后期编年史和势力扩张有地图坐标可依附。这里的“地图坐标”不一定是像素级地图，但至少要在文本层面有相对位置关系。

3. 势力与组织第三。势力的兴衰、冲突、结盟，都依赖种族能力和地理条件，放在第三位顺理成章。

4. 编年史最后。前面三层等于“资源系统”，编年史则是在这个系统上运行的“状态迁移”。大部分早期冲突后面都能在编年史里找到对照位置，不会莫名冒出没有前因后果的大事件。

每完成一个模块，就运行一次索引构建脚本。生成的索引文件不是给读者看的，而是给我和 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(encoding='utf-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 为每个模块按字段补全。别急着追求一天内铺完整个世界，那是传统输出逻辑里最容易翻车的原始冲动。按模块推进、按批次生成、按脚本校验，后面你会回来感谢这套流程的。