下一章不一定是第十一章

作者剛寫完第十章。

照順序來看，下一章理所當然應該是第十一章。

但他腦中最清楚的不是第十一章。

而是第二十七章。

他已經看見那一章的場景。

Elena 終於進入封鎖多年的地下檔案庫。

她會在那裡見到一直拒絕和她合作的館長。

城市的封鎖已經解除。

她也終於知道多年前那封信的真正寄件人。

這幾件事會在同一個場景裡交會，讓她有資格打開一份足以改變整個世界的紀錄。

作者還不知道第十一章到第二十六章的所有細節。

卻知道故事必須抵達這裡。

於是他沒有先建立第十一章。

他先建立第二十七章。

然後在這個未來場景裡放下一個 REQ 錨點。

這個錨點要求：

地下檔案庫的位置已經被發現。

館長的信任至少達到 3。

城市警戒狀態已經變成解除封鎖。

信件寄件人的身分已經確認。

那份一次性的檔案庫通行資格尚未被提前使用。

這些條件現在都還沒有成立。

但作者已經知道，第二十七章需要它們。

所以那一章不是寫作已經抵達的地方。

它是一個先被放在遠方的未來。

從那一刻開始，第十一章到第二十六章便有了需要完成的事。

作者可以先看見結果，再回頭尋找足以支撐它的原因

長篇寫作不一定永遠從前往後發生。

作者可能先想到結局。

先看見一場重逢。

先知道某件物品最後會回到誰手上。

先寫下一段角色已經完成轉變之後的對話。

也可能先確定某一章需要幾條分散已久的劇情線同時交會。

這不是異常的寫作方式。

很多時候，作者對故事最清楚的部分，本來就不會按照章節順序出現。

問題在於，先看見未來很容易。

讓未來得到足夠的前因，卻比較困難。

作者知道 Elena 會在第二十七章得到館長協助。

但她在第十章仍然不受館長信任。

作者知道城市封鎖會在那一章以前解除。

但封鎖目前才剛開始。

作者知道信件的祕密會成為進入檔案庫的關鍵。

但前文甚至還沒有建立足夠線索，讓 Elena 懷疑寄件人的身分。

如果這些差距只留在作者腦中，第二十七章很容易提前使用尚未形成的結果。

角色忽然擁有信任。

封鎖忽然消失。

身分之謎像是早已解開。

通行資格也在需要時自然出現。

作者確實先看見了未來。

但世界沒有走到那裡。

所以先寫未來真正需要的，不只是保留一段靈感。

還要把那個未來正在等待的前因，一起留下來。

REQ 不是備忘錄，而是未來向前文提出的條件

作者可以在筆記裡寫：

記得讓 Elena 得到館長信任。

記得解除城市封鎖。

記得揭露信件寄件人。

記得準備進入檔案庫的方法。

這些都是有用的提醒。

但它們仍然只是作者寫給自己的文字。

完成其中一項以後，作者必須自己把待辦勾掉。

修改前文以後，也要自己重新判斷那些安排是否仍然成立。

REQ 的作用不同。

它不是一句「記得處理」。

它位於第二十七章的實際時間點，並且明確聲明：

當世界重播到這裡時，這些條件必須成立。

因此，REQ 不是放在故事外面的規劃筆記。

它是故事時間線裡的一個因果檢查站。

地下檔案庫的位置是否已經被發現，不由作者手動宣告完成。

館長信任是否達到 3，也不由待辦清單上的核取方塊決定。

因果律引擎會沿著第十章之後真正發生的事件，重播相關 Flag 的狀態。

走到第二十七章的 REQ 時，再檢查那些條件是否已經成立。

如果尚未成立，未來仍然在等待自己的原因。

如果全部成立，第二十七章才真正得到世界的支持。

這份未來待辦，不需要作者手動勾選

一般待辦事項的完成狀態由人決定。

作者寫完一場對話，便把「提高館長信任」勾掉。

寫完解除封鎖的場景，再把另一項工作標示為完成。

但「作者覺得自己處理過」和「世界狀態真的已經改變」，不是同一件事。

作者可能寫了一場讓館長開始動搖的對話。

卻沒有讓信任達到第二十七章需要的程度。

可能寫了市政府準備解除封鎖。

但命令尚未真正生效。

可能揭露信件上的筆跡屬於某個人。

卻還沒有讓 Elena 確認寄件人的完整身分。

所以 REQ 不會因為相關內容曾經被提到，就自動完成。

作者需要在正文中放入真正改變相應 Flag 的事件錨點。

例如：

第十二章，Elena 從舊地圖上確認地下檔案庫的位置，讓「檔案庫位置已發現」成立。

第十六章，她歸還館長遺失多年的紀錄，讓館長信任發生改變。

第二十章，她找到第二份證詞，使「信件寄件人已確認」成立。

第二十四章，城市危機解除，警戒階段才正式改為解除封鎖。

