Scribe 與 Notion：協作大綱到獨立稿件的切換點
Notion 擅長團隊大綱與素材協同，Scribe 擅長長稿成書。本文給出從 Notion 切到 Scribe 的時機、匯出 Markdown 時常見的結構丟失、以及出書後知識沉澱的去向。
Scribe 與 Notion：協作大綱到獨立稿件的切換點
Notion 是 2026 很多寫作合作圈用得最順手的協同工具。和 Obsidian 那種”個人深度筆記庫”的定位不同，Notion 真正的優勢是”幾個人能同時看到、同時編輯、同時討論一份內容”。共筆小說圈、IP 聯合開發、有責任編輯全程跟進的作者，都很容易在 Notion 上長出一份龐大的專案空間：大綱、人物表、參考資料、討論記錄、出版進度表，全部塞在同一個 workspace 裡。
但 Notion 不是寫正文的好地方。它的塊結構（block-based editor）對長篇連續閱讀不太友好——游標移動、上下翻頁、統計字數都比純文本編輯器慢半拍；它的”頁面”概念又讓一本書的章節邊界變得模糊，一不小心就會出現”第三章的後半段被分到子頁面裡”這種結構上的混亂。更現實的問題是 Notion 是雲端協作工具，所有內容都需要聯網編輯——這對長稿的”沉浸寫作”狀態不是好事，對一份還沒公開就需要嚴格控制訪問範圍的稿件也不是好事。
Catalpas Atelier Scribe 和 Notion 的關係比較像”前期協作 → 後期成稿”。Notion 留給那些必須多人參與的環節——商討大綱、收集素材、安排進度；Scribe 接手”一個人按章節寫下去”以及”匯出 EPUB 和印刷 PDF”這一段。兩個工具不衝突，關鍵是切換髮生在正確的位置。
Notion 適合做大綱，不適合寫正文
很多作者在試用 Notion 時會被它的靈活性迷住，一度想”是不是連正文也可以在這裡寫”。短期內是可以——一兩萬字的中篇、單線性的非虛構稿件，Notion 都能扛得住。但一本 8 萬字以上的長篇放進 Notion，會逐漸暴露幾個問題：
第一，長文件的編輯效能。Notion 在單頁超過幾萬字後，游標響應、自動儲存、滾動都會出現可感的延遲。這是 block-based 架構在長文件上的固有問題，不是某次版本更新能徹底解決的。第二，章節結構容易碎片化。Notion 的”sub-page”機制鼓勵你把每一章拆成一個子頁面，但當你想統一調整版式、統計總字數、或者從頭到尾通讀一遍時，跨子頁面的操作非常費勁。第三，離線與備份。Notion 的離線模式仍然有限，對長期稿件的”我必須能保證檔案躺在我硬盤裡”的訴求覆蓋不到。
這些不是 Notion 的設計錯誤，而是它作為”協作工作空間”和長稿寫作工具之間的本質差異。Notion 在自己的賽道里仍然非常優秀。
切換點：大綱凍結 + 第一章定稿之前
什麼時候從 Notion 切到 Scribe？經驗上有兩個判斷訊號疊在一起就是切換時機。
訊號一：大綱凍結——你和合作者（或編輯）已經在 Notion 上對完大綱，確認 80% 以上的章節順序、關鍵劇情節點、人物弧線，未來即使有調整也只是區域性。如果大綱還在大改，提前遷就會反覆同步兩邊，浪費工時。
訊號二：第一章定稿之前——還沒開始寫正文，或者只寫了一點試筆。如果已經在 Notion 上寫了五六章正文，再遷過來需要面對”既有正文要不要重新整理”的額外工作。這種情況發生時，最務實的做法是把已有正文當成”草稿”複製到 Scribe，然後在 Scribe 裡逐章順一遍——不要試圖”無損遷移”。
切到 Scribe 之後，Notion 上的大綱頁面不刪除，但明確標記為”參考態”——後續大綱的任何調整都要先在 Scribe 工程的大綱視圖裡發生，再回填到 Notion 讓合作者看到。這條規則的核心是”正文與大綱的最新版本只能活在一個地方”。
匯出 Notion 的坑：巢狀 toggle / database / sub-page
從 Notion 匯出到 Markdown 這一步幾乎一定會有損耗。最常見的三類丟失或變形，提前知道就能在切換前少踩幾個坑。
巢狀 toggle——Notion 的 toggle 塊（點選展開/摺疊）在匯出 Markdown 時會變成簡單的標題 + 縮排，巢狀層級超過兩層時容易亂套。如果你的大綱深度依賴 toggle 的摺疊效果，建議在匯出前把它平鋪成 H2/H3 標題。
database——Notion 的 database（人物表、章節表、待辦表）匯出後會變成普通表格或者一坨連結，結構關係大部分會丟。最穩的做法是匯出前手動把每張關鍵 database 截圖、並把核心欄位複製成 Markdown 表格存到一份單獨檔案裡。指望”匯出之後再重建關係”基本不可能。
sub-page——子頁面在 Markdown 匯出裡預設會變成一個個獨立資料夾和檔案，連結關係會被打散。如果你在 Notion 裡大量使用 sub-page 組織內容，匯出之後會得到一堆鬆散的 .md 檔案，需要手動重新拼。
知道這些坑之後，反推的最佳做法是：遷過來的內容只挑”大綱 + 人物表的核心欄位”，不要嘗試把整個 Notion workspace 映象到本地。Notion 那邊的協作空間繼續保留並繼續維護——它是合作流程的載體，不是稿件本身。
出書後：知識沉澱去向
一本書寫完、上架之後，Notion 上那個專案頁面的去向也是值得提前規劃的。最常見的兩種做法：
歸檔為參考資料——把這個 workspace 標記為”已完結”，許可權改成只讀，作為後續作品的參考庫繼續放在 Notion 裡。如果你和同一批合作者還會繼續合作，這種做法成本最低。
沉澱到個人知識庫——如果你同時維護著 Obsidian vault 或類似的長期知識系統，可以把 Notion 上”跨專案複用價值”的內容（世界觀、共享設定、研究材料）單獨匯出後併入個人庫；專案專屬的進度表、討論記錄就讓它留在 Notion 裡。
不要做的是——把 Notion 上的全部內容硬塞進 Scribe 工程或本地存檔裡”以防丟失”。Scribe 工程是這本書的成稿，不是專案的歸檔庫；硬塞進去會讓工程檔案臃腫，匯出時也會出現莫名其妙的版式問題。
Notion 和 Scribe 長期共存的理由很簡單：協作不會消失（下一本書你可能還要和編輯一起做大綱），成書也不會消失（每一本都需要一份能交付出去的 EPUB 和印刷 PDF）。兩個工具各自負責自己擅長的那段，工作流就會清爽很多。
你可能也想看
- Scribe 協作指南合集 — 與其他寫作 / 筆記 / 審校工具的協作工作流入口
- Scribe 與 Obsidian：知識庫 + 稿件的兩段式工作流 — 如果你同時還在用 Obsidian 維護個人知識庫