AI 讀得到角色設定，不等於世界狀態已經被證明

假設作者寫到第二十三章。

角色伊蓮娜走進王宮，從懷裡取出銀印，要求守衛放行。

這個場景讀起來沒有問題。

伊蓮娜確實曾經擁有銀印。

角色資料裡也寫著，銀印是她取得王室信任的重要證明。

但在第十四章，她已經把銀印交給另一名角色。

第十八章，那名角色又帶著銀印死在城外。

如果作者忘了這段流轉，第二十三章的場景就失去了前提。

Scrivener 可以讓作者搜尋銀印出現過的章節，並把角色資料、研究筆記與正文放在同一個專案裡。

Novelcrafter 可以讓 Codex 保存伊蓮娜與銀印的資料，也能把相關設定、場景、章節或大綱交給 AI，詢問這段內容是否一致。

兩種方式都可能幫助作者發現問題。

但它們回答問題的方法不一樣。

搜尋讓作者自己找答案。

AI 根據取得的上下文作出判斷。

還有第三種可能：

讓每一次取得、轉交、死亡與遺物處置都成為世界事件，再從事件順序計算第二十三章的銀印究竟在哪裡。

這時候，問題不再是系統「記不記得銀印」。

而是它能不能證明，伊蓮娜在這一章是否仍然持有它。

Scrivener 管理的是一份不必從頭寫到尾的長篇

Scrivener 對長篇寫作最重要的貢獻，是讓一本書不必永遠表現成一份巨大文件。

作者可以把作品拆成卷、章節、場景或更小的段落。

Binder 保存整個專案結構。

Corkboard 把章節與場景變成可以移動的索引卡。

Outliner 則讓作者查看摘要、字數、狀態、標籤與自訂資料。

正文、研究資料、圖片、筆記與角色設定可以留在同一個專案。

作者能同時打開多份內容，在寫作時對照前文或研究資料。

大幅修改以前，可以使用 Snapshots 保存舊版本並比較差異。

作品完成後，Compile 再把分散的文件重新組合，輸出成 Word、PDF、電子書或其他格式。

Scrivener 的核心不是替作者理解故事。

它讓作者能夠掌握一份持續成長、反覆調整，而且不按照線性順序完成的長篇文件。

角色資料可以建立成文件範本。

重要事件可以寫進摘要。

物品、地點與伏筆也能透過資料夾、標籤、關鍵字與自訂中繼資料管理。

這是一套高度自由的結構。

作者可以依照自己的思考方式建立工作流。

但自由也代表這些文件之間的故事關係，主要仍由作者自己維持。

角色頁寫了什麼。

正文後來改了什麼。

哪一份 Snapshot 保存哪個版本。

後面的章節是否仍然符合前面的事件。

Scrivener 可以把所有材料放在作者手邊。

它不會替這些材料建立一套必須共同遵守的世界狀態。

Novelcrafter 讓 Codex 成為寫作與 AI 共享的上下文

Novelcrafter 同樣能規劃、撰寫、整理與審閱小說，但它對故事資料採取了不同方法。

Codex 可以保存角色、地點、物品、組織、設定與其他世界知識。

這些條目不只是作者查閱的資料。

它們也可以被連結到故事內容，成為規劃、寫作、審閱與 AI 對話時使用的上下文。

角色出現在場景中時，相關 Codex 資訊能更容易被帶進工作流程。

同一套 Codex 也能在系列作品之間共享，減少作者在續集裡重新建立相同角色與世界設定的工作。

Novelcrafter 的規劃檢視則讓作者從不同角度查看章節、場景、故事節拍與人物視角。

作者可以移動場景、調整結構，也可以在不使用 AI 的情況下，把它當成小說規劃與寫作環境。

AI 是可選的。

作者可以決定要不要使用、使用多少，也能連接不同供應商或本機模型。

需要時，AI 可以協助腦力激盪、生成文字、分析場景、提供評論，或者根據作者選擇的 Codex、章節、大綱與其他內容回答問題。

這使 Novelcrafter 的 AI 不必每次都從空白對話開始。

作者可以把自己的故事資料帶給模型。

AI 因此比較有機會知道角色是誰、場景發生在哪裡，以及目前正在處理哪一部分故事。

這比把一小段正文單獨貼進一般聊天視窗，更接近完整的創作上下文。

上下文能讓 AI 知道更多，卻不能把判斷變成事實

AI 判斷的品質，很大程度取決於它得到什麼上下文。

如果 Codex 裡仍然寫著伊蓮娜持有銀印，AI 可能依照這份資料接受第二十三章的場景。

如果作者把第十四章的轉交事件一起放進上下文，AI 可能指出銀印已經離開她手中。

如果第十八章的死亡與遺物處置沒有被提供，模型又可能得到另一個答案。

即使相關內容都被送進上下文，語言模型仍然是在閱讀文字、理解語意，再根據機率產生判斷。

