企业官网建设流程全解析

如果你正在追更一档跑团 replay，或者自己就是那个负责整理跑团记录的玩家，你大概率遇到过这种状态：剧情推进到第七话，伏笔和人物关系已经多到记不住；上一场的关键骰点究竟是成功还是失败，翻聊天记录翻到凌晨三点；主持人写的场景描述、几个玩家的即兴台词、战斗中的临时判定，全混在一起，最后整理出来的内容像一锅粥。

以“虚舟之村07：黑死牟很满意”这类章节为例。表面看，这是《鬼灭之刃》题材 TRPG 跑团的一段叙事记录，但真正做过连载内容的人会意识到，它本质上是一个内容生产项目：有固定角色、有连续剧情、有随机骰点、有章节发布节奏。只要超过三期，单靠记忆和聊天记录来维护，必然出问题。

本文要给出的判断是：跑团 replay 的记录难点，不是“文笔不好”，而是缺少工程化流程。解决它不靠更复杂的工具，靠一套轻量的 Markdown + Python + Git 流程就够了。读完这篇文章，你会得到一整套可复用的跑团 replay 工作流，包括章节目录设计、角色卡模板、骰点记录脚本、自动汇总脚本，以及多人协作时避免冲突的工程建议。这套流程不只适用于鬼灭题材，任何长篇连载式内容创作都能用。

1. 跑团 replay 记录为什么值得工程化

先定义一下“跑团 replay”。TRPG 玩家在跑团时，主持人负责描述剧情、控制 NPC，玩家操控自己的角色行动，系统通过骰子决定关键事件的成败。“replay”是把这场游戏过程重新呈现出来的内容形态，它可以是文字小说、图文记录，也可以在此基础上制作成视频。

很多玩家以为 replay 就是“把跑团过程记录下来”，实际上难点远不止记录。一场三小时的跑团，录音转文字可能有三万字，其中有大量闲聊、规则争辩、空场等待；真正对剧情有推动作用的可能是三千字；这三千字里，主持人叙述、玩家台词、NPC 对话、规则判定又需要区分。如果你在连载一个系列，比如“虚舟之村”已经到第七话，那么你还面临另一个问题：第七话里出现的某个道具，可能是在第三话埋下的伏笔；黑死牟这个 BOSS 的能力数值，可能和第五话的某次判定有关。

把这些信息全部塞进人的大脑，结果就是更新速度越来越慢，质量越来越不稳定。最常见的情况是：玩家在跑团群里说“上次我过了体质检定，应该没事”，但翻聊天记录发现那次检定其实失败了，只是主持人给了剧情补偿。这类分歧一旦出现，后续内容就失去可信度。

工程化的价值不在于替代创作，而在于解决三件事：可检索、可回溯、可协作。可检索是指你随时能找到“某一次骰点是什么结果”；可回溯是指你能从第一话开始追溯角色成长线索；可协作是指主持人、玩家、剪辑者可以同时在一个内容仓库里工作，互不覆盖。

2. 从“跑团章节”到“内容项目”：核心概念与数据模型

要设计流程，先把一个跑团章节拆成数据。以“虚舟之村07：黑死牟很满意”为例，这个章节包含四类核心信息：

第一，元信息。包括系列名、章节号、章节标题、发布日期、参与玩家。这些信息用于系列归档和发布页展示。第七话的标题“黑死牟很满意”在元信息里就是章节标题字段。

第二，场景。一场跑团由若干连续场景构成，例如“月光下的芦苇原”“村口遭遇战”“夜色中的对峙”。“虚舟之村07”至少包含一个核心战斗场景，因为黑死牟作为强敌登场。

第三，角色与台词。玩家角色、主持人 NPC、本话登场的敌对角色，都需要有持续存在的角色卡。台词要标明说话者，否则整理成文字后无法阅读。

第四，骰点记录。这是跑团 replay 和普通小说最大的区别。骰子结果直接决定剧情走向，例如一次敏捷检定失败可能让玩家在 BOSS 面前失去先手。记录骰点时，至少需要包含：场景编号、骰子表达式、结果、备注。

把它们组合成一个数据模型：

章节 = 元信息 + 若干场景 场景 = 场景编号 + 地点描述 + 角色 + 台词 + 骰点记录 角色 = 角色名称 + 类型 + 属性 + 背景信息 骰点记录 = 时间 + 场景编号 + 表达式 + 结果 + 备注

