如何防止 AI 角色对话在解谜游戏中捏造线索

为什么捏造的线索会破坏解谜游戏

在解谜游戏中，玩家收集信息、得出结论，并利用所学知识去寻找更多信息。这使得线索与玩家认知之间的关系成为游戏核心循环的一部分，而不仅仅是对话风格的细节。如果一个角色言之凿凿地提及一封尚未放置的信件，或者报出一个玩家从未遇到过的人名，就可能在无意中制造出一条全新的线索。玩家根本无法可靠地判断该细节是精心设计的线索、故意的谎言，还是生成的无意义填充物。论文《生成式取证：程序化生成与信息游戏》（Generative Forensics: Procedural Generation and Information Games）将信息游戏描述为收集知识并利用知识理解谜题的过程；套用这一框架，未受追踪的生成陈述会混淆玩家据以进行推理的既有认知。

解决之道始于明确的区分：线索是玩家可以据此采取行动的游戏事实；风味文本则是富有表现力但不增加或改变游戏事实的对话。角色的语气可以犹豫不决、闪烁其词、幽默或生动，但绝不能仅仅因为一句台词措辞极具说服力就将其视为证据。

在生成对话前创建由作者预设的线索记录

为每一条可操作的线索维护一份小巧而明确的记录。它可以保存在数据库、内容文件或叙事工具中；关键在于模型不能凭空捏造其内容。记录中包含的字段应能回答该线索的内容是什么、来自哪里、谁可以知晓，以及何时变为可用。

字段：clue_id；记录内容：证据的稳定标识符；示例（说明性质）：note_blue_01

字段：canonical_fact；记录内容：游戏确立的事实；示例（说明性质）：“便条署名带有首字母 M。”

字段：source_id；记录内容：支持该事实的作者预设对象、场景或台词；示例（说明性质）：archive_note_03

字段：discovery_condition；记录内容：允许讨论前所需达到的游戏状态；示例（说明性质）：found_archive_note_03

字段：allowed_speakers；记录内容：允许知晓或讨论该线索的角色；示例（说明性质）：Mara, Ivo

字段：certainty；记录内容：该来源陈述的是既定事实还是仅暗示了一种推论；示例（说明性质）：explicit

字段：player_facing_label；记录内容：该证据在日志中的显示名称（若适用）；示例（说明性质）：“未署名的便条”

上述名称和取值只是用于展示格式的虚构示例，并非针对任何特定游戏的主张。请注意，该记录将来源的明确内容与推论进行了区分：署名首字母本身并不能证明便条是谁写的。这种区分为对话系统留出了空间，允许角色进行推测，而不会将这种推测呈现为最新证实的证据。

通过发现状态而非单纯对话来限制线索开放

将发现状态表示为游戏本身拥有的状态。例如，只有当玩家真正找到便条时，found_archive_note_03 才会变为 true。在对话开始时，向角色传递一份允许他们讨论的预设事实列表，该列表已通过玩家的发现状态和角色的认知范围进行了过滤。只有当两项检查均通过时，线索才可用：玩家已达成其发现条件，且说话者已被授权知晓该内容。

这是检索增强生成（RAG）的一种实际应用：检索相关记录，将其放入模型的上下文中，并根据这些记录进行生成。微软的 RAG 概述介绍了这种“检索–增强–生成”流程，并提醒注意不佳或不完整的检索仍可能导致不准确的输出。对于游戏而言，检索在到达模型之前就应遵循发现条件。直接告诉模型“不要剧透任何内容”，远不如完全不向其提供未发现的证据来得有效。

尽量将权限检查保留在模型之外。应该由游戏本身，而非一行生成的文本，来决定证据是否进入日志、是否解开谜题或揭示新的交互。模型可以负责转述授权的事实；而游戏状态则应在最初就决定该事实是否获得授权。

为模型设定严格的契约与安全的后备机制

一个实用的提示词应明确角色的语气、当前场景、允许使用的线索记录，以及证据与风味文本之间的区别。明确指出当玩家提出的问题超出所提供的证据时该如何处理：拒绝确认、表示角色不知情，或者以符合角色性格的不可操作台词作出回应。同时包含处理冲突或模棱两可记录的指令。微软的 RAG 提示词工程指南建议设定明确的实证限制、后备行为、来源标识符以及应对冲突的指令。这些无论对于受控的角色对话还是信息助手，都是极有价值的设计原则。

