Scroll 長篇創作指南：從構思、規劃到沉浸寫作

長篇寫作很少真的停在「沒有靈感」。更常見的情形是：你知道兇手是誰，卻看不清三條時間線在哪裡衝突；你知道下一章要寫什麼，腦中卻同時掛著十幾處待修訂的問題；資料已經蒐集得很完整，坐到正文前還是忍不住回頭整理人物卡。

這些停滯看起來相似，實際需要的下一步並不相同。開始之前，不妨先問一句：我此刻需要看清故事、推進寫作，還是處理研究、修訂與版本？

Scroll 把 Story 規劃、任務、研究資料與正文放在同一個本機 Project 中，但並不要求作者沿著一條固定流水線前進。你可以在構思、檢查、起草和修訂之間往返；重要的是讓每個工作區回答它真正負責的問題。

構思與規劃：先讓故事資料參與正文

人物、地點、事件、時間與關係屬於故事本身。面對一部跨三代的家族小說，你也許先用表格找出缺失欄位，再用時間線核對年齡，用關係圖確認親緣與利益關係。它們觀察的是同一組由作者記錄的 Story data，不需要為每種檢視各維護一份副本。

• 《同一個故事，為什麼需要 11 種檢視？》說明表格、時間線、關係圖、地圖與畫布分別適合回答什麼問題。
• 《模板不是故事公式》區分內容模板、Project 模型與故事公式，協助作者只記錄真正會反覆使用的資訊。
• 《世界觀不是百科全書》討論怎樣讓人物、地點、規則與歷史回到場景選擇，而不是在正文之外無限生長。

這些檢視不會從正文裡推斷日期、關係或缺失事實。它們讓已經明確記錄的資訊更容易檢查，也把「什麼是真的」這項判斷留在作者手裡。

推進與沉浸：把「繼續寫」縮小成今天能完成的工作

有時 Story 已經足夠清楚，寫作時段卻仍然無法開始。「推進整本書」太大，複雜的追蹤系統又會把原本有限的時間消耗掉。更實用的做法，是把作品中發生的事件與作者接下來要做的工作分開。

• 《把「寫完一本書」拆成看得見的工作》把起草與修訂變成可以完成的任務，並用看板限制同時推進的事項。
• 《怎樣建立可持續的沉浸寫作時段》圍繞明確目標、適量回饋和安全出口組織小黑屋，而不是把沉浸寫作變成意志力競賽。
• 《即閱模式還是原始碼檢視？》說明怎樣在流暢寫作與 Markdown 原始碼檢查之間切換，而不把它們當成兩份稿件。

一部雙時間線小說可以這樣推進：先用事件卡和時間線找出衝突，把「修正第十二章的日期」寫成任務，再用一段專注時間修改正文。第二天，作者完全可以因為新的發現回到 Story；創作路徑不必假裝是一條直線。

研究、修訂與版本：讓成熟稿件仍然可以追溯

初稿越接近完成，問題越可能從「下一章寫什麼」變成「誰在何時知道什麼」「這條資料來自哪裡」「哪些章節都受同一條編輯意見影響」，以及「現在究竟哪一份稿件要進入出版準備」。這時需要的不是更多零散筆記，而是一條能串起資料來源、作者判斷與正文的路徑。

• 《線索沒有丟，只是散在整本書裡》把實際事件、人物知情範圍與讀者取得的資訊分開，協助懸疑作者人工核對公平性與時間順序。
• 《「我記得看過這條資料」》區分外部原始資料、Project 副本、作者判斷與正文表達；連結和搜尋能找回脈絡，卻不會自動產生正式引用或證明資料可信。
• 《初稿寫完以後，真正困難的是怎麼改》把寬泛回饋收束成一個結構問題，再用跨章任務完成一輪邊界清楚的修訂。
• 《別再靠 final-final 找定稿》梳理作品、稿件版本、Publish Version、真實副本與完整 Project 備份各自負責什麼。

Timeline 只能顯示作者輸入的日期，搜尋結果也不能替作者判斷一條資料的意義；版本標籤更不是自動儲存的歷史快照。Scroll 的優勢在於讓這些問題留在同一個創作環境中，作者仍然負責完成編輯判斷、備份與交付檢查。

當稿件開始變成一本書

如果你只寫一篇線性短文，檔案樹與編輯器也許已經足夠，不需要為了顯得「專業」而建立複雜資料。相反，當稿件版本已經穩定，真正的問題變成 Appearance、分頁與出版輸出，就應從創作工作轉向Scroll 與 Scribe 的分工指南。Scroll 負責構思、正文、修訂、版本組織與交付準備；作者在 Scribe 中核對識別結果後，再開始書籍製作。Scroll 不直接完成 PDF、EPUB 或印刷版式，準備好交付也不等於 Scribe 已成功識別。

今天只需要選擇一個最接近目前卡點的入口。若想看看這些路徑怎樣圍繞同一個本機 Project 工作，可以繼續了解 Scroll；其餘工作區可以等問題真正出現時再使用。