它可能發現矛盾。

可能提出正確提醒。

也可能被一段更醒目的角色描述影響，忽略藏在較早章節裡的一次物品轉交。

還可能把作者原本計畫發生、但正文中尚未真正發生的內容，和已經成為歷史的事件混在一起。

這不是 Novelcrafter 做錯了什麼。

這是 AI 上下文的本質。

上下文不是世界本身。

它是這一次請求中，模型被允許看見的世界材料。

Codex 可以讓資料更有結構。

上下文控制可以讓作者更精確地決定模型參考什麼。

但 AI 最後提供的仍然是判斷。

它不能因為讀過資料，就把一段敘述變成經過數學驗證的世界事實。

一份設定、一次提及與一個事件，不是同一件事

故事一致性最容易混淆的，是三種看起來很接近的資料。

第一種是設定。

伊蓮娜曾經擁有銀印。

銀印可以讓持有人進入王宮。

這些內容可以寫在角色資料與物品資料裡。

第二種是提及。

某一章談到銀印。

伊蓮娜回憶自己取得它的過程。

另一名角色懷疑銀印已經被偷走。

文字出現了銀印，不代表它的歸屬一定改變。

第三種才是事件。

伊蓮娜把銀印交給卡爾。

卡爾死亡後，銀印被留在城外。

米拉後來從遺物中取得銀印。

這些事件一旦被作者確認，就會改變後文的成立條件。

如果系統只知道設定，它會記得銀印和伊蓮娜有關。

如果系統能找到所有提及，它會知道哪些章節寫過銀印。

如果 AI 能閱讀相關上下文，它還可能理解轉交、死亡與遺物之間的語意。

但只有當這些變化被建立成可以重播的事件，世界才能得到確定答案：

第二十三章的銀印到底在哪裡？

誰可以使用它進入王宮？

伊蓮娜再次拿出銀印，是新的劇情安排，還是前文已經斷裂？

長篇需要的不只是更多上下文。

它還需要知道哪些文字已經被作者承認為世界歷史。

Scrivener 和 Novelcrafter 會如何面對同一把銀印

在 Scrivener 裡，作者可以搜尋「銀印」。

找到取得、轉交、死亡與王宮場景。

也可以打開伊蓮娜的角色資料、物品筆記與相關章節，逐一比對。

Collections、關鍵字與自訂中繼資料，還能讓作者建立自己的追蹤方式。

這種方法把判斷權完整留給作者。

只要資料整理得清楚，作者可以非常精確地找到答案。

代價是搜尋結果仍然需要被重新閱讀。

作者必須判斷哪一次提及真正改變了物品歸屬，哪一段只是計畫、回憶或對話。

在 Novelcrafter 裡，作者可以讓 Codex 保存銀印資料，再把相關場景、大綱與條目加入 AI 上下文。

接著詢問：

伊蓮娜在第二十三章是否仍然持有銀印？

模型可以整理材料、說明理由，甚至建議如何修正場景。

如果上下文完整，這可能比作者自己翻閱所有章節更快。

但答案仍然依賴模型讀到了什麼、如何解讀，以及這一次推理是否遺漏內容。

下一次更換模型、提示或上下文，說明方式甚至結論都可能改變。

這兩種方式分別提供人工查核與 AI 輔助。

它們都可能找出錯誤。

但「可能找到」和「按照世界規則必然報錯」，仍然不是同一種保證。

InkWeave 的因果律引擎不是 AI 審稿

InkWeave 不會把整部小說交給 AI，再要求模型尋找劇情漏洞。

它使用的是自行研發的因果律引擎。

作者建立角色、物品、地點、陣營、屬性與旗標，再確認正文裡真正發生的世界事件。

伊蓮娜取得銀印，是一次事件。

把銀印交給卡爾，是另一次事件。

卡爾死亡，是角色狀態改變。

死亡後如何處理銀印，則會決定物品接下來位於哪裡。

因果律引擎按照正文時間順序重播這些已確認事件。

物品數量透過取得與交出的變化計算。

角色位置由移動事件推導。

生命狀態由死亡、失蹤或恢復事件改變。

地點狀態、陣營結構、屬性與旗標，也各自依照明確規則更新。

所以到了第二十三章，系統不需要猜測伊蓮娜是否仍然持有銀印。

事件重播後，她的持有數量已經是零。

她若再次交出或使用同一件唯一物品，當下事件便失去可計算的來源。

這不是 AI 認為「她可能忘了已經交出去」。

而是目前世界裡沒有第二枚銀印可以支持這個行動。

數學保證讓一致性不再依賴模型信心

InkWeave 所說的數學保證，不是宣稱系統理解小說裡所有隱喻、情緒與敘事意圖。

它保證的是作者已經建模並確認的因果。

角色持有一件物品，轉交一件之後，餘額就是零。

