企业官网建设流程全解析

跑团 replay 在中文 TRPG 社区里，已经从简单的过程记录，变成了一套带有明确编辑思路的内容产品。像《谢娘娘点化》第二回：不儿绣花鞋为啥不要啊？这样的标题，明显不是桌面玩家原始聊天记录的复刻，而是经过二次创作之后的成品：有人在整理日志，有人在判断哪些信息值得保留，有人在设计章节悬念，也有人负责最终的排版与发布。这篇文章要讲的，就是文字团 replay 背后的工程化生产流程：从原始聊天记录里切分角色与动作，用脚本清洗骰点噪声，维护一张角色别名表来保证全文称呼统一，再把粗糙过程记录重构为带钩子的章节文本，最后做一遍发布前检查。这套流程对跑团主持人和长期做跑团二创的编辑尤其有用。学完之后，你可以把自己仓库里那些零散截图、聊天导出和骰娘日志，稳定地变成一篇结构完整、可发布、可存档的 replay 长文。

1. 先把 replay 的工序拆开：原始记录如何变成可读故事

1.1 replay 不是转写，而是有视角的二次创作

很多人对 replay 的理解是“把跑团过程记下来”。实际上，只做记录得到的是流水账，不是 replay。流水账里充满了骰点数值、系统提示、撤回消息、角色瞬移、规则争执，以及不适合公开的隐私信息。真正的 replay 要保留的是故事层面：角色的选择、失败的影响、关键台词的语气，以及玩家之间临时碰撞出来的戏剧性。

这意味着 replay 生产天然包含两层工作。第一层是技术层：把原始日志变成结构化数据，保证角色、动作、台词、检定结果被正确识别；第二层是创作层：从结构化数据里选出有戏剧价值的内容，重新安排详略，给章节起标题，决定哪里挖坑、哪里揭晓。

《谢娘娘点化》第二回这个标题已经能说明问题。标题里有几个明显信号：

• “第二回”说明这是一个按回目组织的连载结构，不是一次随机记录。
• “不儿绣花鞋为啥不要啊？”是口语化反问，带着明显情绪，制造好奇心缺口。
• 整句话是疑问句，读者不知道绣花鞋和“不要”之间发生了什么，就会想点进去看。

所以，一个合格的 replay 标题不是写完后顺手起的，而是在叙事重构阶段就要设计的信息装置。技术流程的任务，是把做这件事所需要的重复劳动降到最低。

1.2 一条适合大多数文字团的 replay 生产链路

把 replay 生产当成一条流水线来看，可以避免“边写边整理、越整理越乱”的情况。下面这条链路适合绝大多数 QQ 群、Discord 服务器或论坛文字团：

1. 获取原始日志：从聊天记录导出、骰娘机器人日志或群下载记录中拿到源文件。
2. 日志清洗：去掉系统消息、撤回记录和无关闲聊，把每行内容拆成时间、说话人、正文。
3. 结构化标记：识别台词、动作、旁白、检定记录，把骰点从“1d100=88/65”转成“失败”这样的故事语义。
4. 一致性校正：把同一个角色的多种昵称统一，确认地名、道具、关键剧情名词不冲突。
5. 叙事重构：按回目或幕组织内容，确定详略，补写过渡句，设计章节标题。
6. 自动检查与校对：统计字数，检查是否残留骰点、是否有人名异常、是否出现平台敏感词。
7. 发布适配：把 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 等平台有导出记录，但可能只给纯文本或包含大量系统消息。
• 骰娘机器人日志：有一定规则的骰点记录，经常连技能名、目标值、成功失败都写在同一条消息里。
• 主持人或记录员手动补记：适合剧情突发、语音团、线下团，缺点是漏记和口语化严重。

无论哪一种来源，原始日志里都会有大量噪声。常见的噪声类型包括：

处理原则不是“尽量保留”，而是“只保留对故事理解有贡献的内容”。replay 是给读者看的故事，不是给裁判复核的原始档案。

2.2 把原始行解析成结构化数据

