KTSL：CoC 分队调查的时间同步与信息隔离协议

技术报告草案 / 2026 年 7 月 5 日

摘要

《克苏鲁的呼唤》（Call of Cthulhu, CoC）的调查者经常分头行动。角色一旦分散，KP 便要同时维护两条容易失控的边界：不同场景的叙事时间不能互相矛盾，玩家在公共频道听见的内容也不能未经角色内传播就改变行动。现有规则多把这两项工作留给主持人裁量，社区经验则缺少可记录、可复盘的共同格式。为此，本文把分队调查建模为带信息标签的多场景离散事件系统，并提出 KP 时间同步与信息隔离三层协议（Keeper Time-Sync and Leakage-control protocol, KTSL）。Schedule 层维护因果偏序、同步屏障、事件提交与有限回滚边界；Filter 层管理信息敏感度、授权受众、输出通道和降密条件；Coupling 层依据共享线索、倒计时、资源、空间邻近与即时伤害依赖，选择松散叙事、调查交换、严格轮次或场景合并。本文给出形式模型、协议对象、伪码、不变量、主持流程、案例轨迹与可复现消融。两个确定性测试用例的三层开关实验中，Schedule 将因果违反总数从 2 降至 0；Filter 将未授权行动与公共高敏泄露合计从 4 降至 0，并把降密完整度从 0.00 提高到 1.00；Coupling 将高耦合时间漂移从 6 降至 0。H1—H3 在测试预言中均为 2/2。这些结果只说明协议在受控案例中按预期工作；它们不是实际跑团证据，外部效度仍需真实跑团记录（transcript）与盲审标注检验。

关键词： TRPG；Call of Cthulhu；Keeper；时间同步；信息流控制；叙事系统；分布式系统；metagaming

引言

调查场景的时间并不比战斗简单，只是它通常没有写在轮次表上。CoC Quick-Start 与 D&D Basic Rules 都用主持人裁量或先攻顺序组织战斗 [cocquickstart; cocpdf; dndbasic2018]；调查却常在模糊的时间窗里并行推进。同一晚，一名记者可能在图书馆翻查十九世纪的地方报纸，两名医生进入下水道寻找仪式痕迹，一名神父则留在教堂解读壁画。桌面叙述只能逐段进行，故事中的行动却未必先后发生，耗时也可能相差悬殊。若把发言顺序直接当成叙事顺序，时间错位很快就会出现。

A 在图书馆查到“祭坛位于下水道第三岔口，午夜前必须破坏银钥匙”。为了让全桌都能参与，KP 在公共频道念出了这段线索。镜头随后切回下水道，B 的玩家立刻决定去第三岔口。这个选择在桌面上顺理成章，在叙事中却没有来源：B 没看过日记，没接到电话，也没有从其他线索推断出地点。争议的关键不在玩家听见了什么，而在这份玩家知识是否未经授权就进入了角色行动。

时间又使问题复杂了一层。假设 A 查日记用了三十分钟，而 B、C 在下水道只推进了两分钟：A 得到线索时，他们是否已经走过岔口？电话还来得及吗？教堂中的失败又是否会推进同一场仪式的倒计时？发言先后无法回答这些问题。KP 需要一份叙事账本，知道哪些事件已经发生，哪些事实已经公开，哪些信息仍只属于部分角色，以及哪些局部进展必须同步。

主持人通常凭经验解决这些冲突：勤切镜，少公开未在场角色可利用的细节，适时让队伍会合，并提醒玩家区分角色内（IC）与角色外（OOC）知识 [rpgsplit; rpgmeta]。这些办法有效，却很难教给新 KP，也不便团后复盘。一次旁听信息究竟从哪里进入了角色行动，某个场景为何应该转为严格轮次，往往只能依赖当时主持人的直觉。熟悉队伍中的默契，换到线上团、录播团、陌生玩家团或高秘密密度模组时也未必成立。

本文不打算把 CoC 改造成机械仿真。研究问题更窄：在保留调查叙事弹性的前提下，KP 如何显式维护事件因果、角色知识、场景同步和不可回滚的事实边界？

本文把并行调查视为带信息标签的多场景离散事件系统，而非依赖精确全局时钟的回合系统。对 KP 而言，秒表通常不如四件事重要：事件之间的因果偏序、信息的授权传播、共享倒计时的同步，以及角色行动能否由其知识和动机解释。Lamport 的偏序时间、DIFC 的授权标签和 Riedl—Young 的叙事可信度分析分别为这三类约束提供了概念工具 [lamport1978; myers1997; riedlyoung2010]。KTSL 正是在这一转译上建立的。

Schedule 层决定事件如何排序、何时提交，并记录局部时间窗、因果边、同步屏障与可补叙的待定区域。Filter 层决定信息给谁看，以敏感度、所有者、授权受众、降密条件和公共摘要描述线索。Coupling 层判断场景之间需要多强的同步，再选择松散因果、调查交换、严格轮次或场景合并。

本文的贡献有四项：一是建立同时包含事件、局部时间、角色知识、玩家观察与信息标签的分队调查模型；二是把严格轮次、exchange、flashback、因果偏序、分布式仿真、信息流控制和叙事规划中的可用部分转写为主持约束；三是给出可落到主持表、电子账本或平台插件中的协议对象、伪码与不变量；四是通过两个确定性测试用例和三层开关消融检查 H1—H3，同时保留跑团记录审计作为后续外部效度实验。

协议不声称让玩家在心理上“忘记”旁听内容。它只检查这些内容是否进入角色知识并转化为可行动优势，这是一种面向可观察影响的弱化 noninterference [goguen1982]。KTSL 也不要求所有场景启用完整账本：低风险、低耦合、低秘密密度的调查可以继续采用轻量主持。本文报告的仍是确定性测试用例，而非大规模真人跑团；在获得真实记录与盲审标注前，结论只能停留在受控案例。

问题、缺口与研究方法

目标环境与目标应用

KTSL 面向 CoC 及相近调查型 TRPG 的分队场景，用于真人桌面或线上语音跑团中的运行时协调，而非战斗轮次优化或自动剧情生成。这里有四项基本事实：KP 通常全知，玩家和角色却各有视野；事件以“几分钟后”“同一晚”“仪式开始前”等叙事时间窗表达，不必精确到秒；信息必须经由看见、阅读、通话、复述、展示物证或 NPC 告知等角色内路径传播；主持人需要在因果一致、玩家公平、秘密保护与戏剧节奏之间取舍。

因此，文中的计算机系统术语都只作结构转译。“进程”对应场景或角色小组，“消息”对应角色内通信、物证展示、NPC 转述或共享环境变化；“安全策略”约束角色使用尚未获得的信息；评估关注时间矛盾、未授权行动、玩家等待和事后改写，而非吞吐量。本文借用这些概念来命名边界，不把 TRPG 等同于计算机程序。

现有方法的缺口

分队调查通常有四种处理方式。严格轮次最容易执行，却也最重。查书、街头打听与警署交涉未必需要秒级同步，强行排进战斗式轮次，会把调查变成等待队列，削弱恐怖叙事需要的停顿与不确定感。

全公开叙述能让所有玩家参与，适合录播、教学或低秘密密度场景；代价是核心线索、怪物弱点、NPC 身份或陷阱机制一旦进入公共频道，后续选择便很难区分为角色推理还是玩家记忆。这不是预设玩家会作弊，而是承认信息暴露会改变决策环境。

全私聊降低了直接泄露，却把成本转移给等待者。某组获得十分钟私密戏份时，其他玩家只能旁等，共同体验也被切碎。私聊本身还不会生成角色知识表：会合后谁告诉了谁、说到什么程度、是否展示证据，仍需另行记录。

经验切镜最灵活，也最接近成熟主持人的实际做法：玩家犹豫时换组，危险临近时同步，必要时促成会合。它缺少的不是有效性，而是显式标准——何时必须同步、哪些内容只能公开摘要、哪些事实已经不能由补叙改写。判断若不落到对象和规则上，就难以训练与复盘。

四种做法留下了四个相连的缺口。CoC 与 D&D 的战斗规则说明了严格轮次如何工作，却没有给低耦合调查提供可迁移的模糊时间模型 [cocquickstart; cocpdf; dndbasic2018]；社区实践提醒主持人防范 metagaming，却很少用数据结构区分玩家观察、角色知识和公共事实 [rpgmeta]；Fate 的 exchange 提供了比战斗轮次更松的镜头单位，但不处理高敏信息标签 [fateexchange]；BitD 的 flashback 展示了补叙的玩法价值，CoC 调查则还需要区分待定事实与已提交事实 [bitdsrd; jefferson1985]。KTSL 试图补上的正是这组中间层。

研究方法与证据等级

本文采用“概念编译”的方法：从规则文本、社区经验和计算机科学文献中抽取结构相近的机制，再将其改写为 KP 能执行的主持对象。分布式系统文献在这里是命名和约束工具，用来说明因果边、未授权信息流与同步屏障，而不是用来证明 CoC 与分布式系统同构。

证据分为三级。A 级是全文论文、完整规则文本或完整 SRD，用于支撑主要定义与设计；B 级是官方页面、标准页面、社区实践和可读全文镜像，用于支撑工程启发与实践约束；C 级只包含摘要、元数据或部分扫描页，只能作为背景类比。分级的目的，是避免把结构相似误写成已经证明。

全文按系统论文的逻辑展开：问题与证据之后给出形式模型，再说明协议设计、运行方式、受控评估与后续审计。当前证据来自确定性测试用例，而非真实跑团记录；评估部分因此只报告可复现的机制检查，并另外规定真实数据应如何收集、标注和判断。

形式化问题模型

调查系统

定义一次分队调查为如下元组：

其中，$P$、$U$、$S$、$E$、$M$ 和 $T$ 分别表示角色、玩家、场景、事件、信息单元与叙事时间域。$loc(p,t)$ 给出角色 $p$ 在时间 $t$ 所处的场景；$know(p,t)$ 是角色当时合法掌握的信息；$obs(u,t)$ 是玩家在桌面层面观察到的内容；$ch(p_i,p_j,t)$ 表示两名角色之间存在合法通信通道。$label(m)$ 则记录信息 $m$ 的敏感度、所有者（owner）、授权受众和降密条件。

