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 的更长讨论