畫面安靜下來了，作者腦中的世界卻沒有
作者把 Ulysses 切換成專注寫作模式。
側邊欄消失。
工具列淡出。
畫面只剩下正在書寫的段落。
游標向前移動，句子一行接著一行落下。
這種安靜很珍貴。
寫作不再像是在操作一套龐大的軟體。
作者不需要一直看見格式選項、文件樹、工具面板與大量設定。
他只需要面對文字。
但長篇寫到某個程度後，真正打斷專注的東西不一定來自介面。
角色現在身上還有那枚戒指嗎？
他是在第幾章把戒指交給別人的？
這一幕發生時，王城已經封鎖了嗎？
兩名角色現在是否位於同一個地方？
這個陣營在前一章失去領袖後，還能按照原本方式行動嗎？
作者可以隱藏所有面板。
卻不能把這些問題一起藏起來。
Ulysses 和 Scrivener 對專注有不同理解。
一個盡可能降低寫作介面的存在感。
一個讓複雜文件保持可以尋找、拆分與操作。
但長篇寫作還有第三種負擔。
不是畫面太吵。
也不是章節太多。
而是作者必須一邊完成眼前的句子，一邊記住整個世界走到這裡時，究竟已經變成了什麼。
Ulysses 的專注，不只是把按鈕藏起來
Ulysses 的寫作體驗建立在一套很一致的設計上。
作者在 Sheets 裡寫作。
用 Groups 與 Projects 整理作品。
使用 Keywords 和 Filters 尋找不同類型的內容。
不需要進入傳統的檔案開啟與儲存流程，也不需要先決定每一份文字最後要長成什麼版面。
寫作時，作者使用的是帶有標記語意的純文字。
標題、強調、引用與其他結構先服務內容。
等到輸出時，再將作品轉換成 PDF、DOCX、ePub、HTML 或其他格式。
Material Sheets 可以保存研究、人物資料與不應進入成品的內容。
寫作目標、字數統計與工作紀錄則讓作者掌握進度。
透過 iCloud，內容也能在 Mac、iPad 與 iPhone 之間延續。
所以 Ulysses 的乾淨並不代表它沒有組織能力。
它把很多複雜度放在寫作畫面以外。
作者仍然可以整理章節、保存素材、建立關鍵字、設定目標與輸出完整作品。
只是這些功能不需要一直站在句子旁邊提醒自己的存在。
這是一種很明確的產品哲學。
寫作工具不必要求作者一直操作它。
好的時候，它應該安靜到讓作者忘記自己正在使用工具。
Scrivener 的專注，來自知道所有東西放在哪裡
Scrivener 採取的是另一種方法。
它不試圖讓長篇作品看起來像一張單純的白紙。
它承認一部長篇可能由大量章節、場景、研究資料、人物筆記、圖片、舊版本與暫時無法歸類的片段共同構成。
Binder 讓這些內容維持清楚的階層。
作者可以把正文拆成不同大小的文件，再依需要重新排列。
Corkboard 以索引卡觀看章節和場景。
Outliner 提供摘要、字數、標籤與自訂中繼資料。
Scrivenings 讓分開管理的文件重新以連續正文呈現。
Snapshots 可以保存文字修改前的版本。
Compile 則在作品完成後，將內部結構整理成投稿、印刷或其他輸出格式。
Scrivener 的介面比 Ulysses 顯示更多結構。
但這些結構不是單純的干擾。
對某些創作流程而言，知道研究資料就在旁邊，知道某一幕位於哪個章節，知道整本書可以被拆開再重新組合，本身就是一種專注。
作者不必把所有內容塞進同一份文件。
也不必在幾十個獨立檔案之間尋找失蹤的場景。
Ulysses 讓作者少看見一些東西。
Scrivener 讓作者知道需要的東西在哪裡。
兩者都在降低寫作負擔。
只是它們選擇降低的，不是同一種負擔。
這不是極簡工具和專業工具的簡單對決
把 Ulysses 稱為簡單工具，把 Scrivener 稱為複雜工具，看起來很容易理解。
但這種比較並不準確。
Ulysses 可以管理完整書籍、研究素材、關鍵字、篩選條件、寫作目標與不同輸出格式。
它不是只能寫短文的筆記工具。
Scrivener 也不要求每一位作者先建立龐大架構。
作者可以從空白文件開始，在需要時才逐步拆分章節、增加研究資料與使用大綱功能。
它不是只有高度規劃型作者才能操作的系統。
兩者更真實的差異，在於它們如何讓作者接近作品。
Ulysses 希望文字始終位於中央，組織功能盡可能順著寫作自然展開。
Scrivener 則把作品視為一個可以拆解、排列、比較與重新編譯的長篇專案。
這兩種方法都可以承擔長篇。
也都能讓創作者建立屬於自己的工作流程。
真正不能從這種比較中得到答案的，是另一個問題：
當某一章真正改變了角色、物品、地點或關係，這項改變會不會自動成為後文必須承認的世界狀態？
這不是介面簡潔與否的問題。
也不是文件管理功能多少的問題。
它是故事裡的因果，是否和正文存在於同一套系統裡。
文件知道文字放在哪裡，不代表世界知道東西在哪裡
作者在 Ulysses 裡建立一個角色資料 Sheet。
上面寫著：
艾琳持有王室戒指。
他也可以在 Scrivener 裡建立角色文件，將戒指資訊放進筆記、自訂中繼資料或場景摘要。
這些資料都能幫助作者查找設定。
但故事繼續發展後，艾琳可能把戒指交給另一個人。
可能將它藏在某個地點。
可能在逃亡時遺失。
也可能在正文修改後，根本沒有取得這枚戒指。
這時候，角色資料仍然可能寫著他持有戒指。
早期大綱也可能仍然依賴這項安排。
後面的章節甚至已經讓他使用戒指證明身分。
Ulysses 知道角色資料存在哪一張 Sheet。
Scrivener 知道角色文件位於 Binder 的哪個位置。
但「戒指現在在哪裡」不是文件位置問題。
它是世界狀態問題。
作者當然可以手動更新資料。
修改角色筆記。
增加關鍵字。
調整場景摘要。
搜尋後文裡所有戒指出現的位置。
問題是，一枚物品的轉手可能不只改變一份設定。
它還可能改變誰能證明身分、誰能進入王宮、哪個陣營相信誰，以及哪些後續場景仍然成立。
文件可以保存答案。
但只要答案仍然要由作者逐份同步，它就可能在某次改寫後停留在舊世界裡。
打開設定資料，看到的也可能只是最新版本
作者在寫第二十章時，想確認艾琳是否持有戒指。
他打開角色資料。
看到戒指目前屬於另一名角色。
這個答案對第二十章可能是正確的。
但如果作者回頭修改第五章，最新資料反而可能誤導他。
第五章發生時，戒指還沒有轉手。
另一名角色甚至還沒有登場。
作者需要知道的不是戒指最後屬於誰。
而是故事走到第五章時，它應該位於哪裡。
靜態角色資料很難同時回答這兩個問題。
如果只保存初始設定，它跟不上後面的改變。
如果不斷覆蓋成最新狀態，它又會讓未來滲進過去。
作者可以替每次變化留下日期與章節。
可以建立物品流轉表。
也可以保存多個版本的角色文件。
這些方法都能減少混亂。
但它們會讓專注寫作逐漸變成資料維護。
作者原本只是想確認第五章的一個句子。
最後卻必須離開正文，閱讀角色卡、物品表與前後場景，重新推導那一刻的世界。
真正需要的不是更多可以打開的筆記。
而是當作者站在第五章時，世界本身就回到第五章。
InkWeave 讓游標所在的位置決定作者看見哪個世界
InkWeave 同樣提供正文、章節，以及角色、地點、物品、陣營與其他世界資料。
但這些資料不只有一個永遠最新的版本。
當作者確認一項世界變化時，它會成為正文時間流裡的事件。
艾琳取得戒指。
將戒指交給另一個人。
把戒指留在旅館。
或在某次事件裡失去戒指。
這些改變各自發生在故事中的特定位置。
當作者把游標放在戒指轉手以前，InkWeave 會沿著當時以前已經發生的事件，推導出較早的世界切片。
戒指仍然屬於艾琳。
後來的人物關係、地點狀態與陣營變化，也不會提前回到這一章。
當游標移到轉手事件之後，世界才承認新的持有人。
AVG Stage 與 Inspector 因此不是固定角色卡。
它們會隨著作者所在的正文位置，呈現那一刻的角色、物品、地點與其他狀態。
作者不必先離開正在修改的章節，再從幾份設定資料推算答案。
游標不只是輸入位置。
它也是故事時間的座標。
這種設計不要求作者先證明自己的作品已經足夠龐大，才值得管理世界狀態。
工具本身會改變創作者能夠承擔的複雜度。
當角色、物品與事件不再只能依靠記憶維持，作者從故事開始就能更自由地讓世界累積改變。
前文改掉一件事，後文不能繼續使用舊答案
假設作者原本讓艾琳在第五章取得王室戒指。
第十章，他用戒指通過王宮守衛。
第十四章，他將戒指交給盟友。
第二十章，盟友再用戒指取得軍隊支持。
後來，作者回到第五章。
他決定讓艾琳拒絕接受戒指。
這個改動可能讓角色更符合當時的心理狀態，也可能替後面的關係留下更好的發展空間。
在 Ulysses 裡，作者可以專注地改好這場戲。
在 Scrivener 裡，他可以保存 Snapshot、更新摘要，再搜尋後面的相關場景。
但真正困難的工作才剛開始。
第十章的進宮方式已經失去。
第十四章無法轉交一件從未取得的物品。
第二十章依賴戒指的軍隊支持，也不再擁有原本的條件。
作者必須記得這三個地方。
還要知道是否有其他沒有直接提到戒指、卻依賴王宮身分與陣營信任的事件。
InkWeave 不會因為後文已經寫好，就讓舊答案繼續成立。
作者確認並保存第五章的改變後，因果律引擎會重新重播事件。
艾琳的戒指數量不再增加。
後面的使用、轉交與條件檢查也會因此得到不同結果。
Project Seer 會將受到影響的問題依章節呈現，讓作者回到確切位置處理。
它不會自動把戒指重新交給艾琳。
也不會替作者改寫進入王宮的方法。
系統只會指出：按照目前正文真正建立的歷史，這些後續事件已經失去因果來源。
新的答案仍然由作者決定。
但舊答案不能在世界裡假裝自己沒有受到影響。
這不是 AI 閱讀全文後提出的猜測
一套系統如果能指出角色沒有某件物品，很多人會直覺認為它使用 AI 閱讀正文。
模型可能分析第五章與第十章的語意。
判斷角色是否取得戒指。
再猜測後面的使用是否構成矛盾。
這種方式可以提供閱讀意見。
也可以幫助作者發現值得重新檢查的內容。
但它仍然是一種判斷。
模型選擇了哪些上下文、如何理解句子，以及這次認為哪一段較可疑，都可能影響結果。
InkWeave 的 Project Seer 不是 AI 審計。
它使用的是 InkWeave 自行研發的確定性因果律引擎。
系統不會從散文裡自行猜測戒指是否轉手。
作者先明確確認哪些事件真正改變了世界。
因果律引擎再按照正文順序重播這些事件，計算每一刻的物品數量、持有人、角色位置、地點狀態、陣營結構與故事條件。
如果艾琳從未取得戒指，他能夠轉出的戒指數量就是零。
如果一座城市已經毀滅，後文不能在沒有新規則或事件的情況下，把它視為普通地點進入。
如果一名角色已經死亡，他也不能繼續像活人一樣移動、交易或參與後續事件。
相同的事件、順序與規則，會得到相同的驗證結果。
這裡所說的數學保證，不是宣稱系統理解整部小說的一切。
保證只存在於作者明確建模的範圍內。
數量如何增加與減少。
角色屬於哪些集合。
事件按照什麼順序發生。
狀態可以如何轉換。
後續條件是否符合目前結果。
這些都能被重播、比較與驗證。
作者沒有建立的文學意義，InkWeave 不會假裝知道。
但一旦世界變化被明確確認，它的後果就不再依賴模型的印象。
AI 提供的是判斷。
InkWeave 的因果律引擎提供的是證明。
真正的專注，不是作者什麼都看不見
無干擾寫作很容易被理解成讓畫面減少。
隱藏側邊欄。
進入全螢幕。
降低工具列存在感。
讓文字成為唯一可見的東西。
這些設計確實有價值。
但作者在長篇裡承受的干擾，還有另一種來源。
他擔心自己忘記。
所以停下來搜尋前文。
打開角色資料。
檢查物品筆記。
重新閱讀幾章以前的場景。
比較大綱與正文。
試著判斷腦中記得的是正式版本、舊草稿，還是尚未寫出的安排。
這些動作不一定讓介面看起來混亂。
卻會不斷把作者從當前場景拉走。
真正的專注，不是讓所有資訊消失。
而是讓正確的資訊在需要時出現，不相關的資訊在此刻保持安靜。
作者寫到角色時，看見角色此刻的狀態。
寫到物品時，知道它目前的持有人與位置。
回到早期章節時，不會被最新設定污染。
修改前文後，能立即知道哪些後果需要重新處理。
世界不必一直向作者發出提醒。
但當正文碰到已經累積歷史的實體時，它應該能夠回應。
Ulysses 與 Scrivener 改變的是作者如何接近文字
Ulysses 讓寫作保持輕盈、連續，並在 Apple 裝置之間自然延伸。
作者可以在 Mac 上整理專案，在 iPad 上修改章節，在 iPhone 上記下一張新的 Sheet。
內容、標記與輸出格式彼此分離，讓作者先完成文字，再決定作品如何呈現。
Scrivener 則讓長篇專案的結構始終可見。
章節可以拆分。
場景可以移動。
研究資料可以和正文並列。
版本可以保存。
最後再由 Compile 將所有內容組合成需要的格式。
兩者都能讓作者完成長篇。
也都在解決真實的寫作問題。
但 InkWeave 關心的不只是作者如何接近文字。
它還關心文字發生之後，世界變成了什麼。
角色移動後，位置應該改變。
物品轉手後，歸屬應該改變。
地點被封鎖後，後面的行動條件應該改變。
角色死亡、陣營重組或故事旗標成立後，相關結果都應該沿著時間繼續存在。
InkWeave 不只是替複雜故事收拾後果。
它讓作者從故事開始，就有能力創造一個可以持續變得更複雜、卻不必依靠記憶勉強維持的世界。
最好的寫作環境，不該只保護眼前的句子
Ulysses 與 Scrivener 對寫作環境提出了兩種成熟的回答。
一種讓文字盡可能不被介面打擾。
一種讓長篇專案不會因為內容龐大而失去結構。
但一個真正能承擔複雜故事的寫作環境，還需要保護另一件事。
作者已經寫下的過去。
角色做過的選擇。
物品留下的路徑。
地點承受的改變。
陣營失去的人。
以及這些事件對後文產生的條件。
否則，作者即使擁有再乾淨的畫面，仍然要在腦中維護一個不斷變化的世界。
即使擁有再完整的文件結構，也仍然可能讓新的正文和舊的設定同時存在。
專注寫作不該只是讓作者看不見工具。
複雜長篇管理也不該只讓作者找得到文件。
真正重要的是，當作者專心寫下一個改變時，世界能夠替他記住這個改變，並且讓後文繼續承擔它。
最好的寫作環境，不只保護眼前的句子。
它也保護這些句子共同創造出的世界。