PF2跑团Replay整理工作流：从素材归档到数字校验
PF2 跑团 replay 不是普通战报，它要还原的是“当时为什么会这样选择”的过程。当战役推进到第 25 回，玩家角色之间已经积累了大量共同经历，GM 也建立了更复杂的剧情分支，这时候整理一篇 replay，真正的难点已经不在写作，而在于如何让时间线、规则判定、角色状态和战斗数字互相咬合。下面这套工作流以“颂神之人-第25回”这类长线战役回放为整理对象，覆盖素材归档、逐场手稿、战斗数据结构、数字校验链路和发布前检查清单。整理完成后，后续第 26 回、第 27 回都可以复用同一套模板和校验脚本。
1. 为什么“第25回”的复盘比战报更依赖结构化记录
1.1 跑团 Replay 不是复述剧情，而是还原一场决策过程
跑团战报通常只写结果，比如“队伍击败了敌人，救出了人质”。但 replay 需要让读者看到过程：进入遭遇前队伍掌握哪些情报、谁先攻、玩家如何分配行动点、检定是否达到 DC、状态如何变化、谁最后倒下。对参与者和后来者来说，过程价值远高于结论。
举一个示意对比。战报写法可以是：
队伍击败了敌人。
Replay 的写法至少要包含这样一层信息：
这个示例只是为了说明信息密度差异，不是“颂神之人-第25回”的实际内容。真正的回放稿需要把每一段对话、判定和裁决按时间顺序放回去，让读者清楚是谁在什么时候做了什么，依据是什么，结果如何。
1.2 长线战役里，第 25 回是信息密度最高的节点
“第25回”意味着这不是第一篇战报，而是同一个战役中持续进行的第 25 次冒险。此时剧情线、角色动机、人物关系和房规都已经叠加得很复杂，回放必须与前面的记录保持连续性。
开始整理第 25 回前，建议先维护一份“上次结束状态”清单：
- 每个玩家角色在第 24 回结束时的 HP、关键资源与身上状态。
- 上一回结束时队伍所在的地点，以及下一个目标。
- 尚未解决的剧情线索或谜团。
- GM 之前临时使用过、且第 25 回可能继续沿用的房规或裁决。
生产环境中，这些信息应当放在独立文件里，而不是每次写进回放正文。否则第 26 回整理时，又要从旧文中翻找上下文。
1.3 PF2 的检定、DC 与行动点，是复盘时必须对齐的规则底座
Pathfinder 2e（开拓者 2 版，以下简称 PF2）的核心判定是：投一个 d20，加上对应调整值，与 DC 比较，结果通常分为四级：大成功、成功、失败、大失败。回放记录时不能只写“成功”或“失败”，因为大成功和大失败在伤害、效果和后续结算中可能有完全不同的处理。
PF2 角色在一轮内通常有 3 个行动点。记录动作时最好标明行动点消耗，否则后期无法判断角色是否有余力执行后续动作。比如某角色本轮已经移动两次，又进行了一次攻击，那么行动点已经用完，不能再执行需要额外行动点的动作。
另外，frightened、sickened、persistent damage 这类状态会影响检定和结算。如果回放里只记了“角色受到 8 点伤害”，却没有记录伤害类型和 CD，也没有记录状态来源，后续校验时就无法确认这个数字是否完整。
注意：PF2 的检定结果分为四级，不要只记“成功/失败”。大成功与大失败在后续结算中有完全不同的处理方式。
2. 从原始录音到可编辑的逐场手稿
2.1 回放素材要按“音频、文本、地图、骰子记录”四类归档
整理回放的第一步不是写正文，而是把原始素材归档。没有素材归档，转录时一旦中断，找回上下文就会非常低效。
在线下跑团中，常见素材有四类：录音、文字记录、地图或截图、骰子记录。归档时建议按回数建目录，文件名带上会话编号和场景编号。
| 素材类型 | 内容 | 推荐保存格式 | 常见问题 |
|---|---|---|---|
| 音频 | 现场录音或线上会议录音 | m4a / mp3 / wav | 多段录音时间重叠 |
| 文字 | 聊天窗口、GM 笔记、玩家私信确认 | txt / md | 玩家昵称与角色名混用 |
| 地图 | 战斗地图、场景图、区域连接图 | png / jpg / pdf | 没有标注关键位置 |
| 骰子记录 | 手动记录或骰子程序日志 | csv / md | 缺少骰子面数与调整值 |
如果录音分成多个片段，建议命名成 session-25-act-1.m4a、session-25-act-2.m4a 这样有语义的文件名，并把每个片段对应到手稿中的时间戳。
2.2 用表格建立角色、地点、线索和事件索引
转录之前，先建索引，再写细节。角色索引表是所有后续工作的基础。
| 正式名 | 别名/昵称 | 角色类型 | 当前状态 | 关键道具 | 至第 25 回前需要记得的事 |
|---|---|---|---|---|---|
| 示例占位 | 示例占位 | PC / NPC | 示例占位 | 示例占位 | 示例占位 |
表格里的内容不是第 25 回的实际数据，而是结构。实际整理时，每一行都对应一个真实角色。索引表存在的意义有两个：一是转录时保持称呼一致，避免同一角色一会儿写角色名一会儿写玩家名；二是发布时可以用别名替换真名。
事件索引表记录“什么时候发生了什么”，比角色表更偏时间线：
| 时间点 | 场景 | 参与角色 | 事件概述 | 是否进入下一阶段 |
|---|---|---|---|---|
| 00:12:30 | 某区域入口 | PC-A、NPC-1 | 触发对话，接取任务 | 否 |
| 00:31:05 | 某战斗场景 | 全队 | 遭遇第一波敌人 | 是 |
这里的“时间点”对应录音时间戳。记录时间戳的好处是，后期回听时可以直接定位，不需要从头播放。
2.3 转录时的分类规则：旁白、对话、规则判定与 GM 裁决
转录时经常出现一个问题：同一段声音里，GM 前一秒还在描述场景，下一秒就进入规则判定。如果全部混在一起写，读者很难分辨哪些是叙事、哪些是检定、哪些是 GM 临时裁决。
建议在手稿阶段使用段落类型标记。比如在 Markdown 中这样区分：
这个标记体系不用完全照搬，但需要确保“规则判定”和“GM 裁决”不会混在一起。GM 临时裁决尤其重要。如果某次 DC 被临时调高或调低，回放中要写出原因，否则后续复盘时读者会不断质疑 DC 为什么与规则不一致。
3. 战斗回放的数据模型：回合、行动、检定与状态
3.1 先定义一场遭遇战的字段，再填写回放内容
战斗回放如果要经得起校验，就不能只写成作文。建议先用字段把一次遭遇战结构化成数据，再基于数据生成叙述。
一场遭遇战中常用字段如下：
| 字段 | 含义 | 说明 |
|---|---|---|
| encounter | 遭遇战标识 | 建议使用 session-25-enc-1 |
| participants | 参与者列表 | PC 与 NPC 分开维护 |
| initiative | 先攻值 | 用于轮次排序 |
| hp | 战斗前后 HP | 必须配合 damage_taken 与 healing |
| conditions | 状态效果 | 记录来源和剩余轮数 |
| rounds | 轮次列表 | 每一轮按先攻顺序排列 |
| actions | 动作内容 | 记录动作类型和行动点消耗 |
| check | 检定信息 | 骰面、加值、DC、成功度 |
| effect | 结算效果 | 伤害、治疗、状态获得或移除 |
这里的重点是：回放数据不只是给读者看的，更是给参与者核对用的。字段越结构化，越容易检查和复用。
3.2 一份 YAML 示例：角色、先攻、行动与状态变化
YAML 适合保存这类结构化回放数据，因为它比 JSON 更易读，也方便后续写脚本校验。下面是一份通用示例的结构：
这个 YAML 是通用结构示例，不是“颂神之人-第25回”的真实战斗数据。落地时要用录音、GM 笔记和角色卡逐项替换。注意 YAML 中的字段必须保持同一口径，否则后续脚本无法读取。
注意：这里的 YAML 是通用结构示例。落地时要根据录音、GM 笔记和角色卡逐项替换，不能让示例字段混入正式回放稿。
3.3 用表格转写回合，并做 HP 与状态结算校验
如果不想用 YAML，也可以先用 Markdown 表格逐轮转写。表格适合人读，YAML 适合脚本校验，两者可以配合使用。
| 轮次 | 行动者 | 动作 | 行动点 | 检定 | 结果 | HP变化 | 状态变化 |
|---|---|---|---|---|---|---|---|
| 1 | PC-A | 移动至门口 | 1 | 无 | 成功 | 无 | 无 |
| 1 | PC-A | 攻击敌人 | 2 | 攻击检定 d20+6 vs DC23 | 失败 | 无 | 无 |
| 1 | NPC-1 | 施放区域效果 | 3 | 无 | PC 豁免 DC19 | PC-A -8 | 获得 frightened 1 |
每一轮结束后，建议立即核对该轮所有 HP 变化和状态变化。若状态持续多轮，要在后续轮次开头再次检查是否到期。
HP 结算的基本公式是：
但这只是最简口径。实际回放中还要考虑临时生命、持续伤害、伤害减免、免疫和弱点。如果出现 after 不等于 before - 伤害 + 治疗 的情况，优先回听录音确认数字，再检查是否有未记录的减免项。
4. 验证回放准确性的四条检查链路
4.1 骰值、加值与 DC 能不能对上
一份回放稿最容易出现的问题，是检定结果与骰面、加值、DC 互相矛盾。比如记录写“d20 结果为 15，加值 4，DC 18，判定成功”。15 + 4 = 19，19 大于等于 18，所以成功成立。但如果写“d20 结果为 13，加值 4，DC 20，结果大成功”，这里就有明显问题，因为 17 没有达到 20，更不可能达到大成功所需的 DC + 10。
检查顺序建议按下面这张表：
| 检查项 | 核对方式 | 异常信号 | 处理建议 |
|---|---|---|---|
| 骰值 | 回听录音或对照骰子日志 | 数字和时间点不一致 | 以 GM 判定或录音为准，并标注修正 |
| 加值 | 对照角色卡 | 加值找不到来源 | 回到角色卡确认是否包含临时效果 |
| DC | 对照规则书或 GM 笔记 | 成功/失败结果与 DC 矛盾 | 确认是否存在环境减值或 GM 临时调整 |
| 成功度 | 对照 PF2 四级结果规则 | 大成功/大失败边界不对 | 回看规则原文，确认差值边界 |
校验时不要只盯最终结果，要把每个判定拆成“骰子值 + 调整值 vs DC”三个独立输入。三个输入中任何一个记录错了，都会误导后续复盘。
4.2 HP、治疗、伤害和临时状态能不能闭环
HP 校验比检定校验更容易漏错。因为战斗越久，数字越碎片化。建议在原始记录中用一张小表持续维护每个角色的 HP 变化：
| 角色 | 起始HP | 受到的伤害 | 获得治疗 | 临时生命 | 结束HP | 是否正确 |
|---|---|---|---|---|---|---|
| PC-A | 46 | 18 | 0 | 0 | 28 | 是 |
| NPC-1 | 60 | 60 | 0 | 0 | 0 | 是 |
如果结束 HP 与“起始 HP - 伤害 + 治疗”不一致，先不要急着改数字。优先回听录音，确认是否存在伤害减免、免疫、弱点或临时生命护盾。确认全部计算因素后，再把差异修正进回放稿。
状态也需要类似闭环。要记录状态的获得轮次、来源效果、持续轮数、到期时间。否则下一轮可能把一个已经结束的状态继续保留在角色身上。
4.3 用 Python 脚本做一致性校验，避免人工漏查
当回放数据进入 YAML 后，可以用简单脚本自动检查多条规则。下面是一个最简校验示例，只检查 HP 闭环：
这个脚本只覆盖最基础字段。长期整理时，可以继续扩展以下校验：
- 检定结果是否等于
d20 骰值 + 加值。 - 行动点消耗是否超过动作点上限。
- 已死亡角色是否继续执行动作。
- 状态持续时间是否超过记录上限。
- DC 是否存在明显异常值。
脚本不是发布给读者看的，而是整理者自己的“回归测试”。每次改完 YAML，都跑一遍，能减少大量人工复查工作。
4.4 复盘结论要区分“事实层”和“评价层”
回放稿最后通常有一段复盘分析。复盘要避免把主观判断和客观事实混在一起。读者需要先知道“事实是什么”，再知道“评价是什么”。
事实层的写法示例：
第 1 轮，PC-A 选择移动至门口并使用攻击动作，攻击未命中。第 2 轮，NPC-1 施放区域效果，PC 豁免失败，PC-A 受到 8 点伤害并获得 frightened 状态。
评价层的写法示例：
在角色尚未确认敌人数量时，优先建立掩体是合理选择。但由于 PC-B 没有一起移动，区域效果覆盖了两位角色，说明队伍在阵型沟通上仍有成本。
评价应聚焦“决策在当时信息下是否合理”，而不是“玩家是否玩得不好”。最好给结论留出讨论空间，比如“可以进一步观察该决策在后续回合的实际收益”。
5. 发布前需要处理的保密、剧透与格式问题
5.1 发布前检查清单：剧透标注、角色别名、玩家许可
发布跑团 replay 前，最需要明确的是公开边界。这不仅是写作规范，更是对参与者体验的保护。以下清单可以在每次发布前逐项确认：
| 检查项目 | 要求 |
|---|---|
| 剧透提示 | 标题或开头标注“剧透：本回为完整回放，未跑者慎入” |
| 角色别名 | 使用玩家约定的昵称或角色化名 |
| 玩家许可 | 正式发布前获得参与玩家和 GM 的同意 |
| 素材权限 | 引用截图、地图、图片前与 GM 确认版权 |
| 规则版本 | 在文末或开头标注 PF2 版本及房规说明 |
| 数字一致性 | 发布前重新跑一遍 YAML 脚本校验 |
| 术语统一 | 同一术语在全文保持一致，不混用译法 |
| GM 裁决 | 所有临时裁决单独标注，标注为“GM 裁决” |
注意：发布前最容易被忽略的不是错别字，而是玩家对公开程度的分歧。角色状态信息可以全员确认后再发布。宁可晚一天，也不要因为剧透破坏后续跑团的体验。
5.2 常见问题：听错数字、术语不统一、版本规则混用
整理 PF2 回放时，有三个问题出现频率特别高。
第一个问题是听错数字。回听录音时，17 和 70 可能很难分辨，特别是环境音嘈杂时。不要强行猜测数字。如果数字无法确认，建议在手稿中标注“此段音频不清，数字待确认”，而不是写一个看似确定的错误值。
第二个问题是术语不统一。同一场对战里，不同玩家可能把同一个规则概念叫成不同名字。建议建立一份简单术语表：
| 英文 | 中文译法 | 说明 |
|---|---|---|
| d20 | 二十面骰 | PF2 主要使用 d20 进行检定 |
| check | 检定 | 指技能、攻击、豁免等判定 |
| DC | 难度等级 | 用于判断检定结果是否成功 |
| frightened | 惊惧 | 一种状态效果，具体数值以实际版本和 GM 裁决为准 |
第三个问题是版本规则混用。PF2 与 PF1 的行动经济不同。PF2 通常采用 3 行动点，PF1 采用标准动作、移动动作和迅捷动作的结构。如果回放中出现了跨版本内容，务必在发布说明中单独标注，避免读者用错误版本理解判定过程。
5.3 长期维护：从单篇 Replay 到可复用模板
第 25 回整理完成后，下一回不能又从头设计工作流。建议建立统一目录结构：
其中 audio 保存录音片段，notes 保存索引表和转录手稿，data 保存 YAML 和校验脚本，output 保存发布版 Markdown。使用版本管理工具管理这些文件，每次大修改都留下提交记录，便于回溯。
每个回放文件开头维护一段“上次状态”块，方便第 26 回直接续接。长线战役的 replay 价值会随回数增加而不断放大，但前提是每一回都能稳定复用同一套模板。
回放整理到最后，最有价值的不是一篇格式工整的文档，而是让参与者看到自己在第 25 回里真正做过什么、当时掌握多少信息、规则如何走向当前结果。对玩家来说，这是策略复盘；对 GM 来说，这是主持校准；对后来者来说，这是一份可学习的战斗与叙事案例。从第 25 回开始建立这套工作流，第 26 回之后，素材整理、数字校验和发布准备都会逐渐变成固定动作。