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 的橫向對比 — 如果你想從工具對比角度先看一下兩者分工