Metlivi 部落格

如何在不破壞故事連貫性的情況下建立 AI 世界觀設定集

建立 AI 世界觀設定集的方法：為每項已確立的事實賦予穩定的 ID、負責決策的人類所有者、來源以及明確的適用範圍。追蹤它在何時為真、適用於何處，以及哪些角色知曉這件事。讓 AI 提出增補建議並標註衝突；在這些提議成為正史（canon）之前，必須經過明確的編輯決策。本指南專為正在為下一個章節、場景或任務建立實用參考資料的小說與遊戲作家而設計。任務是建立一套既能查閱又能修改，同時不會意外改變故事規則的設定集。下方可重複使用的連貫性台帳（continuity ledger）將事實與依賴這些事實的場景連結在一起。

2026年9月22日閱讀時間 3 分鐘閱讀、藝術與文化作者：Metlivi Editorial Team

開啟產品返回文章庫

第 1 節

您的 AI 世界觀設定集應該包含哪些內容？

從一個能回答實際起草問題的小型參考系統開始。這個角色能在日落前到達天文台嗎？他們知道門是怎麼打開的嗎？這個答案在另一個故事分支上是否會改變？

將設定集整理為六個相互連結的部分：

使用試算表、連結文件或您可以輕鬆維護的資料庫。為實體賦予穩定的 ID，例如 LOC-01 和 CHAR-02；將顯示名稱和別名保留在單獨的欄位中。重命名「玻璃天文台」不應破壞對其位置記錄的所有引用。

將敘事摘要視為台帳的便捷檢視模式。當摘要與底層記錄不一致時，請檢查來源並在根據任一版本進行起草前解決衝突。

事實與規則：已確立的屬性、限制與例外情況。

時間線：事件、持續時間、先決條件和不確定的日期。

地點：穩定身分、連結關係、旅行條件和進出限制。

角色認知：每個角色知曉或相信什麼，以及他們是如何得知的。

未決問題：刻意留下的謎團和仍在等待解答的決定。

變更記錄：已接受的修訂、其原因以及受影響的內容。

第 2 節

誰擁有事實，又是什麼讓事實成為正史？

在此工作流程中，事實所有權分為兩部分：一筆權威記錄保存該陳述，且由一人負責接受變更。獨立作家獨自承擔該角色。團隊則可以將地點決策分配給世界觀設計師，將角色揭秘分配給敘事負責人，並指定一人來解決重疊的決策。

在所有權旁記錄出處（provenance）。W3C 的 PROV 概述（https://www.w3.org/TR/prov-overview/）將出處描述為關於參與產出某事物之實體、活動和人員的資訊。應用於故事設定集時，這意味著要保留陳述源自何處、如何變化以及誰接受了它。這裡的台帳借鑑了該原則；它並非正式的 PROV 實作。

為每筆記錄提供明確的狀態：

匯入現有手稿時，讓 AI 擷取候選事實，並附上準確的場景參考資料和簡短的佐證引文。親自檢查這些參考資料。某個角色說「天文台總是鎖著的」，僅確立了這句話曾被說出過；這並不自動確立為一條客觀規則。

寫下您專案的權威方針。例如：已接受的吃書修訂（retcon）決策優先於先前的正史條目；已接受的來源場景確立事實；工作草稿和腦力激盪內容仍屬暫定。如果兩個已接受的場景發生衝突，請將該衝突標記為未解決，直到您決定更改其中哪一個。

狀態 — 含義 — 起草處理方式

Proposed（提議）— 等待決定的想法 — 在標示明確的備選方案中進行探索

Canon（正史）— 針對指定連貫性和修訂版本所接受的內容 — 在其陳述的條件範圍內使用

Unresolved（未決）— 缺少資訊或存在衝突證據 — 保留不確定性；標註依賴此項的場景

Superseded（已廢棄）— 被已接受的修訂所取代 — 保留作為歷史記錄；從當前起草工作中排除

第 3 節

如何同時追蹤時間線與地點？

