Scribe 與 Obsidian：知識庫 + 稿件的兩段式工作流
Obsidian 適合養設定與素材，Scribe 適合長稿成書。把它們分工清楚，可以避免筆記和稿件互相汙染，也避免一份內容兩邊維護。
Scribe 與 Obsidian：知識庫 + 稿件的兩段式工作流
Obsidian 是 2026 這一代獨立寫作者最常用的筆記與知識管理工具之一。它的雙向連結、本地 Markdown 檔案、外掛生態，讓它在”養一份長期的素材庫”這件事上幾乎沒有對手。很多作者寫完一本書，回頭看會發現：真正花時間的不是動筆那幾百小時，而是那個跑了好幾年、塞滿人物檔案、時間線、設定細節的 vault。
問題是 Obsidian 的強項也是它在”成書”那一步的短板。一份 vault 不是一份稿件：它沒有線性的”章節順序”概念，匯出 PDF/EPUB 時雙鏈 wikilink 會變成普通文本、模板外掛生成的 YAML 塊會留在正文裡、上百個零散筆記之間沒有統一的版式與字號體系。這些不是 Obsidian 設計上的缺陷，而是它作為”知識工具”和”稿件工具”兩類產品本質上的差別。試圖讓 vault 直接出書，往往是用錯了工具。
Catalpas Atelier Scribe 在這套流程裡扮演的不是 Obsidian 的替代品，而是它的下游。Obsidian 負責”長期養著”——設定庫、人物表、研究筆記、靈感碎片；Scribe 負責”這本書”——線性章節、版式、最終 EPUB 與印刷 PDF。兩個工具的邊界一旦劃清楚，作者就不用再糾結”這條筆記該寫在哪裡”或”vault 裡的章節稿要不要繼續在那邊改”。
Vault 不是稿件：為什麼不要硬把它當稿件用
很多剛開始用 Obsidian 的作者會嘗試在 vault 裡直接寫章節檔案——一篇筆記一個章節、按 01-序章.md、02-第一章.md 命名。這種做法在前 10 個章節看起來還行，到了 50 個章節、加上修訂版本、加上”我想在 chap 12 之前插一段倒敘”這種結構調整，問題就開始堆。Obsidian 檔案瀏覽器沒有針對長篇稿件的章節排序、批次重排、版本快照功能；它的搜尋擅長找”哪條筆記提到過這個人物”，不擅長回答”我這一稿和上一稿之間這一段改了什麼”。
更要命的是匯出。Obsidian 官方的 PDF 匯出會原樣保留 Markdown 渲染樣式，對印刷既不夠精細也不夠穩定；社群外掛（如 Pandoc Plugin、Better Export）可以做更復雜的匯出，但配置成本很高，而且每次升級 Obsidian 或外掛都可能讓匯出流程突然報錯。真正決定要不要”在 vault 裡寫章節”的關鍵不是技術上能不能做，而是當你寫到第 80% 時，vault 是會幫你還是絆你。絕大多數走完整本書的作者會告訴你：從某一刻起，vault 開始絆腳。
兩段式工作流：在哪裡切換
更可持續的做法是把 Obsidian 和 Scribe 拆成兩段，並明確切換點。
第一段（在 Obsidian 裡）——所有還沒成形的內容都在這裡。人物檔案、世界觀設定、研究剪報、靈感碎片、章節大致順序、甚至每一章的開頭一兩段試筆。這一階段的特點是”資訊密集、結構鬆散”，需要的是 vault 的雙鏈與搜尋能力。你可以維持一個長期的 vault，把它當成你這十年寫作的”地基”，跨專案複用。
切換點——當你對某一個專案的大綱已經穩定，準備進入”按章節順序逐章寫出正文”這一段時，就是切換的時候。判斷的標誌通常是：你已經能列出至少 80% 的章節標題，並且每一章能用一兩句話說清楚要寫什麼。在這個點之前留在 Obsidian 是對的；之後留在 Obsidian 反而會讓進度變慢。
第二段（在 Scribe 裡）——把大綱落到一份獨立的 Scribe 工程裡。這裡的工程結構以”章節”為一等公民、有版式與字號的統一設定、有 EPUB 和印刷 PDF 的匯出路徑。從這一刻起，正文的最新版本只活在 Scribe 工程裡，Obsidian 那邊的章節稿（如果之前在寫）就降格為”參考”，不再回頭改。
這種”兩段式”的核心不是技術，而是紀律：明確規定哪一段的產出住在哪個工具裡，不讓正文版本同時活在兩邊。一旦正文同時在兩邊維護，工作量會以 1.5 倍的速度膨脹，而錯版的風險也會成倍增加。
資產搬遷：哪些帶走、哪些原地不動
第二段開始時，需要從 vault 拉一些東西過來——但不是全部。
直接帶走：本專案的章節大綱（如果之前在 vault 裡寫過）、人物卡的核心欄位（姓名、關係、貫穿本書的關鍵設定）、本書需要直接出現的引文與材料。這些內容需要在稿件裡被反覆查閱，留在 vault 裡跨工具切換太費。帶的時候建議手動複製，不要試圖”批次同步”——批次同步系統是另一個需要長期維護的副業，對獨立作者不划算。
原地不動：vault 裡跨專案複用的設定庫（比如你寫的系列共享同一個世界觀）、研究筆記（你可能在第三本書還會用）、靈感碎片（絕大多數不會進入這本書）。這些東西留在 Obsidian 裡，需要時去查就好，硬塞進 Scribe 工程會讓稿件檔案變得臃腫。
搬遷的格式坑：從 vault 複製貼上的文本，最容易帶過來的兩類雜質是 wikilink（[[某人物]]）和模板生成的 YAML 塊。wikilink 在 Scribe 裡不會自動解析，需要在帶過來時就轉換為普通文本——或者乾脆用 Obsidian 的”複製為 Markdown”功能去掉雙鏈。YAML 塊如果不是 Scribe 工程檔案需要的欄位，就直接刪掉。這兩步處理不復雜，但如果跳過，會在後面匯出時變成需要排查的”為什麼這段文字格式不對”的小bug。
雙工具長期共存：這不是臨時方案
很多文章談”工具遷移”時預設終點是”全部換成一個工具”。Obsidian + Scribe 的組合不是遷移關係，而是長期共存。理由也很簡單：vault 是你十年的資產，不會因為這本書寫完就停止生長；Scribe 工程是這一本書的”成稿態”，下一本書會開新的工程。兩個工具的生命週期本來就不同步。
接受這個事實之後，工作流會清爽很多——你不再糾結”以後要不要換掉其中一個”，也不會浪費時間研究各種”即時雙向同步”的奇技淫巧。Obsidian 那邊繼續養你的知識庫，Scribe 這邊繼續出你的下一本書。兩段之間的切換是手動的、有意識的、按專案發生的——這本身就是好事，因為它強迫你在切換點確認”這本書的大綱真的穩定了嗎”。
如果你已經在 Obsidian 裡養著一份龐大的 vault，又在為”怎麼把它變成下一本書”發愁，那麼你需要的可能不是更多的 Obsidian 外掛，而是把”成書”這一段單獨拆給一個專門做這件事的工具。Scribe 試圖做的就是這一段。
你可能也想看
- Scribe 協作指南合集 — 與其他寫作 / 筆記 / 審校工具的協作工作流入口
- 本地優先的寫作軟體 — 關於本地檔案 + Markdown 的更長討論