从车卡到log清洗：TRPG跑团replay制作全流程实用指南

在实际跑团项目里，“车卡”和“制作replay”经常被当成两件事：前者是开团前的玩家行为，后者是跑完后的后期工作。但如果你真正做过一个完整跑团replay，就会发现这两件事的关联远比想象中紧密。尤其像《常暗之厢》这种题材偏向封闭、压迫、信息有限的模组，角色卡如果不考虑实用性，跑团过程中就会出现“想调查却找不到线索、想逃命却跑不动、想交流却被人设卡死”的尴尬情况，而这些问题最终都会原封不动地进入replay素材，变成后期无法挽救的叙事短板。

这篇文章围绕“跑团replay前篇”这一阶段，从角色卡实用性、log结构化、素材录制、常见坑和发布检查几个维度展开。不是站在观众角度谈“这期视频剪得怎么样”，而是站在制作团队角度讲清楚：如何在开跑之前，就让角色卡服务于剧情传播；如何在跑团之后，用一套可复用的文件结构和脚本工具，把原始聊天记录变成方便剪辑的replay草稿。内容适合刚接触TRPG replay制作的社团成员、负责跑团记录的文字后期、以及想把自己的面团log整理成片的新手KP和玩家。

1. 为什么跑团replay也需要“实用性”设计

1.1 replay不只是录屏：从原始log到成片的工程链路

跑团replay在多数平台上呈现为文字加画面、音频加字幕、或者带立绘和骰点的动态视频。很多人以为制作replay的核心是软件操作，其实真正的核心是信息整理。一场四小时团会产生几千行聊天记录，里面有PC发言、NPC描述、骰点结果、玩家插科打诨、KP的即兴补充，甚至还有因为网络问题产生的重复消息和乱序消息。如果这些内容直接进入剪辑软件，任何后期都会被大量重复劳动拖垮。

更合理的方式，是把整条链路拆成四个阶段：

• 开跑前：确定模组基调、车卡、设定replay需要的素材清单。
• 跑团中：按约定格式记录log、录音、截图或录屏。
• 跑团后：清洗log、提取关键信息、生成分镜草稿。
• 制作发布：补立绘、配字幕、混音、压制、上传。

在这条链路中，角色卡的作用不只是游戏内的战斗能力，它同时决定了replay素材里“谁适合成为镜头焦点”“哪些场景有情绪冲突”“哪些检定结果值得被放大”。所以车卡阶段做一次实用性检查，本质上是给后续replay制作降低信息处理成本。

1.2 车卡实用性决定了replay素材质量

在TRPG中，角色卡通常包括属性、技能、道具、背景故事和人设。所谓“实用性”，不是要求所有人都是战斗力拉满的战士，而是要求角色在某一个或某几个场景里有“能做事”的最低能力。比如一个主打社交的角色，至少要有话术或说服类技能；一个定位侦查的角色，至少要有侦察或聆听；一个负责殿后的角色，至少要在生命值或闪避上有余量。

《常暗之厢》这类标题本身就暗示了场景处于常暗环境，那么光源、感知、逃跑、封闭空间里的行动能力就会成为核心需求。如果一桌人全部选择高智力低体质的书卷型角色，跑团中可能所有行动都依赖KP不断放水。更麻烦的是，这种短板会在replay里被反复放大：观众能看到角色不断失败、不断迷失，但因为没有前后因果支撑，这些失败只会显得像“全员犯蠢”。实用性设计的意义，就是让角色在关键情节前拥有“可以做选择”的资本，而不是每次都被单维属性卡死。

1.3 适用读者和预期产出

这篇文章的读者并不是纯玩家，而是同时承担了“记录者”“后期”“流程策划”角色的实践者。最终预期产出包括三样东西：

• 一张经过模组适配的车卡检查清单。
• 一套从log到replay草稿的可复用脚本和文件规范。
• 一份发布前需要逐项确认的复查清单。

这三样东西都可以直接放进下一次跑团项目里使用。遇到类似《常暗之厢》这种封闭黑暗题材时，不需要重新摸索，只要按同一套流程调整即可。

2. 在车卡阶段就把“角色的功能位”定下来

2.1 先读模组，再决定属性分配

