“角色桌 replay”在跑团社区里往往指一类把 TRPG 过程整理成可读故事的长期内容。一个系列从单篇试水做到第 08 期甚至更久之后真正的问题通常已经不是“有没有灵感”而是“角色状态还记不记得清、时间线是否对得上、发布时是否会漏掉前情提要、读者从第 01 期追到第 08 期时是否还在同一条线索上”。这篇内容就以“虚舟之村”这类以《鬼灭》角色背景开展的角色桌 replay 长期连载为例讲清楚如何用内容工程的方式管理回放档案、角色状态表、剧情节点和发布流水线。读完可以直接套用到自己的跑团记录、同人连载或任何多期文字项目中。1. 不要把多期角色桌 replay 当成“写作文”而要当成内容项目来管1.1 为什么多期连载需要结构而不只是文笔写单篇跑团记录时思路可以很自由先写开场再写战斗最后收尾。角色在某一篇里受伤还是觉醒、NPC 说了哪句伏笔都在同一篇的上下文中作者不容易写乱。但当项目变成“虚舟之村 08”这样的第 08 期时问题就变了。读者会带着前七期的记忆进来作者也需要回答这些跨期问题上一期结束时队伍在哪个地点、什么状态下某位角色的受伤程度、记忆状态、持有的关键道具是否已经变化哪个 NPC 的伏笔需要在本期回收或推进如果角色 A 在第 05 期已经死亡或离开本期是否还能以原状态出场前情提要是否有更稳定的生成方式而不是靠作者临时回忆这些问题本质上不是文字能力问题而是数据一致性问题。软件工程里解决数据一致性会引入版本控制、状态管理、规范化表和自动化检查多期角色桌 replay 也一样完全可以把文件、元数据、角色状态和发布流程全部结构化。其实跑团记录的本质是“一个持续演进的世界状态”配合“一期一期发布的文本快照”。前者的稳定程度决定了后者的质量上限。1.2 一个角色桌 replay 内容项目里真正要管理的是哪些对象把连载内容拆开看至少有四类对象需要持续维护对象典型内容最容易出错的位置期次档案每期的原始记录、整理后正文、标题、发布时间文件名不统一、没有记录整理状态角色状态角色姓名、状态、所在地、持有的关键信息状态只写在正文里不写入数据文件剧情时间线每期时间节点、发生的事件、留下的伏笔时间线散落在正文段落里难以检索发布产物生成后的 HTML、PDF、博客文章草稿与发布版混在一起误改旧版如果这四类对象都堆在同一个 Markdown 文件里短期内方便长期看一定会乱。第 08 期还能靠记忆撑住第 20 期、第 50 期时基本不可能。更合适的做法是正文文件只负责“当期叙事文本”状态数据、时间线数据、发布产物分别用不同文件存放再通过脚本或人工检查串起来。1.3 先确立一条最小可验证流程从草稿到发布要经过四步内容项目管理不一定要上复杂系统。先做一条最小流程即可建好统一的目录结构。每期正文文件头部写清元数据包括期号、标题、时间线位置、收录角色。把角色状态表放在独立文件中正文引用时保持一致。发布前用脚本或检查表验证数据完整性和引用关系。只要这套流程能稳定跑过三期就比临时整理强得多。后面的章节就以“虚舟之村”这个示例系列为背景展示具体怎么做。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] ---元数据字段含义如下字段说明使用建议episode期号数字用数字不要用第 08 期这种带汉字的写法status文档状态draft或final发布前必须为finaltimeline叙事时间与地点保持与data/timeline.yaml一致characters本期出场角色只写“本期”的状态不是角色全量状态prev_episode/next_episode前后期链接用于自动生成阅读导航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 期又要使用时靠CtrlF在正文里查找会非常痛苦。更可行的方式是维护一个角色状态文件。假设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(encodingutf-8) # 简化解析只取出 YAML front matter 中的 characters 部分 match re.search(rcharacters:\n((?:\s-.*\n?)), text) if not match: return [] lines match.group(1).splitlines() names [] for line in lines: m re.search(rname:\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 结构的独立页面适合直接放到静态服务器或博客附件页。如果还需要 PDFpandoc episodes/008-final.md -o dist/008.pdf \ --pdf-enginexelatex \ -V CJKmainfontNoto Sans CJK SC使用--standalone是因为默认转换只生成内容片段在部署网站上往往需要一个完整 HTML 文档。PDF 转换时如果没有指定中文字体很容易出现中文乱码这是最常见的问题。注意Pandoc 每次生成的都是全新文件不要在原 Markdown 文件上直接覆盖否则会丢失源文档。输出统一放到dist/源文件始终留在episodes/。4.2 用脚本生成全系列阅读索引连载站点最需要的是一个能自动更新的首页索引。手动维护链接列表在期数少时没有问题期数多了以后必然会出现漏链接。下面是一个简单脚本它扫描episodes/下所有-final.md文件读取 front matter并按期号生成dist/index.htmlimport re from pathlib import Path def extract_meta(text): title re.search(rtitle:\s*\([^\])\, text) episode re.search(repisode:\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(encodingutf-8)) entries.append((episode, title, f{fp.stem.replace(-final, )}.html)) entries.sort(keylambda x: x[0]) html_parts [ !DOCTYPE html, html langzh-CN, headmeta charsetutf-8title虚舟之村 replay 目录/title/head, bodyh1虚舟之村 replay 目录/h1ul, ] for episode, title, filename in entries: html_parts.append(flia 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), encodingutf-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 生成内部预览或存档需要额外处理样式、导航、阅读进度比起一次性配好所有东西建议从“手动发布 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换行。在仓库根目录创建.editorconfigroot 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 期前可以逐项确认检查项具体操作期次文件命名当前定稿是否叫XXX-final.mdfront matter是否有episode、title、date、statusfinal角色状态同步data/characters.yaml中出场角色是否已更新到本期结束状态时间线更新data/timeline.yaml是否记录了本期公开事件前情提要是否基于时间线生成是否接得上上一期结尾链接完整性目录脚本生成的链接是否全部有效发布产物Pandoc 或静态站点是否成功生成、页面能否访问Git 提交是否已提交并保留版本记录这个清单不需要每次都手工在纸上打钩可以做成脚本里提示的输出项。重点是“定稿前强制检查一遍”而不是发布后再补。6.2 更成熟的内容管理方向当连载期数超过 30 期、角色超过 10 个时YAML 文件也能继续工作但可以考虑这些扩展把角色状态改为数据库表比如 SQLite通过界面或脚本录入减少手写 YAML 的错误。引入静态博客生成器用标签、系列分类、前一篇/后一篇导航替代手动链接。为每一期增加配图和音频在assets/中维护素材清单避免发布时图片丢失。加入内容审核机制发布到公开平台前检查文本中是否包含需要脱敏的信息。从工程角度看这套方法和维护一个小型文档站点没有本质区别把每一期当成一次“发布”把角色状态和事件时间线当成“数据库数据”把脚本当成“构建工具”把 Git 提交当成“版本历史”。6.3 对新手最有用的第一步如果之前从来没有做过任何结构化管理不要一次性尝试所有技巧。最值得先做的一件事是把即将写的下一期正文文件命名为009-draft.md在文件头部补上episode: 9、characters两个字段并在外部单独建一个characters.yaml记录本期出场角色的最终状态。仅凭这三条改动第 10 期时你就能体会到“翻数据文件比翻正文更快”的差别。跑团回放写得好不好终归还是要看叙事能力但连载能不能稳定更新下去靠的往往是这些看起来不起眼的管理动作。把每一期当成内容项目对待让角色状态、时间线、发布产物都有自己的归属地后续连载才会越写越轻松。
“角色桌 replay”在跑团社区里往往指一类把 TRPG 过程整理成可读故事的长期内容。一个系列从单篇试水做到第 08 期甚至更久之后真正的问题通常已经不是“有没有灵感”而是“角色状态还记不记得清、时间线是否对得上、发布时是否会漏掉前情提要、读者从第 01 期追到第 08 期时是否还在同一条线索上”。这篇内容就以“虚舟之村”这类以《鬼灭》角色背景开展的角色桌 replay 长期连载为例讲清楚如何用内容工程的方式管理回放档案、角色状态表、剧情节点和发布流水线。读完可以直接套用到自己的跑团记录、同人连载或任何多期文字项目中。1. 不要把多期角色桌 replay 当成“写作文”而要当成内容项目来管1.1 为什么多期连载需要结构而不只是文笔写单篇跑团记录时思路可以很自由先写开场再写战斗最后收尾。角色在某一篇里受伤还是觉醒、NPC 说了哪句伏笔都在同一篇的上下文中作者不容易写乱。但当项目变成“虚舟之村 08”这样的第 08 期时问题就变了。读者会带着前七期的记忆进来作者也需要回答这些跨期问题上一期结束时队伍在哪个地点、什么状态下某位角色的受伤程度、记忆状态、持有的关键道具是否已经变化哪个 NPC 的伏笔需要在本期回收或推进如果角色 A 在第 05 期已经死亡或离开本期是否还能以原状态出场前情提要是否有更稳定的生成方式而不是靠作者临时回忆这些问题本质上不是文字能力问题而是数据一致性问题。软件工程里解决数据一致性会引入版本控制、状态管理、规范化表和自动化检查多期角色桌 replay 也一样完全可以把文件、元数据、角色状态和发布流程全部结构化。其实跑团记录的本质是“一个持续演进的世界状态”配合“一期一期发布的文本快照”。前者的稳定程度决定了后者的质量上限。1.2 一个角色桌 replay 内容项目里真正要管理的是哪些对象把连载内容拆开看至少有四类对象需要持续维护对象典型内容最容易出错的位置期次档案每期的原始记录、整理后正文、标题、发布时间文件名不统一、没有记录整理状态角色状态角色姓名、状态、所在地、持有的关键信息状态只写在正文里不写入数据文件剧情时间线每期时间节点、发生的事件、留下的伏笔时间线散落在正文段落里难以检索发布产物生成后的 HTML、PDF、博客文章草稿与发布版混在一起误改旧版如果这四类对象都堆在同一个 Markdown 文件里短期内方便长期看一定会乱。第 08 期还能靠记忆撑住第 20 期、第 50 期时基本不可能。更合适的做法是正文文件只负责“当期叙事文本”状态数据、时间线数据、发布产物分别用不同文件存放再通过脚本或人工检查串起来。1.3 先确立一条最小可验证流程从草稿到发布要经过四步内容项目管理不一定要上复杂系统。先做一条最小流程即可建好统一的目录结构。每期正文文件头部写清元数据包括期号、标题、时间线位置、收录角色。把角色状态表放在独立文件中正文引用时保持一致。发布前用脚本或检查表验证数据完整性和引用关系。只要这套流程能稳定跑过三期就比临时整理强得多。后面的章节就以“虚舟之村”这个示例系列为背景展示具体怎么做。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] ---元数据字段含义如下字段说明使用建议episode期号数字用数字不要用第 08 期这种带汉字的写法status文档状态draft或final发布前必须为finaltimeline叙事时间与地点保持与data/timeline.yaml一致characters本期出场角色只写“本期”的状态不是角色全量状态prev_episode/next_episode前后期链接用于自动生成阅读导航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 期又要使用时靠CtrlF在正文里查找会非常痛苦。更可行的方式是维护一个角色状态文件。假设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(encodingutf-8) # 简化解析只取出 YAML front matter 中的 characters 部分 match re.search(rcharacters:\n((?:\s-.*\n?)), text) if not match: return [] lines match.group(1).splitlines() names [] for line in lines: m re.search(rname:\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 结构的独立页面适合直接放到静态服务器或博客附件页。如果还需要 PDFpandoc episodes/008-final.md -o dist/008.pdf \ --pdf-enginexelatex \ -V CJKmainfontNoto Sans CJK SC使用--standalone是因为默认转换只生成内容片段在部署网站上往往需要一个完整 HTML 文档。PDF 转换时如果没有指定中文字体很容易出现中文乱码这是最常见的问题。注意Pandoc 每次生成的都是全新文件不要在原 Markdown 文件上直接覆盖否则会丢失源文档。输出统一放到dist/源文件始终留在episodes/。4.2 用脚本生成全系列阅读索引连载站点最需要的是一个能自动更新的首页索引。手动维护链接列表在期数少时没有问题期数多了以后必然会出现漏链接。下面是一个简单脚本它扫描episodes/下所有-final.md文件读取 front matter并按期号生成dist/index.htmlimport re from pathlib import Path def extract_meta(text): title re.search(rtitle:\s*\([^\])\, text) episode re.search(repisode:\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(encodingutf-8)) entries.append((episode, title, f{fp.stem.replace(-final, )}.html)) entries.sort(keylambda x: x[0]) html_parts [ !DOCTYPE html, html langzh-CN, headmeta charsetutf-8title虚舟之村 replay 目录/title/head, bodyh1虚舟之村 replay 目录/h1ul, ] for episode, title, filename in entries: html_parts.append(flia 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), encodingutf-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 生成内部预览或存档需要额外处理样式、导航、阅读进度比起一次性配好所有东西建议从“手动发布 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换行。在仓库根目录创建.editorconfigroot 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 期前可以逐项确认检查项具体操作期次文件命名当前定稿是否叫XXX-final.mdfront matter是否有episode、title、date、statusfinal角色状态同步data/characters.yaml中出场角色是否已更新到本期结束状态时间线更新data/timeline.yaml是否记录了本期公开事件前情提要是否基于时间线生成是否接得上上一期结尾链接完整性目录脚本生成的链接是否全部有效发布产物Pandoc 或静态站点是否成功生成、页面能否访问Git 提交是否已提交并保留版本记录这个清单不需要每次都手工在纸上打钩可以做成脚本里提示的输出项。重点是“定稿前强制检查一遍”而不是发布后再补。6.2 更成熟的内容管理方向当连载期数超过 30 期、角色超过 10 个时YAML 文件也能继续工作但可以考虑这些扩展把角色状态改为数据库表比如 SQLite通过界面或脚本录入减少手写 YAML 的错误。引入静态博客生成器用标签、系列分类、前一篇/后一篇导航替代手动链接。为每一期增加配图和音频在assets/中维护素材清单避免发布时图片丢失。加入内容审核机制发布到公开平台前检查文本中是否包含需要脱敏的信息。从工程角度看这套方法和维护一个小型文档站点没有本质区别把每一期当成一次“发布”把角色状态和事件时间线当成“数据库数据”把脚本当成“构建工具”把 Git 提交当成“版本历史”。6.3 对新手最有用的第一步如果之前从来没有做过任何结构化管理不要一次性尝试所有技巧。最值得先做的一件事是把即将写的下一期正文文件命名为009-draft.md在文件头部补上episode: 9、characters两个字段并在外部单独建一个characters.yaml记录本期出场角色的最终状态。仅凭这三条改动第 10 期时你就能体会到“翻数据文件比翻正文更快”的差别。跑团回放写得好不好终归还是要看叙事能力但连载能不能稳定更新下去靠的往往是这些看起来不起眼的管理动作。把每一期当成内容项目对待让角色状态、时间线、发布产物都有自己的归属地后续连载才会越写越轻松。
