MarkdownCo
返回博客
教學指南

Word 轉 Markdown 完整遷移指南：2026 實戰版

三百份 .docx 要搬進 Git 和 Obsidian？這篇用實測流程告訴你三種轉換方法、哪些格式會陣亡，以及匯出後必做的清理清單。

Word 轉 Markdown 完整遷移指南：2026 實戰版

這種請求通常聽起來很單純：「可以把這些 Word 檔搬進我們團隊的 Wiki 嗎？」

你打開共享硬碟，看到三百個 .docx 檔案。十年份的內部文件——規範、維運手冊、會議記錄、規格書——散落在命名方式亂七八糟的資料夾裡。沒有一份能乾淨地跑 diff，沒有一份能好好被搜尋。然後主管拍板決定：這一季結束前，全部都要轉成 Git 控管的 Markdown。

我自己做過兩次這種遷移。一次是合規檔案庫（約 200 個檔案），一次是工程團隊的知識庫（約 500 個檔案）。兩次學到的教訓都一樣：Word 轉 Markdown 從來不是一鍵搞定的工作。它是一條工作流水線——轉換、檢查、清理——真正吃時間的是清理那一步。

這篇指南要談的是實務上真正有效的做法：三種值得認識的轉換方法、哪些 Word 功能能撐過這趟旅程（哪些會悄悄陣亡），以及能幫你省下大把手動修補時間的轉換後檢查清單。

為什麼要把 Word 文件搬到 Markdown？

在談怎麼做之前，先講為什麼。如果團隊沒把理由講清楚，這場遷移通常做不完也撐不久。

  • 可 diff 的歷史紀錄。 Word 的 .docx 本質上是一包壓縮的 XML，對 Git 來說兩個版本就是兩坨隨機的二進位。Markdown 是純文字——每一次修改都是清清楚楚、讀得懂的 diff。
  • 可搜尋、可 grep。 rg "incident response" docs/ 掃過幾千份 Markdown 只要幾毫秒。同樣的事情在 Word 檔上要靠專有搜尋工具才辦得到。
  • 自動化友善。 Markdown 可以被靜態網站產生器、文件工具（Docusaurus、MkDocs、Nextra）、LLM 資料擷取流程、CI 系統、Linter 直接消化。Word 基本上只能被 Word 消化。
  • 長壽。 純文字檔的壽命超越軟體廠商。DOCX 目前是穩定格式，但老的二進位 .doc 能撐多久已經有點模糊了。

如果上面這些對你團隊都不適用，那大概就不用遷移。只要有一條打中痛點，那你就來對地方了。

哪些內容撐得過轉換，哪些會陣亡

說明哪些 Word 文件元素能在轉 Markdown 後存活、哪些會遺失的對照圖

事先把期待值講清楚，能省下最多時間。以下是我做過上百份轉換累積下來的觀察：

Word 功能（Word Feature）能不能保留？備註
標題樣式 Heading 1–6可以直接對應到 # 到 ######
粗體、斜體、底線粗體／斜體可以Markdown 沒有底線的原生語法（會變成斜體或 HTML <u>）
項目符號與編號清單多半可以巢狀太深有時會被攤平
超連結（Hyperlink）可以網址與連結文字都會保留
表格（Table）簡單表格可以合併儲存格、背景色、框線都會消失
行內圖片可以會被抽出到資料夾，連結會被改寫
註腳（Footnote）可以（GFM）會轉成 [^1] 語法
程式碼（套 Code 段落樣式）要看情況經常被攤平成純文字，沒有圍欄
數學方程式部分支援有機會轉成 LaTeX，有時會被攤平
追蹤修訂（Track Changes）不行請先接受或拒絕所有修訂
註解（Comment）不行轉檔前先處理或另外匯出
文字方塊、SmartArt、圖形不行會整個消失——先改成圖片或純文字
自動生成的目錄（TOC）不行用你新的文件工具重新產生
Word 功能變數（日期、交互參照）不行匯出前先轉成純文字

遷移時最常讓人崩潰的兩件事通常是：（1）看起來像標題，其實只是人工用粗體＋放大字型做出來的——這些會變成普通粗體，你的輸出就完全沒有結構；（2）有合併儲存格的表格，轉出來的樣子很醜而且得手動重建。

在開始批次轉檔之前，隨機抽十份原稿掃一遍，把這些問題標起來。花個三十分鐘，能幫你省下後面大量的重工。

方法一：線上轉換工具

如果是單一檔案或小批量（大概 50 份以內），我會推薦這個方法。這是從 .docx 到乾淨 Markdown 最快的路徑，完全不用設定環境。

  1. 打開我們的 Word 轉 Markdown 工具
  2. 把 .docx 拖進上傳區
  3. 預覽轉換後的 Markdown
  4. 下載 .md 檔（有圖片時會另外打包）

輸出採用 GitHub Flavored Markdown（GFM），所以表格、任務清單、註腳都會保留。標題會對應到 # 層級，清單維持原本的階層，超連結也會保留錨點文字。

值得一提的是：標準文件的轉換過程全部在瀏覽器內完成。如果你處理的檔案很大，或內容比較敏感，讓檔案不離開本機是真正的功能，不只是行銷話術。

