在解謎遊戲中，失蹤角色的 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 中，故事變數（story variables）可以跨段落使用，而在 Harlowe 和 SugarCube 中，暫存變數（temporary variables）則僅限於當前段落。這種差異說明了為什麼作者應該深思熟慮地決定某個事實是貫穿整個故事，還是僅屬於特定場景。具體實作取決於故事格式，因此請將此規則視為設計模型而非程式碼指南。Twine Cookbook: Variables
讓「不確定性」對玩家發揮作用
當紀錄缺失、過時或模稜兩可時，讓助理用具體的詞語來描述這個缺口。它可以說它有星期一的計劃，但沒有後續的確認；或者某個角色回報說移走了標牌，但公告欄上沒有任何更新。這為玩家提供了一個有意義的下一步：去查閱另一個作者設計的來源、重溫與角色的對話，或是判定該線索目前仍未獲解決。
這種方法在不引入武斷全知視角的情況下維繫了解謎感。互動敘事的研究探討了有限知識如何塑造玩家行為，其中包括一項使用互動小說《Anchorhead》來探索玩家模型的研究。對於編寫出的助理而言，這在設計上的意涵相當單純：玩家和助理所了解到的資訊會影響他們的下一步選擇，因此必須明確追蹤這些知識狀態。Rivera-Villicana et al., “Informing a BDI Player Model for an Interactive Narrative”
撰寫助理對話前的快速審查
在起草回覆之前，請針對每個具影響力的主張檢查以下幾點：
該主張是否存在於作者紀錄中，抑或已被標記為推論？
該紀錄是否指明了其來源，並明確區分了計劃、回報、觀察或後續確認？
助理是在故事時間的何時獲得該紀錄存取權限的？
助理的虛構角色身分是否允許存取該來源？
如果紀錄不完整或存在衝突，對話是否保留了這種不確定性？
如果上述任何問題的答案不明確，請限縮助理的陳述，直到它與現有紀錄相符。這樣塑造出的角色依然能夠提供幫助：它可以總結自己看到的一切、指出哪些部分尚未證實，並指引玩家走向下一個作者留下的線索。它的可信度，正是建立在故事完整紀錄與其真正收到的資訊之間清晰可見的界線之上。