傳統工作流的三個斷裂點
AI 寫作最大的謊言，不是「AI 不夠聰明」。是「AI 已經夠聰明了，所以什麼都能做」。
把 ChatGPT 當作寫作夥伴——這個想法聽起來合理。開一個對話視窗，貼一段稿子進去，問它：「這段對話自然嗎？」它回答了，回答得漂亮。再問：「幫我想三個結局走向。」它也給了，而且真的不錯。
問題從來不在這裡。
問題在第十七次對話。在那個你終於問出關鍵問題的時刻——「女主角在第三章承諾過的事，和她第十七章的行為矛盾嗎？」AI 很有自信地說：不矛盾。但它錯了。因為它根本沒讀過第三章。
整本書貼進去？超出長度限制。角色設定做成表格每次都貼？到第五輪對話，AI 把表格的內容也忘了。
三個工具同時在運轉——Word 負責寫稿，ChatGPT 負責問答，大腦負責記住一切——但它們之間沒有任何連結。稿件在一個視窗，AI 在另一個視窗，角色關係、伏筆位置、支線進度全部塞在頭腦裡。這不是效率低的問題。這是系統設計的根本缺陷。
Word 把一本二十萬字的小說當成一份文件。一份文件。角色設定塞在最前面，每次要看都得捲動三十頁；或者分散在十幾個檔案裡，寫到一半要查設定就得切換視窗、找檔案、再切回來——思路斷了。
版本管理更慘。刪掉一段，怕後悔，另存新檔。改了結局，不確定，再存一個。三個月後資料夾裡堆著五個「最終版」，沒有人記得哪個是哪個。
AI 需要的不是更聰明，是更完整的脈絡
「等 GPT-5 就好了。」
這句話暴露了一個根深蒂固的誤解。
把一段對話單獨丟給 AI，問它寫得好不好——AI 只能看到那段對話本身。兩個角色之間有二十章的恩怨糾葛？AI 不知道。這場對話發生在葬禮還是婚禮上？AI 不知道。整本書是黑色幽默還是古典悲劇？AI 也不知道。
模型再強，看不到脈絡就是看不到。這跟智慧無關。一個讀了全書的普通讀者，判斷力都比只看到一段的天才 AI 強。
所以真正的問題從來不是「AI 夠不夠聰明」，而是「AI 能看到多少」。
Slima 的 Writing Studio 把整本書的結構——章節、角色設定檔、世界觀筆記、大綱——全部放進同一個專案裡。AI Assistant 不是只看到當前開啟的檔案，它理解整個專案的脈絡。問它「這個角色的決定合理嗎」，它可以回溯她在前面章節說過的話、做過的事。
這不是更聰明的回答。是更知情的回答。差別巨大。
版本控制：寫作者最被低估的需求
程式設計師從來不直接改正在運行的程式碼。從來不。
他們建一個 branch，在上面實驗，確定沒問題才合併回主線。改壞了？切回去，什麼都沒發生。這個習慣讓他們可以毫無顧忌地嘗試任何瘋狂的想法。
作家沒有這個習慣。不是不想要，是工具不給。
寫到關鍵轉折點——主角該活還是該死？傳統工具逼你做選擇。只能選一條路走。另一條路？永遠不知道它會通往哪裡。
Slima 的 Version Control 改變了這個局面。做重大修改之前，建立一個 Snapshot——整本書當前狀態的完整快照。想嘗試不同走向？開一個 Branch。主線和分支之間自由切換，隨時比較差異，任何時候都能回到任何歷史狀態。
Branches 對小說創作的意義遠超過技術便利。角色該死的那個版本，寫下去之後發現帶出了意想不到的情感深度。角色活著的版本，反而變得平淡。沒有 Branches，這個發現永遠不會發生——因為大多數作家在那個分岔路口，會選「安全」的那條路。
改壞了，一鍵回去。這句話聽起來像小事，但它改變的是寫作時的心理狀態——從「小心翼翼地保護已有的成果」變成「放手去試，反正回得去」。
用 AI 讀者測試你的故事
初稿寫完，找人試讀。這個流程存在了幾百年。
問題不在流程本身，在時間。找到願意讀的人——幾天。等他們讀完——幾週。收到回饋——「還不錯啊」「有些地方有點慢」。太模糊了，幾乎沒辦法據此修改。等到回饋終於到手，距離寫完已經過了一兩個月。當初寫那些段落時在想什麼，早就記不清了。
AI Beta Readers 不取代真人讀者。真人讀者的直覺、情感反應、文化背景帶來的洞察——這些無可替代。但 AI Beta Readers 做的事不一樣：它們在初稿完成的當天，就給出結構性的回饋。
每個 AI Beta Reader 都有自己的人設。對節奏敏感的那位，會在覺得拖沓的地方直接標記「這裡我想跳過」。專找邏輯漏洞的那位，會問「她怎麼知道這件事？前面沒有交代」。看商業潛力的那位，會評估開頭能不能讓讀者繼續翻下一頁。
關鍵在這裡——因為 AI Assistant 讀過全書，這些回饋不是隨機挑毛病。它真的知道第三章寫了什麼，所以當它說第十七章有矛盾，那就是真的有矛盾。
寫完一章，當天就拿到多角度的分析。趁思路還在的時候修改。不用等。
專案管理：把小說當專案，不是當文件
一本長篇小說裡藏了多少東西？
三十個章節。十五個角色設定。一套魔法系統的規則文件。三份歷史背景研究。一條主線時間軸。四條支線時間軸。刪掉但捨不得丟的三萬字。
全部塞進一個 Word 檔案——那個檔案會變成一座迷宮。分成二十幾個檔案——光是在視窗之間切換就能把思路切斷五十次。
File Tree 借鑑了程式開發的 IDE 設計。整本小說是一個專案，章節在一個資料夾，角色設定在另一個，世界觀筆記在第三個。層級清楚，一眼就能找到任何東西。
寫到第十二章，突然想確認反派的本名——Cmd+P 打開 Quick Open，輸入兩個字，模糊匹配直接跳到角色設定檔。兩秒鐘。不用離開正在寫的頁面。
Cmd+ 開 Split Window。左邊是第十二章，右邊是反派的設定檔。兩份文件並排，一邊寫一邊查，視線不用離開螢幕。
這些操作各自省下的時間微不足道——兩秒、三秒。但一天省一百次，累積起來就是心流和分心的差別。工具跟得上思考速度的時候，寫作才真正開始。
離線優先：在任何地方寫作
咖啡廳的 Wi-Fi 斷了。飛機上沒有網路。火車穿過隧道的那二十分鐘。
Google Docs 在這些時刻變成唯讀模式——或者更糟，讓你編輯了但不保證回到線上後能正確同步。依賴 API 的 AI 工具直接變成一片空白。
Slima 的架構是離線優先。所有資料存在本地裝置上。沒有網路的時候，寫作、編輯、在 File Tree 裡整理檔案——全部正常運作。回到有網路的環境，自動同步。
AI Assistant 需要連線，這沒辦法——大型語言模型跑在雲端。但寫作本身不需要任何網路。靈感來的時候不用先確認訊號強度。
怎麼選擇適合的工具？
短篇——兩萬字以下——老實說不需要專門的寫作工具。Word 加 ChatGPT 就夠了。脈絡限制撞不到，版本管理的需求也不強烈。
但長篇不一樣。十萬字以上的長篇，有三件事不是「有也不錯」，是「沒有就做不下去」：
AI 必須看得到全書。不是片段，是全書。不然它給的每一條建議，都是去脈絡化的猜測。對不對？自己判斷吧。但當一本書有四十個角色和十二條支線的時候，「自己判斷」這件事本身就是問題的一部分。
Version Control 不是花俏的附加功能。它是讓作家敢於冒險的基礎建設。「另存新檔」是認知負擔偽裝成的版本管理。
專案結構必須撐得住一本書的複雜度。三十個章節、十幾份設定文件、研究資料、時間軸——這些東西需要一個系統來組織，不是一個資料夾裡堆一堆檔名差不多的 .docx。
工具不重要，完成故事才重要
最後一件事，而且這件事跟前面說的有點矛盾——
不要花太多時間挑工具。
這篇文章用了幾千字談工具的差異。但如果挑工具變成了拖延寫作的藉口，那工具本身就成了問題。完美的工具不存在。任何工具都有讓人抓狂的地方，都有學習曲線，都有某個功能做得不夠好。
選一個。開始寫。用著不對，換。
重要的事只有一件：故事有沒有往前推進？今天有沒有坐下來，寫了幾百個字？
AI 能幫忙。好工具能減少摩擦。但讓故事存在於世界上的，只有一個動作——坐下來，寫。
關掉這篇文章。打開 Writing Studio。
寫下今天的第一個字。