將故事時間與修訂時間分開記錄。「橋樑在第 6 天關閉」描述的是一個事件。「作者在第 4 版修訂中更改了橋樑的關閉日期」描述的是一項編輯決策。將兩者混淆會造成模糊不清，無法判斷究竟是世界發生了變化，還是其描述得到了更正。

針對每個事件，記錄其最早和最晚可能發生的時間、地點、參與者、先決條件以及結果狀態。在不需要極高精確度時使用區間：「早晨派送之後，日落之前」可能比憑空捏造的精確分鐘更有用。如果您的設定使用不常見的日期或季節，請定義曆法單位。

針對每條路線，記錄起點、終點、出行方式、所需時間或範圍，以及可用條件。說明該旅程是否為雙向可行。地圖上可能顯示兩地相距很近，但您已確立的路線仍可能需要長途繞行。

請參考這個明確用於說明的連貫性檢查範例：一名信使於 09:00 離開果園，需要三個小時才能到達天文台，並花費另外 30 分鐘領取鏡片。最早到達時間是 12:30。如果某個場景讓信使在正午出現在那裡，除非適用已接受的例外情況，否則就會與這些輸入條件發生衝突。

透過更改有依據的輸入條件來解決衝突：出發時間、路線、延誤或會面時間。如果路程需要兩到四個小時，到達時間則為一個區間。保留該不確定性，而不是直接判定為矛盾。

第 4 節

如何區分世界真相與角色認知？

將認知記錄與客觀事實分開。對於每一次重大的揭秘，記錄角色、事實或信念、獲取事件、時間以及任何分支條件。區分「知道」、「懷疑」、「錯誤相信」和「尚未得知」。記錄缺失意味著認知未被記載；這並不能證明該角色不知情。

這在互動式敘事中有著直接的對應物。Inkle 的官方 ink 教學（https://www.inklestudios.com/ink/web-tutorial/）展示了基於先前造訪過的故事章節的條件文字和選擇。它還介紹了自訂變數。這些機制可以代表對資訊的獲取，儘管作家仍必須決定造訪某個場景是否真的能讓角色得知特定事實。

例如，天文台的門可能在銅圓盤與標記對齊時打開。這是一個世界事實。Mira 在示範過程中學會該操作流程則是一個獨立事件。另一個閱讀不完整筆記的角色可能僅僅是懷疑它的運作方式。

對於分支遊戲，將學習事件關聯到相關路徑或狀態條件。同時測試角色學會操作流程的路線與跳過該流程的路線。對於小說，請檢查說明和對話在故事時間線上是否發生在學習事件之後，即使章節在呈現上是非年代順序的。

第 5 節

可重複使用的連貫性台帳

將以下欄位作為試算表欄位或筆記中的可重複記錄使用。每筆記錄保持一項可獨立修訂的陳述。以下範例純粹是為了示範工作流程而虛構的。

以下是三筆相關記錄的精簡檢視。完整的台帳應為每一行保留上述的證據和所有權欄位。

不要讓「未決」默認變成「否定」。問題 Q-003 讓替代圓盤的選項懸而未決。它既不允許也不禁止。需要答案的場景應該觸發一項決策請求。

為每個未決問題分配一位所有者和一個決策點：「在起草 S-15 之前解決」。如果答案是刻意對讀者隱瞞的，請記錄作者是否已經知道答案。作者掌握的答案與尚未決定的設計選擇需要不同的處理方式。

欄位 — 記錄內容

記錄 ID 與類型 — 穩定的 ID；事實、事件、地點、認知或問題

陳述 — 一項明確的主張或未決問題

狀態 — 提議、正史、未決或已廢棄

連貫性範圍 — 書籍、版本、路線或共享設定

故事時間有效性 — 該主張何時開始為真、何時停止為真

實體與地點 — 引用的角色、物體和地點 ID

條件 — 先決條件和明確的例外情況

認知 — 角色、信念狀態以及獲取事件 ID（適用時）

證據 — 來源修訂版本、場景或段落，以及佐證文字

決策所有者 — 負責接受或更改該記錄的人員