$know$ 与 $obs$ 必须分开：玩家听见线索，只能说明它进入了 $obs$，不会自动写入角色的 $know$。Noninterference 关注高敏行为是否影响低权限主体的可观察输出，DIFC 则用所有者、读者和降密描述信息传播 [goguen1982; myers1997]。转到跑团语境后，一条信息只有经过同场感知、阅读物证、NPC 告知、角色内通信、他人复述、证据展示或得到 KP 认可的推理，才进入角色知识。行动还应当能由角色的意图与信念解释 [riedlyoung2010]。许多 metagaming 争议由此可以改写成一个可核对的问题：角色获得这条信息的路径在哪里？

事件 $e \in E$ 记录场景、参与角色、局部时间窗、前置条件、行动、输出信息与提交状态。状态只有两种：待定（pending）事件尚未被公共叙述、机械后果或其他事件锁定；已提交（committed）事件已经产生不可逆的叙事依赖，普通补叙（flashback）不得改写。

叙事 happened-before

事件先后关系写作 $e_i \rightarrow e_j$，表示叙事上的 happened-before，而非现实秒表上的小于号。以下情况都会建立这条边：同一场景中 $e_i$ 先于 $e_j$；$e_i$ 的信息经合法通道进入 $e_j$ 参与者的知识；两者被同一倒计时、NPC 行动或环境变化连接；或者 $e_j$ 的前置条件直接引用 $e_i$。

这一定义借鉴 Lamport 的事件偏序 [lamport1978]，用因果关系替代伪精确。KP 不必给每个行动标注“耗时 37 秒”；记录谁依赖谁、谁通知了谁、哪些场景共享倒计时，已经足以发现多数叙事矛盾。

一个图书馆与下水道的例子可以说明。A 在图书馆读到祭坛地点，事件记为 $E_L$。A 打电话告诉 B，事件记为 $E_T$。B 前往第三岔口，事件记为 $E_S$。若电话实际发生，则有 $E_L \rightarrow E_T \rightarrow E_S$。若电话没有发生，B 的 $E_S$ 就不能引用 $E_L$ 的输出。玩家旁听不建立这条边。

信息泄露

本文把审计对象限定为“可行动泄露”，不判断玩家是否在心理上记住了旁听内容。Noninterference 提供了一个更可操作的视角：风险在于高敏信息是否改变了未授权主体的可观察行为或输出 [goguen1982]。据此，高敏信息 $m$ 对角色 $p$ 在时间 $t$ 的未授权泄露定义为：

其中，$use(m,p,t)$ 表示信息 $m$ 对角色 $p$ 的行动产生了可观察影响；$authorized(m,p,t)$ 表示存在同场感知、通信、物证、复述、展示、降密或合法推理路径。泄露问题由此从“玩家有没有听到”转为“角色行动是否存在未授权依赖”。桌面环境很难完全隔离玩家的观察，却可以要求角色行动具有叙事依据；RPG 社区关于分队 metagaming 的建议也强调减少可利用细节，并在角色会合后再同步信息 [rpgmeta; rpgsplit]。

信息的行动价值并不相同。“图书馆里很潮湿，远处钟声沉闷”只营造气氛，通常不会指向最优行动；“银钥匙是唯一破坏仪式的触媒”却包含核心内容（payload）。若不在场角色据此立刻寻找银钥匙，就构成高风险的可行动泄露。Filter 层处理的正是这一区别。

主持目标函数

KP 的目标不是单一最优，而是多目标平衡。本文把目标写作：

其中，$V_c$、$V_l$、$W_s$ 和 $R$ 分别表示因果违反、未授权信息影响、最大镜头等待与事后改写次数；$F$ 和 $N$ 约束叙事流畅度以及恐怖、推理体验的最低质量。公式不是给 KP 的求解任务，而是把冲突摆在明面上：保密可能增加等待，流畅可能掩盖因果错误，平均分配轮次也可能破坏调查节奏。Fate exchange 与社区切镜实践为行动机会提供参照，叙事规划则区分情节连贯性和角色可信度 [fateexchange; rpgsplit; riedlyoung2010]。

相关工作与技术映射

TRPG 规则文本

CoC 7e Quick-Start Rules 给出了 Keeper 控制流程和战斗行动顺序，战斗中角色通常按 DEX 顺序行动，combat round 的长度则保持叙事模糊 [cocquickstart; cocpdf]。这支持本文对时间窗的处理：在调查场景中，KP 不必把所有行动换算为精确秒数，而应使用能维持因果的局部窗口。CoC 的规则气质本来就不是战棋式精确仿真，这一点很重要。

D&D Basic Rules 把战斗定义为一系列 rounds，每轮约六秒，每个参与者有自己的 turn，initiative 在战斗开始时确定 [dndbasic2018]。它是严格同步的代表。本文不把 D&D 轮次直接移植到 CoC 调查，但它提供了一个边界条件：当分队调查升级为共享危险、战斗、追逐、抢夺同一物品或仪式倒计时时，严格轮次有价值。

Fate Core 的 exchange 更接近本文需要的中间层 [fateexchange]。Exchange 不要求所有行动有精确秒数，而是保证参与者在一个冲突单位中获得行动机会。本文的 investigation exchange 借用这一点：每个分队在一个 exchange 中处理一个 significant action，然后 KP 检查同步屏障和信息传播。

Blades in the Dark 的 cut to the action、engagement roll 和 flashback 提供了另一个启发 [bitdsrd]。BitD 不要求玩家提前详述所有准备，而允许在行动中补叙过去准备。CoC 可以借用有限 flashback 作为调查自由度工具，但必须增加 committed 约束。若一条事实已经公开、已被他人行动依赖或已产生机械后果，就不能被 flashback 改写。

社区主持实践

RPG StackExchange 上关于分队和 metagaming 的讨论反复出现几个经验点：频繁切换 spotlight，在玩家犹豫或行动告一段落时切镜，不把全部私密细节公开，必要时引导重聚，明确玩家知识与角色知识的差别 [rpgsplit; rpgmeta]。这些建议不是形式化协议，却说明问题确实来自桌面实践，而不是人为构造的学术问题。

社区实践的不足在于缺少对象层。它会说“别公开太多细节”，但不说明“哪些细节属于高敏 payload”。它会说“经常切镜”，但不说明“高耦合场景最多能漂移多久”。它会说“让玩家别 metagame”，但不说明如何判定一个行动是否依赖未授权信息。本文的贡献不是推翻这些经验，而是给它们补上可执行数据结构。

分布式时间与仿真

Lamport 的经典论文指出，在分布式系统中，很多事件之间没有全局可观测的真实先后；系统真正需要维护的是 happened-before 偏序 [lamport1978]。这与 CoC 分队调查很像。图书馆读书和下水道探索未必有可比的精确先后，除非两者通过通信、共享倒计时或共享后果发生连接。把时间同步改写为因果一致性，是本文最重要的理论转译。

Chandy 和 Misra 的分布式仿真研究强调 logical process、消息、无全局控制和死锁避免 [chandymisra1979]。每个分队场景可以看作一个 logical process。若一个场景的下一步需要另一个场景可能产生的信息，KP 不应继续长距离推进，而应设置屏障或切换 spotlight。这个类比尤其适合处理“下水道队伍是否已经错过电话”之类问题。

Jefferson 的 Virtual Time 和 Time Warp 说明乐观推进必须配套 rollback 和全局虚拟时间边界 [jefferson1985]。TRPG 中的 flashback 与 rollback 不是同一机制，但二者共享一个思想：未提交区域可以改写，已提交区域不能随意改写。本文把这个思想转化为 pending events 与 committed events。KP 可以允许角色补叙“我出门前带了粉笔”，但不能允许“我其实早就拆掉了刚刚公开爆炸的炸弹”。

Cristian 的概率时钟同步提醒我们，真实系统中的同步也不是绝对精确，而是依赖误差边界和故障假设 [cristian1989ibm; cristian1989springer]。本文只把它作为弱类比：KP 可以使用时间窗口和误差带，例如“图书馆场景在 22:10 至 22:40 之间”，而不是强行精确到每一分钟。IEEE HLA 标准则说明分布式仿真需要对象模型、federate 与时间管理 [ieee1516]。这些概念为本文的 SceneCard 和 EventRecord 提供了工程语言。

互斥、仲裁与等待成本

Ricart-Agrawala 分布式互斥算法通过 REQUEST 和 REPLY 消息实现对临界区的互斥访问 [ricart1981; ricartmirror]。在 TRPG 中，临界区可以是同一个 NPC 的注意力、同一件物品、同一道门、同一个仪式节点或同一段先手行动。若两个分队都声称“先去找同一个证人”，KP 不能只按谁先在桌面发言决定，而应显式建立仲裁。

Maekawa 的 quorum 算法减少了互斥通信成本，关键在于任意两个投票集合有非空交集 [maekawa1985; maekawamirror]。对 KP 来说，这个思想转译为“最小共同仲裁点”。并不是所有冲突都需要全桌重新同步；如果冲突只涉及一个 NPC 和两个角色小组，KP 可以把该 NPC、相关地点或共享线索作为仲裁点，只同步受影响的场景。

Rubinstein 的轮流议价模型揭示等待成本会影响策略和结果 [rubinstein1982]。本文只把它作为 spotlight fairness 的背景提醒。玩家等待不是中性的。一个玩家连续二十分钟没有镜头，即使其角色没有危险，也会降低参与感。严格保密如果造成长时间私聊，就可能以另一种方式损害体验。

信息流控制与隐私

Goguen 和 Meseguer 的 noninterference 将安全性表述为高安全级主体的行为不应影响低安全级主体可观察输出 [goguen1982]。转译到 CoC，某个分队的私密发现不应影响不在场角色的行动，除非经过合法通信或降密。与笼统要求玩家“别乱用”相比，可观察影响提供了更清楚的审计对象。

Bell-LaPadula 模型提供了强制访问控制中的 no read up 与 no write down [belllapadula1976]。TRPG 不需要军事级访问控制，但可借用两个规则。角色不能读取权限之外的线索，高敏线索也不能直接写入公共频道。若 KP 需要维持全桌氛围，可以公开低敏摘要，而不是公开 payload。

