Obsidian 匯出 Word 完整攻略：保留雙向連結與附件

如果你平常在 Obsidian 裡工作，大概早就碰過這個痛點。你花了三個月整理一份研究筆記，裡面塞滿 Obsidian 特有的語法，像是這幾種：

[[Project Plan]]        → link to another note
![[diagram.png]]        → embedded image
> [!note] Key insight   → callout block

然後同事跟你要 Word 版本——每一個非標準元素都原形畢露。

我第一次遇到這個狀況，是要把一份 40 頁的技術調查交給一位不碰 Obsidian 的主管。在 vault 裡看起來精緻的排版，匯出到 Word 之後變成滿滿的中括號和孤立的圖片佔位符。那次之後又處理了好幾次類似的交接，我才慢慢整理出一套真正撐得住的流程。這篇就是整套流程——包含多數人會跳過的預處理步驟、三個真正會出包的 Obsidian 特有語法，以及圖片或 callout 不配合時的應變方式。

為什麼 Obsidian 的 Markdown 不通用（以及會壞在哪裡）

Obsidian 把筆記存成純文字 .md 檔，所以大家直覺以為匯出 Word 是一件小事。其實不是——因為 Obsidian 在標準 Markdown 之上疊了一層擴充語法，通用轉換器根本不認得。

這四個擴充功能幾乎是每次匯出失敗的元兇：

標準的 Markdown 轉換器——Pandoc、大多數線上工具——會把 [[...]] 當純文字，![[...]] 直接視為無法辨識的 token。你在 Obsidian 裡看到的漂亮畫面是預覽，不是原始碼。這個差異是多數「為什麼我的匯出壞掉」的根本原因。

還有一個比較隱微的問題：附件路徑。Obsidian 解析 ![[image.png]] 的方式是在整個 vault 裡搜尋對應檔名，不管它放在哪個資料夾。標準 Markdown 需要明確的相對路徑。如果你的附件放在 99 Attachments/，筆記放在 10 Projects/，那條圖片連結在任何轉換器吃下去之前都需要先改寫。

匯出之前：那個能救你一命的預處理步驟

我整個流程最大的可靠度提升，來自於在跑任何轉換器之前先做 5 分鐘的預處理。跳過這一步，你後面要花 30 分鐘在 Word 裡收拾殘局。

步驟 1：檢查附件設定

打開 Settings → Files and links，記下兩個值：

• Default location for new attachments——新圖片/PDF 會存到哪裡
• New link format——Obsidian 寫路徑的方式（Shortest path when possible、Relative path to file 或 Absolute path in vault）

如果這個設定停在 Shortest path when possible（Obsidian 預設值），只要附件不在筆記同一層資料夾，匯出就會壞。匯出前請切到 Relative path to file。這個設定只影響之後新寫的連結——既有連結要等到被改寫才會更新格式。下面的步驟 2 就是做這件事。

步驟 2：把 wikilinks 轉成標準 Markdown 連結

Obsidian 內建了一個開關：Settings → Files and links → Use [[Wikilinks]] → OFF。關掉之後，新連結會寫成 [Note Name](Note-Name.md)。但這只影響新的連結。

要把既有的 [[wikilinks]] 也一起轉掉，你有兩個選擇：