很多玩家习惯先想人设，再翻技能表，最后才看模组背景。这种顺序可以用来塑造有趣的角色，但放到replay制作里常常会制造矛盾。因为replay需要“高光时刻”，而高光时刻依赖技能能不能用出来。先读模组，再做属性分配，才能让角色设定和实际剧情产生耦合。

建议在开团前，KP或者replay策划先整理一份“模组关键词表”。比如根据《常暗之厢》这个标题，可以列出：黑暗、封闭、未知、搜查、逃离、人心隔阂。每个关键词对应一个或几个可能需要的技能类型：

• 黑暗对应侦查、聆听、照明道具、勇气相关。
• 封闭对应机械维修、撬锁、攀爬、潜行。
• 未知对应灵感、心理学、图书馆使用。
• 搜查对应侦察、追踪、电子设备或旧式观察手段。
• 逃离对应闪避、领航、驾驶、体格、运气。

这张表不需要写进最终replay，它的作用是让每个玩家在车卡时看到“这个模组里什么能力更容易被用到”，而不是等到骰子投出大失败才发现技能表选错了方向。

2.2 不同角色在replay中的叙事作用

replay不是逐字逐句的完整记录，而是有取舍的二次创作。剪辑时会突出冲突、悬念和情绪点。因此每个PC最好能承担一个清晰的叙事角色：

• 调查担当：负责推进信息收集，是replay的主线引擎。
• 交涉担当：负责与NPC对话，制造表面平和与暗流涌动。
• 战斗或逃跑担当：负责在危机来临时制造紧张感和动作场面。
• 气氛担当：负责吐槽、害怕、歪逻辑，给紧张模组提供节奏喘息。
• 后勤担当：负责道具、地图、关键物品管理，防止团队因为丢线索卡关。

这个分工不必摆在台面上，但KP在车卡时需要心里有数。如果所有玩家都想当“沉默冷酷的神秘角色”，那么跑团中就没有人承担主动沟通，replay素材里就会缺少对白密度，后期只能靠旁白硬填。实用性不仅指属性，也指角色在叙事分工上的用途。

2.3 把技能点与replay高光场景做对照

高光场景是可以预先设计的。以《常暗之厢》为例，可以预想几个大概率出现的情节：

• 进入黑暗环境前需要决定携带哪些光源。
• 在狭窄通道中遭遇意外，需要有人侦查到异常。
• 遇到不可名状或精神冲击时，需要进行意志检定。
• 为了逃生，需要有人能快速判断路线或破坏障碍。

在车卡时，可以让每个玩家回答一个问题：我的角色在哪个预想场景里能做出别人做不到的事？这个问题会让技能点分配更聚焦。例如“我点了高潜行，可以在被追捕时吸引敌人”“我点了黑市知识，可以在前期买到廉价光源”都是实用性高的选择。相反，“我的角色擅长二十世纪艺术史”在replay里也许能成为有趣的边缘人话题，却不能为团队在黑暗封闭场景里提供支撑。不是说不能点冷门技能，而是需要提前想清楚冷门技能如何被切入剧情。

2.4 车卡检查清单

为了方便直接复用，这里整理一张车卡完成后的自检表。每一项都可以在开跑前花两分钟确认。

这张表不是要限制玩家自由发挥，而是让自由度保留在“有底线的空间”内。replay里最怕的不是角色不够有趣，而是角色设定上无法行动，导致每个关键节点都只能等待别人救场。

3. 用结构化文件管理跑团log，避免后期手工整理

3.1 约定log格式：发言人、动作、骰点、OOC

跑团记录不管是文字团还是语音团转文字，都会产生不规整的原始文本。为了让脚本能自动处理，开跑之前需要约定一个轻量级格式。注意这套格式只服务内部处理，不需要玩家做复杂标记，只需要在最开始时统一三个习惯：

• 发言统一用“角色名：内容”开头。
• 动作和描述统一放在方括号或圆括号内。
• OOC（玩家场外吐槽）统一使用“（OOC）”前缀，或者统一放在斜杠内。

例如：

KP：你们推开那扇沉重的铁门。门轴发出刺耳声响，走廊深处没有一点光。 顾夜：我要把手电筒打开，先照一下地面有没有脚印。 （OOC）顾夜玩家：等等，我手电筒在包里还是手里？ KP：就算默认在腰间吧，你打开手电筒，看到地面全是灰尘。 顾夜：我蹲下仔细看那些脚印，要侦察。 KP：请骰侦察。 顾夜：侦察 65/42，成功。脚印看起来是新的，而且有两排。

