在解谜游戏中，失踪角色的 AI 助手究竟能知道些什么？
在虚构的解谜游戏中，AI 助手应该只了解作者向其开放的故事记录——并且只能从故事中这些记录变得可供访问的时间点开始了解。为每条事实赋予来源、获知时间以及访问规则。这样可以让助手帮助玩家串联线索，而不至于在不知不觉中变成无所不知的叙述者。
将故事记录与助手的访问权限区分开来
首先建立一份面向作者的完整故事记录：事件、角色陈述、物品、消息，以及它们进入游戏的顺序。然后为助手定义一个更小范围的视角。某项事实可以存在于故事设定集（story bible）中，但暂不对助手开放。这种区分是公平解谜的基石：作者可以知道发生了什么，而助手只能使用其虚构角色设定所允许查阅的记录。
像 Twine 这样的互动小说工具将故事组织成段落（passages），并可以使用变量和条件逻辑来改变玩家看到的内容。这提供了一个有用的设计类比：将每条创作的记录视为一个独立的单元，并使其访问权限以相关的段落、事件或选择为条件。Twine’s basic concepts
例如，假设一个名为 Mara 的虚构角色正在准备社区花园的展示活动。助手可能会访问她分享的计划备忘、发布在群组公告板上的日程安排，以及她后来发送的关于将手绘标牌移至室内的消息。助手不应仅仅因为知道 Mara 喜欢园艺就推断出她的下落，也不应看到从未与它分享过的私人草稿。这些限制来自故事设定的访问规则，而不是源于对现实中 AI 系统能访问什么的论据。
为每项事实赋予来源和获知时间
一条有用的事实记录至少要回答四个问题：陈述的内容是什么、谁或什么提供了该内容、助手何时可以访问它，以及它是直接事实还是推论。W3C 出处模型（provenance model）通过实体（entities）、活动（activities）和代理（agents）来描述信息的来源；它还允许记录描述一个项目是如何从另一个项目衍生而来的。即便游戏使用的是简单的标签而非形式化模型，这也是一个适用于虚构记录的实用框架。W3C PROV Model Primer
一条精简的记录可能如下所示：
陈述：Mara 计划给花园标牌上漆；来源：共享的计划备忘；助手获知时间：周一，10:00；类型：直接陈述
陈述：标牌被移至室内；来源：群组公告板更新；助手获知时间：周二，16:30；类型：直接更新
陈述：Mara 可能因为天气预报有雨而移走了标牌；来源：天气备忘加上更新；助手获知时间：周二，16:30；类型：推论；未证实
示例中的时间仅供参考。重要的区别在于事件发生的时间与助手获知该事件的时间。如果周一创建的备忘录在周二被共享，那么除非故事明确赋予其更早的访问权限，否则助手的知晓时间从周二开始。当两个时间戳不一致时，应同时保留二者。
明确区分观察、汇报与推论
来源并不能自动保证其内容的确定性。角色可能只是描述了他们所看到的事情；备忘录可能不完整；日程安排记录的可能只是一项计划，而非实际发生的行动。标注记录类型有助于助手准确组织回答的措辞：“公告板上说标牌被移走了”不同于“Mara 移走了标牌”，而这两者又都不同于“她可能是因为天气原因移走了标牌”。
保持使用一套精简一致的词汇：直接观察、角色汇报、作者设定记录以及推论。推论应当能够回溯到支撑它的记录，并始终标记为推论。W3C PROV 明确地对代理在活动中的职责以及实体间的衍生关系进行了建模；将这种区分应用到对话中，有助于游戏展示结论的由来，而不是将其作为全新的事实呈现。W3C PROV-O
这也为创作提供了一个有用的检验标准：玩家能否将助手自信陈述的内容追溯到它获准访问的记录？如果不能，请修改回答，补上缺失的设定记录，或者让助手说明它没有足够的信息。
根据故事时间定义访问权限，而不仅仅依据角色
对于每条记录，都要明确解锁助手访问权限的事件。一条共享消息可能在发送时即刻可用；公告板上张贴的通知可能在助手查看公告板时可用；而一段对话可能只有在玩家选择询问之后才可用。避免依赖含糊不清的标签，例如“助手知晓档案中的一切”，除非故事交代了该档案包含什么以及何时更新。
一条实用的访问规则包含三个部分：记录的受众、可用性触发条件以及任何延迟。例如：“玩家打开群组公告板后，助手可以阅读板上的帖子；它无法阅读个人草稿。”在分支故事中，延迟非常重要。如果玩家尚未查看公告板，助手就不应表现得好像已经看到了最新帖子，仅仅因为该帖子已存在于作者文件的其他地方。
在 Twine 中，故事变量可以在各个段落之间通用，而在 Harlowe 和 SugarCube 中，临时变量仅限于当前段落。这种差异说明了为什么创作者应该审慎决定一项事实是贯穿整个故事，还是仅属于特定场景。具体实现取决于故事格式，因此请将该规则视为一种设计模型，而非具体的代码指令。Twine Cookbook: Variables
让不确定性对玩家发挥作用
当记录缺失、过时或模糊不清时，让助手用具体的语言描述这种信息缺口。它可以说自己拿到了周一的计划，但没有后续的确认；或者某个角色汇报说移走了标牌，但公告板上没有任何更新。这为玩家提供了有意义的下一步行动：检查另一个设定来源、重新询问某个角色，或者认定该线索目前仍悬而未决。
这种做法在不引入肆意全知视角的前提下支撑了解谜机制。针对交互式叙事的研究探讨了有限的信息如何塑造玩家的行为，其中包括一项利用互动小说《Anchorhead》探索玩家模型的研究。对于人工创作的助手而言，其设计启示非常朴实：玩家和助手所了解到的信息会影响他们接下来的选择，因此请明确追踪这些知识状态。Rivera-Villicana et al., “Informing a BDI Player Model for an Interactive Narrative”
撰写助手对话前的快速审查
在起草回复之前，针对每个关键陈述核对以下几点：
该陈述是否存在于作者设定的记录中，还是被标记为推论？
该记录是否指明了来源，并区分了计划、汇报、观察还是后期的确认？
助手是在故事时间的哪个节点获得访问权限的？
助手的虚构角色设定是否允许访问该来源？
如果记录不完整或存在冲突，对话是否保留了这种不确定性？
如果对其中任何一个问题的答案不够明确，请收窄助手的陈述，直至其与可用记录相符。由此塑造的角色依然能提供帮助：它可以总结所见所闻，指出尚未证实的内容，并引导玩家寻找下一条创作好的线索。它的可靠性正是源于故事完整记录与其自身实际接收到的信息之间那条清晰可见的界限。