企业官网建设流程全解析

“角色桌 replay”在跑团社区里，往往指一类把 TRPG 过程整理成可读故事的长期内容。一个系列从单篇试水做到第 08 期甚至更久之后，真正的问题通常已经不是“有没有灵感”，而是“角色状态还记不记得清、时间线是否对得上、发布时是否会漏掉前情提要、读者从第 01 期追到第 08 期时是否还在同一条线索上”。这篇内容就以“虚舟之村”这类以《鬼灭》角色背景开展的角色桌 replay 长期连载为例，讲清楚如何用内容工程的方式管理回放档案、角色状态表、剧情节点和发布流水线。读完可以直接套用到自己的跑团记录、同人连载或任何多期文字项目中。

1. 不要把多期角色桌 replay 当成“写作文”，而要当成内容项目来管

1.1 为什么多期连载需要结构，而不只是文笔

写单篇跑团记录时，思路可以很自由：先写开场，再写战斗，最后收尾。角色在某一篇里受伤还是觉醒、NPC 说了哪句伏笔，都在同一篇的上下文中，作者不容易写乱。

但当项目变成“虚舟之村 08”这样的第 08 期时，问题就变了。读者会带着前七期的记忆进来，作者也需要回答这些跨期问题：

• 上一期结束时，队伍在哪个地点、什么状态下？
• 某位角色的受伤程度、记忆状态、持有的关键道具是否已经变化？
• 哪个 NPC 的伏笔需要在本期回收或推进？
• 如果角色 A 在第 05 期已经死亡或离开，本期是否还能以原状态出场？
• 前情提要是否有更稳定的生成方式，而不是靠作者临时回忆？

这些问题本质上不是文字能力问题，而是数据一致性问题。软件工程里解决数据一致性会引入版本控制、状态管理、规范化表和自动化检查；多期角色桌 replay 也一样，完全可以把文件、元数据、角色状态和发布流程全部结构化。

其实跑团记录的本质是“一个持续演进的世界状态”配合“一期一期发布的文本快照”。前者的稳定程度决定了后者的质量上限。

1.2 一个角色桌 replay 内容项目里，真正要管理的是哪些对象

把连载内容拆开看，至少有四类对象需要持续维护：

如果这四类对象都堆在同一个 Markdown 文件里，短期内方便，长期看一定会乱。第 08 期还能靠记忆撑住，第 20 期、第 50 期时基本不可能。

更合适的做法是：正文文件只负责“当期叙事文本”，状态数据、时间线数据、发布产物分别用不同文件存放，再通过脚本或人工检查串起来。

1.3 先确立一条最小可验证流程：从草稿到发布要经过四步

内容项目管理不一定要上复杂系统。先做一条最小流程即可：

1. 建好统一的目录结构。
2. 每期正文文件头部写清元数据，包括期号、标题、时间线位置、收录角色。
3. 把角色状态表放在独立文件中，正文引用时保持一致。
4. 发布前用脚本或检查表验证数据完整性和引用关系。

只要这套流程能稳定跑过三期，就比临时整理强得多。后面的章节就以“虚舟之村”这个示例系列为背景，展示具体怎么做。

2. 建立项目目录与元数据模板，让每一期都可追溯

2.1 给每一期一个稳定目录和统一命名

很多连载内容前期不规划目录，结果第一年文件叫虚舟之村01.md，第二期叫village_02_final2.md，第三期直接躺在网盘里。这样做的代价很快就会暴露：脚本无法覆盖全部文件，读者找不到历史页面，作者也无法快速判断“这份文件是草稿还是定稿”。

推荐在一个项目根目录下这样组织：

village-boat/ ├── episodes/ │ ├── 001-draft.md │ ├── 001-final.md │ ├── 002-draft.md │ ├── 002-final.md │ └── ... ├── data/ │ ├── characters.yaml │ ├── timeline.yaml │ └── continuity.yaml ├── scripts/ │ ├── validate_state.py │ └── build_index.py ├── dist/ │ ├── 001.html │ ├── 002.html │ └── index.html ├── assets/ │ ├── images/ │ └── css/ └── README.md

关键规则有三条：

• 期号固定用三位数，例如001、008，方便按字典序排序。
• 草稿和定稿分文件名保存，例如008-draft.md和008-final.md，不要只靠文件夹区分。
• 数据文件统一放在data/，文本与数据分离，这样脚本才能读取。

如果原始材料里已经有散乱的文件，迁移时不要急着合并，先把当前最新一期复制为008-final.md，再逐步归档旧文件。

2.2 用 YAML front matter 保存当期元数据

在 Markdown 正文前加入 YAML front matter，可以让每期内容自带结构化信息。下面是一个针对第 08 期的示例模板：

