本地优先写作工具：小说家把稿件留在自己电脑上

本地优先的写作工具：把稿件留在自己电脑上，但不孤立

云端写作工具的吸引力是真实的——浏览器一开就能写、自动保存、跨设备无缝。但对一部分作者，尤其是处于一部长篇深处的小说家来说，这种便利的背后藏着两个不容易当下察觉的代价。第一个是稿件归属：你的小说究竟”住”在哪里？如果你的工具明天关停、调整定价、被收购，你能不能、用多久把稿件原样取回来？第二个是离线可用性：飞行途中、咖啡馆 Wi-Fi 不稳、家里临时断网，你能不能继续写下去？这两个问题在工作顺利的时候不会浮现，但一旦出现，往往是在最不该出现的时刻。

Scribe local-first desktop workspace — Catalpas Atelier Scribe · Local-first writing

围绕这两个问题，“本地优先”（local-first）这个词在 2026 越来越频繁地出现在独立作者的讨论里。它常常被误解为”反对云”或”必须断网工作”，但本地优先并不是孤立。它的核心命题是：稿件的权威副本（source of truth）在你的本地硬盘上——可以同步、可以备份、可以协作，但当你按下保存时，写入的是一个你能完全掌控的本地文件。云只是你选择的扩展，而不是被迫接受的前提。

主流的云端写作工具——Google Docs、Notion、Atticus、Reedsy Book Editor——在易用性与协作上确实领先；它们对绝大多数作者也确实够用。本文不打算否定它们，只是为另一群作者——那些对稿件归属、对离线可用、对长线可移植性有更高敏感度的小说家——梳理一条本地优先的可行路线，并说明这条路线并不意味着放弃同步与协作。

下面从四个维度展开：数据归属、本地优先不等于孤立、用 Git 做版本与协作、以及 Catalpas Atelier Scribe 在这条路线上的落地形态。

数据归属：你的稿件住在哪里？

很多云端写作工具的”导出”功能是存在的，但常常隐藏在不显眼的位置，且导出格式不总是源稿。导出 PDF 不是导出源稿——PDF 是产物，重新编辑要回到原平台；导出 .docx 是把结构化文档拍扁成单一格式；某些工具的导出甚至会丢失内部链接、批注、嵌入资源。

更隐蔽的问题是长期可读性。十年后，你今天写在某个云端工具里的稿件还能不能用？这个问题没有人能给保证。但如果你的稿件是一个文件夹里的纯文本 Markdown 文件，再加上一组图片资源，那么十年后只要文本编辑器还能打开 .md、图片格式还在被支持，你的稿件就还能用。这种”格式不绑定具体工具”的属性，是本地优先最朴素也最重要的价值。

数据归属还包括未经同意的训练数据使用这件事。2026 的云端写作工具几乎都在条款里保留了对用户内容进行分析、改进服务、训练模型的权利。这些条款的边界对不同平台不同；对于一些作者，这种不确定性本身就是一个不能接受的状态。本地优先工具默认不上传任何内容——除非你主动连接同步服务。

本地优先不等于孤立

本地优先最容易被误解的一点是：它不意味着你必须放弃同步、协作、备份这些云端工具带来的好处。它只是改变了控制权的方向。

举个例子。你的小说稿在本地硬盘上，是一个文件夹结构：

my-novel/
├─ chapters/
│  ├─ 01.md
│  ├─ 02.md
│  └─ ...
├─ images/
└─ metadata.yaml

你可以把这个文件夹放进 Dropbox / iCloud / Google Drive，立刻获得跨设备同步——但同步的是你已经决定要同步的本地文件，而不是默认上传一切。你可以用 rclone 把它定时备份到任何对象存储；你可以把它放进 Git 仓库做版本管理。你可以授权某位合作编辑通过 Resilio Sync 与你共享同一份本地文件夹。这些都是”加在本地之上”的扩展，而不是”被云端取代”的退步。

这种结构的另一个好处是：当某一项云服务出问题（账号被锁、订阅过期、平台政策变更），你的稿件不会被锁住——它一直在你的硬盘上。云只是你选择的便利层。