Myers 和 Liskov 的去中心化信息流控制引入 owner、reader 和 declassification [myers1997]。这非常适合线索传播。线索并不总是 KP 单方拥有；A 读到日记后，A 成为该信息在角色层面的 owner。A 可以选择复述、隐瞒、打电话或展示证据。降密不是自动发生，而是由叙事动作触发。

LIO 的动态标签思想也适合 KP 叙述状态 [stefan2011]。当 KP 正在处理高敏私聊内容，当前叙述标签升高。回到公共频道时，KP 不能无过滤输出刚刚读取的 payload，而要降为 redaction 或等待降密条件。这个提醒很实用，因为很多泄露不是恶意，而是 KP 在解释掷骰、描述 NPC 反应或总结场景时顺手说漏。

Dwork 等人的差分隐私强调按 sensitivity 校准输出扰动 [dwork2006]。本文不把 TRPG 信息处理称为差分隐私，也不引入数学噪声保证。可借用的是敏感度意识：低敏氛围可公开，高敏弱点和地点要私发或延迟，中敏战术信息可以摘要化。Yao 的安全秘密交换则提醒，多方协作不必要求所有人知道全部输入 [yao1986]。

叙事规划

Riedl 和 Young 的叙事规划研究指出，故事需要同时维护情节因果和角色意图可信度 [riedlyoung2010]。这补足了纯信息流模型的不足。一次行动即使没有直接泄露，也可能因为动机路径不可信而破坏叙事。例如一个胆小的图书管理员角色突然无理由冲向下水道最危险的岔口，即使玩家声称“我只是猜的”，也需要 KP 要求更清楚的角色内依据。

因此，本文的安全概念不是只看信息集合，也看角色行动是否有叙事上可接受的解释路径。ValidateICAction 的作用并非惩罚玩家，而是让玩家补出角色能成立的推理。若补不出，KP 可以把行动降级为“朝声音更明显的方向探索”，而不是允许精准使用未授权 payload。

文献依据与协议应用矩阵

下表只记录“文献观点—协议对象—使用边界”三者之间的对应关系。计算机系统概念在 KTSL 中均属结构转译，不承担工程等价或形式安全保证。

这张矩阵也限定了正文的措辞。社区经验只能写成实践启发；分布式系统文献只能支撑结构类比；Cristian 的时钟误差和 Rubinstein 的等待成本只作背景提示，不承担 KTSL 的正确性命题。

设计目标、非目标与总体结构

设计目标

因果一致是 Schedule 层的首要目标，依据来自 Lamport 的 happened-before 偏序与分布式仿真的安全推进条件 [lamport1978; chandymisra1979]。若 $E_2$ 依赖 $E_1$，前者不能在叙事上先成立；线索若通过电话传播，账本中必须存在时间上可行的通话事件；仪式倒计时一旦推进，所有受影响场景都要更新。

Filter 层把授权信息流从主持人的临时记忆移到账本。每条核心线索记录敏感度、所有者、授权受众、降密条件与公共摘要；Bell–LaPadula 的输出约束、DIFC 的去中心化标签和 LIO 的动态标签为这一设计提供了参照 [belllapadula1976; myers1997; stefan2011]。公共叙述可以维持气氛，却不能在未降密时说出高敏核心内容。

镜头公平限制了 Filter 层的使用方式：防泄露不能退化为无限私聊。Fate exchange 提供了按行动机会组织镜头的实践依据，Rubinstein 的等待成本只作为弱类比，提醒主持人等待本身会改变参与体验 [fateexchange; rubinstein1982]。每轮调查交换结束后，KP 都应检查等待债务；长期没有镜头的玩家至少需要一次状态更新、选择机会或低敏公共摘要。

叙事弹性同样是设计目标。CoC 需要即兴、误解、延迟揭示和玩家创造；BitD 的 flashback 展示了补叙的价值，Jefferson 的回滚边界则说明乐观推进必须知道哪里可以停 [bitdsrd; jefferson1985]。KTSL 不记录每一步脚印，也不禁止补叙，只标出高敏信息、共享倒计时、共享资源、即时危险和已提交事实这些高风险边界。

非目标

KTSL 不保证玩家心理上遗忘旁听信息。这个限制来自本文对 noninterference 的弱化使用：协议只观察未授权信息是否影响角色行动，而不声称能控制玩家内部记忆 [goguen1982]。KTSL 也不取代 session zero、玩家信任和社交契约。若玩家故意把 OOC 知识转成 IC 行动，协议只能提供证据和处理流程，不能替代桌面沟通。

KTSL 不是完整自动主持系统。本文不尝试让程序替 KP 决定所有叙事结果，也不提供完整跑团平台实现。协议对象可以被纸笔、电子表格、Notion、Obsidian、VTT 模块或聊天机器人实现，但本文关注的是抽象接口和运行原则。

KTSL 也不是普遍适用于所有 TRPG 的通用定律。它更适合秘密密度高、分队常见、调查链复杂的模组。对于规则本身鼓励玩家共享作者视角的叙事游戏，严格角色知识边界可能不合适。本文讨论的是 CoC 及相近风格调查游戏。

总体结构

KTSL 的运行结构。Schedule 层控制事件和时间，Filter 层控制信息输出，Coupling 层控制同步强度。三层共享同一份主持账本。

上图给出 KTSL 的结构。KP 在运行时维护一个轻量账本。每个场景有一张 SceneCard，每次显著行动生成一个 EventRecord，每条重要信息生成一个 InfoLabel，每对关键场景有一个 SceneCoupling。SceneCard 与 EventRecord 的设计来自 HLA 对分布式仿真对象与时间管理的要求、Lamport 事件偏序以及 Chandy-Misra logical process 模型的组合应用 [ieee1516; lamport1978; chandymisra1979]；InfoLabel 来自 DIFC、Bell-LaPadula 和 LIO 的信息标签传统 [myers1997; belllapadula1976; stefan2011]。三层不是三个孤立模块，而是同一份账本的三个视角。Schedule 层决定何时推进和提交；Filter 层决定如何叙述；Coupling 层决定是否切换调度模式。

Schedule 层：因果、同步屏障与提交边界

SceneCard 与 EventRecord

SceneCard 是场景层状态。它至少包含场景编号、地点、参与角色、局部时间窗、当前调度模式、pending events、committed events、公共可见摘要、私有事实、出入通信通道和与其他场景的耦合度。该对象借鉴 HLA 中 federate、对象模型和时间管理必须显式化的思想 [ieee1516]，但粒度降到 KP 可手工维护。SceneCard 的目的不是让 KP 写日志，而是让 KP 在切镜时能回答三个问题：这个场景推进到哪里了，哪些事实已经不能改，下一步是否会影响其他场景。

SceneCard:
  scene_id: library
  local_window: W2
  participants: [A]
  mode: investigation_exchange
  pending_events: [E07]
  committed_events: [E01, E03]
  public_view: "A 正在查阅旧报纸，神色越来越紧张。"
  private_facts: [I12]
  channels:
    outbound: [telephone_if_declared]

EventRecord 是事件层状态。它记录行动者、场景、窗口、行动、前置条件、输出信息和提交状态。该对象对应 Lamport 偏序中的事件节点，也对应分布式仿真中 logical process 之间可产生依赖的离散事件 [lamport1978; chandymisra1979]。每次 significant action 至少生成一个 EventRecord。所谓 significant action，是指会改变线索状态、危险状态、角色位置、资源、NPC 态度或倒计时的行动。普通氛围描述不必生成事件。

EventRecord:
  id: E07
  scene: library
  actors: [A]
  window: W2
  action: "查阅馆藏日记"
  preconditions: [E01]
  happens_after: [E01]
  outputs: [I12]
  status: pending

调度模式

Schedule 层提供四种主要模式。Loose causal 适用于低耦合场景。KP 只记录因果边和大致时间窗，可以用 montage 快速推进。Investigation exchange 适用于中等耦合调查，其来源是 Fate exchange 对行动机会的组织方式 [fateexchange]。每个场景解决一个关键行动，然后检查信息传播和同步屏障。Strict round 适用于高耦合、高危险或共享资源竞争场景，其基线来自 CoC 与 D&D 战斗轮次规则 [cocquickstart; cocpdf; dndbasic2018]。它类似战斗轮次，但可以按叙事声明顺序、DEX 或现场优势决定。Macro scene 适用于多个分队实际上处在同一物理或叙事空间，例如同一栋宅邸的不同房间，此时应合并场景，同时保留局部可见性。

调度选择算法如下：

ChooseSchedule(scene_a, scene_b):
  c = Coupling(scene_a, scene_b)
  if CombatOrChaseActive(scene_a, scene_b):
      return strict_round
  if c >= 4:
      if SameMacroLocation(scene_a, scene_b):
          return macro_scene
      return strict_round
  if c >= 2:
      return investigation_exchange
  return loose_causal

这个算法有意简单。KP 不需要在桌上运行复杂模型。真正重要的是把“感觉上该同步了”改写为若干可见条件：有没有共享倒计时，有没有同一 NPC 或物品，有没有即时伤害依赖，有没有跨场景通信，有没有一条线索会改变另一组的行动空间。

事件提交与有限回滚

事件提交是 KTSL 中最容易被低估的机制。TRPG 中很多矛盾不是来自事件发生，而是来自事后改写了已经被别人依赖的事件。为了避免这种问题，Schedule 层把事件分为 pending 和 committed。这个划分来自两条来源链：BitD 证明补叙和 flashback 有玩法价值，Jefferson 的 Time Warp 则说明 rollback 必须有全局边界 [bitdsrd; jefferson1985]。Pending 事件可以被 flashback、补叙或轻微修正影响。Committed 事件则进入不可改写区。

CommitEvent(event):
  if event.has_public_narration and event.used_by_other_event:
      event.status = committed
      event.commit_reason = public_dependency
  else if event.has_irreversible_mechanical_effect:
      event.status = committed
      event.commit_reason = mechanical_effect
  else if event.declassifies_high_sensitivity_info:
      event.status = committed
      event.commit_reason = declassification
  else:
      event.status = pending

举例说，A 说“我出门前把手电筒塞进包里”，若这没有影响已公开事实，KP 可以允许作为 flashback。A 说“我其实早就给 B 打过电话告诉他祭坛地点”，如果 B 之前已经因为不知道地点而做出选择，这个 flashback 就可能改写 committed 事件。KP 可以拒绝，或要求付出代价并只允许它解释后续行动。