--- title: "虚舟之村 08" episode: 8 date: 2025-01-15 status: final timeline: in_universe_date: "宽永十七年 秋" start_location: "虚舟之村入口" end_location: "虚舟之村祠堂" characters: - name: "猗窝座" role: "敌对/限时同行" state: "记忆恢复中" appears: true - name: "示例角色A" role: "玩家角色" state: "轻伤" appears: true summary: "本期进入虚舟之村祠堂，发现上一期留下的封印被揭开。" prev_episode: 7 next_episode: 9 tags: ["鬼灭主题", "虚舟之村", "replay"] ---

元数据字段含义如下：

front matter 的作用不只是给脚本读，更重要的是迫使作者在写作前先确认“本期角色在什么状态、从哪里开始、到哪里结束”。这个确认动作本身就能避免大量剧情漏洞。

2.3 用 Git 管理草稿和发布版本，而不是只保存最最终版

很多连载作者只保留最终 Markdown 文件，一旦误删某段精彩原文就没有恢复手段。更稳妥的方式是用 Git 管理整个内容项目。

cd village-boat git init git add episodes/ data/ scripts/ README.md git commit -m "初始化虚舟之村 replay 内容仓库"

之后每写一版草稿就提交一次：

git add episodes/008-draft.md git commit -m "008 草稿：祠堂入口场景"

发布时再提交一次，形成稳定快照：

git add episodes/008-final.md dist/ git commit -m "008 定稿并生成发布页面"

用 Git 的三个理由是：可以回滚误删内容；可以比较不同版本的差异；可以看清每一期的修改历史。对于只有一个人维护的文字项目，Git 已经足够，不需要引入复杂 CMS。

注意：Git 里不应该提交生成过程中的临时文件。建议在项目根目录创建.gitignore，把产物目录、编辑器临时文件、系统文件排除在外，避免误提交。

3. 让角色状态和剧情时间线脱离长篇正文，成为结构化数据

3.1 角色状态表应该独立于正文

正文适合展示故事，但不适合做“角色状态检索”。当角色在第 02 期说过一句话、第 05 期达成某个约定，第 08 期又要使用时，靠Ctrl+F在正文里查找会非常痛苦。更可行的方式是维护一个角色状态文件。

假设data/characters.yaml内容如下：

characters: - id: akaza name: "猗窝座" role_in_series: "原作联动角色" status: "记忆恢复中" last_episode: 8 current_location: "虚舟之村祠堂" key_items: [] notes: | 第 06 期开始出现，第 08 期由敌对转为限时同行。 不要提前写上第 09 期才会公开的设定。 - id: character_a name: "示例角色A" role_in_series: "玩家角色" status: "轻伤" last_episode: 8 current_location: "虚舟之村祠堂" key_items: ["祠堂铜钥匙"] notes: "第 07 期获得钥匙，尚未使用。"

这个文件的意义在于：

• 它是角色状态唯一数据源，正文只是展示。
• 每期结束后，作者必须更新last_episode、current_location、status。
• 剧本复盘或读者提问时，不需要重读全文就能拿到某个角色的当前快照。

如果角色数量较多，不要在 YAML 里把所有人写成一个长列表，可以按阵营分组，或者用多个文件拆分。保持数据文件的结构简单，比对后续写脚本有利。

3.2 剧情时间线需要记录事件节点，而不只是日期

时间线文件适合单独保存。它不记录每一句台词，只记录对后续剧情有影响的公开事件和隐藏伏笔。

timeline: - episode: 6 event: "队伍抵达虚舟之村入口" visible_to_reader: true - episode: 7 event: "祠堂封印被探测，发现异常" visible_to_reader: true - episode: 8 event: "封印被揭开，虚舟之村内部机关激活" visible_to_reader: true references: - "第 07 期封印探测"

时间线字段可以很轻量：episode、event、visible_to_reader、references。references用来记录“这个事件关联到哪一期的伏笔”，方便后续回收伏笔时快速定位，也方便写前情提要。

有了时间线文件，前情提要就不再靠记忆生成。第 09 期发布时，可以直接把第 06 到 08 期的事件节点整理成两三句话，放进文章开头。

3.3 用脚本校验数据完整性，避免角色状态落后于正文

结构化数据也会出错，常见错误是正文里写“角色已经离开”，但characters.yaml里current_location还停留在上一期。要解决这类问题，可以写一个简单脚本。

下面是一个用 Python 校验角色状态和期次元数据是否一致的例子：

