跑团 replay 在中文 TRPG 社区里已经从简单的过程记录变成了一套带有明确编辑思路的内容产品。像《谢娘娘点化》第二回不儿绣花鞋为啥不要啊这样的标题明显不是桌面玩家原始聊天记录的复刻而是经过二次创作之后的成品有人在整理日志有人在判断哪些信息值得保留有人在设计章节悬念也有人负责最终的排版与发布。这篇文章要讲的就是文字团 replay 背后的工程化生产流程从原始聊天记录里切分角色与动作用脚本清洗骰点噪声维护一张角色别名表来保证全文称呼统一再把粗糙过程记录重构为带钩子的章节文本最后做一遍发布前检查。这套流程对跑团主持人和长期做跑团二创的编辑尤其有用。学完之后你可以把自己仓库里那些零散截图、聊天导出和骰娘日志稳定地变成一篇结构完整、可发布、可存档的 replay 长文。1. 先把 replay 的工序拆开原始记录如何变成可读故事1.1 replay 不是转写而是有视角的二次创作很多人对 replay 的理解是“把跑团过程记下来”。实际上只做记录得到的是流水账不是 replay。流水账里充满了骰点数值、系统提示、撤回消息、角色瞬移、规则争执以及不适合公开的隐私信息。真正的 replay 要保留的是故事层面角色的选择、失败的影响、关键台词的语气以及玩家之间临时碰撞出来的戏剧性。这意味着 replay 生产天然包含两层工作。第一层是技术层把原始日志变成结构化数据保证角色、动作、台词、检定结果被正确识别第二层是创作层从结构化数据里选出有戏剧价值的内容重新安排详略给章节起标题决定哪里挖坑、哪里揭晓。《谢娘娘点化》第二回这个标题已经能说明问题。标题里有几个明显信号“第二回”说明这是一个按回目组织的连载结构不是一次随机记录。“不儿绣花鞋为啥不要啊”是口语化反问带着明显情绪制造好奇心缺口。整句话是疑问句读者不知道绣花鞋和“不要”之间发生了什么就会想点进去看。所以一个合格的 replay 标题不是写完后顺手起的而是在叙事重构阶段就要设计的信息装置。技术流程的任务是把做这件事所需要的重复劳动降到最低。1.2 一条适合大多数文字团的 replay 生产链路把 replay 生产当成一条流水线来看可以避免“边写边整理、越整理越乱”的情况。下面这条链路适合绝大多数 QQ 群、Discord 服务器或论坛文字团获取原始日志从聊天记录导出、骰娘机器人日志或群下载记录中拿到源文件。日志清洗去掉系统消息、撤回记录和无关闲聊把每行内容拆成时间、说话人、正文。结构化标记识别台词、动作、旁白、检定记录把骰点从“1d10088/65”转成“失败”这样的故事语义。一致性校正把同一个角色的多种昵称统一确认地名、道具、关键剧情名词不冲突。叙事重构按回目或幕组织内容确定详略补写过渡句设计章节标题。自动检查与校对统计字数检查是否残留骰点、是否有人名异常、是否出现平台敏感词。发布适配把 Markdown 稿件复制到 CSDN、独立博客或公众号等平台微调图片和格式。这套流程的关键点是先让机器做能稳定重复的判断再让人做需要语境理解的判断。比如“这句话该不该保留”需要人判断但“这段话里是否还残留 1d100 骰子样式”应该让脚本判断。1.3 工具栈选型不需要复杂系统但需要固定习惯replay 生产不需要大型软件。常用的工具组合如下文本编辑VS Code、Obsidian甚至 Vim 都够用。重点是支持 Markdown 预览和全局搜索。数据处理脚本Python 3.9 以上用标准库 re、json 就可以不需要上爬虫框架。词汇表YAML 或 JSON。YAML 可读性更好适合人维护。版本管理Git。replay 稿件和脚本建议放进同一个仓库方便回溯。发布平台CSDN、博客园、知乎专栏、B 站专栏都支持 Markdown 或富文本粘贴。工具不建议频繁更换。replay 项目通常周期长跨越多周甚至数月如果每个章节都换一套工具格式一致性和自动化脚本都会失效。1.4 原始材料质量决定工作流复杂度需要提前判断的一个问题是你拿到的原始日志是不是完整、连续、带时间戳的如果原始材料来自骰娘机器人的自动记录那么时间、说话人、骰点都是结构化文本清洗成本低。如果原始材料来自群成员手动补录的截图那就只能用 OCR 或人工录入清洗成本会明显升高。这里有一个简单的判断标准如果一份日志里 80% 的行都能靠正则规则识别成“时间 人名 内容”就可以走自动化脚本如果大部分行是对话截图或语音转写碎片那么自动脚本只能做辅助检查主要工作要交给人工。下面几节的脚本默认建立在“日志本身有规律可循”的前提下。2. 原始日志的获取与清洗正确拆分角色、动作和骰点2.1 文字团日志的常见来源与噪声文字团日志主要来自三个地方聊天平台导出QQ、Discord 等平台有导出记录但可能只给纯文本或包含大量系统消息。骰娘机器人日志有一定规则的骰点记录经常连技能名、目标值、成功失败都写在同一条消息里。主持人或记录员手动补记适合剧情突发、语音团、线下团缺点是漏记和口语化严重。无论哪一种来源原始日志里都会有大量噪声。常见的噪声类型包括噪声类型示例片段处理策略系统消息“管理员开启全员禁言”直接删除撤回记录“某成员撤回了一条消息”跳过必要时用相邻台词补剧情重复消息玩家重复发送同一动作保留语义最新一条其余删除规则争执“这个判定应该用困难成功”删除不影响故事的规则讨论隐私信息手机号、年龄、地址、私人发言一律脱敏或删除骰点原始串“1d10088/65 失败”转成“检定失败”的语义标记无关闲聊外卖、工作、表情包刷屏删除处理原则不是“尽量保留”而是“只保留对故事理解有贡献的内容”。replay 是给读者看的故事不是给裁判复核的原始档案。2.2 把原始行解析成结构化数据先看一段通用日志样例。下面这段是演示格式与任何具体跑团剧情无关[2025-01-01 20:11] 团务官各位确认一下当前场景 [2025-01-01 20:12] 店员小姐那我先把那双布鞋放到柜台上 [2025-01-01 20:13] 骰娘店员小姐 进行 手艺-布鞋 检定1d10088/65 失败 [2025-01-01 20:14] 主持人鞋底翻上来针脚已经开线她盯着看了几秒皱起眉。用 Python 可以先按“时间 说话人 内容”的结构拆分每一行import re LINE_PATTERN re.compile( r^\[(?Ptime.*?)\]\s*(?Pspeaker.*?)[:]\s*(?Pcontent.*)$ ) line [2025-01-01 20:13] 骰娘店员小姐 进行 手艺-布鞋 检定1d10088/65 失败 m LINE_PATTERN.match(line) if m: print(m.groupdict())输出结果是一个字典{ time: 2025-01-01 20:13, speaker: 骰娘, content: 店员小姐 进行 手艺-布鞋 检定1d10088/65 失败 }这样还不能直接用来写故事因为“骰娘”的发言其实是一条检定记录需要进一步解析。2.3 用正则把骰点记录转成语义标记对骰娘的发言做拆分提取技能名、掷骰值、目标值和结果DICE_PATTERN re.compile( r^(?Pcharacter.*?)\s*进行\s*(?Pskill.*?)\s*检定 r1d100(?Proll\d)/(?Ptarget\d)\s*(?Presult成功|失败) ) msg 店员小姐 进行 手艺-布鞋 检定1d10088/65 失败 dice DICE_PATTERN.match(msg) if dice: print(dice.groupdict())输出{ character: 店员小姐, skill: 手艺-布鞋, roll: 88, target: 65, result: 失败 }这一步的价值是把纯数字信息转成故事语义。88/65 失败在叙事重构阶段可以写成“手一滑针尖戳进指肚”或“针脚歪了和样品差了太多”。数值本身不需要读者知道读者只需要感受失败带来的后果。把两种正则串成一个完整解析函数可以得到稳定结构def parse_log_line(line): basic LINE_PATTERN.match(line) if not basic: return None record basic.groupdict() if record[speaker] 骰娘: dice DICE_PATTERN.match(record[content]) if dice: record[type] dice record[dice_info] dice.groupdict() else: record[type] system else: record[type] speech return record这里把骰娘发言单独区分出来是为了避免把“骰娘xxx 检定失败”当成对白写进文章。2.4 清洗完成的检查点清洗完成后建议按下表检查检查项期望结果检查方式行数是否合理清洗后行数远小于原始行数脚本统计清洗前后行数是否还有系统噪声无“禁言”“撤回”“上传文件”等字段搜索关键字是否存在明显空隙时间戳连续剧情不中断按时间排序检查骰点是否全部语义化正文不含 1d100、d20 等原始掷骰表达式脚本搜索正则是否有隐私残留无手机号、实名、地址人工抽查这里要特别提醒不要在清洗阶段丢失“失败”的剧情信息。很多新手会把失败的检定当作“没发生”忽略掉实际上失败的场景往往是 replay 最有戏剧性的地方。3. 用词汇表管理人名、地名和专有名词的一致性3.1 为什么靠肉眼替换容易翻车文字团最大的一个特点是称呼混乱。同一个人物玩家之间可能叫“仙姑”“谢娘娘”“娘娘”作者在旁白里又可能写成“庙里那位”。同一个地方可能交替出现“娘娘庙”“小庙”“山神庙”。地名还好人物名一旦替换错第二章就会出现两个角色合并成一个人的事故。如果直接在稿子里做全局查找替换会出现更麻烦的问题两个字的人名可能嵌在另一个词里。比如“娘娘”如果直接替换成“谢娘娘”遇到“娘娘腔”“娘娘驾到”就可能出现错误反过来把“谢娘娘”展开成“娘娘”再统一又会丢失原文本的正式感。稳妥做法是用脚本找出疑似名称标记出来交给人工确认而不是让脚本直接改稿。脚本负责“找到不一致”人负责“决定怎么改”。3.2 用 YAML 维护一份角色与名词词表推荐维护一份 vocab.yaml放在项目的 config 目录下characters: deity_altar: canon: 谢娘娘 aliases: - 仙姑 - 谢姑娘 - 娘娘 note: 庙中供奉的娘娘核心剧情角色 shopkeeper: canon: 店员小姐 aliases: - 店员 - 布鞋店员 note: 与绣花鞋线索相关的 NPC locations: temple: canon: 娘娘庙 aliases: - 小庙 - 庙里 shoe_shop: canon: 布鞋铺 aliases: - 铺子 - 鞋铺 items: embroidered_shoe: canon: 绣花鞋 aliases: - 那双鞋 - 布鞋 note: 当前回目的核心物品字段含义canon正式名称最终稿默认采用的名字。aliases用户在原始日志里可能使用的叫法。note备注帮助编辑判断什么时候该换用别的称呼。这不是数据库表不需要追求完整字段。它的作用是给编辑一个统一的“称呼决策参考”。当一篇文章中同一个角色出现多种昵称时编辑要决定哪些保留、哪些合并。3.3 脚本只做检测不做无脑替换下面这个脚本负责扫描稿件找到词表里没有覆盖到的人名嫌疑项并统计 aliases 出现次数from pathlib import Path import yaml def load_vocab(path): with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) def scan_text(text, vocab): found {} for group in (characters, locations, items): for entity in vocab[group].values(): name entity[canon] count text.count(name) if count: found[name] {group: group, count: count} for alias in entity.get(aliases, []): count text.count(alias) if count: found[alias] {group: group, count: count, canon: name} return found text Path(chapter_02.md).read_text(encodingutf-8) vocab load_vocab(config/vocab.yaml) for key, info in sorted(scan_text(text, vocab).items()): print(key, info)这样能直观看到每个称呼的出现次数帮助判断是否该统一。比如“仙姑”出现 12 次、“谢娘娘”出现 3 次、“娘娘”出现 40 次那就可以考虑是否把“娘娘”统一成“谢娘娘”但也可能因为语气需要保留“娘娘”的亲近感。这个决策留在人这里。3.4 真正需要自动替换时的保护规则如果场景是“同一篇文章必须保持单一称呼”自动替换也不是完全不行但要加保护规则先替换长词再替换短词避免“谢娘娘”被“娘娘”先吃掉。设置上下文黑名单比如“娘娘腔”“娘娘庙香火”不参与替换。替换后立即跑一次校验脚本统计是否有异常组合词。保留原始文件在 Git 提交记录里能看到替换前版本。一个简化例子def safe_replace(text, old, new, blacklist): pattern re.compile(rf(?![\u4e00-\u9fa5]){re.escape(old)}(?![\u4e00-\u9fa5])) result [] pos 0 for m in pattern.finditer(text): prefix text[pos:m.start()] left text[m.start() - 1] if m.start() 0 else right text[m.end()] if m.end() len(text) else if left old right in blacklist: prefix m.group() continue result.append(prefix new) pos m.end() result.append(text[pos:]) return .join(result)这个函数会在替换前检查相邻字符尽量避免把娘娘从娘娘腔里截出来替换。黑名单见下BLACKLIST {娘娘腔, 娘娘庙, 娘娘驾到, 谢娘娘点化}3.5 词表维护不只是写作初期的事词表要随着章节推进持续更新。新 NPC 登场时立刻在 characters 下新增一条新地点被提及马上更新 locations关键道具出现items 里补上。如果不更新等到第三章需要回溯第二章设置时会很痛苦。维护词表时也可以记录“这条线索是否已揭晓”。比如绣花鞋在第一回出现、第二回成为钩子那么词条 note 可以写“第二回主道具尚未解释为何不要”。这个信息对后续回目的标题设计非常有用。4. 叙事重构把骰点变成悬念把标题变成钩子4.1 骰点结果如何映射成戏剧冲突骰点本身没有意义。1d10088/65 只是“失败”两个字。叙事重构要回答的是这次失败在故事里造成了什么后果。通常有三种处理方式骰点结果处理方向示例写法成功达成目标但可以留下代价她把鞋放回柜台上样子是修好了可指腹上留了一道细小的血痕失败目标没达成推进新冲突针脚一拉就脱线她愣了一下抬眼看向门外大失败制造反转或加剧威胁那双鞋突然自己动了一下针线在木柜上拖出吱嘎一声这里要注意尺度。不要每次失败都写成世界毁灭也不要每次成功都写成毫无波折。最稳定的方法是把检定结果当作“新信息输入”成功给出推进信息失败给出代价信息大失败给出超预期信息。4.2 标题设计的结构身份 悬念 口语化反差回到《谢娘娘点化》第二回标题。这个标题里至少能看到三层信息身份层谢娘娘点化说明这一回的核心关系是“娘娘”和“某个对象”之间的点化给读者定位了剧情类型是仙怪、民俗或志怪。悬念层绣花鞋为啥不要是一个未解答的问题。读者不知道“不要”的主体是谁也不知道不要的理由更不知道“不儿”这个语气词背后是什么情绪。反差层正式感来自“点化”“第二回”生活感来自“不儿……为啥……”两者放在一起就有阅读趣味。写章节标题时可以套一个可复用的公式[人物或场景] [动作或事件] [口语化疑问/反转]尽量不要把标题写成纯“事件概括”。比如“第二回 谢娘娘点化布鞋店员”虽然清楚但缺少钩子。改成“不儿绣花鞋为啥不要啊”之后读者会带着问号进入正文。4.3 常见回目结构与每节的职责文字团 replay 常用章节结构可以拆成五个部分开场用一句旁白或一个动作把读者拉回场景迅速交代时间、地点、当前目标。推进玩家角色尝试动作检定结果陆续出现台词与动作交织。转折出现一次失败或意外导致原有计划中断。点题揭示本回最重要的信息但不把坑全部填完。钩子结尾留一个悬念比如物品异动、人物回头、未解之谜再次出现。对应到 Markdown 稿件可以在写作时用注释标记每个部分的起止!-- 开场鞋铺雨停 -- 门外雨刚停柜台上的木盆还滴着水。 !-- 推进店员小姐修鞋 -- **店员小姐**这针脚我再走一道不会掉线。 她低下头把鞋翻过来。 !-- 转折检定失败针线开线 -- 鞋底上一根线突然崩开她手里的针停在半空。 !-- 点题谢娘娘开口 -- **谢娘娘**那双鞋不能留。 !-- 钩子灯灭 -- 话音一落柜台后的油灯闪了一下。这种注释化写法对后续自动化排版很有帮助。脚本可以把!-- 开场 --这类注释提取出来生成目录也可以统计每个部分的字数判断节奏是否失衡。4.4 台词的保留标准与口语化边界不是所有对话都值得保留。筛选台词时按优先级判断推动情节台词改变了角色行动必须保留。塑造人设语气词、口头禅、用词习惯能立住角色可以保留。增进关系角色之间的互动有化学反应可以保留。过程性交流比如“你确定吗”“我确定”如果对结果没有影响可以简化或删除。原文中的口语通常带有语气词和简短句改写时不要强行书面化。比如“为啥不要啊”比“为何拒绝”更适合跑团故事的现场感。但也不要走向另一个极端把所有台词都变成“俺寻思”式方言。要结合世界观如果角色设定是庙里的娘娘她说话可以略带文言或沉稳如果是市井店员口语化更强。4.5 排版规范让读者一眼分清谁在说话、谁在行动replay 排版的底线是读者不用往回翻就能知道哪句是台词、哪句是动作、哪句是旁白。推荐统一为三种形式角色台词加粗角色名后接冒号再接台词。动作描写用括号包裹单独成段。旁白与场景描写普通正文段落可以略文艺但不能超过一定体量。示例**谢娘娘**不儿你先别问为啥不要。 她把鞋拿起来指尖沿着鞋口摸了一圈。 屋外的蛙声突然停了。这个瞬间店里安静得能听见针线落地的声音。这三行分别承担了对话、动作、气氛。如果旁白连续超过四五行读者会失去线索感所以在节奏检查时要留意段落长度。4.6 节奏检查清单检查项推荐标准检查方式开场是否 3 段内进入场景是阅读前 200 字失败检定是否都有后果有对照清洗后的检定记录检查单段旁白是否过长不超过 5 行脚本统计段落长度章节结尾是否留有钩子存在未解问题阅读最后 200 字标题是否包含悬念或反差是发布前自评5. 发布前的自动化检查错字、残留骰点和多平台排版5.1 写一个只检查不修改的校验脚本发布前最重要的一步不是反复改稿而是先让脚本把所有客观问题找出来。下面这个脚本检查四个维度import re from pathlib import Path def check_replay(filepath, min_words3000): text Path(filepath).read_text(encodingutf-8) issues [] # 字数统计 no_whitespace re.sub(r\s, , text) word_count len(no_whitespace) if word_count min_words: issues.append(f字数偏少{word_count} 字低于 {min_words}) # 残留骰点 dice_residue re.findall(r[^。\n]*1d\S[^。\n]*, text) if dice_residue: issues.append(f发现未转换的骰点{dice_residue[:3]}) # 角色名异常太短的疑似名称 suspicious_names re.findall(r^\*\*[^*]{1,2}\*\*, text, re.MULTILINE) if suspicious_names: issues.append(f疑似过短角色名{suspicious_names}) # 连续回车过多 if re.search(r\n{4,}, text): issues.append(存在多个连续空行需要清理) return issues这段代码本身不复杂但它把“人容易漏掉”的机械问题前置了。实际使用中可以把任何你能想到的规则都加进去比如“括号是否配对”“引号是否成对”“章节编号是否连续”。5.2 敏感词和违禁词过滤公开平台发布前必须做跑团 replay 发布到公开平台必须考虑平台对内容的要求。这不是简单的审核规避问题而是因为跑团过程中玩家可能即兴说了不合适的话这些内容如果原样发布会伤害读者也可能引发争议。敏感词检查需要覆盖几类涉政和意识形态类任何历史事件隐喻、人物争议内容都不能留。人身攻击和地域攻击玩家之间的玩笑话发布时必须删除或改写。色情低俗即使用了隐喻也不应出现在公开可见的稿件里。隐私信息手机号、地址、实名、社交账号一律删除。建议维护一个 denylist.txt一行一个词或正则。脚本检查到命中后不要自动替换而是输出所有命中位置由人工决定是否删除。grep -n -f denylist.txt chapter_02.md如果使用 grep命令会在终端列出匹配行和行号。人工逐个确认后再在文本里处理。这一步不能省因为脚本无法判断一个词在具体语境里是否违规。注意敏感词脚本的结果只是一个辅助信息最终决定权必须交给发布者。不要因为脚本没有命中就放心发布也不要因为脚本命中了一个词就不加判断地删除整段。5.3 从 Markdown 到多平台发布CSDN、博客园、知乎、B 站专栏对 Markdown 的支持各有差异。建议主线稿件统一使用标准 Markdown发布时再调整为平台格式。常见差异平台标题层级表格代码块图片CSDN 博客支持支持支持支持博客园支持支持支持支持知乎专栏支持容易错位支持支持B 站专栏支持偶尔错位支持支持在发布时可以先用 Markdown 预览器检查一遍再粘贴到平台。粘贴后重点检查三点表格是否错位、代码块是否高亮、标题层级是否丢失。如果平台不支持某些 Markdown 语法可以采用 HTML 表格或截图代替。5.4 单章发布检查清单检查项完成标准字数达标单章正文不少于 3000 字骰点清零正文不出现 1d100、d20 等原始骰式称呼一致角色对应词表没有莫名新称呼连续段落检查无 4 个以上连续空行敏感词审查无命中项或已人工确认标题回目连续上一回、本回、下一回顺序正确版权确认得到参与者同意能公开发布6. 生产环境排查replay 制作中最常踩的六个坑6.1 现象骰点记录对不上叙事顺序原因聊天记录导出时系统消息和骰娘消息可能有延迟或乱序。骰娘在一个小时后才补发检定结果实际剧情发生在前。处理方式清洗时不要只看时间排序还要按“说话内容”判定逻辑顺序。先按剧情动作排序再把对应检定结果挂到动作后面。如果实在无法确定顺序可以省略具体顺序用后果替代。比如检定结果延迟缺失时写“这一针下去她知道坏了”不写具体数值。6.2 现象全局替换把角色名改坏了原因没有设置黑名单直接全量替换了两个字的人名或短称呼。比如把“娘娘”替换成“谢娘娘”连“娘娘腔”也被改了。处理方式先恢复 Git 历史再按 3.4 节的安全替换方式操作。以后替换前先跑一次“候选词上下文统计”看看每个旧称呼周围都出现了什么词再决定是否替换。6.3 现象日志缺失导致情节断档原因玩家在另一个聊天窗口推进了一段重要剧情或者群记录被清理导致中间少了关键动作。处理方式不要强行补全编造剧情。可以在 replay 里增加一句作者注例如“这段内容原记录缺失根据前文推断店员小姐在鞋铺外遇到了谢娘娘”。把不可靠的推理明确标出来比自己虚构一段处理方式要稳妥。6.4 现象同一角色在不同平台昵称不一致原因有人用 PC 昵称、有人用简称、有人用角色卡名字导出后发现同一个角色有三四种写法。处理方式抽出一张别名映射表先统计每个名字在全文中的出现频率再做合并。合并后的规范名要在词汇表里更新并作为后续章节的固定称呼。6.5 现象洗稿脚本每次跑的结论不一样原因脚本没有固定运行顺序或者读入的文件夹里混入了多个版本文件。比如目录里同时存在 chapter_02.md 和 chapter_02_改.md脚本遍历时顺序不稳定。处理方式在脚本里显式指定输入文件或按文件名排序不用glob(*)的无序结果。更稳妥的是用 Git 管理版本每次只从主分支选一个文件作为输入。6.6 排查顺序总表排查任何 replay 生产问题时按下列顺序查找根因优先级检查点具体操作1原始数据是否完整确认源日志时间范围、群成员、聊天渠道2清洗脚本是否稳定同一输入跑两次结果要一致3词汇表是否更新检查新角色、新道具是否已加入 YAML4替换是否考虑上下文检查黑名单和后缀保护5叙事是否过度补写对照原始记录看是否有不可验证的细节6发布格式是否正确粘贴到目标平台后检查表格和代码块7. 从单篇二创到长期内容项目协作、模板和版本管理7.1 多人协作时分工要先于写作到了连载阶段replay 生产不是一个人能轻松完成的。比较合理的分工是记录员负责从群里提原始日志做清洗。编辑负责叙事重构、标题设计。校对负责词汇表、敏感词、格式检查。排版发布负责 Markdown 转平台格式、配图、发布时间。如果团队只有两个人也要明确谁负责内容、谁负责检查。一个人又做清洗又做校对容易产生“自己写的东西永远没问题”的盲区。7.2 模板化把回目生产拆成固定模块制作一个标准的回目模板能显著降低连载启动成本!-- 回目信息 -- # 第X回标题 !-- 开场 -- !-- 推进 -- !-- 转折 -- !-- 点题 -- !-- 钩子 -- !-- 作者注 --每次新建回目时复制这个模板填充内容即可。好处是脚本可以按注释定位结构读者也能获得一致的阅读节奏。模板不需要很复杂但要长期稳定。7.3 用 Git 管理稿件版本replay 文稿和脚本必须纳入版本管理。推荐目录结构replay_project/ ├── config/ │ ├── vocab.yaml │ └── denylist.txt ├── scripts/ │ ├── parse_log.py │ ├── check_replay.py │ └── vocab_scan.py ├── archive/ │ └── raw_logs/ ├── drafts/ │ ├── chapter_01.md │ └── chapter_02.md └── release/ └── chapter_02_final.md每次保存用语义化提交信息例如git add . git commit -m replay: 第二回 完成叙事重构待校对不要直接把 release 目录里的 final 文件又复制回 drafts。一个文件只有一个正式来源否则很容易出现“改了半天发现改的是旧版”的情况。7.4 学习环境与正式发布环境的差别个人练习时可以只用一条命令跑通清洗脚本然后手动改稿、复制到平台。正式发布时建议至少补充以下控制配置外置词汇表、敏感词表、目录路径都放进 config不硬编码在脚本里。自动检查流水线用一条 make 命令依次执行清洗、检查、统计。发布回滚Git 打 tag发布后发现问题可以快速回到上一版本。素材归档角色立绘、地图、语音录音都要统一存放最好有命名规范。权限确认发布前取得所有参与玩家的同意确认不包含不适合公开的内容。如果内容计划做成付费、实体或视频衍生品还要额外关注参与者授权和利益分配这属于项目规范问题不能只靠技术手段解决。7.5 从文字 replay 到视频、条漫与声音剧文字 replay 在排版发布后还可以继续向其他媒介扩展。扩展方向包括视频版把章节按镜头拆成字幕稿先做分镜脚本再用剪辑软件合成。条漫版把关键场景转成分镜描述交给画手执行。声音剧把台词分给配音旁白单独成轨背景音用古风或志怪氛围。互动阅读器把 Markdown 章节导入自建页面支持章节折叠、人物词条跳转、检定记录展开。技术工作流在这些扩展中仍然有效词汇表可以直接迁移到分镜表Git 版本管理可以管理多个媒介版本自动检查脚本可以复用到字幕文本上。前期建立的数据结构后期会成为多媒介生产的基础资产。跑团 replay 的生产本质上是把一场即兴的口头表演变成一组可复读、可检索、可再编辑的内容资产。真正决定一篇 replay 好坏的不是脚本写得多聪明而是创作者有没有把力气花在标题钩子、角色语气和失败后果这些关键节点上。与其把所有精力耗在复制粘贴和肉眼排错不如先搭起一条固定的清洗、解析、检查流水线。把重复工作交给脚本把判断交给编辑这样当故事推进到“那双绣花鞋为什么会动”的时候你才有余力写出真正让读者记住的那一句。