Schedule 层维护三个不变量。S1：对任意 committed 事件，不允许后续 flashback 改写其事实 payload。S2：若 $e_i \rightarrow e_j$，则 $e_j$ 的结算不得引用未结算或已撤销的 $e_i$。S3：若两个场景共享高耦合倒计时，每个 exchange 结束时必须检查同步屏障。

Filter 层：信息标签、输出通道与降密

InfoLabel

Filter 层的核心对象是 InfoLabel。每条会改变玩家选择的线索都应拥有标签。标签至少包含信息编号、来源事件、来源场景、敏感度、owner、授权受众、释放策略、降密条件和公共摘要。该对象直接吸收 DIFC 的 owner、reader 和 declassification 结构，并用 Bell-LaPadula 的 no write down 直觉约束公共输出 [myers1997; belllapadula1976]。低敏氛围不必全部标注；高敏线索必须标注。

InfoLabel:
  id: I12
  source_event: E07
  source_scene: library
  sensitivity: 3
  owners: [A]
  authorized_audience: [KP, A]
  release_policy: private
  declassify_when:
    - A 通过电话复述
    - A 与队伍会合并展示日记
    - NPC 在公共场合说出同一事实
  payload: "祭坛在下水道第三岔口，午夜前必须破坏银钥匙。"
  public_redaction: "A 读到一段与今晚某地点有关的危险记录。"

敏感度分为四级。0 级是氛围信息，没有直接行动价值。1 级是低行动价值信息，能影响情绪和方向，但不会直接给出关键最优解。2 级是战术信息，会改变近期选择，例如门后有脚步、NPC 在说谎、某条路危险。3 级是核心秘密，例如地点、弱点、仪式步骤、秘密身份和真相解释。这个分级不是差分隐私的数学 sensitivity，而是借用 Dwork 等人“输出处理应随敏感度变化”的方法论 [dwork2006]。

输出通道选择

输出通道选择算法如下。它把 noninterference 的“未授权影响不可见”、Bell-LaPadula 的输出限制和 LIO 的动态标签约束合并成 KP 可执行判断 [goguen1982; belllapadula1976; stefan2011]：

SelectChannel(info, audience):
  if info.sensitivity <= 1:
      return public
  if audience subseteq info.authorized_audience:
      return private
  if DeclassifyConditionSatisfied(info):
      return public
  if NeedPublicEngagement(info):
      return redacted
  return delayed

这个算法体现一个折中。高敏信息默认不公开，但 KP 可以公开 redaction 来维持桌面参与。例如 A 读到日记时，全桌可以听见“A 读到一段让他脸色发白的记录”，但不能听见“祭坛在第三岔口”。这种叙述保留戏剧张力，也让其他玩家知道 A 的场景有进展，却不把 payload 交给不在场角色。

公共摘要（redaction）保留表象、情绪和节奏，移除可直接操作的地点、弱点、身份与具体机制。若完整内容是“地下室有陷阱，失败会掉进井中”，公开时可以说“地板结构让你觉得不安”，而不宜说“这里有个很危险的机关”；后者已经给出了过多战术信息。

降密

降密是信息从私有知识进入共享知识的过程。它必须由叙事动作触发。DIFC 中 declassification 由拥有相应权限的主体释放信息；转译到 TRPG 中，owner 角色通过复述、展示物证或通信释放信息 [myers1997]。常见触发包括角色口头复述、电话沟通、展示物证、转交手记、翻译完成、NPC 在公共场合说出同一事实、环境变化使事实变得可见。KP 不应默认“会合就自动共享全部私聊内容”。会合只是提供降密机会，不是自动降密。

Regroup(characters):
  for info in private_infos:
      if OwnerNarrates(info) or EvidenceShown(info) or TranslationCompleted(info):
          Declassify(info)
          AddToSharedKnowledge(info)
      else:
          KeepPrivate(info)

降密的粒度也可以部分化。A 可以告诉 B“下水道里有危险，先别乱走”，但不说“第三岔口和银钥匙”。此时 B 获得的是一个 1 级或 2 级摘要，而非完整 3 级 payload。KP 记录 partial declassification，可以防止后续争议。

Filter 层维护三个不变量。F1：敏感度不低于 2 的信息不得写入公共频道，除非满足降密条件。F2：玩家旁听不得自动扩展 owner 或 authorized audience。F3：若公共叙述必须提及私密事件，只能输出 public redaction，不输出 payload。

Coupling 层：同步强度选择

场景耦合度

Coupling 层把“这些场景是不是互相影响很大”转为一个可讨论评分。本文使用五个二值因素：共享线索链、共享倒计时、共享 NPC 或物品、物理邻近、即时伤害依赖。该评分的来源不是单一论文，而是三类文献的合并：HLA 强调联邦对象和时间管理，Maekawa 强调共同仲裁点，TRPG exchange 强调按行动机会同步 [ieee1516; maekawa1985; fateexchange]。耦合度定义为这些因素之和：

得分 0 到 1 为低耦合，适合 loose causal。得分 2 到 3 为中耦合，适合 investigation exchange。得分 4 到 5 为高耦合，适合 strict round 或 macro scene。这个评分不是自然法则，而是主持工具。若模组特点导致某个因素特别重要，KP 可以调整权重。

同步屏障

同步屏障是必须暂停局部推进并检查全局状态的节点。常见屏障包括共享倒计时推进、跨场景电话、同一 NPC 被两个分队接触、同一地点被两组角色同时进入、核心线索被一组发现且足以改变另一组行动空间、战斗或追逐开始。

NeedBarrier(scene_set):
  for each pair (sa, sb) in scene_set:
      if Coupling(sa, sb) >= 4:
          return true
      if SharedCountdownWillAdvance(sa, sb):
          return true
      if NewInfoChangesActionSpace(sa, sb):
          return true
      if CrossSceneCommunicationDeclared(sa, sb):
          return true
  return false

屏障不是暂停游戏的借口，而是减少 retcon 的保险。例如仪式倒计时从 23:30 推进到 23:45 时，所有相关场景都应更新。下水道中怪物苏醒，教堂壁画开始渗血，图书馆旧报纸上的墨迹也许出现变化。若某一组继续停留在旧时间窗，后续很容易出现“明明已经午夜，为什么这边还在傍晚”的矛盾。

Coupling 层维护三个不变量。C1：高耦合场景不得连续两个 exchange 不同步。C2：共享倒计时推进时，所有受影响场景必须同时更新 local window。C3：若两个场景共享同一关键资源，必须建立仲裁点。

协议运行流程

开团前准备

准备阶段只处理核心风险点，无须为模组中的每件物品建模。KP 先列出真相、地点、弱点、仪式步骤和秘密身份等关键线索，写明敏感度、初始所有者与降密条件；再为可能分队的地点建立 SceneCard，估算关键场景之间的耦合度。会前约定也应说清楚：可以分队，旁听可能发生，但角色行动必须有角色内的知识路径。

一张最小线索表如下：

一张最小耦合矩阵如下：

开团中循环

运行时循环如下：

RunInvestigation(scene_set):
  initialize SceneCards
  while not scenario_finished:
      mode = ChooseGlobalOrLocalMode(scene_set)
      for scene in SpotlightOrder(scene_set, mode):
          event = ResolveOneSignificantAction(scene)
          labels = LabelOutputs(event)
          for info in labels:
              channel = SelectChannel(info, current_audience)
              Deliver(info, channel)
          CommitEvent(event)
          UpdateLedger(scene, event, labels)
      if NeedBarrier(scene_set):
          ResolveBarrier(scene_set)
      RebalanceSpotlightDebt(scene_set)

这套循环用纸笔即可执行。每次处理当前镜头时，KP 只需确认：行动是否改变了线索、危险、位置、资源、NPC 态度或倒计时；若有改变，它产生了什么信息、应交给谁、是否已经提交、是否触发屏障；最后再看谁等待得太久。

角色行动验证

当玩家提出一个明显利用旁听信息的行动时，KP 不必直接指责玩家。更好的做法是执行 ValidateICAction：

ValidateICAction(action, character):
  required_infos = InferRequiredInfo(action)
  for info in required_infos:
      if info not in know(character):
          ask "你的角色如何知道这一点？"
          if no valid channel or inference path:
              reject action or downgrade to low-confidence guess

“拒绝”不是唯一结果。KP 可以把精准行动降级为模糊行动。B 不能直接去第三岔口，但可以说“我沿着金属摩擦声更明显的方向走”。D 不能说“NPC 是混血”，但可以说“我觉得他的档案有问题，想继续查”。这样既保护信息边界，也不把玩家的创造性全部堵死。

性质与证明思路

P1：未提交事实回滚安全

命题 P1：若 flashback 只修改 pending events，且所有 committed events 禁止被改写，则 flashback 不会破坏已公开因果链。该命题的来源是 BitD flashback 的补叙机制与 Jefferson virtual time 中 rollback 边界的合并转译 [bitdsrd; jefferson1985]。

证明思路如下。根据 CommitEvent，一个事件成为 committed 至少因为公共依赖、机械后果或降密中的一种。Schedule 不变量 S1 禁止改写 committed 事件。Flashback 只作用于 pending 区域。因此 flashback 可改变尚未被其他场景依赖的局部事实，但不能改变后续 committed 事件的前置事实。若 $E_i$ 已经被 $E_j$ 引用，则 $E_i$ committed 或应当在屏障检查中被提交。此时 flashback 不能撤销 $E_i$，因果链保持稳定。这里的“因果链”按 Lamport happened-before 理解，而不是按真实秒表理解 [lamport1978]。

失效条件也很明确。若 KP 忘记把公共叙述标记为 committed，或允许玩家在事后补出已经影响他人选择的电话，P1 就失效。因此协议的实际效果取决于 KP 是否认真标记事件提交，而不是伪码本身。

P2：高敏 payload 不进入公共频道

命题 P2：若所有敏感度不低于 2 的信息都经过 SelectChannel，且 Filter 不变量成立，则高敏 payload 不会进入 public channel，除非满足降密条件。该命题对应 Bell-LaPadula 的输出限制、Goguen-Meseguer 的 noninterference 和 DIFC 的 declassification [belllapadula1976; goguen1982; myers1997]。