import re from pathlib import Path def load_front_matter(path): text = path.read_text(encoding="utf-8") # 简化解析：只取出 YAML front matter 中的 characters 部分 match = re.search(r"characters:\n((?:\s+-.*\n?)+)", text) if not match: return [] lines = match.group(1).splitlines() names = [] for line in lines: m = re.search(r'name:\s*"([^"]+)"', line) if m: names.append(m.group(1)) return names def main(): episode_dir = Path("episodes") data_file = Path("data/characters.yaml") if not episode_dir.exists(): print("未找到 episodes 目录") return final_files = sorted(episode_dir.glob("*-final.md")) print(f"找到 {len(final_files)} 篇定稿") for fp in final_files: names = load_front_matter(fp) if not names: print(f"{fp.name}: 没有读取到 characters，请检查 front matter") else: print(f"{fp.name}: 收录角色 {len(names)} 个") if data_file.exists(): print("角色状态文件存在") else: print("缺少 data/characters.yaml") if __name__ == "__main__": main()

这个脚本并不复杂，但它可以快速暴露两类问题：定稿文件没有角色信息；数据文件缺失。实际项目中还可以继续扩展：

• 校验每期episode是否连续。
• 校验next_episode是否指向存在的文件。
• 校验data/timeline.yaml中的事件是否都能对应到具体期次。
• 校验角色状态中的last_episode是否大于等于当前期号。

不要一开始就做复杂的数据模型，先用 20 行脚本跑通“发现问题”这条路径，再逐步加规则。

4. 用命令行把 Markdown 草稿变成可发布页面

4.1 用 Pandoc 把 Markdown 正文转换为 HTML 或 PDF

当内容整理成 Markdown 后，发布环节完全可以用命令行完成。以 Pandoc 为例：

pandoc episodes/008-final.md -o dist/008.html \ --standalone \ --metadata title="虚舟之村 08"

这条命令把 Markdown 转成带完整 HTML 结构的独立页面，适合直接放到静态服务器或博客附件页。如果还需要 PDF：

pandoc episodes/008-final.md -o dist/008.pdf \ --pdf-engine=xelatex \ -V CJKmainfont="Noto Sans CJK SC"

使用--standalone是因为默认转换只生成内容片段；在部署网站上往往需要一个完整 HTML 文档。PDF 转换时如果没有指定中文字体，很容易出现中文乱码，这是最常见的问题。

注意：Pandoc 每次生成的都是全新文件，不要在原 Markdown 文件上直接覆盖，否则会丢失源文档。输出统一放到dist/，源文件始终留在episodes/。

4.2 用脚本生成全系列阅读索引

连载站点最需要的是一个能自动更新的首页索引。手动维护链接列表在期数少时没有问题，期数多了以后必然会出现漏链接。

下面是一个简单脚本，它扫描episodes/下所有-final.md文件，读取 front matter，并按期号生成dist/index.html：

import re from pathlib import Path def extract_meta(text): title = re.search(r"title:\s*\"([^\"]+)\"", text) episode = re.search(r"episode:\s*(\d+)", text) return title.group(1) if title else "未命名", int(episode.group(1)) if episode else 0 def main(): episode_dir = Path("episodes") entries = [] for fp in episode_dir.glob("*-final.md"): title, episode = extract_meta(fp.read_text(encoding="utf-8")) entries.append((episode, title, f"{fp.stem.replace('-final', '')}.html")) entries.sort(key=lambda x: x[0]) html_parts = [ "<!DOCTYPE html>", "<html lang='zh-CN'>", "<head><meta charset='utf-8'><title>虚舟之村 replay 目录</title></head>", "<body><h1>虚舟之村 replay 目录</h1><ul>", ] for episode, title, filename in entries: html_parts.append(f'<li><a href="{filename}">第 {episode:02d} 期：{title}</a></li>') html_parts.append("</ul></body></html>") output = Path("dist/index.html") output.write_text("\n".join(html_parts), encoding="utf-8") print(f"已生成 {output}，共 {len(entries)} 篇") if __name__ == "__main__": main()

这个脚本的输出是一个极简目录页。实际项目中可以再加入摘要、标签、发布时间等字段。核心价值在于：当新增一篇最终稿后，只需再次运行python scripts/build_index.py，目录页面就会自动更新，不需要手动修改链接。

4.3 接入静态博客或内容站点时的注意事项

如果最终要发表到 CSDN、博客园或自建静态博客，不建议把dist/里的 HTML 全量复制到博客后台。更常见的方式有两种：

• 静态博客方式：把episodes/和data/交给 Hugo、Jekyll、VitePress 等工具，由它们读取 Markdown 并生成站点。
• 手动发布方式：把 Markdown 正文复制到博客编辑器中，保留标题和段落结构。

两种方式各有适用场景：

比起一次性配好所有东西，建议从“手动发布 + Pandoc 生成本地预览”开始，等连载稳定后再决定是否迁移到静态博客。