这个模型很朴素，但它有两个关键优点：一是所有内容都能用纯文本表示，不需要数据库；二是每个字段都对应一个文件或一行记录，方便脚本处理。这就是后面工程实现的基础。

如果只靠人工整理，流程是：跑团结束 → 打开聊天记录 → 把消息逐条复制 → 按剧情顺序排列 → 补充描写 → 发布。这套流程在章节少的时候没问题，但一旦进入第七话、第八话，就会出现两个典型问题：第一，聊天记录中的骰点消息经常被玩家消息打断，漏记概率高；第二，不同玩家对同一剧情的记忆不一致，返工成本大。

引入工程化流程后，顺序变成：跑团时用统一格式快速记录 → 场景写成分散的 Markdown 文件 → 脚本自动读取场景文件和骰点日志 → 生成一篇完整的 replay 博文 → 发布。这样做的核心变化是：记录和发布分离，写场景时不用考虑最终排版，发布时不用重新整理场景。

3. 环境准备与目录结构设计

接下来进入实操。整套流程只需要三个基础工具：Git、Python 3、一个文本编辑器。VSCode 或者 Obsidian 都可以；如果用 Obsidian，还能顺便获得双向链接和关系图谱，对跑团系列的长期维护有帮助。

Python 版本建议使用 3.8 及以上，本文的脚本没有依赖第三方库，用标准库即可完成。

创建项目之前，先设计目录结构。这里给出一套适合长篇跑团系列的目录：

trpg-replay/ ├── README.md ├── characters/ │ └── kokushibo.md ├── scenes/ │ ├── 07-01-moonlight.md │ ├── 07-02-battle.md │ └── 07-03-aftermath.md ├── logs/ │ └── rolls.jsonl ├── templates/ │ ├── character_template.md │ └── scene_template.md ├── scripts/ │ ├── dice.py │ └── build_replay.py └── export/ └── 虚舟之村07.md

每个目录的职责：

• characters/：角色卡目录。每个角色一个 Markdown 文件，文件名建议使用角色名称的英文或拼音，避免中文文件名在某些平台上的兼容性问题。
• scenes/：场景文件目录。文件名规则是“章节号-场景序号-场景名.md”。例如07-01-moonlight.md表示第七话第一个场景。这个命名规则决定了后续脚本的排序逻辑。
• logs/：存放骰点日志。使用 JSONL 格式，每行一条 JSON 记录。
• templates/：模板目录。新建角色卡或场景时，从模板复制，避免手写格式不一致。
• scripts/：Python 脚本目录。
• export/：脚本自动生成的发布文件目录。这个目录下的内容可以由脚本覆盖，不建议手动编辑。

创建目录的 Git 命令：

mkdir -p trpg-replay/{characters,scenes,logs,templates,scripts,export} cd trpg-replay git init

这里真正容易踩坑的地方是：场景文件的命名一定要统一。如果第一个文件叫07-1-moonlight.md，第二个叫07-02-battle.md，脚本按字符串排序时会把07-1排在07-10之后，造成顺序错乱。建议场景序号统一用两位数补零：01、02、03，不要混用一位数和两位数。

4. 用 Markdown 模板固化场景、角色卡与章节信息

4.1 角色卡模板

角色卡的作用是保证每个角色在每话中的属性、背景、关系一致。尤其是黑死牟这类持续出场的 Boss，玩家会在意他的行为是否前后矛盾。

templates/character_template.md示例：

--- name: 角色名称 role: PLAYER / NPC / BOSS chapter_first_seen: "07" status: active abilities: - 能力一 - 能力二 --- ## 角色背景 这里写角色背景。对于 NPC，可以记录他与主线的关系、当前目标、隐藏动机。 ## 关键事件 - 第 07 话：本角色首次登场/态度转变/受伤/获胜。

实际创建黑死牟的角色卡时，可以在characters/kokushibo.md中这样写：

--- name: 黑死牟 role: BOSS chapter_first_seen: "07" status: active abilities: - 月之呼吸 - 血鬼术 --- ## 角色背景 黑死牟是《鬼灭之刃》世界观中的上弦之壹，本章作为“虚舟之村”剧情的核心威胁登场。对于 TRPG 记录来说，角色卡不需要写成维基百科，只需要记录本团设定下的事实。 ## 关键事件 - 第 07 话：于月光下与主角团对峙，进入战斗场景。