這些事件被放進第二十七章以前，因果律引擎重新驗證後，REQ 缺少的條件便會逐項減少。

待辦不是被作者勾掉的。

是世界沿著實際歷史證明它已經完成。

一個未來，可以同時等待不同種類的條件

第二十七章需要的條件，不一定全部都只是「有」或「沒有」。

有些事情適合使用布林旗標。

地下檔案庫的位置是否已被發現。

信件寄件人的身分是否已經確認。

某份協議是否正式成立。

這些條件通常回答：某件事現在成立了嗎？

有些事情具有多個階段。

城市警戒可能經歷：

正常、警戒、封鎖、解除封鎖。

調查也可能從未知、懷疑、確認，走向公開。

這類狀態適合使用列舉旗標。

REQ 不只確認旗標存在，還能要求它在第二十七章抵達特定階段。

另一些條件則需要累積。

館長信任至少達到 3。

調查進度高於某個門檻。

敵對程度低於特定數值。

三項授權中至少已經取得兩項。

這些狀態可以使用計數旗標，讓 REQ 比較目前值是否大於、小於或達到指定門檻。

因此，第二十七章不是只有一張簡單的完成清單。

它可以等待多種不同形狀的世界狀態。

某件事已經發生。

某件事走到特定階段。

某個數值累積到足以支撐後續事件。

某項一次性條件也仍然保有作用。

當這些條件同時成立，未來場景才不只是作者希望它發生。

而是世界已經走到能讓它發生的位置。

第二十七章不會把第十一章變成過去

先建立第二十七章，不代表故事時間已經越過中間十六章。

「第二十七章」首先是一個章節名稱。

真正決定世界時間的，是它在專案結構中的排列位置。

作者剛建立它時，結構可能是：

第十章。

第二十七章。

接著，作者開始補寫中間的路。

他建立第十一章，放在第二十七章以前。

再建立第十二章、第十三章與後續章節，逐步把它們插入正確位置。

最後，專案結構變成：

第十章。

第十一章。

第十二章。

一路到第二十六章。

然後才是第二十七章。

InkWeave 的因果律引擎不會因為章節標題裡寫著「二十七」，就憑空假設前面已經存在二十六章的歷史。

它依照卷冊、章節與正文錨點的實際順序重播事件。

所以只有真正被放到第二十七章以前的 Flag 變化，才能滿足第二十七章的 REQ。

如果作者把解除封鎖的事件寫在第二十八章，它不會倒流回去支援第二十七章。

如果作者後來把那個事件移到第二十四章，它才會成為 REQ 可以承認的前因。

第二十七章沒有反過來創造第十一章到第二十六章的歷史。

它只是先說明：

當故事真正走到我這裡時，我需要前面的世界已經完成這些改變。

Project Seer 讓未來持續出現在作者眼前

作者建立第二十七章的 REQ 以後，可以先回到第十一章繼續寫作。

但第二十七章不會因此從專案的因果視野中消失。

Project Seer 會掃描整個專案。

當因果律引擎重播到第二十七章，REQ 會按照那一刻的 Flag 狀態檢查所有條件。

如果地下檔案庫位置尚未發現，Project Seer 可以指出這項條件尚未成立。

如果館長信任只有 1，但第二十七章要求至少達到 3，它可以同時顯示目標值與目前值。

如果城市警戒仍然處於封鎖，REQ 也不會因為作者打算在前文解除，就提前把意圖視為結果。

如果一次性資格已在更早的事件被回收，Project Seer 也會指出它不能再被第二十七章使用。

這些未完成條件會持續留在專案檢查裡。

作者寫完第十二章，滿足其中一項。

寫完第十六章，再滿足一項。

如果第二十章的事件仍然不足，其他條件就繼續存在。

因此，Project Seer 不只是找出已經寫錯的地方。

它也能讓作者看見自己先放在未來的責任。

第二十七章還沒有正式抵達。

但它已經開始向前文提出要求。

REQ 負責驗證，Flag 事件負責讓世界改變

REQ 不會替作者建立它需要的條件。

它也不會因為作者希望第二十七章成立，就自動改變任何 Flag。

REQ 只做一件事：

檢查世界走到這個位置時，指定條件是否成立。

真正讓條件發生變化的，仍然是前文中的事件錨點。

角色找到檔案庫。

館長改變信任。

警戒進入新的階段。

祕密身分被確認。

這些事件使 Flag 取得新的值。

等到因果律引擎重播至 REQ，它才有狀態可以比較。

這個分工很重要。

如果 REQ 同時負責建立自己需要的條件，世界就會變成只要抵達第二十七章，一切前因便自動成立。

那不是因果。

那是作者把結果寫進未來以後，要求世界倒過來承認它。

InkWeave 不會這樣做。

未來可以提出條件。

前文必須真正產生條件。

REQ 則站在兩者交會的位置，確認世界是否已經走完那段距離。

通過 REQ，不一定代表伏筆已經回收

