跑团社区里replay 是每次跑团结束后最重要的交付物。它把语音频道里的笑闹、骰娘滚出的数字、GM 即席描述的场景整理成一篇能再次阅读的剧本式记录。而“鬼灭角色桌replay”这类连载更是把同人世界观、原创村落和原作角色放到同一张桌面上的内容创作。以“虚舟之村07黑死牟很满意”为例它意味着第 07 集剧情推进到一个关键节点黑死牟作为强敌或关键 NPC 登场并且这一集的剧情方向要让这个角色“很满意”。很多同好做连载到中段就会乱角色卡散在各处伏笔前后矛盾单集记录要么像聊天记录水账、要么像小说却丢了判定过程。这篇文章会从工程整理角度给出跑团 replay 的标准化处理流程并以“虚舟之村07”为例覆盖单集结构模板、整理流水线、NPC 驱动设计、分幕设计、发布校验和排错清单。学完后你可以把任意一集跑团记录整理成可复现、可连载、可发布的技术文档。1. 先理解角色桌 replay 的记录形态和信息架构1.1 replay、角色桌和跑团记录的关系TRPG 全称是 Tabletop Role-Playing Game也就是桌面角色扮演游戏。玩家围坐在一张“桌子”旁由 GMGame Master主持人描述环境和 NPC由玩家控制自己的角色做出选择用骰子判定行动结果。这里的“角色桌”是一个同好社群说法意思是这一桌玩家按固定的角色身份进行长期连载跑团角色不随便更换故事线也不断延续。“replay”这个英文词在跑团语境里不是“重播”而是“把跑团过程整理成可读作品”。它既可以是录音整理稿也可以是补全了动作、表情和内心描写的文学化文本还可以是带分镜说明的视频脚本。不同平台对 replay 的要求不一样在论坛和博客上读者更看重角色台词、判定结果和剧情推进在视频平台上读者更看重画面节奏和情绪张力。“鬼灭角色桌”就是指定世界观和角色身份玩家可能扮演鬼杀队成员、普通村民或使用原作角色作为 NPC。虚舟之村则是这一桌原创出的冒险舞台。“黑死牟很满意”作为第 07 集的标题说明这一阶段的核心张力不在简单战斗而在于 NPC 的态度变化。记录这种态度变化恰恰是 replay 整理中最容易丢失的信息。1.2 “虚舟之村07”这一集需要哪些结构模块跑团进行到第 07 集单集 replays 已经不能只靠“谁说了什么”来组织。一个集数到了中段的连载需要至少覆盖以下模块模块作用内容示例集数元信息说明这集在整体时间线中的位置第 07 集、故事线阶段、记录日期出场角色读者先认识角色才能看懂对话玩家角色、GM 控制的 NPC、临时配角场景列表按空间和时间切分剧情入村、祠堂、屋敷、夜斗判定记录保留骰子结果和技能行为感知检定 2D69成功剧情推进本集达成了哪些目标找到虚舟之村的线索引出黑死牟伏笔状态哪些问题仍悬而未决村长为何隐瞒祭品黑死牟为何满意下集预告给读者明确的期盼点接下来去后山还是先调查祠堂这七个模块不必都出现在正文里但至少要在元信息和幕后记录里存在。否则第 07 集发布后等到第 10 集再回头补设定成本会很高。1.3 为什么到第 07 集必须引入结构化整理前两三集可以靠记忆和聊天记录硬撑因为角色少、场景少逻辑关系一眼能看清。但到第 07 集通常已经积累了至少两三个场景、七八个 NPC、若干条伏笔和多次战斗。如果每集都是一大段聊天记录原文再去查“黑死牟上次说了什么”就会非常痛苦。结构化整理的目的不是限制创作而是降低查档成本。把单集拆成场景和事件标记每个角色的行为目标记录判定结果这样你在写后续剧情时可以在几分钟内确认某条伏笔是否已经回收。这也是把“临时跑团”升级成“可管理连载”的关键一步。2. 搭建一个可持续维护的 Markdown 单集模板2.1 用 YAML front matter 承载单集元信息在 Obsidian、Typora 或支持 Markdown 的博客编辑器中可以在文档顶部写一段 YAML front matter用来存放机器可读的元信息。这样后续做标签检索、文件名搜索和预览都方便。--- type: replay-episode serial: 鬼灭角色桌replay-虚舟之村 episode: 7 title: 黑死牟很满意 world: 鬼灭之刃世界观二次创作 status: 整理中 source: 语音频道录音 跑团文字记录 created: 2026-01-20 updated: 2026-01-20 tags: - 跑团 - replay - 鬼灭之刃 - TRPG scenes: - 虚舟之村·入村 - 虚舟之村·祠堂 - 虚舟之村·夜斗 characters: - GM - 玩家角色A - 玩家角色B - NPC黑死牟 cliffhanger: 黑死牟露出的满意笑意是否意味着新的命令 ---注意created和updated要按实际整理时间填写不要编造。YAML 的价值在于让一篇 replay 从“纯文本”变成“可检索的数据”。后续用脚本批量统计出场角色、伏笔状态也依赖这些字段。2.2 按“场景”而不是“聊天记录顺序”组织正文整理长文时最常见的错误是照着聊天记录的时间顺序一路复制粘贴。跑团过程中会出现大量闲聊、重复询问、反复确认规则这些内容不适合逐字保留。更推荐的做法是把正文拆成场景每个场景内部保留GM 描述、玩家行动、判定结果、角色台词。场景切换的判断标准有三个空间发生变化例如从村口走进祠堂。时间跳转例如从白天跳到夜晚。人物组合发生变化例如 NPC 退出、新角色进场。只要满足其中一个就应该另起场景。这样读者不会在同一个段落里同时面对三个空间的剧情GM 也更容易在回看时定位具体节点。2.3 用代码块、引用块和加粗标记保留骰娘判定、角色台词和 GM 描述在正式 replay 正文中有三种信息要区分得非常清楚GM 的环境描述、玩家的行动和台词、骰子判定结果。推荐用固定标记表示每种信息。## 场景·祠堂 **GM描述** 祠堂门口摆着两只褪色的石狐香炉里的烟不散反而贴着地面像水流一样朝内室涌去。 **行动判定** text 玩家角色A感知检定2D69成功。 GM你听见内室有极轻的呼吸声。角色台词A村长说祠堂十年没开过门可门环上一点灰都没有。GM黑死牟你们要找的“虚舟”早就沉在你们脚下。这样写的好处是读者扫一眼就能分辨信息类型。代码块里的判定记录不会误读成普通叙述引用块可以单独用来放关键伏笔。相比把一切都写成对话流水账这种格式更接近技术文档也更容易维护。 ## 3. 从录音/聊天记录到正式 replay 的整理流水线 ### 3.1 第一步原始材料转写与清洗 整理流水线并不复杂但不能省略步骤。第 07 集的原始材料可能是语音频道录音、YY 录音、文字语音频道也可能是大家用腾讯文档同步记录的文字。首先要做的是把语音转成文字初稿然后把语气词、重复句子、闲聊内容清洗掉。 清洗时可以保留以下内容 - 和剧情有关的角色台词。 - 所有掷骰记录。 - GM 的场景描述。 - 玩家讨论出的重要决策。 需要删掉的内容包括网络卡顿的重复发言、点外卖的闲聊、角色技能规则的反复争论。如果这些内容影响剧情可以在“幕后记录”中留一段摘要而不是塞进正文。 ### 3.2 第二步按角色标记发言并拆成场景 转写稿清洗完之后通常会得到一长串流水账。下一步要给每条发言标上角色名再按场景归组。这里的关键问题是跑团录音里说话的人名往往和角色名不一致玩家习惯用自己的昵称说话例如搬运工“达芬奇”嘴里的台词其实属于角色“鬼杀队队员”。 推荐做法是建一张映射表 | 玩家昵称 | 角色名 | 备注 | | --- | --- | --- | | 达芬奇 | 村雨玩家角色 | 战斗主力 | | 阿岚 | 藤原玩家角色 | 擅长调查 | | 夜风 | GM | 控制所有NPC包括黑死牟 | 标记完角色后再按上一节提到的场景切分规则把发言拆到不同场景块里。这一步是整理过程中最消耗时间的部分但也是决定 replay 质量的关键。 ### 3.3 第三步补全判定、时点和衔接词 语音转写稿中骰子结果经常和发言混在一起例如 text 夜风你先感知一下。 达芬奇哦好的我骰嗯9成功了吧 夜风成功你看见村口的灯笼在冒黑烟。整理成正文时需要把判定结果从流程化对话中剥离出来再补上场景和时间信息**行动判定** text 村雨感知检定2D69成功。GM描述 村雨站在村口看见原本红色的灯笼正在冒黑烟。烟不是从灯芯里冒出的而是从灯笼的纸面上渗出来的。这一步的本质是“把口语补成书面语”。补全时不要擅自增加角色没有做过的动作只把已经发生的口语表达压缩成清晰句子。如果现场没有明确说时间就写“日暮时分”或“夜间”不要编造具体日期。 ### 3.4 第四步用 Git 或版本文件保留过程稿 整理过程中一般会有三个稿态 - 原始转写稿。 - 结构化整理稿。 - 发布用最终稿。 不要直接在最终稿上覆盖原始稿。推荐建一个简单的 Git 仓库管理文本 bash cd replay-project git init mkdir -p episodes/assets mv 07原始转写.md episodes/07-source.md git add . git commit -m 第07集原始转写入库这样做最大的好处是可回溯。发布后如果发现某句台词标错了角色可以直接对比原始稿确认如果写后续剧情需要引用第 07 集的细节也能快速定位到当时玩家的实际发言而不是依赖记忆。4. 角色卡与 NPC 设计黑死牟这类 BOSS 如何写成可驱动的剧情节点4.1 角色卡结构不只有数值还要有行为目标跑团角色卡通常包含数值例如生命、技能、装备。但如果只写数值NPC 在剧情里会变成一个“站着等战斗的怪物”。对于黑死牟这类原作中的强大角色更重要的是他的行为目标、态度变化和剧情按钮。可以把每张重要 NPC 卡设计成下面这个结构--- name: 黑死牟 identity: 上弦之壹设定参照原作但按本桌剧情调整 desire: 寻找能与自己抗衡的对手 current_feeling: 冷淡隐藏的战意正在上升 trigger: - 对手展示出某种“不屈服”的意志 - 有人提到过去武士时代的名号 boundary: - 不会对毫无价值的弱者出手 - 会对侮辱剑士尊严的行为出手 satisfaction_level: 6 satisfaction_threshold: 0-3: 无感兴趣随手离开或命令下位者处理 4-6: 开始观察允许对方继续行动 7-8: 主动释放压力引用剑士荣誉 9-10: 罕见地认可做出“满意”表态 ---这段结构不是严格的游戏数值而是一种“剧情驱动表”。它回答的问题只有一个在什么情况下这个 NPC 会觉得“满意”一旦确定这个问题GM 就可以在剧本里给玩家递出机会而不是全靠临场发挥。4.2 用“剧情满意度”作为驱动 BOSS 行为的量表把 NPC 的行为映射到一个 0 到 10 的量表是非常实用的做法。它不会影响战斗数值但会影响角色说话的方式、出手的时机和放水的程度。对黑死牟而言如果“满意”是这一集的标题那么满意度变化就是整集的主线。满意度黑死牟可能的行为玩家可察觉的迹象0-3无视玩家转身离开对话得不到回应4-6停步听玩家说完并简单回应愿意回答一个直接问题7-8主动描述自己过去的时代释放压迫感台词变多语气有变化9-10承认玩家的资格做出“满意”表态出现“满意”或等价台词剧情进入新阶段这张表对 GM 也有保护作用。它让高强度反派不至于被“玩家三句话说服”也不会毫无理由地暴走。满意度上升需要有对应的事件支撑例如玩家展示了勇气、查清了某个关键线索、或在战斗中坚持到某个回合。4.3 给 NPC 设计反应表避免 GM 临场乱答高人气 NPC 最容易出现的崩坏就是 GM 临场回答“这也行那也行”导致玩家觉得角色态度反复无常。更稳妥的做法是预设一套反应表玩家行动类型NPC 反应方向备注主动进攻防御并试探实力不立刻杀死玩家先观察表现出不屈斗志嘴角微动战意上升满意度 1用谎言遮掩真相冷漠拆穿谎言但不解释满意度保持不变主动询问剑士精神愿意给出带有隐喻的回答满意度 2侮辱剑士尊严表情变冷开始使用力量满意度 -3反应表不需要覆盖所有情况只要覆盖你判断会出现的几类行动。真正跑团时如果出现表外行为GM 可以临时决定但至少有反应表兜底。标题里“黑死牟很满意”对应的就应该是表中某个明确动作让满意度突破阈值。5. 分幕设计把“黑死牟很满意”做成阶段高潮5.1 用三幕结构组织单集侦察、试探、交锋单集 replay 如果从头到尾都是铺陈读者会失去耐心。跑团记录也可以参考叙事结构。第 07 集如果以“黑死牟很满意”为目标整体节奏可以拆成三幕侦察幕玩家在虚舟之村调查异象逐步靠近黑死牟所在的核心场景。试探幕玩家与黑死牟或其下属发生接触通过对话、鉴定或短战斗判断对方身份和意图。交锋与表态幕玩家用行动争取黑死牟的认可最终触发“满意”表态结束本集并留下下集钩子。三幕不是死规则而是兜底框架。如果第 07 集实际录音只有两个场景那就不要为了凑三幕硬改记录。结构整理的作用是让节奏更清楚而不是虚构不存在的剧情。5.2 在一个剧本文件中落实“开始-发展-高潮-收尾”整理时可以给每集写一个“编辑用剧本块”放在正文前面或独立幕后台账里。它不发给读者只给整理者自己用## 第07集编辑剧本 - 开始玩家在虚舟之村后山找到被烧毁的祠堂。 - 发展祠堂地下发现旧剑触发黑死牟的精神投影。 - 高潮玩家坚决否认自己会放弃剑士身份黑死牟从俯视变成正视。 - 收尾黑死牟留下一句话并消失满意度达到 8本集标题成立。如果实际录音中玩家没有做出那个“坚决否认”的行动那就不能把高潮写成这样。整理分幕时的原则是先看跑团现场实际发生了什么再用分幕结构去解释它而不是反过来要求现场剧情迁就模板。5.3 设计“满意”的高光节点胜利不一定是战斗胜利很多跑团记录到了与强敌对峙的场景都会滑向“战斗解决一切”。但“黑死牟很满意”这个标题本身就提示了一种更耐读的节点反派满意不代表玩家打败了反派也不代表玩家讨好反派。认可可以来自战斗中的气魄、调查里表现出来的敏锐或者对某段旧事的诚实回答。在高光节点设计时要确认三个信息都覆盖到触发者玩家中谁的行动让 NPC 满意度变化。触发点具体是哪个动作或哪句话。后续影响满意之后 NPC 是离开、结盟、还是更危险的试探。这三个信息必须在 replay 正文里清楚体现。否则读者读完只会觉得“黑死牟突然笑了”不会觉得“黑死牟很满意”是一个有因果支撑的剧情节点。6. 发布前验证从工作稿到可读稿件的检查清单6.1 预览、超链接、图片路径和标签检查Markdown 写完后不能只看编辑器的流畅预览就发布。至少要在发布前走一遍以下检查1. 检查图片路径是否相对路径发布到博客后能否正常显示。 2. 检查所有二级标题是否有序号三级标题是否归到正确二级标题下。 3. 检查代码块是否标注语言比如 text、markdown、yaml。 4. 检查标签是否和既有连载一致例如“鬼灭角色桌”“虚舟之村”。 5. 检查每段之间是否有空行防止 Markdown 解析粘连。CSDN 和博客园对 Markdown 的解析不完全一致。在编辑器里看起来正常发布后可能出现清单序号错乱、表格宽度异常、代码块语言标识失效。因此发布前要重新打开发布预览再用手机端看一眼排版。6.2 内容合规和剧透提示检查同人创作发布时需要额外注意两点一是剧透提示二是内容尺度。如果文章涉及原作动画后续剧情最好在开头写一句“本文含原作设定剧透请谨慎阅读”。这既是保护读者体验也是让连载读者做好心理准备。跑团记录中的战斗描写可以保留但不要故意放大血腥和惊悚。例如“黑死牟的刀锋掠过眼前”可以保留“五脏六腑被切开”这类细节就不需要写在 replay 里。二次创作可以写冲突但要保持在合理讨论和正当创作的范围内。6.3 连载信息一致性检查连载最怕前后不一致。发布第 07 集前要对照前几集确认以下信息检查项示例角色姓名是否一致第 07 集角色名是否沿用前几集的叫法场景名称是否一致是“虚舟之村祠堂”还是“虚舟村祠堂”已回收伏笔是否标记第 05 集提到的旧剑是否在本集出现时间线是否连续本集发生在第 06 集之后第几天标题格式是否统一是否沿用“【鬼灭角色桌replay】虚舟之村07”的命名这些看似小事但在连载中会被读者反复检查。信息不一致会直接破坏可信度比文笔不精致更致命。7. 常见问题排查跑团记录整理到底容易卡在哪7.1 转写错乱对话张冠李戴现象一段台词本来应该是 NPC A 说的结果整理文中变成了 NPC B 说的或者玩家角色 A 的台词写到了角色 B 头上。原因语音转写稿本身没有角色标签玩家昵称和角色名混用整理时凭印象填名字没有回到原始稿核实。检查方式用搜索工具在原始稿里搜台词中的关键名词例如“虚舟”“满意”“剑士”确认说话人身份。处理建议整理时先建立昵称到角色的映射表台词归位要逐条完成。发布前至少通读一遍发现任何不自然的对话立刻回原始稿对照。7.2 时间线冲突同一事件两种说法现象第 07 集说“祠堂是昨天烧毁的”但第 05 集已经写过“祠堂三年前被烧毁”。原因跑团过程中时间感模糊玩家和 GM 可能在闲聊中随口调整了设定但整理时没有同步修改前几集记录。检查方式把每一集的高亮关键事件做成一行摘要放进集数总表例如“第 05 集祠堂烧毁事件”“第 07 集祠堂地下发现旧剑”。处理建议把冲突写到“待确认清单”中和 GM 确认后再修改。不要自己在没有依据的情况下强行选择其中一个版本因为玩家群里可能有明确的共识。7.3 角色语气不一致现象黑死牟在前一幕说话克制、用词古老后一幕却变成白话甚至加入了现代网络用语。原因整理者为了让记录“热闹”擅自给角色增加了原设定里没有的口癖和语气或者 GM 在跑团时说话太快把 NPC 语气和 GM 自己的语气混在一起。检查方式单独抽出一段角色台词和前几集同角色台词对比确认语气词汇是否在同一体系内。处理建议给重要角色写一句“语气关键词”。例如黑死牟关键词可以定为“克制、俯视、带有旧时代称谓”。整理台词时始终参考关键词。如果 GM 现场出现明显语气偏出走的情况可以改为“GM 以黑死牟身份低声说”并固化在旁白中。7.4 单集过长或过短现象第 07 集整理稿超过 1 万字但绝大多数是场外闲聊或者只有 2000 字剧情推进过少读者觉得“什么都没发生”。原因没有设置集数内容的上限和下限也没有在跑团前和 GM 对齐本集目标。检查方式统计本集场景数、关键事件数和有效台词比例。如果场景数小于 2且没有形成明确的高潮节点就要考虑是否把两集合并。处理建议建议每集设定一个明确目标例如“调查祠堂”“引出黑死牟”“提高满意度到 8”。整理时只保留服务于这些目标的内容。超出目标但很精彩的剧情可以留下一集使用不要硬塞进本集合。8. 最佳实践把单集模板升级成“跑团连载知识库”8.1 建立角色、地点、事件三个标签维度一集一集的 Markdown 文件会越来越多。为了不淹没在文件堆里要给每篇文档打上三个维度的标签角色、地点、事件。角色黑死牟、玩家角色A、村长 地点虚舟村、祠堂、后山 事件调查黑猫、发现旧剑、满意度达到阈值在 Obsidian 中可以在每集 front matter 的tags里写入这些标签然后利用嵌套标签搜索。例如想看所有“黑死牟”出场的集数直接按#角色/黑死牟检索就可以。这比把信息堆在脑内可靠得多。8.2 用 Obsidian 双向链接管理跨集伏笔如果整个连载目录放在 Obsidian 知识库中可以给关键人物和地点建立独立文档再用双向链接把它们串起来。--- name: 黑死牟 type: npc appearances: - [[虚舟之村07-黑死牟很满意]] - [[虚舟之村03-剑士的传说]] ---在“虚舟之村07”正文中把黑死牟的名字写成[[黑死牟]]Obsidian 就会自动生成反向链接。这样当你思考下一集剧情时打开黑死牟的角色页就能看到所有他出现过的集数以及当时的状态。跨集伏笔的回收情况一目了然。8.3 可复用清单每集发布前要核对什么把发布检查固化成清单每集都按同一套顺序执行能避免人为遗漏。以下是一个可直接复用的发布前核对清单标题是否保持统一格式例如“【鬼灭角色桌replay】虚舟之村07黑死牟很满意”。front matter 中的集数、日期、角色、场景是否更新。场景之间是否用了明确的标题分隔是否按时间、空间变化切分。判定结果是否保留是否标注了哪些角色参加了检定。本集标题中的“满意”是否有明确事件支撑读者能否从正文中看到触发原因。关键 NPC 的态度变化是否清楚满意度从多少变成了多少。是否标注了本集回收的旧伏笔和新埋下的伏笔。是否在文末留下下一集钩子例如“后山的雾越来越浓黑死牟的满意究竟意味着什么”。是否有明显血腥描写或不适内容是否需要弱化。是否用发布预览重新渲染表格和代码块是否正常。是否和前几集的时间线一致没有把旧事件写成新事件。这个清单可以贴到每篇文档的末尾作为幕后备注也可以在发布前单独打开一份。重点不是清单本身多长而是每次发布都按同一标准执行。8.4 下一步扩展从文字 replay 到视频分镜脚本当连载进入成熟期很多人会把 replay 改造成短视频或分镜脚本。到这一步之前按场景拆分的 Markdown 文档会变成非常好的素材库。一个场景块里的 GM 描述、角色台词、判定结果可以分别映射到视频的旁白、角色配音、字幕和画面提示。场景标题可以直接变成分镜的镜头编号。角色满意度变化则可以作为剪辑节奏的依据满意度低时节奏平缓满意度到 7-8 时开始切近景满意度到 9-10 时给出停顿或呼吸感。没有必要等跑团跑完才开始规划视频。从第 07 集开始如果每集都保留结构化场景将来做视频时只需要做“翻译”不需要重新听录音。这也是结构化整理最直接的长线回报。跑团 replay 的记录整理本质上是一项内容项目管理工程。你可以从最轻量的 Markdown 模板开始先把第 07 集的场景、角色、判定和满意度变化标记清楚再逐步加入 YAML 元信息、Obsidian 双链和 Git 版本管理。不必第一次就做到完美但每一次整理都要比上一次多保留一点可查询的信息。真正有价值的不是“写得像小说”而是“任何节点都能被后来的创作者找到”。下次动笔整理下一集之前先把自己当成三个读者急着看剧情的读者、要查伏笔的编辑、以及三个月后还要继续写续集的你自己。