用 Git 做协作与版本控制

对于愿意稍微学习一点工具的小说家，Git 把”版本管理”提升到了云端写作工具难以企及的精度。它对长篇写作的价值并不在于”提交”这个动作本身，而在于：

任意回退到历史快照——三个月前那一版结局比现在的版本更好？一条命令切回去，原稿就在那里。
分支实验不污染主稿——想试一条新的情节支线？开一个 branch 写一两章，不喜欢就丢掉，喜欢就合并回主线。
与编辑或合作者的精确协作——编辑在自己的 branch 上改稿，你在你的 branch 上写新章节，merge 时 Git 会精确告诉你哪些段落有冲突，逐段确认。

学习曲线确实存在——Git 在开始时不友好，需要花一两天理解 commit / branch / merge 的心智模型。但一旦熟悉，它给长篇创作带来的安全感远超云端”自动保存”。本地的 .md 文件加上 Git 仓库（推送到私有 GitHub / GitLab / 自建 Gitea），构成了一套既本地、又同步、又可协作的工作流——而所有这些的权威副本依然在你的硬盘里。

Catalpas Atelier Scribe：本地优先的工作环境

本地优先这件事，需要工具配合。如果你的写作工具坚持用专有格式（如 Scrivener 的 .scriv 包），即使文件在本地，本地优先的核心价值——纯文本可移植——也会打折扣。Catalpas Atelier Scribe 在三端原生应用的形态下，把本地优先做成了默认值。

源稿是文件夹里的 Markdown 每一章是一个 .md 文件，元数据是一份 YAML。这种结构可以被任意编辑器打开（VS Code、Obsidian、Sublime、甚至 Notepad），可以纳入 Git，可以被任何同步工具识别。Scribe 不会把稿件锁在专有数据库里。

本地默认，云端可选 Scribe 不强制账户登录、不强制云端同步。文件默认在你的本地路径下，云同步（Dropbox / iCloud / Google Drive 任选其一）只在你主动配置时生效。这种”默认本地，按需扩展”的姿态是本地优先工具的标志。

三端原生 + 完整工作流 Windows、macOS、Linux 三端均有原生客户端，所有 tier 在三端可用。从 Free 起步，写作 + CJK 竖排 + 图片导出免费可用；Plus 解锁 EPUB 3 与灰度/RGB PDF；Pro 提供 CMYK、自定义印刷母版、Ruby 注音、LaTeX 等完整印刷链路。Pro 早鸟 79.99 美元/年，常规 129.99 美元/年。

与同步工具的兼容 因为源稿是纯文本文件夹，Scribe 与任何文件级同步工具都天然兼容。你可以把项目放在 Dropbox 里实现跨机同步、放在 Git 里做版本与协作、放在 rclone 流水线里做异地备份——这些都是叠加在本地优先之上的选项，不需要 Scribe 内部支持。

如何做出你的选择

如果你已经在云端写作工具里写得很顺、对当前的协作与同步方式满意、且对数据归属问题不敏感，没有必要为了”本地优先”这个词强迫自己迁移。云端工具的便利是真实的。

但如果你在以下情况下，本地优先可能是更合适的选择：

你的稿件对你有长期价值，希望十年后仍能不依赖任何特定平台打开它；
你的工作场景包含频繁的离线时段（飞行、偏远写作旅居、网络不稳的环境）；
你对未经同意的训练数据使用、平台政策变更、订阅停止等不确定性敏感；
你愿意学一点 Git 或文件级同步工具，换来更精确的版本管理与协作；
你已经有了一套自己的备份与同步基础设施（NAS、私有 Git 服务器、对象存储），希望写作工具不与之冲突。

最好的本地优先工具，是和你已有的备份与同步习惯最合拍的那一款。从 Free 版本开始，用它写几个章节，看看它是否融入你的节奏。

延伸阅读：

在 Scribe 试用同一工作流 — Free 起步，Pro 早鸟限时锁价 →