TRPG Replay工程化整理：从Markdown到Git与Python的完整流程

跑团结束后的那几周往往是热情消退得最快的时候。如果当时没有及时整理语气、动作、即兴发挥的细节都会慢慢丢掉。尤其是长篇连载团前面埋的伏笔、人物关系、场景互动都散落在聊天记录和语音里等到想回头整理时工作量已经大到劝退整理人。本文以“P4角色桌Replay/完结/雪山密室——第九话雪山密室”这类连载型跑团记录为背景展开一套从素材整理、文稿规范化、版本管理到发布的完整操作流程。这篇文章适合每周固定跑团的玩家、负责整理Replay的“书记位”玩家以及想用工程化方式管理长篇写作项目的内容创作者。读完以后你可以把散乱的原始记录整理成结构统一的Markdown文稿用Git给每一话做好版本管理用Python脚本批量清洗文字噪声最后导出成带目录的PDF或在线阅读页面。1. TRPG Replay 是什么为什么需要一套整理流程1.1 什么是 TRPG 与 ReplayTRPG 全称是 Tabletop Role-Playing Game也就是桌面角色扮演游戏。玩家围在一起由主持人负责描述场景、扮演非玩家角色、判定规则玩家则扮演自己创建的角色通过对话和行动推动故事发展。整个过程通常持续两到四个小时短则一次完结长则像连载剧一样分成很多话。所谓 Replay最早是指把跑团过程中发生的故事整理成文稿供没有参与的人阅读。它通常包含场景描写、角色对话、技能判定、骰子结果等。后来 Replay 的范围扩大到所有跑团记录形式包括文字贴条记录、视频录像、图文连载等。随着“角色桌”“面团”“网团”这些玩法越来越普及同一个长篇团会横跨好几周甚至好几个月。参与者习惯了每期跑完就结束却忽略了一个问题跑团是即时体验但故事不应该只停留在那一个晚上。一篇好的 Replay 能让没跑团的人也能看懂整个故事也能让参与者多年后重新翻阅时想起当时的高光时刻。1.2 手工整理 Replay 的常见痛点做 Replay 整理的人都知道这件事看起来简单做起来却很容易烂尾。第一个痛点是素材太散。语音、文字、截图、临时记录分散在多个平台整理时需要在不同软件之间来回切换。第二个痛点是口语化内容太多。真实跑团时大家都会说“嗯嗯”“等一下”“我看看规则”这些内容如果原封不动放进去读者会感觉很碎片。第三个痛点是排版不统一。同一篇 Replay 如果分成多话由不同的人负责整理很容易出现第一话用“某某说”第二话用“某某”第三话又换成了对话气泡截图。读者阅读时会产生强烈的不连贯感。还有一个很难解决的问题是时间跨度带来的前后矛盾。前面一话里角色受了重伤后面整理时可能忘记保留这个状态上一话出现过一条关键线索下一话整理时却完全没提。手工整理时很难记住所有细节更别说把这些线索在文本中统一贯穿。1.3 把 Replay 当成一个“内容项目”来管理如果把 Replay 当成一篇普通的文字稿来写很容易东一榔头西一棒子。但如果你把它当成一个软件项目那样管理事情就会清晰很多。所谓“项目化”就是约定固定目录、固定模板、固定版本让每一话都按照相同的流程产出。例如在 P4 角色桌这个案例中第九话已经是完结篇前面八话已经有了既定风格。如果你想保证第九话的排版和前八话一致就必须先明确一个“规范”。项目化管理的本质不是上纲上线而是把所有重复性劳动标准化把自己从崩溃边缘拉回来。我推荐的思路是用 Markdown 作为统一的书写格式用 Git 做版本管理用 Python 脚本完成重复性的文本清洗再用 Pandoc 或 MkDocs 把成品转成适合阅读的格式。这套流程学起来不复杂一次搭好后后续每一话都能复用。2. 制作一个 Replay 项目前的环境准备2.1 文件目录怎么设计Replay 项目最怕的是文件乱放。建议在开始整理前先建立一套清晰的目录结构。下面是一个比较通用的目录设计p4-replay/ ├── README.md ├── .gitignore ├── raw/ │ ├── 09-雪山密室-语音转写.txt │ └── 09-雪山密室-角色卡.md ├── drafts/ │ └── 09-雪山密室-未校对.md ├── volumes/ │ └── 09-雪山密室.md └── scripts/ └── clean_record.pyraw 目录放原始素材drafts 放未完成的校对稿volumes 放每一话的正式发布稿scripts 放整理脚本。这样一个项目拥有清晰的职责边界原始材料不丢中间稿可见正式稿永远只有一份。2.2 编辑器与写作格式写作格式建议统一使用 Markdown。原因很简单它用纯文本保存任何设备都可以打开后续转 PDF 或 HTML 都非常方便。编辑器可以选择 VS Code也可以选择 Typora 这类所见即所得的工具。如果你经常在校对时查看目录结构推荐 VS Code 配合 Markdown All in One 插件如果你更在意写作沉浸感Typora 的实时预览体验更接近传统文档编辑器。当然这些选择完全看个人习惯关键是最终产出的 Markdown 文件结构要稳定。2.3 Git、Python、Pandoc 的用途Git 用来管理版本。每次校对修改、每次发布前调整都应该形成一次提交这样万一改坏了可以回到上一个版本。Python 用来做文本清洗。尤其当你拿到的是语音转写文本或平台导出的聊天记录时里面会有大量时间戳、系统消息、无意义语气词手工删会非常痛苦。脚本可以一次性处理。Pandoc 用来做格式转换。它可以把 Markdown 转换成带目录的 PDF、Word 文档或 EPUB。如果你需要做在线阅读站还可以用 MkDocs 把整个 volumes 目录渲染成一个静态网站。版本方面本文示例以常见环境为主。Python 建议使用 3.8 及以上版本Pandoc 建议使用 2.x 以上版本。如果你的环境版本差异较大重点参考配置思路不是死记命令。3. 从原始素材到结构化 Markdown 文稿3.1 先建立统一排版规范排版规范的作用是让所有参与者知道“一句话在 Replay 里应该长成什么样”。否则同一段台词在不同人的稿件里会有三种写法。我建议定义以下基本规则旁白用【旁白】标注。PC 台词用【角色名】标注。守秘人或主持人描述用【主持人】标注。技能判定单独成段说明检定目标。骰子结果用【骰子】标注。场景切换用二级标题。这套规范并不复杂但对长篇连载特别重要。前八话如果已经存在那就沿用旧规范如果是新项目第一话就要定下来后面所有话都照做。3.2 一个适合雪山密室场景的 Markdown 模板下面给出一个可以直接复用的模板结构上可以作为每话正文的起点# 第九话雪山密室 系列P4 角色桌 收录第九话完结 地点雪山密室 参与角色PC1、PC2、PC3、PC4 跑团日期202X-XX-XX ## 场景一风雪中的避难小屋 【旁白】 暴风雪把前路完全封死你们只能躲进这间木屋。屋里光线很暗壁炉里只剩下余烬。 【PC1】 先检查门锁是否完好看能不能从里面反锁。 【主持人】 门是厚实的木门门锁没有被破坏的痕迹。你拉动门栓时听到外面传来一阵风声。 【判定】 PC1 进行「侦查」检定目标值 12。 【骰子】 PC1 掷出9失败。 【旁白】 你没发现异常但总觉得这间屋子的墙面比外面看起来宽了一些。这个模板的好处是“谁说的、做了什么、结果如何”一目了然。读者不用猜这段是玩家还是主持人说的。作为整理者你也只需要按照这个结构把原始记录往里填不用每次重新设计格式。3.3 原始记录中的三类噪声如何处理第一类是口语噪声比如“嗯”“啊”“让我想想”“刚才你说了什么”。这些内容可以酌情删除但要注意保留那些体现角色性格的口癖。比如一个角色总喜欢在句尾加某个词这是人设的一部分不该一刀切删掉。第二类是场外讨论比如“今晚吃什么”“等等我找一下规则书”。非剧情相关内容建议移动到文末的“场外记录”附录便于追溯但不干扰主线阅读。第三类是重复表达。跑团时同一件事可能有玩家说了三遍主持人也复述了两遍。整理时应该保留下最完整、最有画面感的一个版本其余删除。3.4 命名规范与目录约定文件命名建议采用“序号-标题”的格式。比如01-序幕、09-雪山密室。数字序号要用两位数否则第 10 话出现后排序会变成 1、10、2极不方便。如果需要维护多话之间的关联可以建立一个README.md在文件里写清每话的状态、负责校对人、发布时间。这样做的好处是即使同一个项目有多个整理者每个人都能快速知道当前进度。4. 使用 Git 管理 Replay 项目的完整流程4.1 初始化仓库与 .gitignore新建项目后第一步是初始化 Git 仓库cd p4-replay git init git branch -M main然后创建.gitignore文件把系统文件和临时文件排除在版本管理之外.DS_Store Thumbs.db *.tmp *.log如果你存放了语音或视频素材不建议直接提交到 Git 仓库因为这些二进制文件会让仓库体积迅速膨胀。更好的做法是素材放到网盘或专用文件存储仓库里只保留文本和脚本。4.2 每次修订的提交粒度Git 不是用来做备份网盘的它的核心价值在于每一版都能追溯。所以提交粒度很重要建议一个逻辑操作对应一次提交。比如你完成第九话初稿可以这样提交git add volumes/09-雪山密室.md git commit -m docs: 完成第九话初稿之后你校对完场景一git add volumes/09-雪山密室.md git commit -m fix: 校对场景一修正 PC2 的台词归属这样每次提交都记录了一个变更原因后面看提交历史时很容易知道哪些地方被改过以及为什么改。4.3 用分支完成校对与发布如果 Replay 项目有多人协作建议用分支隔离不同阶段的工作。比如主分支永远保持“上一个已发布版本”的状态所有修改都在proofread分支上进行git checkout -b proofread git add volumes/09-雪山密室.md git commit -m docs: 第九话校对完成 git checkout main git merge proofread这样即使校对过程中出现大改也不会影响已经发布的历史版本。合并到 main 后再推送到远端仓库参与者都可以拉取最新内容。4.4 用 Tag 标记每话完结当一话正式发布后建议打一个 Tag。Tag 就像给这本书贴上一个醒目的书签之后无论改过多少次你都能快速找到发布时的那个版本。git tag -a v1.0 -m 第九话 雪山密室 完结发布如果之后想对比发布版与最终版之间的差异只需要git diff v1.0 HEAD这套做法很适合长篇连载 Replay。第一话打上 v1.0第二话打上 v2.0后面想回看任何一话都像翻目录一样方便。5. 用 Python 脚本清洗跑团原始文本5.1 为什么要写脚本而不是手工改跑团语音转写文本有个典型特征大量时间戳、无意义语气词、角色名与台词混在一起。如果要靠手工处理一份上万字的转写稿至少两小时起步还容易漏改。而这类文本的噪声模式非常固定用正则表达式就能覆盖绝大部分情况。下面这个脚本的思路是逐行读取原始文本先清理时间戳再把“角色名台词”转换成【角色名】和台词分开的格式。你只需要把它保存为scripts/clean_record.py使用。5.2 清理时间戳与音转文字噪声语音转写工具生成的文本里每一句前面经常带着类似[00:12:23]的时间戳。你可以用下面的正则表达式把它去掉。import re def clean_line(line: str) - str: line line.strip() if not line: return # 去掉时间戳例如 [00:12:23]、00:12:23 line re.sub(r^\[?\d{2}:\d{2}:\d{2}\]?\s*, , line) # 去掉常见的音转文字噪声 noise [ 沉默, 笑声, 音乐, [背景音], ] for n in noise: line line.replace(n, ) return line.strip()这段代码的核心是用正则表达式匹配行首时间戳。如果你的转写文本时间戳格式不同只要调整方括号内的部分即可。5.3 把“角色名台词”转换为【角色名】格式接下来是关键转换函数识别中文冒号或英文冒号把冒号前面的内容作为角色名冒号后面的内容作为台词。def convert_line(line: str) - str: # 匹配“角色名台词”角色名最多 12 个字符 m re.match(r^([^:]{1,12})[:]\s*(.*)$, line) if m: name m.group(1) content m.group(2).strip() if content: return f【{name}】\n{content} return f【{name}】\n无台词 return f【旁白】\n{line}这里需要注意的是万一某个角色名本身包含冒号或者旁白前面没有冒号脚本会把它归为【旁白】。所以脚本只能作为初筛不能完全替代人工校对。5.4 通过脚本批量生成 Markdown 文件最后把读取和写入串起来def main(): input_path ../raw/09-雪山密室-语音转写.txt output_path ../drafts/09-雪山密室-未校对.md with open(input_path, r, encodingutf-8) as f: lines f.readlines() output_lines [] for raw in lines: line clean_line(raw) if line: output_lines.append(convert_line(line)) output_lines.append() with open(output_path, w, encodingutf-8) as f: f.write(\n.join(output_lines)) if __name__ __main__: main()用python scripts/clean_record.py运行后你会在drafts目录得到一个初步整理好的 Markdown 文件。此时不需要马上删除原始文件建议把原始素材留在raw目录里作为后续核对的依据。6. 从 Markdown 导出 PDF 与在线阅读页面6.1 用 Pandoc 导出带目录的 PDF整理完 Markdown 后如果想分享给不熟悉 Markdown 的玩家导出 PDF 是很好的方案。Pandoc 可以把 Markdown 直接转成带书签目录的 PDFpandoc volumes/09-雪山密室.md \ -o 09-雪山密室.pdf \ --toc \ -V CJKmainfontNoto Sans CJK SC其中--toc表示自动生成目录CJKmainfont用于指定中文字体。如果你在 Windows 上使用可能需要把字体名换成“Microsoft YaHei”或你系统里已有的中文字体。如果不指定中文字体PDF 里的中文很可能变成乱码或者方块字。6.2 用 MkDocs 搭建在线阅读站如果你不想每次导出 PDF而是希望整个 Replay 系列都能在线阅读推荐使用 MkDocs。它是一个基于 Python 的静态站点生成器安装命令如下pip install mkdocs项目里新建mkdocs.yml内容参考site_name: P4 角色桌 Replay nav: - 首页: index.md - 第九话-雪山密室: volumes/09-雪山密室.md theme: name: material之后运行mkdocs serve浏览器打开http://127.0.0.1:8000就能实时预览在线阅读页面。预览确认无误后运行mkdocs build它会生成一个site目录里面的内容可以直接部署到任意静态文件托管平台。6.3 导出前需要注意的编码与字体问题中文内容转换成 PDF 或网页时最常见的坑是编码不一致。Markdown 文件和脚本里的encoding参数需要统一使用 UTF-8否则在部分平台上会出现乱码。如果你发现 Pandoc 导出的 PDF 没有中文字体请先确认系统里已经安装对应字体。安装后如果还是不生效可以用fc-list :langzh命令列出当前系统支持的中文字体再把字体名填到CJKmainfont参数里。这个过程不需要记住所有参数但需要知道问题出在字体配置而不是文档内容本身。7. 常见问题与排查思路下面整理 Replay 整理和发布过程中最常见的几类问题按“现象、原因、思路”三列说明。问题现象常见原因解决思路导出 PDF 中文显示为方块缺少中文字体或未指定 CJK 字体用fc-list :langzh检查系统字体在 Pandoc 命令中设置CJKmainfontMarkdown 文件在别人的电脑上显示乱码文件保存时不是 UTF-8 编码统一用 UTF-8 编码保存注意 Windows 记事本的默认编码设置Git merge 时出现冲突多人同时修改同一段内容先用git pull拉取最新代码再手动解决冲突保留合理版本语音转写文本清洗后出现角色名混乱原始文本中存在多个称呼或昵称在脚本中维护一份角色名映射表把同一角色的不同称呼统一替换发布后图片不显示图片路径使用了绝对路径使用相对路径并保证图片文件也纳入 Git 版本管理Replay 前后语气不一致多次跑团间隔太久整理人靠记忆补全每次跑团结束后尽快把语音转写和笔记存入raw目录减少记忆偏差排查时不要一上来就重写全文。先定位是格式层的问题、内容层的问题还是工具链的问题。格式层可以通过规范和模板解决内容层只能靠人工校对工具链问题则优先检查版本和路径。8. Replay 制作的工程化最佳实践第一固定术语表。同一个技能、同一个地名、同一把武器在全文中的叫法需要保持一致。建议在项目根目录维护一份glossary.md把每个专有名词的标准写法记录下来。这样换人整理时不会出现“雪山密室”和“雪山小屋”混用的情况。第二保留可追溯的原始素材。所有来自语音转写、截图、聊天记录的内容都尽量保留在raw目录并且用文件命名标注来源时间和平台。这样复查时你可以快速定位某句台词到底是谁说的。第三提交信息使用清晰的前缀。可以用feat表示新增内容fix表示校对修正docs表示文档调整。比如docs: 完成第九话场景二初稿 fix: 修正 PC3 技能检定结果第四发布前进行隐私和敏感信息检查。跑团记录里很可能混入玩家真实姓名、联系方式、工作信息等。发布前至少通读一遍把能识别到现实身份的信息替换或删除。这既是对参与者的尊重也避免后续不必要的麻烦。第五制定“每次跑团后的黄金 24 小时”规则。跑团结束后当天或第二天先把语音转写、笔记、角色卡状态整理进raw目录。不需要马上写出成品但一定要把原始记忆固化下来越晚越难补。第六常态化导出预览。每次校对完一个大场景都运行一次 Pandoc 或 MkDocs 预览确认最终排版效果。不要在最后一刻才集中导出否则格式问题会堆在一起爆发。9. 总结搭建属于你自己的 Replay 流水线从素材整理到正式发布Replay 制作完全可以像软件项目一样有章法。先建目录再定 Markdown 模板然后用 Git 保留每一次修改用 Python 脚本处理重复性清洗最后用 Pandoc 和 MkDocs 导出适合阅读的成品。这套流程对单话完结团有效对长篇连载团更加有效。在 P4 角色桌这类连载项目中第九话《雪山密室》作为完结篇最大的风险不是写得不够精彩而是前面八话积累的风格和细节到收尾时变得难以衔接。有了统一模板和版本管理哪怕中间隔了很久整理者也能快速找回上下文。建议下一次跑团结束后不要急着把记录文件随手丢进聊天记录里先建一个 Git 仓库复制一份模板然后按照raw → drafts → volumes的顺序整理。动手之后你会发现一篇能长期保留的 Replay 并不需要等灵感真正需要的是稳定的流程。