这段话是模板示例，不是要求你去照抄原著设定。重点是：只要每次跑团前先看角色卡，主持人就不会说出和之前剧情矛盾的角色行为。

4.2 场景模板

场景模板是 replay 中最常用的模板。它需要承载位置、出场角色、台词、场景描述。

templates/scene_template.md示例：

--- scene_id: 07-01-moonlight chapter: "07" title: "月光下的芦苇原" location: "虚舟之村·村外芦苇原" characters: - 黑死牟 - 主角团 --- ## 场景描述 用两三句话描述场景画面、气氛和镜头感。 ## 对话记录 **主持人**：对场景的叙述和 NPC 台词。 **玩家A**：玩家角色的行动或台词。 ## 本场景骰点备注 - 在台词中提及的检定，统一通过 dice.py 写入日志，并在汇总时自动生成表格。

为什么要用 YAML front matter？因为脚本需要读取scene_id来匹配骰点记录，读取chapter来判断属于哪一话。用 front matter 比在正文第一行写# 07-01更稳定，即使正文格式调整，元信息也不会丢。

实际使用中，场景文件不一定要写成完整文章。跑团刚结束时的记录可以很碎，比如：

--- scene_id: 07-02-battle chapter: "07" title: "黑死牟出手" location: "虚舟之村·村口" characters: - 黑死牟 - 主角团 --- 黑死牟拔出刀。月光被刀光切碎。 主持人：敏捷检定。 玩家A：dice.py 1d20 -s 07-02-battle -n "敏捷检定"

发布前再润色即可。这对应了之前说的“记录和发布分离”：场景文件先保真，发布时再优化。

4.3 章节索引

建议在仓库根目录维护一个README.md，作为整个系列的索引：

# 鬼灭角色桌 TRPG Replay 系列 ## 虚舟之村篇 - 第 01 话至第 06 话：scenes/ 目录中的 01- 至 06- 前缀文件。 - 第 07 话：黑死牟很满意，场景文件见 scenes/07-*.md，导出见 export/虚舟之村07.md。

索引文件不需要每次跑团后手动大改，只需要在发布新章节时增加一行。这样整个系列的结构始终有入口，不会因为文件越来越多而失序。

5. 用 Python 脚本记录骰点：dice.py

跑团中会滚动各种面数的骰子。常见的有 d20（二十面骰，用于判定）、d6（六面骰，用于伤害）、d100（百分比，用于稀有事件）。手动记录骰点的问题是玩家容易漏写，或者只记录“成功/失败”，不记录原始数值，导致后续无法复盘。

更好的方案是写一个脚本，输入骰子表达式，自动生成结果并追加到日志文件。日志使用 JSONL 格式，每行一个 JSON 对象，方便后续脚本读取。

scripts/dice.py完整代码：

#!/usr/bin/env python3 # 文件路径：scripts/dice.py """ TRPG 骰点记录脚本。 用法示例： python scripts/dice.py 1d20 -s 07-02-battle -n "敏捷检定" python scripts/dice.py 2d6 -s 07-02-battle -n "伤害骰" """ import argparse import json import random import re from datetime import datetime from pathlib import Path from typing import Optional, Tuple DEFAULT_LOG = Path("logs/rolls.jsonl") def parse_dice(expr: str) -> Optional[Tuple[int, int]]: """解析类似 1d20、2d6、1d100 的表达式。""" match = re.fullmatch(r"(\d+)d(\d+)", expr.lower()) if not match: return None return int(match.group(1)), int(match.group(2)) def roll( expr: str, scene_id: str, note: str = "", log_file: Path = DEFAULT_LOG, ) -> dict: """执行一次骰点并写入 JSONL 日志。""" parsed = parse_dice(expr) if parsed is None: raise ValueError(f"无法解析骰子表达式: {expr}，请使用类似 1d20 的格式") count, sides = parsed results = [random.randint(1, sides) for _ in range(count)] record = { "time": datetime.now().isoformat(timespec="seconds"), "scene_id": scene_id, "expr": expr, "results": results, "total": sum(results), "note": note, } log_file.parent.mkdir(parents=True, exist_ok=True) with log_file.open("a", encoding="utf-8") as fp: fp.write(json.dumps(record, ensure_ascii=False) + "\n") print(json.dumps(record, ensure_ascii=False, indent=2)) return record if __name__ == "__main__": parser = argparse.ArgumentParser(description="TRPG 骰点记录脚本") parser.add_argument("expr", help="骰子表达式，例如 1d20、2d6、1d100") parser.add_argument("-s", "--scene", required=True, help="场景编号，例如 07-02-battle") parser.add_argument("-n", "--note", default="", help="本次骰点备注") parser.add_argument("-l", "--log", default=str(DEFAULT_LOG), help="日志文件路径") args = parser.parse_args() roll(args.expr, args.scene, args.note, Path(args.log))