例如，如果玩家询问首字母 M 是否证明是 Mara 写了便条，允许的回应可以是：“上面确实有个 M，但仅凭这一点无法断定是谁署的名。”系统可以允许这种措辞，因为它保留了事实来源与结论之间的差异。模型绝不应为了让回答更令人满意而即兴编造一名目击者、笔迹比对结果或第二份文件。

让模型返回结构化字段，例如 spoken_text、claim_type 和 source_ids。对于包含线索的回应，要求提供至少一个有效的来源标识符，并对照该轮对话所提供的记录检查该标识符。对于风味文本，将该回应标记为非证据，且不允许其设置线索标记。结构化输出并不能证明文本内容属实，但它为游戏提供了一种在显示或更改状态前可以进行校验的机制。

为风味文本添加标签以便玩家判断其分量

风味文本可能包括角色的心情、无害的玩笑或对房间的泛泛反应。它不应悄悄引入日期、地点、物品、特定名字的目击者、动机或其他可能被玩家合情合理地视为线索的细节。如果你想要推测性的对话，请在措辞中清晰展现出这种不确定性，并将其排除在客观系统之外，例如证据列表、任务状态和基于线索的交互。

这种区分可以同时体现在数据和表现层上。在内部，将台词标记为证据、推论或风味文本；在界面上，仅将证据样式或日志条目保留给游戏预设的线索。角色可以说“也许留这张便条时走得很急”，但除非游戏在设计上将这种可能性作为一种允许的推论，否则它不应作为已确认的线索出现，也不应触发新的剧情分支。这种三分法的标记方式是一项设计建议，旨在维护“来源所陈述的内容”、“他人所推断的内容”以及“纯粹表现性的对话”三者之间的界限。

使用叙事工具跟踪状态和条件

应用这种方法并不局限于特定引擎。交互式叙事工具通常都支持文本段落或章节、变量以及条件内容。Ink 官方编写文档介绍了用于控制故事内容的变量和条件逻辑；Twine Cookbook 的段落（passages）指南将段落解释为内容单元，其中也可以包含影响文本显示或响应方式的代码。无论对话本身是动态生成还是人工编写的，这些功能都可以用来表示发现状态、说话者知识和条件对话。

在叙事记录和游戏逻辑之间保持线索 ID 和状态名称的一致性。类似 found_archive_note_03 的变量比含糊不清的 clue2 标记更容易审计，尤其是在不同场景需要读取或设置它时。为每一条具有可操作性的生成台词建立追溯至其允许来源记录的链接；如果某行台词没有有效来源，运行时可以拒绝该台词或请求安全的后备回应，而不是将其视为证据。

通过针对性游玩测试检查边界

在发现的边界处测试对话，因为这些地方的状态规则最容易失效。在找到线索之前、刚找到线索之后，以及在认知程度不同的角色发言之后，分别尝试新的对话。直接询问关于未发现证据的问题，提出一个来源仅部分回答的问题，并在游戏支持的情况下重放该场景。对比显示的台词、其返回的来源 ID，以及日志或故事状态的任何变化。

一份简洁的测试检查清单有助于确保这些检查具体明确：

每一条可操作的陈述都对应一条作者预设的线索或明确允许的推论。

线索的发现条件在它作为可用认知出现之前必须为 true。

说话者在该场景中被允许知晓该信息。

超出依据的问题会触发所选的后备机制，而非生成新的具体事实。

风味文本台词不能添加日志条目、满足线索门槛或更改证据状态。

模棱两可或冲突的记录会产生不确定性表述或可供审查的后备响应，而不会悄无声息地生成新的判定结论。

事实实证减少了凭空捏造线索的空间，但并不能保证生成的文本始终完全遵循所提供的事实。检索可能会遗漏相关记录，且正如微软在其 RAG 局限性指南中所指出的，即便有实证支撑，模型有时仍可能产生不准确的文本。请将线索的最终决定权保留在作者预设的记录和游戏逻辑中；利用生成技术仅在这些边界之内增添个性表达。

实际的规则很简单：让模型选择用词，而由作者预设的谜题和当前游戏状态决定这些用词允许确立什么。当每一条可操作的线索都有来源、发现门槛和明确的状态时，角色交谈时可以显得更加自然生动，同时又不会向玩家提供游戏中从未放置过的证据。

继续探索这个主题