1. 小量匯出用手動——在筆記裡按 Cmd/Ctrl+F，找每一個 [[ 改寫掉。5 頁以內的筆記這樣做可以。
2. 大 vault 用社群外掛——打開 Settings → Community plugins，搜尋 "link converter" 或 "markdown links" 之類的關鍵字。生態系裡有好幾個外掛可以把 wikilinks（以及 ![[...]] 這種嵌入附件）批次轉成標準 Markdown 語法，能針對單一檔案或整個資料夾處理。挑一個近期還有更新、下載量夠多的版本。

轉換完，你的嵌入附件會變成 ![image.png](path/to/image.png)。檢查一下輸出——如果你的附件資料夾名稱有空格，記得做 URL 編碼（My%20Vault/attachment.png），不然轉換器會悄悄把圖片吃掉。

步驟 3：決定 callouts 怎麼處理

Obsidian 的 callouts（> [!note]、> [!warning] 等）在 vault 裡很實用，但在 Word 裡沒有對應元素。你有三種做法，依工作量排序：

• 接受降級——會渲染成普通的引用區塊。callout 類型（note/warning/tip）會遺失，但內容會留著。多數交接情境下這樣就夠了。
• 手動改寫重要的那幾個——匯出前把 > [!warning] Critical 改成 > **⚠️ Critical:**。兩邊都看得懂。
• Word 裡後處理——用 Word 的快速樣式把引用區塊變成有框線的方塊。只有要做精緻交付物才值得。

20 頁以下的文件我用方案 2，其他一律用方案 1。

步驟 4：把 Dataview 區塊匯出為靜態內容

如果筆記裡有 Dataview 查詢，匯出時跑出來的是查詢語法，不是結果表格。匯出前請先在 Obsidian 裡執行查詢，把渲染出的結果複製下來，以靜態 Markdown 表格的形式取代原本的程式碼區塊。對，這是手工活。沒有，沒什麼漂亮的方法可以繞過——Dataview 是在前端渲染的，原始檔裡實際上就是沒有那份資料。

四步驟匯出流程

預處理做完之後，實際的轉換其實很單純。

1. 複製筆記（不要就地匯出）

把目標筆記和它的附件複製一份到 vault 外面的暫存資料夾。你不會想讓預處理的編輯（連結改寫、callout 替換）污染主 vault。我在桌面上固定開一個叫 _export-staging/ 的資料夾專門放這些。

2. 扁平化附件路徑

把所有被參照的圖片移到跟 .md 檔同一層的資料夾，並把連結改成單純的檔名：![diagram](diagram.png) 而不是 ![diagram](../../99 Attachments/diagram.png)。多數轉換器對於往上跳好幾層的路徑都處理得很勉強。

3. 跑轉換器

把預處理好的 .md 檔上傳到 MarkFlow 的 Markdown 轉 Word 工具。它支援 GitHub Flavored Markdown（GFM），包含表格、任務清單和註腳，預處理之後 Obsidian 會產出的所有標準功能都涵蓋了。圖片會內嵌、程式碼區塊會保留語法高亮、標題會對應到 Word 的標題樣式，所以輸出的 DOCX 在 Word 裡的導覽窗格就能正常運作。

如果筆記裡有 LaTeX 數學公式（$E=mc^2$ 或 $$...$$），記得確認你選的轉換器會把它保留成 Word 方程式，而不是攤平成純文字。對於公式很多的筆記——研究紀錄、學術草稿——這是決定成敗的關鍵功能。如果 Word 不是最終目標，只是需要一個可以分享的檔案，那 Markdown 轉 PDF 可以直接避開 Word 處理方程式的各種眉角。

4. 在 Word 裡做最後調整

打開 DOCX，如果有既有的 Word 範本就套上去。Markdown 的標題樣式會乾淨地對應到 Word 內建的標題 1/2/3，所以整份文件重新套樣式就是 Design → Document Formatting 一鍵的事。送出前檢查這三件事：

• 目錄——透過 References → Table of Contents 插入一個，驗證所有標題都正確被辨識
• 圖片尺寸——Obsidian 是用原始大小顯示，Word 可能會放大。有需要就全選統一縮放
• 超連結——外部連結應該是可點的；內部 [[wikilinks]] 應該已經被解析掉或刪除

Obsidian 特有的幾個邊緣情況

有幾個場景出現頻率夠高，值得單獨講一下。

每日筆記和模板

如果你要匯出使用 {{date}} 或 Templater 變數的每日筆記，Obsidian 先把變數代換掉，匯出的 .md 裡已經是真實日期，不是佔位符。不需要特別處理。唯一的例外是你沒打開筆記就直接從檔案系統複製出來——這樣尚未解析的模板會漏出來。請先在 Obsidian 裡打開筆記讓它渲染一次，再進行匯出。

Canvas 檔案

Obsidian canvas（.canvas）檔是 JSON 不是 Markdown，沒有任何 Markdown 轉換器吃得動。對於 canvas，可行的辦法是把它縮放到你要的比例後截圖存成 PNG，然後在一則包裝用的 Markdown 筆記裡嵌入這張圖，拿那則筆記去匯出。如果這種需求多到值得裝外掛，社群裡也有幾款外掛提供「匯出 canvas 成圖片」的直接功能。

Mermaid 圖表

標記 mermaid 的圍籬式程式碼區塊在 Obsidian 裡會渲染成圖表。大部分線上 Markdown 轉 Word 工具要嘛把它渲染成圖片（好事），要嘛留著原始碼（慘事）。MarkFlow 會在轉換前把 Mermaid 渲染成內嵌 SVG，Word 會當成可編輯的圖片顯示。如果你選的轉換器不支援 Mermaid，退路是在 Obsidian 的預覽裡把圖匯出成 PNG，再把程式碼區塊換成標準的圖片嵌入。

註腳

好消息——Obsidian 的註腳語法（[^1] 以及定義 [^1]: text）是標準 GFM，會乾淨地轉換成 Word 內建的註腳功能。不用預處理。

標籤和 frontmatter

YAML frontmatter（筆記最上方用 --- 包起來的區塊）通常會被轉換器剝掉。如果 frontmatter 裡有讀者需要知道的資訊（作者、日期、狀態），匯出前把它移到內文變成一個普通段落。行內標籤像 #project/research 通常會以純文字保留下來——多數情況沒關係，但偶爾會有點尷尬。如果這份 Word 文件會給非 Obsidian 使用者看，用尋找取代把它們清掉。

什麼時候手動轉換比自動化更快

老實說：一則 2-3 頁、格式簡單的筆記，最快的做法是從 Obsidian 的閱讀模式複製，然後貼到 Word。Obsidian 的閱讀模式渲染的是 HTML，Word 貼上 HTML 會保留相當高的格式忠實度。表格進得去、粗體/斜體會保留、標題會對應到 Word 的標題樣式。

但「從閱讀模式複製」這招在三個地方會失敗：

1. 圖片——會貼成指向 vault 裡檔案的連結參照，檔案一離開你的電腦就壞了
2. 程式碼區塊——語法高亮會消失，等寬字型也不一致
3. callouts 和 Mermaid——跟標準匯出一樣會壞

所以：短、沒程式碼也沒圖片的筆記 → 直接貼。比較長或技術性的 → 走上面那套四步驟流程。

疑難排解：東西壞掉的時候怎麼辦

以下是我最常遇到的失敗情境。如果想要更完整的參考，Markdown 轉換疑難排解指南 整理了 15 個常見轉換問題的詳細解法。

Word 檔裡圖片不見了。 九成是路徑問題。檢查 .md 原始檔——附件路徑是單純的檔名（image.png）還是複雜的相對路徑（../../99 Attachments/My Folder/image.png）？把路徑扁平化。

表格擠成一條線。 你的原始檔用的是 Obsidian 早期的表格格式，或管道符不一致。用純文字編輯器打開 .md，確認每一列的管道符數量相同。表頭分隔列也要對齊：| --- | --- |。

程式碼區塊的語言顏色消失。 檢查圍籬後面有沒有接語言標籤（例如 python、js、bash）就放在三個反引號後面。轉換器是靠這個標籤決定要套哪種語法高亮；沒標的會退回純文字。

匯出後 wikilinks 仍然顯示 [[Note Name]]。 預處理沒跑，或者沒涵蓋到這個檔案。確認 Use [[Wikilinks]] 在設定裡已經關掉，再用步驟 2 裝的那個轉換外掛針對這個檔案重跑一次——多數外掛支援指定單一筆記而不是整個 vault。

數學公式變成原始的 LaTeX。 轉換器不支援公式渲染。要嘛換轉換器，要嘛在 Obsidian 裡把渲染後的方程式截圖嵌入——醜是醜了點，但絕對穩。

給團隊用的實戰流程

如果你是團隊裡唯一的 Obsidian 使用者，但團隊需要 Word 檔，那就不要每次都當一次性腳本寫，而是建立一套可重複的流程。我在協作專案裡用的版本是：

1. 在 vault 裡固定開一個 Exports/ 資料夾，專門放要變成 Word 的筆記
2. 這個資料夾裡的筆記，從一開始就用標準 Markdown 連結（[text](note.md)）而不是 wikilinks——省下預處理
3. 每週把該週有變動的筆記做一次批次轉換
4. DOCX 輸出存到共享雲端硬碟，不要放回 vault

目標是把你的思考空間（有完整 Obsidian 能力的主 vault）跟交付空間（只說標準 Markdown 的 Exports/ 資料夾）分開。第一次重構花了我一小時左右，之後每個月都省下好幾小時。

如果你是從另一個方向進來的——在寫 Markdown，想把基本功打好——如何寫好 Markdown 那篇整理了讓任何匯出都更順的基礎語法。想更深入看轉換這段，Markdown 轉 Word 完整指南 詳細走過複雜文件會用到的轉換器功能。

最後一點心得

Obsidian 真正的強項是那些非標準功能——wikilinks、callouts、動態查詢——讓整個 vault 活起來。匯出到 Word 意味著要放棄其中大部分。訣竅是不要硬要留住全部：接受 Word 版本就是一份攤平後的表達形式，照著這個前提做預處理，然後用 Word 的樣式工具在真正在意的地方把質感重建起來。

一旦預處理變成習慣，整條流程每份筆記大概只要五分鐘。這就是「晚點再弄」跟今天真的把檔案寄出去之間的差別。