脚本的关键逻辑：

parse_dice用正则表达式解析数字d数字格式，返回骰子数量和面数。random.randint(1, sides)模拟一次掷骰。每次掷骰后，脚本把时间、场景编号、表达式、每个骰子的结果、总和、备注写入一行 JSON。追加模式打开文件，意味着不会覆盖历史记录。

这里真正需要理解的是 JSONL 的设计：它比 Excel 更轻量，比 TXT 更结构化。每行一条记录，即使文件增长到几千行，Python 也可以用简单的 for 循环逐行读取。后续如果要生成统计报表，只需要按scene_id或expr字段分组即可。

运行示例：

python scripts/dice.py 1d20 -s 07-02-battle -n "黑死牟登场时的先攻检定" python scripts/dice.py 2d6 -s 07-02-battle -n "月之呼吸造成的伤害"

预期输出是格式化后的 JSON 对象：

{ "time": "2025-06-01T21:30:00", "scene_id": "07-02-battle", "expr": "1d20", "results": [ 15 ], "total": 15, "note": "黑死牟登场时的先攻检定" }

注意：运行两次相同的命令会生成两条记录，因为每次掷骰都应该是独立事件。如果你需要可复现的测试结果，可以在脚本中添加随机种子，但跑团场景下不需要。

6. 用 Python 脚本自动生成整篇 replay：build_replay.py

有了场景文件和骰点日志，下一步就是自动汇总。这个脚本是整套流程的核心价值所在：它把分散的 Markdown 场景文件按章节号读取出来，把对应的骰点记录插入到每个场景末尾，然后生成一篇可以直接发布的 Markdown 博文。

scripts/build_replay.py完整代码：

#!/usr/bin/env python3 # 文件路径：scripts/build_replay.py """ 根据 scenes/ 目录和 logs/rolls.jsonl 生成整篇 replay 文档。 用法示例： python scripts/build_replay.py 07 """ import argparse import json import sys from pathlib import Path SCENE_DIR = Path("scenes") LOG_FILE = Path("logs/rolls.jsonl") OUTPUT_DIR = Path("export") def load_rolls_by_scene(scene_ids: set[str], log_file: Path) -> dict[str, list[dict]]: """从 JSONL 日志中读取指定场景的骰点记录，按 scene_id 分组。""" if not log_file.exists(): return {} rolls: dict[str, list[dict]] = {} with log_file.open("r", encoding="utf-8") as fp: for line in fp: line = line.strip() if not line: continue record = json.loads(line) scene_id = record.get("scene_id") if scene_id in scene_ids: rolls.setdefault(scene_id, []).append(record) return rolls def build(chapter: str, scene_dir: Path, log_file: Path, output_dir: Path) -> Path: """构建单个章节的 replay 文档。""" prefix = f"{chapter}-" scene_files = sorted(scene_dir.glob(f"{prefix}*.md")) if not scene_files: raise FileNotFoundError(f"在 {scene_dir} 中没有找到以 {prefix} 开头的场景文件") scene_ids = {path.stem for path in scene_files} rolls = load_rolls_by_scene(scene_ids, log_file) parts = [ "<!-- 本文件由 build_replay.py 自动生成，请勿手动修改 -->", "", ] for scene_file in scene_files: content = scene_file.read_text(encoding="utf-8") parts.append(content) parts.append("") scene_rolls = rolls.get(scene_file.stem, []) if scene_rolls: parts.append("### 本场景骰点记录") parts.append("") parts.append("| 时间 | 表达式 | 结果 | 合计 | 备注 |") parts.append("| --- | --- | --- | --- | --- |") for record in scene_rolls: result_str = ", ".join(str(r) for r in record["results"]) parts.append( "| {} | {} | {} | {} | {} |".format( record["time"], record["expr"], result_str, record["total"], record["note"], ) ) parts.append("") output_dir.mkdir(parents=True, exist_ok=True) output_file = output_dir / f"虚舟之村{chapter}.md" output_file.write_text("\n".join(parts), encoding="utf-8") return output_file if __name__ == "__main__": parser = argparse.ArgumentParser(description="生成 replay 章节文档") parser.add_argument("chapter", help="章节号，例如 07") parser.add_argument( "--scene-dir", type=Path, default=SCENE_DIR, help="场景目录路径", ) parser.add_argument( "--log-file", type=Path, default=LOG_FILE, help="骰点日志路径", ) parser.add_argument( "--output-dir", type=Path, default=OUTPUT_DIR, help="导出目录路径", ) args = parser.parse_args() try: target = build(args.chapter, args.scene_dir, args.log_file, args.output_dir) except FileNotFoundError as exc: print(f"构建失败: {exc}", file=sys.stderr) sys.exit(1) print(f"构建成功: {target}")