依賴項 — 使用該記錄的事實、場景、任務、地圖或對話

修訂歷史 — 新增該記錄的修訂版本、變更記錄 ID，以及被取代時的替換 ID

ID — 陳述 — 狀態與範圍 — 時間或條件 — 依賴項

F-014 — 當銅圓盤與框架標記對齊時，天文台的門會打開 — 正史；共享設定 — 第 1–10 天；圓盤存在 — 示範 E-008；解謎 S-12

K-009 — Mira 知道對齊操作流程 — 正史；示範路線 — 在第 3 天目睹 E-008 之後 — S-12 中的解釋

Q-003 — 替代圓盤能打開門嗎？ — 未決；所有路線 — 無公認答案 — 可選解謎 S-15

第 6 節

AI 在起草過程中應該如何使用設定集？

準備一個場景資料包，其中包含目標場景的時間、地點、視角、分支、相關正史記錄和未決的依賴項。包括相關聯的先決條件，而不僅僅是與該場景共用關鍵字的條目。一個涉及門的場景可能依賴於先前在另一個地點進行的示範。

使用如下可重複使用的提示詞指令：

根據隨附的連貫性記錄及其註明的修訂版本審閱所提供的場景。針對每個潛在衝突，引用場景段落並指出相關的記錄 ID。將其歸類為矛盾、缺少資訊或提議的增補。檢查時間順序、旅行、地點進出權限、角色認知和分支條件。保留未決問題。分開提出修復建議；切勿更改正史或捏造來源參考資料。說明根據所提供的資料無法完成哪些檢查。

對於生成性工作，要求在明確的限制條件下提供備選方案：「在不更改 F-014 且不讓 Mira 在 E-008 之前得知該資訊的情況下，提出三種拖延她的方式。」用您自己的語言描述所需的氛圍、節奏和設定特徵。

分兩輪審閱輸出內容。首先檢查其引用的記錄是否支援其結論。然後決定哪些建議有助於故事。只有被接受的變更才會記入台帳。如果缺少必要的來源，請將其調出或讓該結論保持未決狀態。

第 7 節

如何在不抹去歷史的情況下處理吃書修訂（retcon）？

區分普通事件與吃書修訂。如果門在第 11 天換了新機制，請新增一個過渡事件和一條具時間限制的新規則。如果您決定它原本就一直使用不同的機制，請修改先前的正史並檢查每個依賴它的場景。

版本歷史使早期的狀態得以復原。官方 Git 書籍的版本控制簡介（https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control）解釋了版本控制如何記錄變更、支援比對以及允許呼叫先前的版本。Git 是一種選擇；如果更符合您的工作習慣，也可以選擇具有可用歷史記錄的文件系統。請單獨記錄敘事決策發生變更的原因。

針對每項提議的修訂：

一筆可重複使用的變更記錄條目應包含變更 ID、修訂日期、決策所有者、原因、舊記錄、替換記錄、受影響內容和驗證狀態。例如：「CH-006 提議要求兩個對齊的圓盤；影響 F-014、E-008、K-009 和 S-12；決策待定。」僅僅批准並不意味著這些依賴場景已經完成修復。

找出舊陳述與提議的替換內容。

列出受影響的記錄，然後追蹤它們在場景和分支中的依賴關係。

再次檢查時間順序、旅行、認知獲取以及未決問題。

明確接受或拒絕該提議。

更新受影響的內容，保留被廢棄的記錄，並記錄任何剩餘的工作。

第 8 節

在接受一個場景之前應該檢查什麼？

在完成創意修訂後，為連貫性通讀一次場景。確認所需事件已發生、旅行和進出條件成立、角色掌握他們所使用的資訊，且分支專屬的事實仍保留在其分支內。檢查新細節是否已被納入正史，或仍處於明確的暫定狀態。

記錄用於該檢查的設定集修訂版本。如果後續變更觸及該場景的某個依賴項，請重新開啟該場景以供審閱。您可以從一個地點、一個角色以及下一個場景的基本事實開始，每當有新細節限制了後續發展的可能性時，就擴充該台帳。