这样的格式好处是后期脚本可以准确区分谁说的、做了什么、哪里属于场外。如果全部混在一起，后期就只能靠肉眼去识别，耗时且容易出错。

3.2 用Python脚本清洗log并转成JSON

拿到原始文本后，可以用Python脚本做第一轮清洗。假设原始log保存在log_raw.txt中，每行格式基本符合上述约定。脚本要做的事包括：

• 去掉空行和多余空格。
• 识别“角色名：内容”的行。
• 识别包含“骰”或“检定”的骰点行。
• 把带有“（OOC）”内容单独标记。
• 输出为结构化JSON。

下面是一个简化的示例脚本，用于说明处理思路：

import json import re RAW_FILE = "log_raw.txt" OUT_FILE = "log_clean.json" def parse_line(line): line = line.strip() if not line: return None # 判定是否为 OOC if line.startswith("（OOC）") or line.startswith("(OOC)"): return {"type": "ooc", "content": line} # 匹配 角色名：内容 m = re.match(r"^(【?([^:：]+)】?[:：])(.*)$", line, re.S) if not m: return {"type": "unknown", "content": line} speaker = m.group(2).strip() content = m.group(3).strip() # 判断是否包含骰点关键字 is_roll = any(k in content for k in ["骰", "检定", "成功", "失败"]) return { "type": "roll" if is_roll else "speech", "speaker": speaker, "content": content, } parsed = [] with open(RAW_FILE, encoding="utf-8") as f: for line in f: item = parse_line(line) if item: parsed.append(item) with open(OUT_FILE, "w", encoding="utf-8") as f: json.dump(parsed, f, ensure_ascii=False, indent=2) print("解析行数:", len(parsed))

这段脚本的关键点在于正则部分。^【?([^:：]+)】?[:：]可以兼容“顾夜：”“【顾夜】：”两种写法。is_roll的判断只是最小实现，实际项目里需要根据模组或骰子机器人的消息格式做调整，比如“侦察 65/42，成功”也可以识别为骰点。脚本不追求一次到位，它的价值是把肉眼检查变成可重复的自动检查。

3.3 从JSON生成replay分镜草稿

得到了结构化的JSON后，可以继续生成更接近剧本格式的replay草稿。每个分镜单元可以包含场景编号、参与角色、内容摘要、骰点事件和情绪标签。这里不需要复杂的NLP，先基于简单规则：

• 如果连续多条type为speed，可以合并成一个场景。
• 每次type为roll，可以作为一个事件点。
• 每出现一个OOC吐槽，可以在旁边标注“此处可剪成字幕彩蛋”。

例如可以输出一个Markdown草稿：

## 场景1：铁门之前 - 角色：KP、顾夜 - 事件：开门、手电筒、发现脚印 - 骰点：顾夜 侦察 65/42 成功 - 情绪：紧张、疑惑 - 备注：OOC吐槽手电筒位置，可做轻松字幕

这层草稿不需要生成得很精细，足够让后期知道“这个片段大概在讲什么”就行。如果团队用剪映、Premiere、Final Cut等工具，可以把这个Markdown粘贴到笔记软件里作为剪辑指引。

3.4 命名规范和目录结构

跑团项目的文件会越来越多，建议从第一天就建立固定目录。下面是一个可复用的目录结构示例：

project/ ├── logs/ │ ├── raw/ │ │ ├── 0117_raw.txt │ │ └── 0131_raw.txt │ ├── clean/ │ │ ├── 0117_clean.json │ │ └── 0131_clean.json │ └── scripts/ │ ├── clean_log.py │ └── gen_storyboard.py ├── assets/ │ ├── characters/ │ │ ├── gu_ye/ │ │ │ ├── face1.png │ │ │ ├── face2.png │ │ │ └── full.png │ │ └── npc_old_man/ │ │ └── face.png │ ├── backgrounds/ │ │ ├── corridor_dark.png │ │ └── basement_door.png │ └── audio/ │ ├── ambient_dark.wav │ └── impact_sting.wav ├── storyboard/ │ ├── 0117_storyboard.md │ └── 0131_storyboard.md ├── edit/ │ ├── project.prproj │ └── render/ └── release/ ├── replay_ep01_final.mp4 └── poster.png

