《冰與火之歌》五個 POV 角色的第一本書，到了第五本膨脹成超過二十個。George R.R. Martin 花了十一年寫不出第六本——不是因為他懶，是因為二十條主觀世界的資訊邊界，已經超出人腦能同時追蹤的極限。
多 POV 寫作的核心難題，三個字就能說完：資訊隔離。每個角色活在自己的泡泡裡。偵探不知道兇手是誰，目擊者不知道自己手上的線索有多關鍵——但寫的人全部都知道。全知作者 vs. 有限視角，這個落差是多 POV 最容易翻車的地方。
聲音的問題同樣致命。三個 POV 角色的內心獨白讀起來像同一個人？那多視角結構等於白搭。偵探進房間先看出口，藝術家先看光線，社工先看人際張力——同一個場景，不同的眼睛，應該產生完全不同的文字質地。
敘事平衡是第三道坎。篇幅怎麼分？順序怎麼排？某個角色消失三章，讀者會不會直接忘了他？
靠直覺同時處理這三件事——坦白說，做不到。需要系統。
多視角的三重挑戰
多 POV 的難，不在「寫多個角色」。任何小說都有多個角色。難在每個 POV 章節必須完全沉入那個角色的主觀世界，而不同的主觀世界之間——不能有任何污染。
資訊管理最容易出事。偵探在第十章才發現關鍵線索，他在第八章的內心獨白就不能流露出對這條線索的任何認知。即使是隱晦的暗示也不行。讀者未必會有意識地發現這個錯誤，但他們會感覺「哪裡不對」。這種感覺會一點一點累積，最後變成對整個故事的不信任。
比「知道」更微妙的是「意識到」。角色 A 在第三章親眼目睹了某件事，但他沒有理解其中的意義——直到第十二章，某個觸發讓他突然明白那代表什麼。追蹤的不只是客觀事實在角色之間的傳遞，還有主觀理解的演變。這兩者之間的時間差，就是懸念的來源。
聲音區分決定了多 POV 結構到底有沒有存在的意義。三個角色的內心獨白讀起來像同一個人在說話？那不如直接用第三人稱全知視角，還省事。
區分聲音，用字遣詞只是表面。更深的層次是思維模式。受過軍事訓練的人進入房間，第一反應是掃視出口和掩體位置；畫家會注意到窗戶灑進來的光打在牆上的角度；心理諮商師會讀房間裡每個人的肢體語言。同一個房間，完全不同的「看見」。
敘事平衡是結構層面的挑戰。篇幅分配、出場順序、切換頻率——每個決定都在影響讀者的耐心。讀者投入情感的角色消失太久，他們會把書放下。這不是誇張，是閱讀行為研究的結論。
在 Slima 中建立 POV 管理系統
處理多 POV 的複雜性，需要兩套系統同時運作。一套服務寫作——讓作者完全沉浸在單一視角裡。一套服務追蹤——讓整體結構不會在寫作過程中失控。
Slima 的 File Tree 天然適合建立這種混合結構：
草稿/
├── 按角色/
│ ├── POV-偵探/
│ │ ├── 發現屍體.md
│ │ ├── 第一個線索.md
│ │ └── 審問證人.md
│ ├── POV-兇手/
│ │ ├── 作案當晚.md
│ │ └── 差點被發現.md
│ └── POV-目擊者/
│ ├── 她看到了什麼.md
│ └── 決定隱瞞.md
└── 整合版/
├── 01-屍體被發現.md
├── 02-兇手的回憶.md
├── 03-目擊者的抉擇.md
└── ...
「按角色」資料夾的用途很直接：寫偵探的時候，打開 POV-偵探，畫面上只有偵探的章節。其他角色的資訊不會出現在視線範圍內，不會干擾，不會污染。這種物理隔離帶來心理隔離——大腦更容易進入單一視角的狀態。
「整合版」資料夾是最終讀者看到的順序。各條故事線的章節寫完之後，按敘事邏輯排列到這裡。先寫作，後組裝。把兩個階段分開，認知負擔立刻減半。
Quick Open（Cmd+P）是在不同 POV 之間快速切換的捷徑。輸入「偵探」看到所有偵探章節，輸入「兇手」看到所有兇手章節。比在 File Tree 裡一層層點開快太多了。
追蹤誰知道什麼
資訊管理需要一份專門的追蹤文件——不是靠記憶，是靠白紙黑字。
在「大綱與計劃」資料夾裡建一個「POV追蹤.md」，裡面記錄三類東西：章節分配、各 POV 篇幅統計、以及最關鍵的——資訊知曉狀態表。
資訊知曉狀態表長這樣：
| 資訊 | 偵探 | 兇手 | 目擊者 |
|------|------|------|--------|
| 被害者身分 | Ch.1 | 一直知道 | Ch.3 |
| 作案動機 | Ch.15 | 一直知道 | 不知道 |
| 兇手身分 | Ch.18 | — | Ch.3（但不確定）|
| 關鍵證據 | Ch.12 | Ch.5 處理掉 | 不知道 |
寫任何一個章節之前，先查這張表。這個角色在這個時間點，知道什麼、不知道什麼——一目了然。多 POV 最常見的錯誤就是讓角色「知道」他還不該知道的事，這張表就是防火牆。
Split Window（Cmd+ 或 Ctrl+）在這裡派上用場。左邊開追蹤表，右邊開正在寫的章節。寫到角色思考某件事的時候，眼睛往左一瞄——他真的已經知道了嗎？兩秒鐘確認，省掉後面幾小時的回頭修改。
讓每個聲音獨特
每個 POV 角色都需要一份「聲音設定」文件。不是角色小傳，不是背景故事——是這個人說話和思考的方式。四個面向：思維模式、觀察重點、語言習慣、內心獨白範例。
思維模式是最深層的差異。這個角色怎麼處理資訊？邏輯推理型——「如果 A 那麼 B，排除 C 和 D」？還是情緒驅動型——「這讓我胃裡發緊，一定有什麼不對」？先看整體還是先看細節？預設立場是信任還是懷疑？
觀察重點決定角色「看見」什麼。同一個犯罪現場：偵探數地上的腳印，計算嫌疑人數；兇手評估哪些表面可能留下指紋；目擊者盯著牆上的全家福，想這家人以後怎麼辦。同一個房間，三段完全不同的描寫。
語言習慣是讀者最快感知到的層面。長句還是短句？書面語還是口語？會罵髒話嗎？有口頭禪嗎？比喻從哪裡來——廚師用烹飪比喻，音樂家用節奏和旋律，工程師用結構和負載？
內心獨白範例最實用。為每個 POV 角色寫兩三段典型的內心獨白，存在角色檔案裡當作參考錨點。寫到某個想法不確定該用什麼語氣表達的時候，回去看一眼範例，聲音就回來了。
在 Slima 的「角色」資料夾中，為每個 POV 角色的檔案加一個「聲音設定」區塊。背景故事和聲音特徵放在同一個地方，查閱的時候不用在不同檔案之間跳來跳去。
讓 AI 幫忙檢查一致性
多 POV 寫作最容易出錯的兩件事——資訊洩露和聲音混淆——恰好是 AI Assistant 最擅長的檢查類型。人腦很難同時記住每個角色在每個時間點的資訊狀態，但 AI 可以系統性地掃描整份手稿，逐章比對。
按下 Cmd+Shift+A（Mac）或 Ctrl+Shift+A（Windows）開啟 AI Chat Panel，執行多 POV 審計。
資訊洩露檢查——提示詞範例：
根據「POV追蹤.md」中的資訊知曉狀態，偵探在第十章才知道兇手的身分。
請掃描「POV-偵探」資料夾中的所有章節（第一章到第九章），檢查是否有任何內容暗示偵探已經知道或懷疑兇手的身分。
包括：
- 直接提及
- 暗示性的想法或觀察
- 對特定角色的不合理關注
請引用具體的段落並解釋為什麼這可能是資訊洩露。
聲音一致性檢查——提示詞範例：
這是「POV-偵探」資料夾中的三個章節。
請根據「角色/偵探.md」中的聲音設定，分析這三個章節的聲音是否一致。
檢查要點：
- 思維模式是否符合設定（邏輯性、分析性）
- 觀察重點是否符合設定（先看手判斷職業等）
- 語言習慣是否一致（正式但不僵硬、避免感嘆詞等）
如果發現不一致的地方，請具體指出並建議修改。
POV 違規檢查——提示詞範例：
這個章節是偵探的視角。
請檢查是否有任何描述違反了嚴格 POV 原則：
- 描述了偵探不可能知道的其他角色的想法
- 描述了偵探不在場時發生的事件
- 使用了偵探不可能有的知識或觀察角度
請引用具體的句子並解釋為什麼這違反了 POV 原則。
重點不是讓 AI 替代作者的判斷。重點是讓它幫忙抓漏——那些人眼因為太熟悉自己的故事而看不見的裂縫。
用分支實驗不同結構
多 POV 的結構有太多排列組合。順序、比例、切換頻率——每一種組合都會產生不同的閱讀節奏。在定稿之前，嘗試幾種不同的安排幾乎是必要的。
問題是，重新組織整本書的章節順序這件事，如果做錯了很難復原。
Slima 的 Branches 功能讓實驗變得零風險。建幾個分支，每個分支嘗試一種結構：
main - 按時間順序交替 POV（偵探→兇手→目擊者→偵探...）
experiment/detective-first - 先講完偵探的整條線，再切到其他角色
experiment/non-linear - 從結局開始，倒敘回到開端
experiment/equal-weight - 三個角色各佔 33%，而不是原本的 45/30/25
每個分支都是獨立的平行宇宙。在 experiment/detective-first 裡把整本書的結構打散重組——main 分支完全不受影響。實驗成功就合併回去，失敗就切回 main，實驗分支留著但不會干擾任何東西。
Version Control 面板（Cmd+Shift+G）可以隨時切換分支、比較不同分支之間的差異。結構性的大改動，做就是了。最壞的結果不過是切回主分支，一切如常。
系列總結：書籍即儲存庫
這是「書籍專案管理」系列的最後一篇。
傳統寫作工具把小說當作「一份很長的文件」。十萬字以下，這個思維沒問題。但當角色超過二十個、時間線有三條、POV 視角有五個——「一份文件」的模式會崩潰。不是工具出了問題，是思維模式碰到了天花板。
Slima 的核心理念是「書籍即儲存庫」。把小說當作一個有結構、有版本、有歷史紀錄的專案來管理。這個理念借鑑了軟體工程幾十年來的成熟實踐，但為作家的工作流程重新設計。
五篇文章，五個面向：
檔案組織搭建了專案的骨架。清晰的資料夾結構讓每份資料有明確的歸屬。File Tree 的拖曳排序取代了檔名排序——不再需要在檔名前面加 01、02、03。
角色資料庫守住了故事的靈魂。細節有記錄、有歸屬、有跡可循。AI Assistant 可以跨章節比對，確保角色在第三章和第三十章是同一個人——不會眼睛顏色換了、口頭禪變了、個性前後矛盾。
時間線管理追蹤了故事的邏輯。事件順序、時間間隔、資訊傳遞——這些細節出錯不會毀掉一部作品，但會留下永久的疤痕。系統性記錄比記憶可靠一百倍。
研究資料整合讓創作的養分隨手可及。研究服務寫作，不是阻礙寫作的藉口。資料和專案放在一起，查閱幾秒鐘的事，創作的流暢感不會被打斷。
多 POV 管理處理了敘事的複雜性。每個視角是一個獨立的主觀世界，邊界必須清晰，污染必須為零。
貫穿這一切的是 Version Control。快照讓修改變得大膽——隨時可以回頭。Branches 讓實驗變得安全——主線永遠受到保護。這種安全感會從根本上改變寫作的心態，從「小心翼翼不要弄壞東西」變成「放手嘗試，最壞不過復原」。
過去的作家管理複雜敘事，靠的是多年累積的心智模型和手工追蹤系統——便利貼、筆記本、牆上的圖表。今天有更強大的工具：一個能理解全書結構的 AI Assistant，一個追蹤所有變動的 Version Control 系統，一個讓資訊隨時三秒內找到的 File Tree 組織結構。
把認知負擔交給系統。專注在最重要的事情上——寫出好故事。
一切工具存在的意義，就是這個。