不管是我們的還是其他家的線上工具，限制都差不多：不適合大量批次處理，也沒辦法塞進自動化流程。如果你有這類需求，直接跳到方法二。

方法二：Pandoc（適合批次與腳本）

終端機視窗顯示 Pandoc 指令正在把 Word 文件轉為 Markdown

Pandoc 是業界的通用文件轉換器。只要檔案數量多一點，或我想細調輸出，我就會搬出它。

最基本的指令

pandoc document.docx -o document.md

單一檔案就這樣。速度很快，輸出可讀性不錯，大多數常見 Word 功能開箱就能處理。但 Pandoc 真正的價值要搭上 flag 才看得出來。

三個值得認識的 flag

pandoc document.docx \
  -o document.md \
  --extract-media=./images \
  --wrap=none \
  --markdown-headings=atx
  • --extract-media=./images —— 把內嵌圖片從 DOCX 抽出來放進資料夾，同時改寫輸出裡的圖片連結。不加這個 flag，行內圖片會被默默丟掉。
  • --wrap=none —— 不讓 Pandoc 在約 80 字元處硬斷行。這很重要，因為硬斷行會讓散文類文件的 Git diff 變得難讀。
  • --markdown-headings=atx —— 強制使用 # Heading 語法，而不是舊的 setext 樣式（用 ==== 底線那種）。ATX 才是現在的主流寫法。

批次處理整個資料夾

for f in *.docx; do
  pandoc "$f" -o "${f%.docx}.md" --extract-media=./images --wrap=none
done

把這段丟進 shell 腳本，幾百個檔案幾分鐘就能處理完。遇到更大的檔案庫，再加上 trap 和 log，中途掛掉時才能續跑。

實戰上要注意的小地雷

  • 項目符號字元不一致。 Pandoc 有時用 -，有時用 *。如果你在意一致性，跑一下 sed -i 's/^\* /- /g'，或在編輯器的 Markdown 格式化器裡做設定。
  • 編號清單會無故重新計數。 Word 裡常有「延續編號」的隱形指令，Pandoc 看不懂，結果你會看到原本連貫的清單變成 1、2、1、2、3。手動掃一遍就能修。
  • 表格儲存格太長會亂掉。 Pandoc 已經盡力了，但 GFM 表格不像 Word 那樣支援儲存格內換行。特別複雜的表格，不如手動改寫成 HTML 區塊。

Pandoc 沒有 GUI，這同時是缺點（非技術同事沒辦法操作）也是優點（可以塞進任何 CI/CD 流程）。

方法三：用 Mammoth.js 做程式化轉換

如果你要做的是一條流水線——例如從 SharePoint 拉 DOCX、轉檔、commit 到 Git 的遷移腳本——那網頁 UI 或 subprocess 呼叫 Pandoc 可能都不合適。Mammoth.js 是一個 JavaScript 函式庫，可以直接在 Node.js 裡把 DOCX 轉成乾淨的 HTML 或 Markdown。

const mammoth = require("mammoth");

mammoth.convertToMarkdown({ path: "document.docx" })
  .then(result => {
    console.log(result.value); // 轉出來的 Markdown
    console.log(result.messages); // 不支援功能的警告訊息
  });

Mammoth 的價值在於它有明確的立場：它完全不理會 Word 的視覺樣式，只聚焦在語意結構上（標題、清單、表格）。預設輸出比 Pandoc 乾淨，代價是可調的東西比較少。如果是遷移結構大致一致的遺留檔案庫，我會先拿 Mammoth。如果文件格式各種奇形怪狀、排版很重，Pandoc 的彈性會贏。

Python 使用者也有類似的選擇，可以用 python-docx 搭配一個 Markdown 寫入器，不過那比較偏 DIY，不是現成的工具。

沒人會提醒你的清理步驟

Word 轉 Markdown 遷移後的清理檢查清單

轉換只會給你一份 .md 檔，不會給你一份你願意 commit 的 .md 檔。

以下是我標準的轉換後檢查清單。熟練之後大概每份文件五分鐘：

  1. 找找被漏掉的標題結構。 搜尋輸出裡那些看起來是標題、但實際上是一行 **Bold Text** 的行。這是有人在 Word 裡用粗體手工做標題，沒套 Heading 樣式。把它們升級成真正的 ## 標題。
  2. 檢查第一個表格。 如果這裡的表格看起來正常，其他大概也都正常。如果第一個就壞了，大家都壞了。
  3. 刪掉清單項目裡的空行。 Pandoc 偶爾會塞空行進去，打斷清單的連續性。
  4. 驗證圖片連結。 用 Markdown 預覽（VS Code 內建的就夠用）打開檔案，確認圖片都載得進來。
  5. 搜一下殘留垃圾。 常見殘渣：行尾的 \（Word 隱藏但 Markdown 會顯示的硬斷行）、{.underline} 這類樣式屬性、偷偷跑進來的 <span> 標籤。
  6. 檢查前 10 行和後 10 行。 Word 的頁首、頁尾、頁碼經常會溢到輸出裡，變成空內容或奇怪的殘渣。