证明思路如下。SelectChannel 对低敏信息允许 public。对高敏信息，它只允许四种结果：授权私发、降密后公开、redacted、delayed。F1 禁止未降密高敏信息直接写入公共频道。Redaction 只保留低敏表象，不包含 payload。因此公共频道最多获得情绪、异常感和非操作性摘要，不获得完整地点、弱点、身份或机制。

这个性质的主要风险来自 KP 自己的临场解释。很多泄露不是正式叙述，而是“你这个检定失败，所以你没看出他是怪物”之类解释。LIO 的 floating label 类比在这里有实际提醒：KP 刚处理完高敏内容后，回到公共频道应先过一遍 redaction [stefan2011]。

P3：高耦合场景不会长期漂移

命题 P3：若 Coupling 不低于 4 的场景遵守 C1 和 NeedBarrier，则两个高耦合场景最多相隔一个 exchange 就会同步。该命题综合 HLA 时间管理、Maekawa 共同仲裁点和 Fate exchange 的 spotlight 单位 [ieee1516; maekawa1985; fateexchange]。

证明思路如下。NeedBarrier 在 Coupling 不低于 4 时返回 true。运行循环在每轮 exchange 后检查 NeedBarrier。C1 又禁止高耦合场景连续两个 exchange 不同步。因此只要 KP 执行循环，高耦合场景的本地窗口不会长期分叉。该性质不保证所有低耦合场景都同步，因为低耦合场景并不需要高频同步。

失效条件主要是评分错误。如果一个场景实际上有共享倒计时和即时伤害依赖，KP 却把耦合度估为 1，协议不会自动救场。这说明耦合评分最好在团后复盘中校准。

P4：旁听不自动授权角色行动

命题 P4：若 $obs(u,t)$ 不自动写入 $know(p,t)$，且 ValidateICAction 使用 $know$ 而不是 $obs$，则旁听信息不会自动成为合法行动依据。该命题来自 noninterference 的可观察影响标准、DIFC 的授权读者模型和叙事规划中的角色意图可信度约束 [goguen1982; myers1997; riedlyoung2010]。

证明思路如下。模型中玩家观察和角色知识是不同集合。玩家旁听只更新 $obs$，不更新 $know$。角色行动验证只检查 $know$。若某行动所需信息不在 $know$ 中，玩家必须提供通信、感知、物证、复述或推理路径。若路径不存在，行动被拒绝或降级。因此旁听不能直接授权精准行动。

这个命题不要求玩家真的忘记旁听内容。它只要求行动层面可审计。这比心理层面的要求更现实，也更适合桌面游戏。

案例研究：图书馆、下水道与教堂

场景设定

设一局 CoC 调查进入最后一晚。A 在图书馆查日记。B 与 C 在下水道探索。D 在教堂解读壁画。仪式将在午夜完成。真相由三条线索拼接而成：日记给出地点，壁画给出触媒，下水道给出当前危险。若玩家分队，KP 面临典型三难：如果公开日记内容，B 和 C 可能直接使用地点；如果私聊 A，其他玩家可能等待过久；如果不记录时间，下水道队伍可能在 A 查完资料前已经越过关键地点。

Baseline 主持可能这样运行。KP 公开对 A 说：“你在日记中看到祭坛在下水道第三岔口，午夜前必须破坏银钥匙。”随后切到 B 和 C：“你们在下水道听到金属摩擦声，准备去哪？”B 的玩家说：“我们去第三岔口。”在桌面层面，这个回答很顺；在角色层面，它缺少知识路径。若 KP 允许，就产生未授权行动。

KTSL 主持轨迹

使用 KTSL 时，KP 先为 A 的发现建立 InfoLabel：

I02:
  payload: "祭坛在下水道第三岔口。"
  sensitivity: 3
  owners: [A]
  public_redaction: "A 读到一段和今晚地点有关的危险记录。"
  declassify_when:
    - A 通过电话告诉他人
    - A 会合后展示日记

公共频道中，KP 说：“A 翻到一段让他明显停顿的记录。那段内容和今晚的某个地点有关，我私发给 A。”然后私发 payload。切到 B 和 C 时，KP 说：“你们在下水道听到远处金属摩擦声，声音从更深处传来，但岔路很多。”B 若说“去第三岔口”，KP 执行 ValidateICAction，询问“你的角色怎么知道是第三岔口？”若 B 无法提供路径，KP 可以允许“朝声音更明显的方向探索”，但不允许精准选择第三岔口。

若 A 选择打电话，则产生 EventRecord：

E08:
  type: declassification
  from: A
  to: B
  info: I02
  channel: telephone
  happens_after: [E07]
  status: committed

此后 B 前往第三岔口合法。注意这里的关键不是禁止玩家使用聪明想法，而是要求聪明想法有角色内通道。电话、物证、复述都可以建立通道。旁听本身不可以。

时间同步处理

时间上，KP 把图书馆、下水道、教堂都置于 W2 时间窗。A 查日记消耗一个 exchange。B 和 C 聆听并选择方向消耗一个 exchange。D 解读壁画失败也消耗一个 exchange。每个 exchange 后，KP 检查屏障。若仪式倒计时推进到 23:30，则三个场景同时更新。若 D 解读出银钥匙信息，而 B 和 C 已接近第三岔口，教堂与下水道耦合度升高到 4，KP 应进入 strict round 或把场景合并为“仪式节点” macro scene。

这个案例展示 KTSL 的主要效果。它没有阻止公共戏剧张力，因为其他玩家仍知道 A 发现了重要内容。它没有强制所有人严格轮次，因为图书馆查资料和下水道探索在中耦合时仍可 exchange。它也没有让私聊无限延长，因为公共摘要给了全桌可见的情绪变化。最重要的是，它把“B 是否可以去第三岔口”从争吵变成了账本检查。

扩展案例：警署、医院与旧宅

案例动机

前一节案例以核心地点泄露为主。真实 CoC 调查中，泄露并不总是“地点答案”这么直接。更常见的是证词、医学证据和现场危险三类信息互相拼接。玩家可能没有听到完整真相，却听到足够多的碎片，从而让角色跳过调查过程。为了说明 KTSL 如何处理这种灰区，本节给出一个扩展案例。

设玩家分为三组。A 在警署查阅失踪案卷宗，并盘问值夜警员。B 在医院检查一具被水浸泡过的尸体。C 和 D 前往旧宅现场，那里有地下蓄水室和一个尚未关闭的暗门。模组真相是：失踪者并非在河边遇害，而是在旧宅地下被仪式水池淹死；值夜警员收过钱，改写了第一份报告；尸体肺部残留的泥沙成分来自旧宅地下水，而不是河水。

这一场景有三处潜在泄露。A 在警署发现“报告被改写”后，旁听者可能让旧宅中的 C、D 优先寻找被掩盖的现场；B 通过医学检定确认液体“不是河水”后，A 的玩家可能让角色直接质问警员伪造报告；C、D 若在旧宅发现暗门危险，过细的公开描述又可能促使 A、B 无理由赶来支援。这里没有单一地点答案，而是多条中、高敏信息的交织。

标签与耦合

KP 在准备阶段可以写下四条信息。I10：第一份警署报告被改写，敏感度 2，owner 初始为空，由 A 盘问或查档获得。I11：尸体肺部泥沙来自旧宅地下水，敏感度 3，owner 初始为空，由 B 医学检定获得。I12：旧宅地下暗门仍可开启，敏感度 2，owner 初始为空，由 C 和 D 现场搜索获得。I13：值夜警员收钱的对象与旧宅产权人有关，敏感度 3，owner 初始为空，由 A 深入盘问或查财务记录获得。

警署与医院共享线索链，但没有即时伤害，耦合度约为 2，适合 investigation exchange。医院与旧宅共享物证来源，且旧宅存在即时危险，耦合度约为 3。警署与旧宅共享嫌疑人和地点，若 A 得到产权人线索，耦合度可升至 3。若 C 和 D 打开暗门并触发蓄水室危险，旧宅与其他场景的耦合度应升高，因为支援是否来得及成为时间问题。

这个案例显示耦合度不是固定值。它会随信息发现而变化。开场时警署和旧宅只是弱相关；一旦 A 查到产权人，C 和 D 的旧宅探索就变成直接相关。KP 应允许 Coupling 动态更新，而不是只在开团前打一次分。

运行轨迹

第一轮 exchange，A 查卷宗，KP 公开摘要：“A 注意到卷宗页码有一处不连续，像是后来重新装订过。”私下告诉 A：第一份报告的时间和地点描述被改写。此时 I10 owner 为 A。B 检查尸体，若检定成功，KP 私下告诉 B：肺部泥沙不像河泥，更像封闭地下水池沉积物。此时 I11 owner 为 B。C 和 D 到达旧宅，KP 公开描述：“房子比预想中潮，木地板下有空响。”这只是 1 级氛围，公共可见。

第二轮 exchange，A 若立刻打电话给 C 和 D，说“旧宅可能才是第一现场”，则 I10 部分降密给 C 和 D。C 和 D 因此搜索地下结构是合法行动。若 A 没有通信，C 和 D 仍可基于木地板空响调查，但不能因为玩家听见卷宗问题就直接寻找“被掩盖的第一现场”。B 若把医学发现发给 A，A 可以在盘问警员时质问河水说法；若 B 没有通信，A 只能基于卷宗页码问题追问报告是否完整。

第三轮 exchange，C 和 D 发现暗门。KP 不应在公共频道说“你们找到通往仪式水池的门”。更合适的 redaction 是：“C 和 D 在地板下找到一处潮湿的结构，里面有一股让人不舒服的水腥味。”具体 payload 私发给 C 和 D。若 C 和 D 呼叫支援，则暗门信息降密给接收者。若他们不呼叫，A 和 B 即使玩家听见公共摘要，也不能直接以“旧宅地下有水池”为理由改变行动。

灰区处理

这个案例的难点是推理链。A 知道报告被改写，B 知道不是河水，C 和 D 知道旧宅潮湿。任何单条信息都不等于真相，但组合起来足以指向旧宅地下水池。若玩家在会合前用公共旁听把三条线索拼起来，角色是否也能拼起来？答案取决于信息是否已经降密。若 A、B、C、D 没有通信，玩家可以在作者层面理解，但角色层面仍是分散知识。若其中两组通过电话交换了摘要，接收者可拥有部分组合推理。

