Scribe 与 Word：docx 桥接的来回审校工作流
编辑、合作者、出版社往往只接受 Word（或同类）。本文讲清楚 Scribe 与 docx 之间的桥接路径、来回审校的版本控制、以及什么时候应当离开 Word 回到 Markdown 这一侧。
Scribe 与 Word：docx 桥接的来回审校工作流
无论作者本人用什么写作工具，Microsoft Word 仍是 2026 出版与编辑流程里最常见的”中转格式”。责任编辑、文字编辑、版权代理、合作作者、传统出版社的内审流程，大部分仍以 .docx 为通用语言。即使你已经用 Markdown 写作多年、即使你打算最终自出版而不走传统渠道，只要在创作链路上有一个环节涉及他人，几乎都绕不开 docx。这一篇所说的”Word”，也覆盖那些能读写 docx 的同类工具——LibreOffice Writer、Apple Pages、Google Docs、WPS——它们的协作模式与 docx 的局限是共通的。
Catalpas Atelier Scribe 的定位不是要替换 Word，也不是去和它的协作功能正面比拼。Scribe 在这条流程里负责”作者侧的正文与出书”，Word 在编辑那一侧负责”批注、修订、走流程”。两者之间通过 docx 这个桥梁来回传递。问题不在于”用哪个”，在于”什么时候把稿子交给 docx、什么时候把它接回来”。
现实是：合作者只接受 docx
对独立作者而言，承认这件事比对抗它划算得多。即使你身边的编辑也是技术派、原则上能读 Markdown，等到真的进入审校阶段时，他们要使用的不是阅读能力，而是**追踪修订（Track Changes）+ 批注（Comments）**这一整套基于 Word 的协作惯例。Markdown 没有同等成熟的可视化审校体系——CriticMarkup 这一类标记可以在小圈子内通行，但拿不出”我希望责任编辑两小时内能看完我整本书的所有修改”这种体验。
所以现实工作流通常是这样的：你在 Scribe 里写正文、组织章节、做局部修改；当稿件需要交给合作者审一轮时，导出一份 docx；对方在 Word（或 LibreOffice、Pages、Google Docs）里用追踪修订与批注做完工作发回来；你回到 Scribe 这边，把对方的修改”翻译”回正文。每一轮往返都伴随一次格式转换，于是问题变成了：怎么让这次转换的成本尽可能小。
docx 桥接：哪些会带过去、哪些会丢
Scribe 导出 docx 时（以及反过来把别人改回来的 docx 拉进 Scribe 时），有几类内容的命运需要提前知道。
结构与章节标题会被相对忠实地保留——Heading 1 / Heading 2 等映射在两边都比较稳定。这意味着对方在 Word 里调整章节顺序、改章节标题，回到 Scribe 这边能识别出来。
段落正文与基本格式（粗体、斜体、引用块）也能跨格式生存。但段间距、行高、字号这些被 Scribe 工程”版式设定”统一控制的属性，不应该在 docx 里被对方手动改——一旦改了，回来这边要么被 Scribe 的版式覆盖、要么造成局部不一致。建议在交付 docx 时就跟编辑说清楚：“请只改文字与结构，版式留给我这边统一处理。”
追踪修订是这个流程里最有价值的东西——它能精确告诉你”在哪一段、加了什么、删了什么、谁加的、什么时候加的”。Scribe 这一侧应当把对方发回的 docx 留作”参考文件”，逐条对照修订记录、决定接受还是拒绝，再在 Scribe 工程里手动落实。不要尝试自动合并——目前没有任何工具能在 Markdown ↔ docx 双向往返中无损保留追踪修订，省下来的几分钟不够你后面排错。
批注也类似——Scribe 这一侧把 docx 里的批注当成”待办清单”，逐条处理后在 Scribe 里改正文，处理完归档原 docx。批注不需要、也不应该跟正文一起活在 Scribe 工程里。
会丢的东西：复杂表格、嵌入对象（公式、图表、SmartArt）、文本框、各种自定义样式。绝大多数小说稿用不到这些；如果你写的是带大量图表的非虚构稿，需要预先和编辑约定”图表暂时不动，只审正文”的工作方式，避免来回每一轮都重新插一次图。
来回审校的版本控制
涉及到来回两三轮的审校时，文件命名与归档比你想象的更重要。一个稳定的做法：
- 每次从 Scribe 导出给编辑时：
书名_v0.3_to-editor_20XX-MM-DD.docx - 编辑发回时：
书名_v0.3_from-editor_20XX-MM-DD.docx - 你处理完后，在 Scribe 工程里把版本号推进到
v0.4，再开始下一轮
这样做的关键不是文件名好看，而是任何时刻你都能回答”现在编辑那边手里是哪一版”以及”我和编辑之间有没有版本错位”。正文的最新版本永远活在 Scribe 工程里——发出去的 docx 是它的”快照”，发回来的 docx 是带批注的”反馈”，但都不是真相本身。
第二条规则：编辑回稿到达后，先别急着改 Scribe。先通读一遍发回来的 docx，对每一条修订与批注做个判断（接受/拒绝/讨论），然后把决定批量带回 Scribe。这样做比”一边读 docx 一边改 Scribe”快得多，也减少版本错位的概率。
何时离开 Word 这一侧：知识沉淀回 Markdown
最后一个判断点：什么时候不应该再走 docx 桥接？
如果你正在做的是自出版、且当前只是个人初稿阶段，那连第一轮都不需要走 docx——直接在 Scribe 里写完、自己回读、修改、出 EPUB 与印刷 PDF。docx 只在”需要给另一个人看并接受 ta 的修改”时才有价值。
如果你已经走完了主审与校对两到三轮，最后的定稿阶段就该彻底回到 Scribe 这一侧：从这里之后所有改动只在 Scribe 工程里发生，不再有”再发一版 docx 给某人确认”的循环。这是因为每一次往返都会引入一点格式与版式风险，到了印前阶段没有必要再冒。
什么时候应当完全跳过 Word？当合作者本身就接受 Markdown 协作（少数技术派编辑、合写小圈子）、且不依赖追踪修订这一套体系时——这时候你可以用 git diff 或 Scribe 内置的版本比较来沟通改动，比 docx 来回更轻。但请如实评估对方的工具习惯，不要让”我希望对方接受 Markdown”压倒”对方真实的工作方式”。
你可能也想看
- Scribe 协作指南合集 — 与其他写作 / 笔记 / 审校工具的协作工作流入口
- Scribe 与 Microsoft Word 的横向对比 — 如果你想从工具对比角度先看一下两者分工