如何防止 AI 角色對話捏造解謎遊戲線索

為什麼捏造的線索會破壞解謎遊戲

在解謎遊戲中，玩家收集資訊、得出結論，並利用所學去尋找更多資訊。這使得線索與玩家認知之間的關係成為遊戲核心循環的一部分，而不僅僅是對話風格的細節。一個自信地提及一封尚未出現的信件或說出玩家從未遇到過的人名的角色，可能會意外創造出一條新的線索。玩家無法可靠地判斷該細節是設計好的線索、刻意的謊言，還是生成的廢話填充。論文《Generative Forensics: Procedural Generation and Information Games》從收集知識並利用其理解謎題的角度描述了資訊遊戲；套用這個框架，未受追蹤的生成陳述可能會混淆玩家本應據此進行推理的知識。

解決方法始於明確的區分：線索是玩家可以據此採取行動的遊戲事實；情境對話（flavor）則是表現性的對話，不會增加或改變遊戲事實。角色的語氣可以顯得不確定、迴避、幽默或生動，但一句話絕不能僅僅因為措辭具有說服力就變成證據。

在生成對話前建立預先撰寫的線索記錄

為每條具可操作性的線索保留一份簡短而明確的記錄。它可以存放在資料庫、內容檔案或敘事工具中；關鍵在於模型不能自行捏造其內容。欄位應包含這條線索說了什麼、來自何處、誰可以知道它，以及它何時變得可用。

欄位：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 的段落指南將段落解釋為內容區塊，其中也可以包含影響文字外觀或回應方式的程式碼。無論對話本身是生成的還是預寫的，這些功能都可以用來表示發現狀態、發言者的知識以及條件對話。

在敘事記錄和遊戲邏輯中保持線索 ID 和狀態名稱的一致性。像 found_archive_note_03 這樣的變數比起模糊的 clue2 旗標更容易審查，特別是在不同場景讀取或設定它時。在每一句具可操作性的生成台詞與其獲允許的來源記錄之間建立可追溯的連結；如果某句台詞沒有有效來源，執行環境可以將其拒絕或要求安全的退路，而不是將其視為證據。

透過專門的遊戲測試檢查邊界

在發現狀態的邊界處測試對話，這些地方最容易出現狀態規則失效的情況。嘗試在找到線索前、找到線索後立即展開新對話，以及在具備不同知識的角色發言後進行測試。針對未發現的證據提出直接提問，詢問來源僅能部分回答的問題，並在遊戲支援的情況下重玩該場景。比較顯示的台詞、其返回的來源 ID，以及日誌或故事狀態的任何變更。

簡明扼要的測試檢核清單有助於使這些檢查具體落實：

每條具可操作性的陳述都對應到預設的線索或明確允許的推論。

線索的發現條件在它以可用知識形式出現之前已為 true。

發言者獲准在該場景中獲知該資訊。

未獲支援的問題會觸發選定的退路機制，而非生成新的具體事實。

情境台詞不能新增日誌條目、達成線索限制條件或更改證據狀態。

模糊或衝突的記錄會產生不確定性或可審查的退路，而不是悄悄生成新的解決方式。

錨定事實減少了捏造線索的空間，但並不能保證生成的文字始終嚴格遵循所提供的事實。檢索可能會遺漏相關記錄，且儘管進行了錨定，模型仍可能產生不準確的文字，正如微軟在其 RAG 限制指南中所指出的那樣。請將線索的最終決定權保留在預寫記錄與遊戲邏輯中；利用文字生成在這些邊界周圍賦予角色聲音。

實用的原則很簡單：讓模型負責選擇措辭，而由預設的謎題架構和當前遊戲狀態決定這些措辭允許確立什麼。當每條可操作的線索都有來源、發現限制與明確狀態時，角色聽起來可以更加自然健談，同時又不會給玩家提供遊戲從未放置過的假證據。

繼續探索這個主題