命名规范建议包含日期和版本，例如0117_raw.txt代表1月17日的原始log，0117_clean.json是清洗后的结果。素材文件不要使用“最终版2修订”这类无法排序的名字。发布目录只放成品，避免把源文件混进去。

4. replay素材录制与时间轴匹配

4.1 素材准备：立绘、头像、背景、动效

跑团replay的画面通常由立绘、头像、背景和少量动效组成。在开跑前，至少要准备一套可以直接使用的通用素材：

• 每个PC的头像，用于发言时显示。
• 至少一张主要场景的背景图，比如走廊、房间、黑暗中的微光。
• NPC不需要全部立绘，可以先准备剪影或局部特写。
• 字体建议选用支持中文且风格贴合恐怖题材的字体。

如果团队美术资源有限，可以优先采用纯文字加背景图的方案。例如铁门场景只需要一张门与走廊的背景图，角色发言时显示头像，关键时刻放大背景或切换滤镜。素材实用性比数量更重要。

4.2 录制分工和音频降噪

语音团制作replay时，音频质量直接影响观感。录制阶段建议做到三件事：

• 每个玩家单独录一条音轨，或者至少分开录，方便后期单独降噪。
• 录制前设置统一的采样率和位深，避免不同录音文件混合后出现音调漂移。
• 录音过程中避免键盘声、塑料袋声和突然提高音量的拍桌声。

降噪可以在剪辑软件里做，也可以在录音后用Audacity批量处理。如果使用Audacity，可以先用“噪音减弱”采集静音段，再处理完整音频。需要注意降噪过度会让声音变闷，所以处理时先预览几秒，不能为了消除底噪把语音也一起削掉。

4.3 字幕与时间轴的常见对不齐问题

replay视频里的字幕，通常不只是语音，还包括骰点、物品名称、地名人名。对不齐的常见原因有三个：

• 时间轴是手工打的，没有以音频峰值作为对齐参考。
• 字幕内容里包含OOC吐槽，被误当成剧情对白。
• 视频剪辑后整体变速，但字幕轨没有跟着变速。

解决方式是在剪辑完成后再统一处理字幕。如果使用剪映，可以先把所有文字做成一个TXT或SRT文件，再拖到时间轴里逐段对齐。如果使用Premiere，可以先把JSON转成字幕文件，再绑定到对应片段。核心原则是不要边剪边加字幕，先确认画面和音频稳定，再集中处理字幕。

5. 常见坑与排查链路

5.1 log出现乱序或漏行

现象：跑团过程中网络波动导致消息顺序错乱，或者某段关键描述没有录到。

可能原因：语音转文字工具本身会延迟；部分平台的聊天记录导出顺序并不是实时的；玩家在快速连续发言时，消息被合并。

检查方式：在清洗log时，对比数字编号或时间戳；如果原始平台不提供时间戳，就看前后文连贯性。

处理建议：乱序严重的段落直接联系相关玩家确认原始内容；漏行的段落可以让玩家补录一条口述说明，后期把这段补成“回忆”或“旁白”。预防方式是开跑前提醒玩家：重要描述尽量一句话说完整，不要拆成十几条短消息。

5.2 角色名和昵称不统一

现象：同一个角色在log里出现“顾夜”“顾夜小姐”“小顾”，脚本无法合并为同一人。

可能原因：玩家在跑团过程中使用简称、绰号，KP也在用不同称呼。

检查方式：写一个统计脚本，把非标称呼全部列出，再手动映射。

处理建议：在解析脚本里维护一个别名映射表：

ALIASES = { "顾夜": ["顾夜", "小顾", "顾夜小姐", "顾夜同志"], "阿铭": ["阿铭", "铭哥"], } def normalize_speaker(raw_name): for canon in ALIASES: if raw_name in ALIASES[canon]: return canon return raw_name

这是低成本但非常有效的一步。否则后期字幕里同一个角色使用多个名字，观众很容易认错人。

5.3 骰点格式多样导致解析失败

现象：脚本只能识别“侦察 65/42”，但当log中出现“顾夜的侦查技能判定：成功”或“D100=42”时，无法正确识别。