大批量遷移時，第 5 和第 6 項可以寫成清理腳本自動化。其他項目還是需要人眼——至少在你對某一類文件養出夠敏銳的模式識別能力之前。

實戰案例：200 份合規檔案的遷移

這是我做那份合規檔案遷移的實際流程。從頭到尾花了兩天，處理完 200 份檔案。

第一天上午：來源檔案的分類盤點

寫了一個 Python 腳本，逐一打開每份 DOCX，統計標題、圖片、表格數量，並標出還開著追蹤修訂或留有註解的檔案。輸出是一份 CSV，按複雜度排序。這一步的目標不是修東西，只是把地形摸清楚。

第一天下午：批次轉換簡單的檔案

200 份裡大約 140 份屬於簡單型：沒圖片、表格單純、標題結構乾淨。用 Pandoc 搭配 --extract-media 和 --wrap=none 跑迴圈批次處理。隨機抽 20 份抽查，全部過關。

第二天上午：複雜檔案逐一處理

剩下的 60 份有問題——有合併儲存格的表格、內嵌試算表物件，或還有一堆追蹤修訂需要先找人審。這些我用線上轉換工具逐一處理，有時換不同 Pandoc flag 再跑一次，有時先把來源 DOCX 清乾淨再轉。

第二天下午：清理與提交

寫了一個清理腳本跑過 200 份轉好的檔案（移除 {.underline} 殘渣、統一項目符號、修好 Pandoc 的斷行輸出）。審過 diff，每 50 份為一批 commit，推上遷移分支。

如果我當初傻傻手動做——每份 Word 打開、複製貼到 Markdown 編輯器——起碼要兩週。這些轉換工具不是錦上添花，而是讓這個專案可行的關鍵。

常見問題與對應解法

表格在 Markdown 預覽裡看起來怪怪的

九成機率是原稿有合併儲存格，或某個儲存格內容很長。這兩種 GFM 表格都處理得不好。你的選項：手動用 GFM 重建表格、在 Markdown 裡塞 HTML <table> 區塊（大多數渲染器都支援）、或把表格拆成多個小表格。

圖片沒有出來

先確認轉換工具有沒有把圖片抽出來。Pandoc 不加 --extract-media 是不會抽的。線上工具通常會給你一個包含 Markdown 檔和 images/ 資料夾的 zip——確認兩邊都放對位置，而且 Markdown 裡的圖片路徑對得上。

輸出在行尾出現奇怪的反斜線

那是 Word 裡的硬斷行，Markdown 渲染成強制換行。如果原稿為了壓縮段落間距，在該用段落分隔的地方塞了換行，Pandoc 會原封不動保留。用 find-and-replace 把 \\$（行尾）清掉通常就好了。

轉完後標題層級不對

Word 文件經常從 Heading 2 或 Heading 3 開始（因為 Heading 1 被留給封面頁標題）。Markdown 的慣例是從 #（H1）起算。看你的文件系統怎麼呈現標題，可能得把所有層級往上推一階。用 sed 就能解決：sed -i 's/^## /# /; s/^### /## /; ...' file.md。

Markdown 看起來跟 Word 完全不像

這很正常。Markdown 描述的是結構，不是外觀。樣式由渲染 Markdown 的系統決定（GitHub、你的文件站、MkDocs 的 theme 等等）。如果真的需要視覺一致，PDF 才是對的目標——可以看我們的 Markdown 轉 PDF 教學，裡面介紹保留視覺設計的流程。

反向：Markdown 再轉回 Word

遷移完之後常會有人問：「如果要把 Markdown 寄給只會開 Word 的窗口怎麼辦？」這就是反向轉換——而且這個方向好做很多，因為 Markdown 能表達的東西有限，要翻譯的也就少。詳細流程可以看 Markdown 轉 Word 完整教學。

對常常在兩種格式間來回的團隊，我看過最可持續的做法是：Markdown 是 Git 裡的真相來源，Word 只在有人要審閱或註解時即時匯出。誰都不會在 Word 裡改了再併回去——這樣遷移成果才不會慢慢崩壞。

小結

Word 轉 Markdown 是一場遷移，不是按個按鈕的事。工具可以扛重——我們的線上工具處理單次檔案、Pandoc 處理批次、Mammoth.js 處理流水線——但真正的工夫在轉檔前的檢視，以及轉檔後的清理。

最省時間的兩個做法：

  1. 先分類盤點。 開始轉換前先搞清楚檔案庫裡有什麼。十五分鐘的抽樣，能讓你省下好幾小時的救火時間。
  2. 預留清理時間。 每份文件抓五分鐘做檢查與收尾。把它當成必經步驟，你對遷移時程的估算才會誠實。

如果你剛接觸 Markdown、不曉得輸出會長什麼樣子，可以從什麼是 Markdown 和基本語法教學開始。表格、註腳、任務清單這些進階功能，延伸語法參考裡有 GFM 支援範圍的完整說明。

如果你的遷移源頭是 Obsidian 而不是 Word，Obsidian 匯出教學會從頭到尾帶你走完那條路徑。

Word 轉 MarkdownMarkdownDOCX文件遷移格式轉換