兩名角色的當前地點不同，就不能在沒有其他事件的情況下直接完成實體物品交易。

角色的死亡發生在移動以前，後面的移動便不符合目前生命狀態。

一座城市已經毀滅，後續進入事件就必須面對地點條件。

某個場景要求旗標成立，引擎就會比較那個時間點的實際值，而不是根據文字氣氛猜測條件大概已經完成。

這些結果由順序、數量、集合、狀態與條件比較決定。

相同事件與規則，永遠得到相同答案。

判斷不會因為更換模型而改變。

不會因為提示詞不同而改變。

也不會因為某段角色介紹寫得比較醒目，就蓋過真正發生在正文裡的轉交事件。

InkWeave 無法驗證作者沒有建立的事實。

它也不會假裝理解所有文學意義。

但只要一件事已經進入因果律，它就不再是一段等待 AI 解讀的資料。

它成為可以重播、驗證與審計的世界歷史。

過去一改，Project Seer 會讓受影響的未來浮出來

真正困難的情況，不一定是作者第一次寫錯。

而是作者回到前文，改變了一件原本成立的事。

假設作者刪除了第十四章的銀印轉交。

伊蓮娜因此繼續持有銀印。

卡爾死亡時，原本確認過的遺物處置便和重新計算出的背包狀態不同。

後面米拉從卡爾遺物中取得銀印的事件，也失去了來源。

如果米拉仍然帶著銀印進入王宮，問題會繼續傳到更後面的場景。

InkWeave 在正文事件保存後，會重新驗證整條專案時間線。

它不只更新伊蓮娜現在持有什麼。

還會檢查後面的死亡遺物、物品取得、唯一性、角色位置、地點限制與條件閘門是否仍然成立。

Project Seer 會依章節整理這些錯誤與警告，顯示哪些地方需要作者重新確認。

作者可以從全域檢視直接跳到出錯的事件錨點。

許多錯誤還能回溯到造成目前狀態的來源。

如果角色在死亡後移動，可以回到死亡事件。

如果兩名角色不在同一個地點卻發生交易，可以查看雙方最近一次有效移動。

如果後續場景缺少旗標或前置條件，系統會列出實際值與需要的條件。

作者得到的不只是一句：

這裡可能不一致。

他可以知道哪個事件無法成立、缺少什麼，以及是哪一段過去改變了現在。

AI 與因果律引擎處理的不是同一種未知

AI 很適合面對沒有唯一答案的問題。

這一幕還能怎麼發展？

角色的反應是否符合他的性格？

這段對話有沒有更強的張力？

有哪些伏筆可能被讀者忽略？

某個選擇還能產生哪些意外後果？

這些問題需要語意理解、聯想、評價與生成。

答案可以不只一個。

Novelcrafter 讓作者把 Codex、正文、大綱與其他內容帶進 AI 上下文，正是在改善這類協作的品質。

因果律引擎處理的則是另一種問題。

伊蓮娜在第二十三章有沒有銀印？

卡爾死亡時身上有哪些物品？

兩個角色現在是否位於同一個地點？

王宮此刻是否仍然開放？

這個事件需要的旗標是否已經成立？

這些問題不應該每次詢問都得到一個新的看法。

它們需要一個可以重現的答案。

AI 可以協助作者想像世界還能變成什麼。

InkWeave 的因果律引擎負責證明，按照已經確認的歷史，世界現在究竟是什麼。

兩者不是同一種審計。

也不能只用「都有上下文」把它們放在一起。

故事一致性不應該只是一項 AI 建議

Scrivener 讓作者掌握長篇文件。

它能拆分、排列、搜尋、比較並輸出一部持續成長的作品。

Novelcrafter 讓 Codex、規劃、正文與可選 AI 進入同一套創作環境。

它能讓模型取得更貼近作品的上下文，協助作者腦力激盪、寫作與審閱。

但故事一致性還有一個不能被省略的問題：

當答案必須唯一時，作者需要的是建議，還是證明？

角色是否擁有一件物品。

是否仍然活著。

是否位於能夠完成交易的地點。

是否已經取得進入某場景的條件。

這些都不該只依賴某一次 AI 是否成功讀懂上下文。

InkWeave 讓正文事件成為可以計算的歷史。

讓游標所在位置擁有自己的世界切片。

也讓前文改動造成的後續錯誤，在保存後重新被驗證、定位與溯源。

這不是用 AI 模仿一名記憶力很好的編輯。

而是替故事建立一套不依賴記憶，也不依賴機率判斷的因果基礎。

AI 可以讀到角色設定。

可以理解一段轉交。

也可能提醒作者哪裡看起來矛盾。

InkWeave 的因果律引擎則會繼續追問：

按照這個世界真正被確認過的事件，這件事在此刻是否可能成立？

因為故事一致性不應該只是模型提供的一項建議。

當世界已經被建立，它應該成為可以證明的事實。