脚本的工作流程分四步：第一步，读取scenes/目录所有以07-开头的 Markdown 文件；第二步，从骰点日志中筛选出这些场景对应的记录；第三步，把每个场景的原文写入输出文件，如果该场景有骰点记录，就追加一个 Markdown 表格；第四步，将结果写到export/虚舟之村07.md。

这里有一个容易被忽略的细节：场景文件的scene_id是文件名去掉.md后得到的字符串，例如07-02-battle。脚本必须依靠scene_id字段把骰点挂到正确的场景下面。如果某一句话的骰点备注写错了场景编号，汇总时就会挂到别的场景，检查起来非常难受。所以在跑团过程中，-s参数一定要填对。

运行命令：

python scripts/build_replay.py 07

如果一切正常，预期输出：

构建成功: export/虚舟之村07.md

生成的文件可以在任意 Markdown 编辑器中打开，也可以直接发布到支持 Markdown 的博客平台。如果你用的是 CSDN，把生成文件内容复制到编辑器即可；如果需要微调，建议先在本地预览，再粘贴，避免因为平台解析差异造成格式错乱。

7. 运行结果与效果验证

任何脚本写完之后都要验证，不能“能跑就认为没问题”。针对这套流程，建议按以下顺序检查。

第一步，验证骰点日志是否追加成功。运行两次dice.py后，打开logs/rolls.jsonl，应该看到两行 JSON。如果文件不存在，或者只有一行，说明脚本可能没找到正确的日志路径，或者运行目录不对。

第二步，验证场景文件是否齐全。运行python scripts/build_replay.py 07前，先确认scenes/下至少有07-01、07-02、07-03中的任意一个文件。如果脚本提示找不到场景文件，大概率是目录结构或前缀写错了。

第三步，检查导出文件的骰点表格是否按场景分组。打开export/虚舟之村07.md，滚动到战斗场景，应该能看到“本场景骰点记录”表格。如果某个场景没有表格，有两种可能：这个场景没有写入骰点记录，或者记录中的scene_id和场景文件名不一致。

第四步，确认编码。在 Windows 上使用 Git Bash 时，中文文件名偶尔会出现乱码。生成脚本已经用encoding="utf-8"读写文件，但如果你用旧版本的文本编辑器打开，建议统一使用 UTF-8 编码保存。

下面是一个验证示例：

假设scenes/07-02-battle.md存在，并且你运行了：

python scripts/dice.py 1d20 -s 07-02-battle -n "敏捷检定" python scripts/dice.py 2d6 -s 07-02-battle -n "伤害骰" python scripts/build_replay.py 07

打开export/虚舟之村07.md，在“07-02-battle”场景的末尾，你会看到类似这样的表格：

如果表格里的数值和你刚才掷出的结果对不上，第一件事不是怀疑脚本，而是检查rolls.jsonl里是否有重复记录。因为脚本是追加写入，重复运行dice.py会产生多条记录，这是预期行为；但如果你不小心运行了多次，表格里会出现重复行。

