Metlivi 部落格

NPC 該如何回答劇本之外的問題？

當玩家向 NPC 詢問對話劇本中未涵蓋的內容時，請讓角色給出簡短的回答，內容應符合其認知範圍，並說明為何無法進一步解答。首先判斷該資訊是屬於未知、已知但隱藏，還是刻意不可透露的。接著以符合角色人設的方式回覆；如果遊戲需要說明系統邊界，可額外加入一個可選的系統說明。這樣能讓玩家理解限制所在，而不會把毫無根據的猜測當作故事事實。

2026年9月27日8 分鐘閱讀閱讀、藝術與文化作者：Metlivi Editorial Team

開啟產品返回文章庫

第 1 節

首先對問題進行分類，而不僅是處理缺失的對話

「超出劇本」（Out of script）描述的是創作上的空白，並不能告訴你角色究竟知道什麼。若將每個無劇本支援的問題都視為同種類型的失敗，會導致令人困惑的回答：NPC 可能會對從未聽說過的事情表現得閃爍其詞，或者不小心洩漏了遊戲原本意圖隱瞞的秘密。

請使用以下三個分類：

**未知（Unknown）：** 角色沒有可靠的資訊。他們可能完全不知道該主題，或者知道該主題存在但無法回答具體問題。

**已知但隱藏（Known but hidden）：** 角色掌握相關資訊，但由於故事條件、人際關係、個人選擇或明確的秘密限制，使他們目前無法分享。「隱藏」是一種故事狀態，而非在暗示每一次拒絕回答都藏有線索。

**不允許的知識（Disallowed knowledge）：** 答案超出了角色既定的世界觀、職責或允許獲取的知識範圍。例如，一個中世紀的擺渡人不該突然解釋現實世界中的軟體發布。這與一個知曉當地秘密卻不願透露的角色是截然不同的。

這些分類是一種設計輔助工具，並非引用的對話研究所驗證的分類體系。它們的價值在於實用性：每一種分類都指向一種不同的真實反應。如果你的遊戲刻意透過魔法、監視或特殊身分讓某個角色獲取資訊，請將其編碼至該角色允許的知識庫中，而不是將其視為生成模型可以自行猜測的特例。

第 2 節

根據事實構建得體的回答

一個實用的備用回覆通常包含三個部分：確認主題、說明角色實際的認知限制，並在存在合適的下一步時提供建議。下一步可以是指向遊戲中既有的人物、地點或行動。如果沒有，在說明限制後即可打住。切勿單純為了讓對話顯得有幫助而憑空捏造線索。

例如，假設玩家詢問小鎮的麵包師傅：「北邊山口之外有什麼？」如果麵包師傅從未去過那裡，一個貼切的回覆可能是：「我從沒去過那麼遠的北方。我的麵粉都是從山谷運來的。」這個回答既符合人設，指出了限制，又回到了麵包師傅自身的經驗範圍。「麵粉」的細節只是一種說明，並不是線索；在正式發布的遊戲中，請使用角色與世界觀設定中已有的細節。

如果麵包師傅知道實情但有所隱瞞，回答應反映該狀態，而不是假裝不知情：「我知道你說的是哪條路。但我答應過不能討論有誰走過那裡。」這句話劃定了界線，同時沒有洩露隱藏的答案。只有當角色的認知與沉默的原因在遊戲狀態中真實存在時，才使用此類拒絕方式。

如果問題涉及角色所在世界或職責之外的事物，應清晰展現限制，而不要假裝那是某種情節謎團：「我不知道什麼是『雲端伺服器』。那是某種氣象站嗎？」具體的措辭取決於設定與語氣。避免讓模型的通用知識滲透到角色的語氣中，誤被當成角色的生活經歷或世界知識。