KP 可以允许“低置信猜测”。例如 A 没有收到 B 的医学结论，但他根据卷宗被改写和旧宅产权人可疑，决定派人去旧宅，这可能合法。A 不能说“尸体不是河水淹死的”，因为他没有医学证据；但他可以说“报告可能遮掩了真正地点”。这种处理比简单允许或禁止更细。它让玩家推理有空间，也让证据边界保持清楚。

案例结论

扩展案例说明，KTSL 不只处理“一个秘密答案被旁听”的简单泄露。它也能处理多线索拼接、部分降密、低置信猜测和动态耦合。现实跑团中，许多争议来自这些灰区。协议的作用不是把灰区消灭，而是把灰区拆成可以讨论的对象：哪条信息被谁知道，哪条信息只是玩家听见，哪条推理可以由角色已有证据支持，哪条推理需要等待通信或会合。

可复现评估与 transcript 审计

研究假设与判定标准

本文提出三个可测试假设。H1：相比经验主持，使用 Schedule 层会降低因果违反次数和 retcon 次数。H2：相比只使用 Schedule 层，加入 Filter 层会降低未授权行动次数和公共高敏泄露次数。H3：加入 Coupling 层后，spotlight 最大等待时间不会显著恶化，且高耦合场景的时间漂移减少。

这些假设现在按两层证据处理。第一层是本文已经完成的确定性 fixture 消融：用固定事件、信息标签和耦合边检查协议对象是否产生预期差异。第二层是后续 transcript 审计：选择同一段 60 至 90 分钟的调查片段，分别在 Baseline、Schedule-only 和 KTSL-full 三种条件下运行。每次运行录音或文字记录，事后由不参与跑团的标注者根据统一规则编码。

指标

标注时需要保留上下文。一个行动是否未授权，不能只看玩家是否说出关键词，而要看角色是否有合法路径。例如 B 说“我去第三岔口”，若 A 已打电话，则合法；若 A 没有通信，且 B 没有其他线索，则记为未授权。一个公共 payload 是否泄露，也要看降密条件是否已满足。

对照条件与消融设计

Baseline 条件只使用主持人的常规切镜经验，不建立显式账本；Schedule-only 使用 SceneCard、EventRecord 与同步屏障，但不使用 InfoLabel；KTSL-full 同时启用三层。确定性测试还把 Schedule、Filter、Coupling 展开为八种开关组合，以分离各层修复的错误类型。只有在真实跑团记录中，KTSL-full 相比 Baseline 降低因果违反、未授权行动和公共高敏泄露，同时没有明显抬高 Spotlight Max Gap，协议才获得经验层面的支持。

该实验不需要复杂设备。一个共享表格、录音转写和两名标注者即可开始。为了避免 KP 个人风格造成偏差，后续应在不同 KP、不同玩家熟悉度、线上和线下环境中重复。若结果显示协议降低泄露但显著增加等待时间，则需要改进 redaction 和 spotlight debt 机制。若结果显示协议负担过重，则需要开发简化表或平台插件。

确定性 fixture 结果

协议机制先在两个受控测试用例上检查：library_sewer_church 与 police_station_hospital_old_house，分别对应前文的两个纸面案例。每个测试用例都包含事件提交顺序、敏感信息标签和高耦合场景边。评估脚本穷举 Schedule、Filter、Coupling 的开关组合，得到 none、S、F、C、S+F、S+C、F+C 和 S+F+C 八种条件。原始输出位于 experiments/ktsl-ablation-20260705/results/ablation-results.json 及同目录 CSV；这些结果是确定性模拟检查，不是跑团记录或盲审标注。

表 tab:ktsl-ablation 汇总两个 fixture 的 aggregate 指标。H1 的判定比较 none 与 S，H2 比较 S 与 S+F，H3 比较 S+F 与 S+F+C。在两个 fixture 上三项假设均通过，分别为 H1 $2/2$、H2 $2/2$、H3 $2/2$。

KTSL 确定性 fixture 三层消融汇总。因果、未授权、泄露、漂移和等待为两个 fixture 的总和；降密为两个 fixture 的均值。

消融结果支持三层拆分，而不是只支持“多记一点账”。Schedule 从 none 到 S 将因果违反从 2 降为 0，但未授权行动和公共泄露仍为 4，说明单靠时间屏障不能解决信息边界。Filter 从 S 到 S+F 将未授权与泄露合计从 4 降为 0，并把降密完整度从 0.00 提高到 1.00，但高耦合漂移仍为 6，说明信息标签不能替代时间同步。Coupling 从 S+F 到 S+F+C 将高耦合漂移从 6 降为 0，且 Spotlight Max Gap 保持 0，说明同步层在这两个 fixture 上没有造成额外镜头空窗。

该结果也暴露了边界。Retcon Count 在所有条件下均为 0，因此 H1 中关于 retcon 的部分尚未被当前 fixture 检验；它需要包含显式回滚事件的新 fixture 或真实 transcript。Barrier Wait 从 0 增至 4，说明 Schedule 的收益伴随等待成本。当前两个 fixture 的 Gap 均为 0，因此只能说明 Coupling 在这些案例中没有恶化 gap，不能证明所有桌面都不会增加等待。后续 transcript 实验仍需由独立标注者检查真实发言、私聊、会合和降密过程。

审计表

评估标注手册

标注单位

若要验证 KTSL，首先需要规定标注单位。本文建议以“可结算行动”为基本单位，而不是以自然语言句子为单位。一个玩家可能用三句话描述同一个行动，也可能一句话里包含移动、观察、交流和检定。标注者应把它拆成若干可结算行动：角色移动到哪里，尝试取得什么信息，是否把信息传给他人，是否使用某条已经获得或未获得的线索。

每个行动要连同四类上下文一起标注：当时角色的 $know$、玩家可能从公共频道获得的 $obs$、行动成功所需的信息，以及两者之间是否存在合法桥接路径。同场感知、既有线索推理、他人复述、电话或纸条、证据展示、NPC 公开说明和 KP 明确降密都可构成桥接。即使行动表面上像是利用了旁听，只要角色能从已知线索合理推得，就不应记为泄露。

例如，B 说“我去第三岔口”时，标注者不能只看 B 是否说出了“第三岔口”。若 B 之前听到金属摩擦声来自右侧，又在地图上看到第三岔口恰好是右侧唯一通路，那么这可能是合法推理。若 B 唯一来源是玩家刚听见 A 的私密线索，则记为未授权行动。这个差别很重要。协议不是要限制玩家推理，而是要限制无路径的精准使用。

因果违反标注

因果违反包括前置未满足、时间窗不相容和共享状态分叉。B 声称收到一通从未发生的电话，属于前置缺失；A 在 23:50 才发现仪式地点，B 却在 23:30 已据此抵达，属于时间窗冲突；下水道已经听见仪式钟声，图书馆仍按钟声前状态处理，则是共享状态分叉。

标注时应避免把所有叙事模糊都判为错误。CoC 本来允许“过了一会儿”“与此同时”这样的叙述。只有当模糊造成角色行动、危险状态或线索链矛盾时，才计入因果违反。若一个时间差不影响任何结算，可记录为“模糊但无害”，不计入主要指标。这样能防止评估把自然叙事误伤为缺陷。

建议每条因果违反记录五列：事件编号、被引用前置、当前证据、违反类型、修复方式。修复方式包括补通信、回滚 pending 事件、公开 retcon、调整时间窗或拒绝行动。若修复需要改写 committed 事件，则同时计入 Retcon Count。若只是在 pending 区补一句“你刚才确实拨出了电话，但信号很差”，可以计为轻微修正，不必算作严重 retcon。

信息泄露标注

信息泄露分为公共核心内容泄露、未授权行动和暗示性泄露。前者是未满足降密条件时，KP 在公共频道说出敏感度不低于 2 的内容；未授权行动指角色使用不在 $know$ 中的信息并获得优势；暗示性泄露则来自检定名称、NPC 反应或过度具体的失败描述。例如“你没有看出他是深潜者混血”虽然以失败作答，实际已经公开了目标身份。

暗示性泄露最难标注。本文建议采用保守原则：只有当暗示能让未授权角色显著缩小行动空间时，才计入。例如“你觉得这个人有点怪”通常只是低敏氛围，不计泄露；“你觉得他的血统不像普通人类”已经接近身份 payload，应计为中高风险。若两个标注者意见不一致，可记录为 ambiguous，并在统计中单独报告。

泄露标注还要区分听见和使用。玩家听见高敏信息，但后续没有任何相关行动，公共 payload 泄露仍然成立，因为 KP 已把信息放进公共频道；未授权行动不成立，因为角色没有使用它。反过来，KP 没有公开 payload，但玩家通过屏幕共享、私聊误发或其他方式获得并使用，也应记为未授权行动。两个指标测量的是不同风险。

Spotlight 与等待成本标注

Spotlight Max Gap 测量玩家两次获得实质镜头之间的最大间隔。实质镜头不是 KP 叫名字，也不是一句“你还在等”，而是玩家获得选择、叙述、检定或角色表达机会。若 KP 对某玩家说“你继续在门外等”，且玩家没有新的选择，这不算实质镜头。若 KP 说“你听见门内争吵升级，现在可以冲进去、继续听、找后门或给别人打电话”，这算实质镜头。

等待成本需要和保密机制一起分析。若 KTSL-full 降低了泄露，却让某玩家最大等待从 8 分钟变成 25 分钟，那么协议并不算成功。此时应检查私聊是否过长，公共 redaction 是否太少，低耦合场景是否被不必要地搁置。好的 Filter 层不只是藏信息，也要提供低敏公开材料，让未参与私聊的玩家仍能理解节奏。

建议记录平均等待、最大等待和等待方差。最大等待能捕捉最糟体验，平均等待能反映整体节奏，方差能反映 spotlight 是否集中在少数玩家。对于恐怖场景，少量刻意等待可以增强张力，但这种等待应伴随明确的叙事状态，而不是让玩家离开桌面。

实施路线与主持细则

纸笔实现