先看一段通用日志样例。下面这段是演示格式，与任何具体跑团剧情无关：

[2025-01-01 20:11] 团务官：各位确认一下当前场景 [2025-01-01 20:12] 店员小姐：那我先把那双布鞋放到柜台上 [2025-01-01 20:13] 骰娘：店员小姐 进行 手艺-布鞋 检定：1d100=88/65 失败 [2025-01-01 20:14] 主持人：鞋底翻上来，针脚已经开线，她盯着看了几秒，皱起眉。

用 Python 可以先按“时间 + 说话人 + 内容”的结构拆分每一行：

import re LINE_PATTERN = re.compile( r"^\[(?P<time>.*?)\]\s*(?P<speaker>.*?)[：:]\s*(?P<content>.*)$" ) line = "[2025-01-01 20:13] 骰娘：店员小姐 进行 手艺-布鞋 检定：1d100=88/65 失败" m = LINE_PATTERN.match(line) if m: print(m.groupdict())

输出结果是一个字典：

{ "time": "2025-01-01 20:13", "speaker": "骰娘", "content": "店员小姐 进行 手艺-布鞋 检定：1d100=88/65 失败" }

这样还不能直接用来写故事，因为“骰娘”的发言其实是一条检定记录，需要进一步解析。

2.3 用正则把骰点记录转成语义标记

对骰娘的发言做拆分，提取技能名、掷骰值、目标值和结果：

DICE_PATTERN = re.compile( r"^(?P<character>.*?)\s*进行\s*(?P<skill>.*?)\s*检定" r"：1d100=(?P<roll>\d+)/(?P<target>\d+)\s*(?P<result>成功|失败)" ) msg = "店员小姐 进行 手艺-布鞋 检定：1d100=88/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 清洗完成的检查点

清洗完成后，建议按下表检查：