如果运行build_replay.py时报错，先看错误类型。文件不存在，检查路径；JSON 解析失败，检查rolls.jsonl是否被手动改成非 JSON 格式；排序不对，检查场景文件名编号是否补零。

8. 常见问题与排查思路

这套流程看似简单，实际使用中会遇到一些共性问题。把它们整理成一张排查表，方便你直接对照。

其中最高频的问题是场景编号不匹配。推荐的做法是：在跑团开始前，主持人先把本话所有场景文件名列出来，跑团过程中按照场景编号逐个记录骰点。这样比跑完再补录要靠谱得多。

9. 最佳实践与工程建议

这套流程从能用到好用，还有几个关键实践值得注意。

第一，命名规范要在一开始就定死。章节号用两位数，场景序号用两位数，全部小写，单词之间用连字符。比如07-01-moonlight.md，不要写第7话场景1月光.md。英文文件名的好处是跨平台兼容，也方便脚本排序。章节标题可以用中文，放在 front matter 的title字段里，不影响最终展示效果。

第二，跑团现场记录和后期润色要分开。跑团结束后的一小时内，直接打开场景模板，把能记得的台词、行动、判定结果快速写下来，不要追求文笔。这时候记录的是事实，越原始越好。等发布前再润色场景描述，补充氛围描写。如果跳过这一步，隔一天再写，很多细节就丢了。

第三，骰点日志是整条内容链的可信来源，不要随意篡改。rolls.jsonl使用追加模式写入，天然保留历史记录。如果遇到玩家质疑“上次是不是过了检定”，直接查日志文件，按scene_id过滤，答案一目了然。在设计上，日志文件不应该是 Excel 或数据库，因为文本文件的审计性最好，任何改动都能通过 Git 历史追踪。

第四，用 Git 管理整个仓库。每次跑团结束后，创建一次提交，提交信息写成“第07话跑团记录：黑死牟登场”。发布前如果修改了场景描写，再次提交。这样整个系列的演进过程都有版本记录。多人协作时，建议每位玩家只编辑自己的角色文件，场景文件由主持人维护，骰点日志由主持人统一写入，避免多人写同一个 JSONL 造成冲突。

第五，发布到 CSDN 时，注意标题和标签。标题建议沿用系列名称和章节号，例如“【鬼灭角色桌replay】虚舟之村07：黑死牟很满意”，这样读者能通过系列标签检索到全部分期。正文中可以保留场景模板中的 YAML front matter，也可以删除；如果你的博客平台会自动渲染 Markdown 表格，保留骰点表格更直观；如果平台对 YAML 支持不友好，发布前去掉 front matter 即可。

第六，不要为了工具而工具。如果只是一次性的跑团记录，用备忘录就够了；但只要你打算长期更新一个系列，就值得花半小时搭建这套目录。它真正降低的不是“写”的成本，而是“找”和“对”的成本。到第十话的时候，你能三分钟定位“黑死牟在第一话是否见过主角团”，这才是工程化最大的收益。

10. 总结与后续学习方向

这套流程的核心并不复杂：用 Markdown 管理场景和角色卡，用 JSONL 管理骰点，用 Python 脚本做自动汇总，用 Git 做版本管理。每个环节都可以替换，比如用 YAML 代替 JSONL，用其他脚本语言代替 Python，但数据模型和流程思想是通用的。

下一步实践建议是：不要急着追求完美，先在下一次跑团中跑通最小闭环。即使只坚持了一话，你也能感受到“记录与发布分离”带来的轻松感。跑团时只需要在关键判定点敲一条命令，结束后把场景记录补全，运行一次构建脚本，就有了发布素材。

如果还想继续深入，可以从这几个方向扩展：给脚本增加--web参数，把 Markdown 段落直接转成 HTML；在logs/rolls.jsonl基础上做骰点统计，计算每个玩家整季的先攻平均分；引入 Obsidian 或 VitePress，把角色卡、场景、章节索引连成知识网络；或者给build_replay.py增加模板引擎，让生成文件更贴近你常发布的内容格式。

对长期连载的跑团系列来说，最重要的不是每一话都写得多华丽，而是当你写到第十话、第二十话的时候，还能准确知道第七话的黑死牟在月光下做了什么事、玩家掷出的那一次 1d20 到底是成功还是失败。工程化不能替你想出精彩的剧情，但它能确保这些精彩不被遗忘。