最小纸笔实现只需要一张 A4 纸。左侧写场景卡，每个场景一行：地点、角色、时间窗、当前模式、pending、committed。右侧写信息卡，每条核心线索一行：ID、payload 摘要、敏感度、owner、公开摘要、降密条件。底部写屏障：倒计时、共享 NPC、共享物、跨场通信。KP 每次切镜只更新一到两格。

纸笔实现的优点是低门槛，缺点是修改和检索不方便。它适合线下短团和一次性模组。为了降低负担，KP 可以只给敏感度 3 的线索建标签。敏感度 2 的战术信息若临场出现，再用铅笔补。敏感度 0 和 1 的氛围信息不进入表格，只在叙述中处理。

一个实用技巧是使用颜色。红色表示敏感度 3，橙色表示敏感度 2，蓝色表示公共或已降密，灰色表示 pending。颜色不是为了漂亮，而是为了让 KP 在紧张场景中快速看见“哪些东西不能公开说”。如果 KP 容易在解释检定时说漏，红色标记尤其有用。

电子表格实现

电子表格适合线上团。一个工作簿可包含四个 sheet：Scenes、Events、Info、Audit。Scenes 记录 SceneCard。Events 记录 EventRecord。Info 记录 InfoLabel。Audit 在团后标注因果违反和泄露。若使用 Google Sheets 或本地表格，还可以用筛选器查看“所有未降密高敏线索”或“所有 pending 事件”。

电子表格的风险是 KP 可能被界面吸走注意力。解决方法是把运行时字段压到最少。运行中只改 scene window、pending event、info owner、declassified 这几个字段。复杂审计留到团后。若 KP 在跑团中不断整理表格，玩家会感到节奏变慢。协议服务叙事，不应抢叙事的镜头。

电子表格还可以支持自动检查。比如若某条 sensitivity 为 3 的信息被标为 public，但 declassified 为 false，表格可以高亮。若某个 high coupling 场景连续两个 exchange 没同步，表格可以提示。本文没有实现该工具，但数据对象已经为这种实现留出接口。

VTT 与聊天机器人实现

在线跑团平台或聊天机器人可以把 KTSL 做成半自动工具。KP 给线索添加标签，机器人根据授权受众自动选择私聊或公共摘要。玩家会合时，KP 点击“降密”，机器人把某条信息加入 shared knowledge。玩家声明行动时，机器人可以显示该角色当前 know 集合，帮助 KP 判断是否需要询问知识路径。

这种实现要避免过度自动化。机器人不应替 KP 判断“这个推理是否合理”，因为合理性依赖角色背景、玩家表演和现场语境。机器人更适合做记忆辅助：提醒哪些信息未降密，哪些事件 pending，哪些场景高耦合。最终裁量仍由 KP 做出。

隐私也需要注意。若工具保存私聊 payload，应明确存储位置和访问权限。对于录播或公开团，未公开线索可能涉及剧透。工具应允许会后导出删减版 transcript，把高敏 payload 替换为 redaction。这样既便于复盘，又不泄露模组核心内容。

KP 语言细则

协议最终要落到主持语言。公共摘要用角色可见的表象替代真相，例如说“档案有一页被撕掉”，而不是“档案隐藏了深潜者血统”；用情绪反应替代机制，例如“A 读完后沉默了一会儿”，而不是“A 发现了怪物弱点”；用风险方向替代精确解法，例如“继续深入可能来不及回头”，而不是“午夜前必须破坏银钥匙”。摘要还应保留选择，不能只用“你不知道”封死行动。

ValidateICAction 的语言也要温和。推荐句式是“这一步需要你的角色知道 X。你觉得他是从哪里推出来的？”而不是“你这是 metagame”。前者邀请玩家补角色推理，后者容易让玩家防御。若玩家给出一个勉强但有趣的解释，KP 可以允许低置信行动，并提高风险。这样既保护边界，也保留桌面的创造性。

对于新玩家，KP 应在开团前给一个例子。比如“如果你听见另一个场景里有怪物弱点，你本人知道，但角色不知道。你可以让角色害怕、犹豫、寻找证据，但不能直接冲去使用弱点，除非有人告诉你或你自己发现。”这个说明比抽象谈 IC/OOC 更有效。

反例与边界案例

低秘密密度场景

并非所有分队都需要 KTSL。若队伍只是在城市中分头采购装备、打听普通传闻、寻找住宿，且没有共享倒计时和核心秘密，完整标签会显得笨重。此时 loose causal 足够。KP 只需记录大致时间和重要花费，不必为每条普通传闻写 InfoLabel。若协议在低秘密密度场景中造成明显拖慢，就说明使用范围过宽。

KTSL 应当选择性启用。分队、秘密、倒计时与共享资源同时出现时，可以进入“高风险模式”；日常采购、普通传闻和低耦合探索则关闭或简化。工具的存在不构成处处使用它的理由。

玩家共同作者视角

某些叙事游戏鼓励玩家从共同作者角度参与故事。玩家知道角色不知道的信息，并故意演出戏剧性误解。在这种桌面文化下，严格防泄露可能削弱乐趣。若玩家和 KP 已明确采用作者视角，KTSL 的 Filter 层应放松，重点转向 Schedule 和 spotlight。也就是说，角色知识边界是桌面契约的一部分，不是所有游戏的普遍义务。

CoC 通常更依赖未知和调查推理，因此本文选择较严格的知识边界。但即便在 CoC 中，也有队伍喜欢公开旁听，只要求玩家自觉。对这类队伍，KTSL 可以作为团后复盘工具，而不是运行时强规则。若出现争议，再用 InfoLabel 回看“这条线索当时是否已降密”。

高信任老玩家桌

一桌高信任老玩家可能几乎不需要显式验证。玩家会主动说“我本人知道，但角色不知道，所以我先不行动”。这种桌面仍可能受益于 Schedule 层，因为时间错位和共享倒计时不是只靠自觉能解决的。Filter 层则可简化为核心线索清单，不必频繁询问。

三层可以独立调节：高信任桌保留强 Schedule、简化 Filter；陌生线上团加强 Filter 与 Coupling；低风险轻松团甚至只使用 Coupling 的切镜提醒。KTSL 不是单一开关，而是一组可组合的主持约束。

故意误导与红鲱鱼

CoC 模组常有红鲱鱼。若某条线索本身是误导，它也可能是高敏信息，因为它会改变行动。InfoLabel 不要求 payload 必须为真。它只要求 payload 有行动价值。一个错误的 NPC 供词、一本伪造日记、一张伪地图，都可以是 sensitivity 2 或 3。降密它们不会破坏协议，因为协议管的是角色如何获得信息，不管信息是否真实。

这点对推理公平很重要。若 A 私下得到一条伪线索，并选择不告诉他人，其他角色不能因玩家旁听而避开错误路线。否则红鲱鱼失去意义。Filter 层保护的不只是正确答案，也保护角色被误导的权利。

角色间秘密与玩家安全

有些秘密不只是剧情信息，也可能涉及玩家安全工具。例如角色背叛、恐怖描写边界、个人触发内容。本文的 InfoLabel 可以记录叙事保密，但不应替代安全工具。若内容涉及玩家不适，X-card、lines and veils、暂停机制和会前沟通优先于协议保密。KP 不应以“防泄露”为理由向玩家隐藏可能越界的现实内容。

因此，KTSL 的安全性是叙事安全和信息边界意义上的安全，不是心理安全工具。两者有交集，但不能混为一谈。正式使用协议时，应在 session contract 中说明：玩家安全高于剧情秘密。

讨论

协议成本

KTSL 的主要成本是记账。若所有物件、台词和气氛细节都打标签，表格会反过来拖垮主持。实际只需标注三类对象：真相、地点、弱点、秘密身份和仪式步骤等核心线索；倒计时、追逐、怪物行动与共享 NPC 等共同风险；以及一旦知晓便会改变最优行动的高收益决策点。其余低敏叙述继续沿用常规主持。

实际执行中，KP 可以使用极简版本。每条高敏线索只写四列：payload、owner、公开摘要、降密条件。每个场景只写三列：当前时间窗、pending 事件、是否触发屏障。耦合度也可以用低、中、高三档，而非五项评分。协议的价值不在格式复杂，而在让关键边界可见。

玩家体验

防泄露协议如果执行得像审讯，会破坏桌面信任。KP 在询问“你的角色怎么知道”时，应把它作为角色扮演邀请，而不是惩罚。玩家也许能给出合理路径：“我记得刚才报纸说下水道西段关闭，而金属声从东边来，所以我想走东边。”这不是泄露，而是推理。协议应保护这种推理，而不是压制它。

公共 redaction 也需要写得有戏。过度干瘪的摘要会让其他玩家无事可做。好的公共摘要保留情绪、节奏和选择信号，却不泄露核心内容。例如，“他的表情变了，像是读到什么会让今晚变得更糟的东西”比“这里有一条私密线索”更适合 CoC。描述应落到可感的表象上，避免用模板句替代现场叙事。

与严格轮次的关系

KTSL 并不反对严格轮次。它反对把严格轮次当作所有时间问题的默认答案。严格轮次适合共享危险、共享资源和即时反应，却不适合所有调查。若 A 在翻报纸，B 在买装备，C 在街上问路，把三人都拉进六秒轮次只会增加噪音。耦合度的作用正是让 KP 知道什么时候该放松，什么时候该收紧。

与纯叙事信任的关系

有些桌面文化强调作者视角共享，玩家可以知道很多角色不知道的信息，并自觉演出不知道。对这类桌面，KTSL 的强信息边界可能显得多余。本文不是要否定这种玩法，而是服务另一类需求：秘密密度高、调查推理强、玩家容易因旁听改变选择、KP 希望可复盘的 CoC 场景。协议应服务桌面契约，而不是凌驾于桌面契约。

威胁与局限

理论迁移存在明确边界。分布式系统的进程没有情绪、审美和角色动机，TRPG 玩家也不会像机器一样执行协议。Lamport、信息流控制和分布式仿真在本文中只提供结构概念；若把 KTSL 当成机械规则，结果可能适得其反。

证据强度也不均衡。Lamport、Goguen–Meseguer、Bell–LaPadula、Myers–Liskov、LIO、Dwork、Yao 与 Riedl–Young 可以支撑核心概念转译；Cristian 和 Rubinstein 只作弱类比。CoC Quick-Start 足以说明 Keeper 流程与模糊战斗轮次，正式投稿前仍应在合法条件下核对更完整的核心规则。