可能原因：不同骰子机器人输出的格式差异很大，同一个机器人不同模组配置也不一样。

检查方式：把原始log里所有含“骰”“成功”“失败”“D100”的行单独导出，查看正则覆盖情况。

处理建议：让KP在开跑时统一使用“技能名 成功率/出目，结果”的格式，例如“侦察 65/42，成功”。如果格式已经混乱，就用第二层正则做兜底匹配：

def is_roll_line(content): patterns = [ r"[\d]{1,3}/[\d]{1,3}", r"D100[=＝]?\d{1,3}", r"(侦察|聆听|意志|闪避|力量|敏捷)[^\n]{0,6}(成功|失败)", ] return any(re.search(p, content) for p in patterns)

这个例子展示了“宁可多识别，也不能漏识别”。多识别会带来少量噪音，漏识别会让关键检定消息被当成普通对白，后期找起来更麻烦。

5.4 长音频不同步

现象：语音团录音有多个文件，拼接后发现前一秒台词还正常，后一秒就开始对不上。

可能原因：不同设备录音的采样率不一致，或者某一台设备因网络问题产生了静音空缺。

检查方式：把两条音轨拖进剪辑软件，观察波形峰值是否对应；也可以打一个响亮拍手作为时间参考点。

处理建议：录制前统一软件和参数，开局和每半小时做一次拍手标记。后期过程中，先对齐拍手标记，再用时间轴微调。如果音频已经严重错位，优先保留质量最高的主音轨，其他音轨作为参考，不要强行拼接。

5.5 发布前检查清单

发布replay之前，建议逐项确认以下内容：

这张表可以在每次发布前打印出来或者放进项目管理文档中，按行打钩。不要跳过，因为replay发布后修改成本很高。

6. 实践建议与扩展方向

6.1 学习环境：先用单模组最小闭环

如果你是第一次做跑团replay，不建议一上来就追求完整视频和花哨转场。可以先用《常暗之厢》前篇或一个短团做一次最小闭环：

• 只做一个场景，约三到五分钟。
• 只保留两个角色、一次骰点、一次关键冲突。
• log手动清理也可以，不急着写解析脚本。
• 使用免费剪辑软件，先完成一条可发布的长视频试作品。

这个闭环的目的是走通“车卡资料确认、log整理、素材准备、剪辑、导出、复查”的完整路径。跑通一次后，再考虑把流程脚本化和自动化。

6.2 生产环境：版本管理与发布流水线

当团队开始稳定产出replay时，就要把制作过程当成一个持续交付项目。建议引入四个机制：

• 文件版本管理：以日期和序号命名，避免“最终版”覆盖。
• 日志和素材的备份：每次跑团结束后，把原始文件压缩存档，不要直接删。
• 脚本复用：把log清洗、分镜生成、字幕文件生成做成固定脚本，放在项目根目录的scripts文件夹中。
• 发布记录：用一个简单的README.md记录每集的发布链接、素材状态和遗留问题。

生产环境最需要考虑的是“如果某个玩家中途换人，replay如何持续更新”。这时角色卡和素材命名的一致性就显得更重要。建议在项目启动时定义好每个角色的正式代号，所有素材都使用代号命名，例如gu_ye_face.png，不要用“新顾夜”“顾夜最终脸”。

6.3 再往后可以做的工具化方向

当你有了一批项目的经验，可以考虑把散落脚本整合成一个小工具。例如：

• 一个命令行工具，输入原始log，输出清洗后的JSON和分镜Markdown。
• 一个角色素材检查器，自动检查每个PC是否缺少头像、背景和语音分段。
• 一个错位校对器，读取字幕文件和音频时长，对标出超长字幕或缺失字幕。
• 一个发布打包脚本，自动把视频、海报、简介文本整理到发布目录。

这些工具不一定要做成网站或平台级产品。只要能减少下一期replay制作时长，就已经形成了实际价值。对于《常暗之厢》这类偏黑暗压抑的模组，最有价值的工具往往不是渲染特效，而是能准确留住“谁在什么时候说了什么、投出了什么结果”的记录系统。

做replay和跑团一样，真正的乐趣在于过程会被还原，而不是被流水账吞掉。从车卡阶段就把实用性考虑进去，再配合一套清晰的文件整理流程，你后续每一次剪辑和发布都会比上一期更从容。