这里要特别提醒：不要在清洗阶段丢失“失败”的剧情信息。很多新手会把失败的检定当作“没发生”忽略掉，实际上失败的场景往往是 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", encoding="utf-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(encoding="utf-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 真正需要自动替换时的保护规则

如果场景是“同一篇文章必须保持单一称呼”，自动替换也不是完全不行，但要加保护规则：

1. 先替换长词，再替换短词，避免“谢娘娘”被“娘娘”先吃掉。
2. 设置上下文黑名单，比如“娘娘腔”“娘娘庙香火”不参与替换。
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 骰点结果如何映射成戏剧冲突

骰点本身没有意义。1d100=88/65 只是“失败”两个字。叙事重构要回答的是：这次失败在故事里造成了什么后果。

通常有三种处理方式：

这里要注意尺度。不要每次失败都写成世界毁灭，也不要每次成功都写成毫无波折。最稳定的方法是把检定结果当作“新信息输入”：成功给出推进信息，失败给出代价信息，大失败给出超预期信息。

4.2 标题设计的结构：身份 + 悬念 + 口语化反差

回到《谢娘娘点化》第二回标题。这个标题里至少能看到三层信息：

• 身份层：谢娘娘点化，说明这一回的核心关系是“娘娘”和“某个对象”之间的点化，给读者定位了剧情类型是仙怪、民俗或志怪。
• 悬念层：绣花鞋为啥不要，是一个未解答的问题。读者不知道“不要”的主体是谁，也不知道不要的理由，更不知道“不儿”这个语气词背后是什么情绪。
• 反差层：正式感来自“点化”“第二回”，生活感来自“不儿……为啥……”，两者放在一起就有阅读趣味。

写章节标题时可以套一个可复用的公式：

[人物或场景] + [动作或事件] + [口语化疑问/反转]

尽量不要把标题写成纯“事件概括”。比如“第二回 谢娘娘点化布鞋店员”虽然清楚，但缺少钩子。改成“不儿绣花鞋为啥不要啊”之后，读者会带着问号进入正文。

4.3 常见回目结构与每节的职责

文字团 replay 常用章节结构可以拆成五个部分：

1. 开场：用一句旁白或一个动作把读者拉回场景，迅速交代时间、地点、当前目标。
2. 推进：玩家角色尝试动作，检定结果陆续出现，台词与动作交织。
3. 转折：出现一次失败或意外，导致原有计划中断。
4. 点题：揭示本回最重要的信息，但不把坑全部填完。
5. 钩子：结尾留一个悬念，比如物品异动、人物回头、未解之谜再次出现。

对应到 Markdown 稿件，可以在写作时用注释标记每个部分的起止：

<!-- 开场：鞋铺，雨停 --> 门外雨刚停，柜台上的木盆还滴着水。 <!-- 推进：店员小姐修鞋 --> **店员小姐**：这针脚我再走一道，不会掉线。 （她低下头，把鞋翻过来。） <!-- 转折：检定失败，针线开线 --> 鞋底上一根线突然崩开，她手里的针停在半空。 <!-- 点题：谢娘娘开口 --> **谢娘娘**：那双鞋，不能留。 <!-- 钩子：灯灭 --> 话音一落，柜台后的油灯闪了一下。

这种注释化写法对后续自动化排版很有帮助。脚本可以把<!-- 开场 -->这类注释提取出来生成目录，也可以统计每个部分的字数，判断节奏是否失衡。

4.4 台词的保留标准与口语化边界

不是所有对话都值得保留。筛选台词时按优先级判断：

• 推动情节：台词改变了角色行动，必须保留。
• 塑造人设：语气词、口头禅、用词习惯能立住角色，可以保留。
• 增进关系：角色之间的互动有化学反应，可以保留。
• 过程性交流：比如“你确定吗”“我确定”，如果对结果没有影响，可以简化或删除。

原文中的口语通常带有语气词和简短句，改写时不要强行书面化。比如“为啥不要啊”比“为何拒绝”更适合跑团故事的现场感。但也不要走向另一个极端，把所有台词都变成“俺寻思”式方言。要结合世界观：如果角色设定是庙里的娘娘，她说话可以略带文言或沉稳；如果是市井店员，口语化更强。

4.5 排版规范：让读者一眼分清谁在说话、谁在行动

replay 排版的底线是：读者不用往回翻就能知道哪句是台词、哪句是动作、哪句是旁白。推荐统一为三种形式：

• 角色台词：加粗角色名，后接冒号，再接台词。
• 动作描写：用括号包裹，单独成段。
• 旁白与场景描写：普通正文段落，可以略文艺，但不能超过一定体量。

示例：

**谢娘娘**：不儿，你先别问为啥不要。 （她把鞋拿起来，指尖沿着鞋口摸了一圈。） 屋外的蛙声突然停了。这个瞬间，店里安静得能听见针线落地的声音。

这三行分别承担了：对话、动作、气氛。如果旁白连续超过四五行，读者会失去线索感，所以在节奏检查时要留意段落长度。

4.6 节奏检查清单

5. 发布前的自动化检查：错字、残留骰点和多平台排版

5.1 写一个只检查不修改的校验脚本

发布前最重要的一步不是反复改稿，而是先让脚本把所有客观问题找出来。下面这个脚本检查四个维度：

import re from pathlib import Path def check_replay(filepath, min_words=3000): text = Path(filepath).read_text(encoding="utf-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，发布时再调整为平台格式。

常见差异：

在发布时，可以先用 Markdown 预览器检查一遍，再粘贴到平台。粘贴后重点检查三点：表格是否错位、代码块是否高亮、标题层级是否丢失。如果平台不支持某些 Markdown 语法，可以采用 HTML 表格或截图代替。

5.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 生产问题时，按下列顺序查找根因：

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 好坏的，不是脚本写得多聪明，而是创作者有没有把力气花在标题钩子、角色语气和失败后果这些关键节点上。与其把所有精力耗在复制粘贴和肉眼排错，不如先搭起一条固定的清洗、解析、检查流水线。把重复工作交给脚本，把判断交给编辑，这样当故事推进到“那双绣花鞋为什么会动”的时候，你才有余力写出真正让读者记住的那一句。