Hi~ 我是 Eric。
工程師寫技術文章時，Markdown 很舒服。標題、程式碼、表格、版本差異都清楚，還能放進 Git 做版本控制。
但準備交稿時，出版社通常會說：「請給我 Word。」
麻煩就從這裡開始。
把 Markdown 貼進 Word 並不難，難的是貼完之後：程式碼跑版、表格寬度亂掉、Mermaid 不見、提示框要重畫、標題層級要重設，連原本很乾淨的清單都有機會多出奇怪黑點。稿件一長，這些小事會慢慢把寫作時間吃掉。
我開發 MD2DOC-Evolution ，就是想把這段「作者語言」到「出版社語言」之間的轉換做穩定。
它是一套開源的 Markdown → Word DOCX 出版工作台。作者保留原本的 Markdown 寫作方式，工具負責把文件結構、版型與出版語法轉成可編輯的 Word 書稿，再交給編輯或出版社做最後修訂。
早期版本的開發故事，我曾寫在 《寫書不再被 Word 搞瘋》 ；後來也分享過 如何用 Codex 把它重整成寫作工作台 。這篇不談開發過程，直接回答使用者最在意的幾件事：怎麼用、會產生什麼、適合誰，以及哪些工作最後還是要回到 Word。
本文依據 2026-07-29 的 MD2DOC-Evolution v2.0.0、公開文件與 Microsoft Word 官方說明撰寫。專案仍會持續更新，實際功能請以 GitHub README 與 線上版本 為準。
先講清楚：它不是 Word 的替代品
MD2DOC-Evolution 負責的是「把內容送進 Word 之前」的工作。
作者用 Markdown 描述章節、段落、清單、程式碼、圖片與圖表；Profile 管理紙張、邊界、裝訂空間和樣式；匯出後得到的 DOCX，才進入編輯校稿、分頁與印前檢查。
flowchart LR
A["Markdown、圖片與 AI 初稿"] --> B["MD2DOC-Evolution<br/>Parser 與連續預覽"]
B --> C["Profile<br/>紙張、邊界、裝訂與樣式"]
C --> D["可編輯 DOCX"]
D --> E["Word 更新目錄、修整分頁"]
E --> F["交給編輯、出版社或客戶"]我把它稱為「出版工作台」，而不是「轉檔按鈕」，原因也在這裡。單純把 .md 變成 .docx 很容易；真正有價值的是，轉換後仍保留可編輯的標題、清單、表格、目錄欄位與超連結，讓下一位接手的人可以繼續工作。
這條界線很重要。MD2DOC-Evolution 不會承諾「按一下就得到可直接印刷、每頁完全固定的完稿」。Word 版本、字型、印表機驅動與圖片尺寸都可能改變分頁。工具先處理大量、重複、容易出錯的結構工作；最後幾個換頁點，留給最了解書稿的人判斷。
哪些人會真的用到？
最直接的使用者，是用 Markdown 寫技術內容、最後卻必須交付 Word 的人。
- 技術書作者：書稿有大量程式碼、表格、Callout、角色對話或 Mermaid。
- 工程師與架構師：要把規格、操作手冊、架構說明交給不使用 Markdown 的客戶或同事。
- 出版社與編輯團隊：希望作者的來稿先符合一套基本版型，減少逐篇重做格式。
- 教材與內容團隊：同一份 Markdown 要長期維護，並定期輸出成可編輯 DOCX。
- 使用 AI 協助寫作的人：想讓 AI 整理章節與語法，但不希望 AI 猜頁碼、亂塞空行。
反過來說，如果內容只有幾頁純文字，而且從頭到尾都在 Word 裡協作，導入這套流程不一定比較省事。它最擅長的，是「內容有結構、來源需要版本控制、交付端又要求 Word」的交界處。
它能替哪些內容省下重工？
「把技術書轉成 Word」是最明顯的用途，但同一條產線也能處理其他需要反覆維護的文件。
技術書與電子書原稿
技術書的麻煩不只在文字量，而是內容種類太多。一章裡可能同時有程式碼、CLI 指令、比較表、架構圖、提示框與下載連結。MD2DOC-Evolution 能先把這些結構轉成一致的 Word 樣式，作者不必每章重新畫一次提示框，編輯也不用猜哪一段是程式碼。
內部操作手冊與 SOP
操作手冊會一直改。畫面更新、流程多一步、指令換版本，都可能需要重新發布。如果 Markdown 是來源，團隊可以在 Git 追蹤差異、審查修改，再定期匯出 Word 給行政、客服或稽核單位使用。
課程教材與訓練講義
工程課程常同時需要線上文件與可列印講義。講師可以維護一份 Markdown，把章節目標、示範程式碼、重點提醒與練習題整理好，再輸出 DOCX 交給教務或設計人員做最後編排。
規格文件與客戶交付
開發團隊習慣在儲存庫維護 API、架構與部署說明，客戶端卻未必會讀 Markdown。這時可以把同一份來源轉成可編輯 Word，讓客戶加註解、走簽核或納入既有文件管理系統。
這些情境的共同點很單純：內容會改，而且最後一哩需要 Word。只要兩個條件同時出現，保留 Markdown 來源通常就有價值。
三分鐘走完一次交稿流程
你可以直接打開 MD2DOC-Evolution 線上版 ，不需要先安裝軟體。
MD2DOC-Evolution v2.0 工作台：左側編輯 Markdown，右側即時檢查文件結構
第一步：先載入公開範例
第一次使用時，先從「範例稿件」選擇「中文快速範例」。如果想一次看完所有正式支援語法，就載入「中文完整功能稿」。
這比直接貼自己的五萬字書稿安全很多。你可以先確認章首頁、目錄、對話框、Callout、程式碼與 Mermaid 的輸出方式，再決定自己的稿件要怎麼整理。
如果中途忘了語法，可以打開「使用教學」。教學中心把快速開始、文件結構、常用語法、Profile、AI 轉稿、Word 後製與交付前檢查整理成十個章節，也能直接下載完整範例。
內建完整使用教學，從 Markdown 結構一路說明到 Word 交付檢查
第二步：貼上或匯入 Markdown
你可以直接在編輯器貼上內容，也可以按「匯入」選擇 .md 檔。圖片則能透過匯入或拖放加入本次瀏覽器工作階段。
工具列與「插入」選單提供常用結構，不必背完所有語法。桌機可以用分組工具列；手機或平板則使用同一套插入選單。
第三步：選擇 Profile、紙張與邊界
按「版面設定」，選擇文件 Profile。v2.0.0 內建三種出版社版型：
| Profile | 適合情境 | 17.6 × 23.6 cm 預設 |
|---|---|---|
publisher-exact | 預設版型，對齊目前的出版社幾何契約 | 上下 2.10 cm、左右 2.30 cm |
publisher-narrow | 想增加內容寬度，先觀察整體篇幅 | 四邊 1.27 cm |
publisher-binding | 雙面印刷，需要預留裝訂空間 | 鏡像內外側邊界，加 0.50 cm gutter |
紙張也能改成 A4、A5、B5 或自訂尺寸；常用邊界包含 1.27、1.50、2.00 與 2.54 cm。
版面設定會同步顯示文件 Profile、紙張尺寸、邊界與有效內容區域
第四步：用預覽檢查結構
預覽區使用連續白底內容流。你會看到標題層級、段落、表格、程式碼、Callout 與媒體是否正確，但它不會在瀏覽器裡畫出假的 Word 頁面。
我刻意這樣設計。瀏覽器切出來的「第 3 頁」，到了不同電腦的 Word 可能已經變成第 4 頁。與其給作者一個不可靠的頁碼，不如先把內容結構看清楚。
第五步：下載 Markdown，再匯出 DOCX
先下載一份 Markdown 備份，再按「匯出 DOCX」。如果圖片、Mermaid 或文件結構有問題，匯出前會先提示。
最後用 Word 開啟 DOCX：
- 按
Ctrl + A全選。 - 按
F9更新目錄與欄位。 - 如果目錄詢問更新方式，標題有變更時選「更新整個目錄」。
- 檢查章首頁、表格、圖片、程式碼與少數換頁點。
- 輸出 PDF，再逐頁確認一次。
Microsoft 的 Update fields 也說明了目錄、頁碼、交叉參照與其他欄位需要更新的情況。
匯出卡住時，先查這四個地方
轉換工具最怕只顯示「失敗」，卻不告訴作者該改哪裡。MD2DOC-Evolution 會在匯出前檢查常見問題；遇到狀況時，也可以依這個順序縮小範圍。
| 現象 | 優先檢查 |
|---|---|
| 目錄沒有頁碼或標題不完整 | 先在 Word 按 Ctrl + A、F9，標題有異動時更新整個目錄 |
| 圖片沒有出現在 DOCX | 確認圖片已匯入本次工作階段；遠端圖片需要明確允許載入 |
| Mermaid 無法匯出 | 先看預覽是否能渲染；圖太大超過安全 Canvas 上限時，拆成兩張較小的圖 |
| 換 Profile 後頁數改變 | 這是內容寬度改變的正常結果，先確定最終 Profile，再進 Word 齊頁 |
如果問題只發生在自己的長稿，先把內容縮成最小範例：保留一個出錯的表格、一段程式碼或一張 Mermaid，其他全部拿掉。接著記錄所選 Profile、紙張、邊界與 Word 版本，再到 GitHub Issue 回報。
這種最小重現比貼一句「我的 Word 壞掉了」有效得多，也能避免把私稿整份公開。
Markdown 寫的是「出版語意」
一般 Markdown 已經能處理標題、段落、清單、引用、程式碼、表格與圖片。MD2DOC-Evolution 再加上一層技術書稿常用的出版語法。
一份稿件可以從這個骨架開始：
---
title: "技術書名"
author: "作者姓名"
header: true
footer: true
---
[TOC]
[CHAPTER]
number: "01"
title: "第一章標題"
summary: "這一章會處理的問題。"
goals:
- "理解本章核心概念。"
- "完成可驗證的實作。"
[/CHAPTER]
# 第一章標題
## 第一節
正文內容。
[TOC] 會建立 Word 原生目錄欄位；[CHAPTER] 則描述章號、章名、摘要與學習目標。轉換器因此知道哪裡是目錄、哪裡是章首頁，不必靠空行硬推版面。
常見內容的轉換方式如下：
| Markdown 內容 | DOCX 中的結果 |
|---|---|
# 到 ### | H1 到 H3 標題與書籤 |
- item、1. item | Word 原生項目符號與編號 |
- [ ]、- [x] | ☐、☒ 待辦項目，不混入清單黑點 |
| 程式碼 fence | 可控制語言標籤與行號 |
| Mermaid | 在預覽與 DOCX 轉為圖像 |
| Markdown table | 可繼續編輯的 Word 表格 |
| 一般 Markdown 連結 | 可點擊的 hyperlink |
[QR:標籤] 加上括號網址 | 給紙本讀者掃描的明確 QR |
明確 QR 的完整寫法如下：
[QR:GitHub 原始碼](https://github.com/eric861129/MD2DOC-Evolution)
Callout 支援 NOTE、TIP、WARNING、IMPORTANT、CAUTION 五種；角色對話則能指定左側、右側或置中。匯出 Word 時，角色名稱與內容會分行，避免整段擠在同一行。
完整語法可以查閱專案的 Supported Syntax 與 完整使用教學 。
成品到底長什麼樣？
下面的畫面不是網站預覽或示意圖，而是 v2.0.0 中文完整功能稿使用 publisher-exact 匯出後，實際以 Microsoft Word 16.0 開啟、更新欄位，再從 Word 文件頁面擷取。
章首頁會把章號、標題、摘要、圖片與本章目標排成可閱讀的開場頁：
Microsoft Word 實際開啟後的章首頁
Callout、左右對話與表格會各自保留清楚的視覺層級。角色名稱也會獨立一行，不會被誤判成項目符號：
Microsoft Word 實際呈現的 Callout、角色對話與表格
技術書常見的比較表與程式碼區塊也能一起輸出。程式碼可以保留語言標籤，並依需求開啟或關閉行號：
Microsoft Word 實際呈現的多欄表格與程式碼區塊
圖片、紙本 QR 與 Mermaid 則會以媒體形式放進 DOCX：
Microsoft Word 實際呈現的圖片、圖說與 QR Code
Mermaid 流程圖在 Microsoft Word 中的實際效果
這些畫面有一個共同點：文字仍是文字，表格仍是表格，超連結仍可點擊。DOCX 不是把整份內容壓成一張張截圖。只有 Mermaid、QR 與圖片本來就是媒體，才會用圖像保存。
對出版社來說，這比「畫面看起來很像完稿」更實際。編輯能改標題、調段落、修表格，也能在既有文件結構上套用內部流程。
同一份稿，為什麼需要三種版型？
publisher-exact、publisher-narrow 與 publisher-binding 使用相同的出版內容與主要樣式，差別在頁面幾何。
以 17.6 × 23.6 cm 為例，publisher-exact 的內容寬度是 13.00 cm，publisher-narrow 是 15.06 cm。內容一樣，行寬不同，換行與總頁數自然可能改變。
所以 exact 的意思是「符合指定的紙張、邊界與樣式契約」，不是保證每一台電腦都產出相同頁碼。
publisher-binding 則使用鏡像邊界。奇數頁與偶數頁的內外側會交換，再加上 gutter 預留裝訂空間。網頁單頁預覽只能示意一側，最後仍要在 Word 的多頁或雙面檢視確認。
如果出版社有自己的完稿尺寸與邊界，建議先拿一個章節做樣張，確認以下項目：
- 紙張尺寸與上下、內外側邊界。
- 正文、標題、表格與程式碼字級。
- 頁首頁尾、頁碼位置與章首頁規則。
- 圖片解析度、圖說和跨頁表格處理方式。
- 最後由作者、編輯還是排版人員負責齊頁。
先把規則說清楚，再轉整本。這比整本匯出後才討論版型便宜太多。
樣章也不要挑最乾淨的前言。應該刻意選一章「難排」的內容：有較長的程式碼、六欄左右的表格、橫向容易超寬的 Mermaid、兩張不同尺寸的圖片，以及會跨頁的對話或 Callout。這些內容都能順利經過作者匯出、編輯修訂與 PDF 檢查，才算真的通過導入測試。
驗收時最好留下可重複的檢查表，不要只憑一句「看起來差不多」。下一位作者換了電腦、Word 版本或圖片素材後，團隊仍能用同一套標準判斷結果。
AI 可以幫忙整理，但不要讓它猜頁碼
網站內建「AI 轉稿提示 v2」，分成兩種模式。
「轉換既有稿件」適合手上已經有文章或章節的人。Prompt 會要求 AI 保留原始事實、程式碼、引用與來源連結，只整理標題、清單、表格、Callout 與對話。
「建立新稿初稿」則從主題、目標讀者、章節構想與可信素材開始。沒有提供的資訊必須標成「待補」，不能把猜測寫成作者經驗。
AI 轉稿提示 v2 提供「轉換既有稿件」與「建立新稿初稿」兩種模式
兩種模式都會要求 AI：
- 只回傳 Markdown 原稿，不要再包一層 code fence。
- 使用 Frontmatter、
[TOC]、[CHAPTER]、H1 到 H3。 - 保留程式碼、檔名、指令、API 與來源。
- 不偽造 Profile、頁碼、空白頁或分節符號。
- 不用大量 Enter 推版。
這個責任分工我很堅持。AI 很適合整理內容結構，卻看不到讀者最後會用哪一版 Word、哪套字型、哪台印表機。讓它預測「這段一定在第 87 頁」沒有意義。
完整規則可以看 AI Generation Guide v2 。
線上直接用，也能把工具留在自己手上
一般作者直接使用線上版最快。若出版社、公司或研究團隊有內部環境需求，也可以把 MIT 授權的原始碼拉回本機執行。
專案需要 Node.js 20.19+、22.12+ 或 24.0+，基本啟動方式如下：
git clone https://github.com/eric861129/MD2DOC-Evolution.git
cd MD2DOC-Evolution
npm install
npm run dev
預設開發網址是 http://localhost:3000/MD2DOC-Evolution/。
底層以 React 19、TypeScript 與 Vite 6 開發，Markdown 會先進入 Parser，轉成共用的內容區塊，再分別交給連續預覽與 DOCX builders。marked、docx、Mermaid 與 QR Code 各自負責對應能力。
這個拆法對長期維護很實用。編輯器按鈕、AI Prompt、公開範例、預覽與 DOCX 不應各自發明一套語法；它們都要回到同一份規格驗證。當專案新增一種語法時，也比較容易找出「網頁看得到，Word 卻沒有輸出」這類漂移。
本機執行能讓稿件留在受管理的環境，但仍要檢查字型、遠端圖片、部署方式與另外使用的 AI 服務。是否連外，取決於完整環境，不只取決於轉換器本身。
有些工作，我刻意不讓它假裝會
目前仍需要 Word 後製的內容包括：
- 精確頁碼、奇偶頁分節與章節起始頁。
- 複雜跨頁表格、索引、交叉參照與腳註。
- 出版社專屬巨集、文獻管理與特殊印前流程。
- 因字型、圖片或 Word 版本造成的個別換頁。
需要改變頁首頁尾、方向、欄數或奇偶頁章首頁時，才使用分節符號；單純要讓標題從新頁開始，優先考慮「段前分頁」等段落設定。Microsoft 也有完整的 Insert a section break 說明。
匯出後可以按 Ctrl + Shift + 8 顯示格式標記，檢查多餘 Enter、手動分頁、分節符號與段落設定。MD2DOC-Evolution 會避免把一般段落、對話或 Callout 誤套成 Word 清單，但作者後續編輯仍可能改變格式，交付前值得再看一次。
稿件主要留在瀏覽器，但隱私不能只寫一句「本機處理」
MD2DOC-Evolution 沒有書稿上傳 API，主要轉換在瀏覽器本機完成。遠端圖片 URL 預設不載入，只有使用者明確按下「載入遠端圖片」後才會發出請求，並使用 no-referrer。
但這不等於整個使用過程永遠沒有第三方連線。網站字型、部署平台、遠端圖片，以及你另外選擇的 AI 服務，都可能產生網路請求。
如果書稿含有個資、未公開產品資訊、合約內容或商業機密，先依組織政策處理。尤其把內容交給 AI 前，應先移除敏感資料，並確認所用 AI 服務的資料政策。
先拿第一章試一次
第一次評估 MD2DOC-Evolution，最好先拿一個夠真實的章節。
挑一章包含標題、清單、程式碼、表格與一張圖的內容，貼進
線上工作台
，選擇 publisher-exact 匯出，再用 Word 更新目錄與欄位。十分鐘後，你就能判斷這套流程是否比手動複製貼上省事。
如果你是出版社或編輯，也可以反過來做：拿一份既有的書稿規範，先定義紙張、邊界與樣式，再讓一位作者用同一個 Profile 交一章樣稿。真正值得導入的工具，應該讓作者比較容易寫，也讓後端編輯更容易接手。
這個專案採用 MIT License。如果你有出版社版型、特殊書稿語法或實際轉檔案例，也歡迎透過 GitHub Issue 提出。我更在意的，是下一個功能能不能少讓作者和編輯重做一次。
如果你實際用過後覺得好用，歡迎到 GitHub 幫 MD2DOC-Evolution 給個 Star ，滿足一下作者小小的虛榮心～ ⭐