相關研究支持這項通用的設計難題，但無法保證直接適用於遊戲方案。Shrivastava 等人於 2021 年發表的 ACL 短篇論文描述了對話系統中針對無法回答的查詢所採取的上下文備用回覆，該研究利用規則以及在合成問答對上微調的 Transformer 模型，其研究範疇並非敘事遊戲中的 NPC。[閱讀該論文](https://aclanthology.org/2021.acl-short.13/)。Sadeq 等人於 2024 年發表的 EMNLP Findings 論文研究了虛構角色扮演，引入了包含 2,000 多個角色、72,000 次訪談（含 18,000 個對抗性問題）的數據集，並提出了 RoleFact 以減少幻覺。該研究與角色的知識邊界高度相關，但並未證明某種特定的備用模式在已上線的遊戲中必定奏效。[閱讀該論文](https://aclanthology.org/2024.findings-emnlp.846/)。

第 3 節

將角色的回答與系統說明分開

角色可以在遊戲世界內回答，而界面則負責解釋背後的情況。當玩家可能將備用對話誤認為是劇本固有情節時，或者當遊戲需要澄清自由提問存在局限時，這種分離非常有用。

舉例來說：

**NPC：**「我從沒聽說過那個地方。不如問問我關於舊磨坊的事吧。」

**可選界面提示：**「該角色無法回答此問題。」

界面提示應描述互動本身的狀態，而非推翻角色的說法或暗示隱藏內容。盡可能保持其為可選或不顯眼；重複出現的系統訊息可能會打斷情境沉浸感。如果玩家的問題已被理解但超出了支援的互動範圍，請坦率說明。如果系統根本沒有理解該問題，請不要將此故障包裝成角色知識匱乏的事實。這是兩種不同的情況，可能需要不同的措辭。

一個實用的回覆規則是：用角色的聲音傳遞故事中的真實情況，用界面來說明互動的限制。切勿讓角色口中的台詞承載其不可能知曉的技術性解釋。反之，當有簡短、符合角色的真實回應可用時，也不要使用通用的系統訊息。

第 4 節

使用邊界矩陣測試知識與故事狀態

單一範例無法反映備用機制是否尊重狀態。請為每個重要的 NPC 或資訊來源建立一個小型的測試矩陣。在每一行中，記錄預期的回答類別、必需的事實、禁止出現的事實，以及是否應顯示界面說明。接著在不同的條件下執行相同的問題進行測試。

**NPC 對該主題一無所知：** 回答不主張任何熟悉度，也不提供細節。以角色的口吻表明不確定或缺乏經驗。

**NPC 了解該主題，但不清楚所問的細節：** 通用知識不會演變成精確的回答。說明已知內容，然後指出具體的盲區。

**NPC 知道答案且可以分享：** 回答符合當前的故事事實。給出有依據的答案；不要僅僅因為問法特殊就退回到備用回覆。

**NPC 知道答案但處於保密條件下：** 秘密保持不公開，且除非本意如此，否則角色不會虛假地聲稱不知情。以符合人設的方式拒絕、轉移話題或劃定界線。

**保密條件解除：** 當故事狀態允許透露時，回覆隨之改變。如果玩家再次提問或遊戲透過其他方式揭示，則提供新開放的資訊。

**問題超出角色的世界觀或職責：** 現實世界或無關的模型知識不會作為事實進入虛構情境中。將該類別標記為不熟悉或無關，而不捏造世界觀內的關聯。

**對話系統無法解析問題：** 解析失敗不可與 NPC 的不知情混為一談。使用清晰的互動層級備用提示，可視情況附帶支援的提問引導。

**同一問題以多種方式表述：** 知識與保密規則不依賴於單一死記硬背的措辭。在允許自然的表述變化的同時，保持相同的事實邊界。

該矩陣是源自上述區分的編審與品保方法；並非上述兩篇引用論文中所載的實驗。請填入您自己的角色事實和實際狀態條件。測試內容應包含誘使系統用看似合理卻無依據的設定來補全模式的問題，以及 NPC 應當正常回答的常規問題。務必驗證這兩方面：防止虛假透露很重要，而在答案明明可用時避免不必要的拒絕也同樣關鍵。

第 5 節

讓邊界在編寫與實作中皆可被測試

將角色認知與世界客觀事實分開。一份精簡的角色檔案可以標記他們知道的事實、懷疑的事實、不知道的事實，以及在條件改變前不可透露的事實。如果遊戲允許角色犯錯，請為不確定的看法標註來源或確信度。懷疑聽起來應該像懷疑，而不是全知的事實。回應層應接收相關狀態，並僅使用該狀態下允許的事實。

對於每一句備用台詞或生成的回答，請審視：

它是否說出或暗示了角色不被允許知道的事實？

它是否將「我不知道」與「我不能告訴你」混為一談？

它是否意外地讓缺失的答案聽起來像是一個秘密或任務線索？

所建議的下一步是否已在遊戲中存在，且符合當前情境？

如果該問題不受互動系統支援，玩家能否從界面得知這一點，而不將其誤認為故事對話？

如果某句台詞未通過上述檢查之一，請對其進行收斂：去除未獲支援的暗示，陳述真實的限制，並僅保留既定的下一步。如果沒有任何能帶來價值的真實角色回答，那麼簡潔的拒絕或系統提示，遠勝於憑空捏造的設定。

第 6 節

簡易決策流程

在審查劇本外的提問時，請依序進行以下檢查：

**遊戲能否解析該問題？** 如果不能，請使用互動層級的說明，而不是將其歸咎為 NPC 的無知。

**所詢問的資訊是否在此角色的知識範圍內？** 若否，給予一個符合該角色經歷或職責的本色限制回覆。

**角色是否知曉該資訊，且目前是否允許透露？** 如果角色知道但不能透露，請使邊界符合其動機與狀態；除非有意為之，否則不要透過提示洩漏答案。

**角色能否提供有依據的部分回答或有用的下一步？** 只有在該內容已於遊戲中有所立足時，才將其納入。

**玩家是否會將備用回覆誤認為線索或原創情節轉折？** 若有可能，請在系統層面澄清該互動，或修改台詞。

其目標並不是讓每個問題都能帶來令人滿意的設定揭密，而是讓回覆易於理解、符合角色的認知，並且確保遊戲故事狀態的安全。一個設計良好的邊界能告訴玩家該 NPC 當前能回答什麼，同時維護虛構世界觀的完整性。