第二十七章抵達時，所有條件都已成立。

這表示那一章可以使用它們。

但 REQ 通過，不一定代表所有 Flag 都已經完成使命。

例如「館長信任至少達到 3」可能是一個持續狀態。

第二十七章以後，這段信任仍然可能影響其他事件，不需要在場景結束時被回收。

「城市已解除封鎖」也可能繼續保持有效。

它不是使用一次就消失的條件。

但一次性通行資格不同。

Elena 使用它進入地下檔案庫後，這項資格可能就應該被回收。

信件寄件人的身分伏筆，也可能在真相公開後完成自己的敘事責任。

因此，完整的因果順序可能是：

前文設定或改變 Flag。

第二十七章的 REQ 檢查條件。

場景正式使用這些條件。

需要結算的一次性 Flag，再由後續錨點回收。

REQ 是檢查。

回收是狀態改變。

兩者不能被壓成同一個動作。

如果一項伏筆被設定，卻到整條時間線結束仍然沒有得到處理，InkWeave 也可以透過契訶夫之槍提醒，讓作者回頭確認它究竟是刻意保留，還是真的被遺忘。

世界不只需要知道伏筆是否足以支撐未來。

也需要知道它完成任務後，是否仍然背著一筆沒有結算的責任。

修改前文，也可能讓已經成立的未來重新失去支撐

作者終於完成第二十六章。

第二十七章的所有 REQ 條件都已經通過。

後來，他回到第十六章修改劇情。

原本是 Elena 歸還失落紀錄，讓館長信任提升。

新版本裡，她選擇隱瞞其中一頁。

這個改動讓場景更有張力。

卻也讓館長的信任不再達到第二十七章要求的數值。

第二十七章的文字沒有改變。

REQ 錨點也沒有改變。

但它的前因已經變了。

因果律引擎重新重播後，原本通過的條件會再次失敗。

Project Seer 便能重新把這筆未完成責任帶回作者眼前。

作者可以修改第十六章。

可以在後面的章節建立另一場恢復信任的事件。

也可以重新思考第二十七章是否真的需要館長信任。

系統不替作者選答案。

它只指出：

你改變了通往這個未來的道路，所以那個未來現在不再像以前一樣成立。

這正是結構化未來待辦和普通筆記最大的差異。

普通筆記只記得作者曾經想做什麼。

REQ 記得的是目前這段世界歷史，是否真的已經做到。

這不是 AI 替作者預測劇情

InkWeave 不會閱讀第二十七章的文字，再由 AI 猜測這場戲需要哪些伏筆。

它也不會分析第十二章的語氣，擅自判定館長開始信任 Elena。

REQ 裡需要檢查哪些條件，由作者明確建立。

Flag 的種類、預設值與狀態變化，也由作者定義。

InkWeave 自研的因果律引擎會按照專案中的實際章節順序，依序重播 Flag 事件。

抵達 REQ 時，再將當下狀態與作者設定的條件比較。

條件可以檢查是否存在、等於、不等於、大於、大於等於、小於或小於等於指定值。

同一個 REQ 也可以同時檢查多項條件。

這裡沒有語意猜測。

沒有模型認為某段對話「看起來像」信任增加。

也沒有 AI 覺得故事「大概已經」解除封鎖。

在作者明確建立的模型範圍內，相同的章節順序、Flag 事件與 REQ 條件，會得到相同的驗證結果。

這是事件順序、狀態轉移與條件比較的數學保證。

沒有被作者建模的情緒、隱喻與文學意義，因果律引擎不會假裝理解。

作者仍然負責意義。

引擎負責確認作者明確交給世界的條件，是否真的沿著歷史成立。

世界模擬不是預測未來，而是讓未來等待自己的原因

先建立第二十七章，看起來像是作者跳到了未來。

但 InkWeave 不會把那個未來當成必然。

第二十七章可以被寫下。

可以保留最重要的對話。

可以先確定角色會站在哪裡，以及那場戲需要什麼。

但只要 REQ 尚未通過，它就仍然是一個等待前因的未來。

這套方式不只適用於小說伏筆。

一場救援演練可以先定義最終撤離需要哪些安全條件。

一個製作計畫可以先定義正式拍攝前必須完成哪些授權與準備。

一段歷史模擬也可以先放下某個政治事件，再檢查前面的支持、資源與衝突是否足以讓它成立。

InkWeave 不會替這些未來生成過程。

它也不會預測人們一定會作出哪些選擇。

它只是讓創作者可以先聲明：

如果世界要走到這裡，它必須先成為什麼樣子？

然後讓每一次真正被寫入時間線的事件，逐步回答這個問題。

作者可以先看見遠方的門。

可以先知道門後有什麼。

也可以先寫下抵達那裡時最重要的一句話。

但世界仍然需要在前面的章節裡，造出那把能夠打開門的鑰匙。

第二十七章不是對未來的保證。

它是一份由未來交給現在的因果契約。