外部效度目前仍然有限。H1—H3 的支持来自两个受控测试用例和三层消融，不来自真实跑团记录。结果能检查协议对象是否按预期工作，却不能替代多 KP、多玩家与盲审标注。真实桌面还可能出现反向代价：信息标签减少泄露，却延长了等待；若发生这种情况，协议需要调整，不能把代价重新解释成成功。

执行者效应可能很大。熟练 KP 也许只增加少量负担，新 KP 却可能被表格分散注意；熟悉的玩家更容易自觉区分 IC 与 OOC，新玩家则需要明确提示。后续评估必须记录 KP 经验、玩家熟悉度、模组秘密密度以及线上或线下环境。

协议还会改变游戏风格。显式标签、行动验证与降密记录会让桌面更偏向审计；有人因此感到公平，也有人会觉得沉浸受损。因此，KTSL 应作为可调工具，而不是默认全开的规则。

与相邻方法的差异

KTSL 并非新的战斗轮次。D&D 的 round、Fate 的 exchange、CoC 的 Keeper 裁量和 BitD 的 flashback 分别解决顺序、行动机会、主持弹性与补叙问题 [dndbasic2018; fateexchange; cocquickstart; bitdsrd]；KTSL 关注的是这些机制之间尚未覆盖的交界：分队调查中的模糊时间窗、角色知识边界与同步强度如何由同一份账本协调。

分布式时间、仿真和互斥文献为账本提供了因果偏序、局部进程、回滚边界与仲裁点等语言 [lamport1978; chandymisra1979; jefferson1985; ricart1981; maekawa1985; ieee1516]。这些概念只被用来约束主持流程。场景不是计算进程，角色通信也不是网络消息；KTSL 追求的是叙事上可解释的先后，而非算法上的最优通信复杂度。

信息流控制与叙事规划共同限定了 Filter 层。一方面，InfoLabel、授权受众和降密条件借鉴 noninterference、Bell–LaPadula、DIFC 与 LIO [goguen1982; belllapadula1976; myers1997; stefan2011]；另一方面，角色行动还需要符合其知识和动机 [riedlyoung2010]。因此，协议既不把防泄露简化成集合权限，也不把“我只是猜的”自动当作充分解释。

结论

KTSL 把 CoC 分队调查中的两类主持负担放进同一份运行时账本：Schedule 层维护事件因果、同步屏障和提交边界，Filter 层维护信息敏感度、授权受众与降密条件，Coupling 层根据场景依赖选择松散叙事、调查交换、严格轮次或场景合并。

它建立在一个简单判断上：调查中的时间一致性主要是因果问题，信息隔离主要是授权传播问题。KP 不必精确记录每一分钟，也不必把所有私密内容移出公共频道；需要显式记录的，是会改变行动空间的事件、线索、共享风险和不可回滚事实。

两个确定性测试用例的消融结果表明，三层机制在受控案例中分别消除了预先定义的因果违反、未授权信息影响和高耦合时间漂移。这个结论仍停留在机制层面。下一步应按本文的标注手册收集真实或近真实跑团记录，比较 Baseline、Schedule-only、Schedule+Filter 与 KTSL-full，并据此校准耦合阈值、公共摘要规则和执行成本。若外部数据仍支持这些假设，KTSL 才有资格进一步发展为一页式 KP 工具、电子表格模板或跑团平台插件。

附录

一页式 KP 执行清单

开团前，KP 先列出核心线索。每条线索写四件事：谁最初能知道，敏感度是多少，公共摘要怎么说，怎样降密。然后列出可能分队的场景，给每对关键场景标低、中、高耦合。最后告诉玩家：分队允许，旁听也许会发生，但角色行动需要角色内依据。

开团中，每次只处理一个显著行动。行动产生线索时先写 InfoLabel，再选择输出通道。切镜前检查 SceneCard：共享倒计时是否推进、是否发生通信、高耦合场景是否连续漂移、是否有人太久没有镜头。高敏信息只私发具体内容，公共频道使用摘要。

会合时，不要自动把所有私聊同步给全队。让角色复述、展示物证或转交笔记。复述到什么程度，就降密到什么程度。若玩家尝试使用旁听信息，问“你的角色怎么知道”。如果能给出合理路径，允许；如果不能，降级为模糊行动或拒绝精准行动。

团后复盘只看三类问题：时间矛盾、未授权行动和公共高敏泄露。泄露若主要来自 KP 的公开叙述，应调整敏感度或重写公共摘要；若来自玩家行动，则加强 ValidateICAction；等待过长时，缩短私聊并增加低敏公开内容。

最小数据模板

SceneCard:
  scene_id:
  local_window:
  participants:
  mode:
  pending_events:
  committed_events:
  public_view:
  private_facts:
  barriers:

EventRecord:
  id:
  scene:
  actors:
  action:
  happens_after:
  outputs:
  status:
  commit_reason:

InfoLabel:
  id:
  source_event:
  sensitivity:
  owners:
  authorized_audience:
  payload:
  public_redaction:
  declassify_when:

SceneCoupling:
  pair:
  shared_clue_chain:
  shared_countdown:
  shared_npc_or_object:
  physical_proximity:
  immediate_harm_dependency:
  score:
  recommended_mode:

证据等级索引

参考文献

• cocquickstart: Call of Cthulhu Quickstart Rules, 2026. https://chaosium.itch.io/call-of-cthulhu-quickstart-rules
• cocpdf: Call of Cthulhu 7th Edition Quick-Start Rules, 2014. https://www.fullasagoog.com/uploads/short-url/oTeMcZZrw4u3OOYgrpP0y3lZi2W.pdf
• dndbasic2018: Dungeons & Dragons Basic Rules, 2018. https://media.wizards.com/2018/dnd/downloads/DnD\_BasicRules\_2018.pdf
• fateexchange: Fate Core SRD: The Exchange, 2026. https://fate-srd.com/fate-core/exchange
• bitdsrd: Blades in the Dark SRD, 2026. https://raw.githubusercontent.com/amazingrando/blades-in-the-dark-srd-content/master/Blades-in-the-Dark-SRD.md
• rpgsplit: How do I keep a party together without railroading?, 2018. https://rpg.stackexchange.com/questions/113268/how-do-i-keep-a-party-together-without-railroading
• rpgmeta: How to prevent players from metagaming when they split the party?, 2016. https://rpg.stackexchange.com/questions/80118/how-to-prevent-players-from-metagaming-when-they-split-the-party
• lamport1978: Time, Clocks, and the Ordering of Events in a Distributed System. Communications of the ACM, 1978. https://lamport.azurewebsites.net/pubs/time-clocks.pdf
• ricart1981: An Optimal Algorithm for Mutual Exclusion in Computer Networks. Communications of the ACM, 1981. https://dl.acm.org/doi/10.1145/358527.358537
• ricartmirror: An Optimal Algorithm for Mutual Exclusion in Computer Networks, readable mirror, 1981. https://scispace.com/pdf/an-optimal-algorithm-for-mutual-exclusion-in-computer-lq856cslpa.pdf
• maekawa1985: A sqrt(N) Algorithm for Mutual Exclusion in Decentralized Systems. ACM Transactions on Computer Systems, 1985. https://dl.acm.org/doi/10.1145/214438.214445
• maekawamirror: A sqrt(N) Algorithm for Mutual Exclusion in Decentralized Systems, readable mirror, 1985. https://scispace.com/pdf/a-n-algorithm-for-mutual-exclusion-in-decentralized-systems-22c8zeohdp.pdf
• chandymisra1979: Distributed Simulation: A Case Study in Design and Verification of Distributed Programs. IEEE Transactions on Software Engineering, 1979. https://gdo-pdes-course-2014.llnl.gov/attachments/20776356/20906700.pdf
• jefferson1985: Virtual Time. ACM Transactions on Programming Languages and Systems, 1985. https://worrydream.com/refs/Jefferson\_1985\_-\_Virtual\_Time.pdf
• cristian1989springer: Probabilistic Clock Synchronization. Distributed Computing, 1989. https://link.springer.com/article/10.1007/BF01784024
• cristian1989ibm: Probabilistic Clock Synchronization, 1989. https://research.ibm.com/publications/probabilistic-clock-synchronization
• ieee1516: IEEE 1516-2025: Standard for Modeling and Simulation High Level Architecture, 2025. https://standards.ieee.org/ieee/1516/6687/
• rubinstein1982: Perfect Equilibrium in a Bargaining Model. Econometrica, 1982. https://arielrubinstein.tau.ac.il/papers/11.pdf
• goguen1982: Security Policies and Security Models. Proceedings of the 1982 IEEE Symposium on Security and Privacy, 1982. https://www.cs.purdue.edu/homes/ninghui/readings/AccessControl/goguen\_meseguer\_82.pdf
• belllapadula1976: Secure Computer System: Unified Exposition and Multics Interpretation. The MITRE Corporation, 1976. https://csrc.nist.gov/files/pubs/conference/1998/10/08/proceedings-of-the-21st-nissc-1998/final/docs/early-cs-papers/bell76.pdf
• myers1997: A Decentralized Model for Information Flow Control. Proceedings of the Sixteenth ACM Symposium on Operating Systems Principles, 1997. https://www.cs.utexas.edu/~witchel/380L/papers/myers97sosp-iflow.pdf
• stefan2011: Flexible Dynamic Information Flow Control in Haskell. Proceedings of the 4th ACM Symposium on Haskell, 2011. https://www.scs.stanford.edu/~dm/home/papers/stefan%3Alio.pdf
• dwork2006: Calibrating Noise to Sensitivity in Private Data Analysis. Theory of Cryptography, Third Theory of Cryptography Conference, TCC 2006, 2006. https://people.csail.mit.edu/asmith/PS/sensitivity-tcc-final.pdf
• yao1986: How to Generate and Exchange Secrets. Proceedings of the 27th Annual Symposium on Foundations of Computer Science, 1986. https://mit6875.github.io/FA23HANDOUTS/yao-garbled-circuits.pdf
• riedlyoung2010: Narrative Planning: Balancing Plot and Character. Journal of Artificial Intelligence Research, 2010. https://faculty.cc.gatech.edu/~riedl/pubs/jair.pdf