5. 连载内容踩坑与排错：先看现象，再定位根因

5.1 文件乱掉、找不到最新一期

现象：想给第 08 期写发布说明，结果目录里同时出现008.md、08-final.md、008终版.md等多个文件，无法判断哪个是最新定稿。

常见原因：前期没有统一命名规则，文件分散保存在不同路径。

检查方式：

ls -la episodes/ find . -name "*.md" -type f | sort

处理建议：立即统一命名规则。把当前正在维护的一期复制为008-final.md，旧文件放入archive/，不要直接删除。

5.2 角色明明已经出场，状态文件却还是旧值

现象：正文第 08 期写“猗窝座已经进入祠堂”，但角色状态表显示他还停留在“虚舟之村入口”。

常见原因：角色状态只更新在正文里，没有同步到data/characters.yaml。

检查方式：

grep -n "猗窝座" episodes/008-final.md

用grep找到正文中所有出现该角色的位置，再对照状态文件里的current_location和status。如果正文有多处矛盾，优先以最新时间点的事件为准。

处理建议：每期定稿前，把data/characters.yaml与正文最后一段的场景地点、角色状态做一次人工比对。长期连载项目可以在发布脚本里加一个提示，强制作者更新last_episode字段。

5.3 发布页链接失效或目录漏期

现象：读者点击第 04 期链接返回 404，或者首页目录里缺少第 07 期。

常见原因：手动维护目录链接时漏改，或者文件名与链接不一致。

检查方式：

curl -I https://example.com/episodes/008.html

本地项目则可以检查文件是否存在：

test -f dist/008.html && echo "存在" || echo "不存在"

处理建议：不要手动维护期刊列表，统一用脚本生成目录。生成后再检查一遍链接对应关系，可以用 HTML 里的链接集合和dist/目录文件列表做差异比较。

5.4 编码乱码和换行符不一致

现象：同一篇 Markdown 在 Windows 下打开正常，提交到 Git 后，在 Linux 上生成 HTML 时出现乱码或段落拼接异常。

常见原因：文件编码不统一，或编辑过程在CRLF与LF之间切换。

检查方式：

file episodes/008-final.md

处理建议：项目统一使用 UTF-8 编码和无 BOM 格式。文本文件保持LF换行。在仓库根目录创建.editorconfig：

root = true [*] charset = utf-8 end_of_line = lf insert_final_newline = true trim_trailing_whitespace = true

这样至少能提醒所有编辑器遵守同样的基础规则。

5.5 前情提要写得太长或太短

现象：第 08 期开头要么把前七期全讲一遍，要么只写一句话，读者完全接不上。

常见原因：前情提要由作者临时回想，没有基于时间线数据。

处理建议：从data/timeline.yaml里取最近三期的事件节点，每期只保留一条最关键的公开事件，合并成两三句即可。不要在前情提要里过早剧透隐藏伏笔。

6. 给长期连载的维护清单与扩展方向

6.1 每期发布前检查清单

每次发布第 N 期前，可以逐项确认：

这个清单不需要每次都手工在纸上打钩，可以做成脚本里提示的输出项。重点是“定稿前强制检查一遍”，而不是发布后再补。

6.2 更成熟的内容管理方向

当连载期数超过 30 期、角色超过 10 个时，YAML 文件也能继续工作，但可以考虑这些扩展：

• 把角色状态改为数据库表，比如 SQLite，通过界面或脚本录入，减少手写 YAML 的错误。
• 引入静态博客生成器，用标签、系列分类、前一篇/后一篇导航替代手动链接。
• 为每一期增加配图和音频，在assets/中维护素材清单，避免发布时图片丢失。
• 加入内容审核机制，发布到公开平台前检查文本中是否包含需要脱敏的信息。

从工程角度看，这套方法和维护一个小型文档站点没有本质区别：把每一期当成一次“发布”，把角色状态和事件时间线当成“数据库数据”，把脚本当成“构建工具”，把 Git 提交当成“版本历史”。

6.3 对新手最有用的第一步

如果之前从来没有做过任何结构化管理，不要一次性尝试所有技巧。最值得先做的一件事是：把即将写的下一期正文文件命名为009-draft.md，在文件头部补上episode: 9、characters两个字段，并在外部单独建一个characters.yaml记录本期出场角色的最终状态。仅凭这三条改动，第 10 期时你就能体会到“翻数据文件比翻正文更快”的差别。

跑团回放写得好不好，终归还是要看叙事能力；但连载能不能稳定更新下去，靠的往往是这些看起来不起眼的管理动作。把每一期当成内容项目对待，让角色状态、时间线、发布产物都有自己的归属地，后续连载才会越写越轻松。