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 需要一個明確的相對路徑。如果你的 vault 把附件放在 99 Attachments/，筆記放在 10 Projects/，那麼在任何轉換器能找到這張圖之前，圖片連結都得先改寫。

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

我這套流程裡可靠度提升最大的一環，就是在跑任何轉換器之前，先做一遍 5 分鐘的預處理。跳過它，你之後得花 30 分鐘去收拾那個 Word 檔。

第一步：檢查你的附件設定

打開 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。這個設定只對今後生效——既有的連結在被改寫之前，仍保留舊格式。下面的第二步就負責處理這個改寫。

第二步：把雙向連結轉成標準 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" 這類關鍵字。生態裡有好幾個外掛能把雙向連結（以及 ![[...]] 形式的嵌入附件）批次轉成標準 Markdown 語法，可以針對當前檔案，也可以整個資料夾。挑一個近期有更新、安裝量讓你放心的。

改寫完之後，你的嵌入附件會變成 ![image.png](path/to/image.png) 的樣子。檢查一下輸出——如果你的附件資料夾名字裡有空格，把空格做 URL 編碼（My%20Vault/attachment.png），否則轉換器會悄無聲息地把圖片丟掉。

第三步：決定 Callout 怎麼處理

Obsidian 的 Callout（> [!note]、> [!warning] 等等）在 vault 裡很有用，但 Word 裡完全沒有對應的東西。你有三種做法，按工作量從低到高排：

• 接受降級——它們會渲染成普通的引用區塊。Callout 的類型（note/warning/tip）丟了，但內容還在。對大多數交接情境來說夠用。
• 改寫重要的那幾個——匯出前把 > [!warning] Critical 換成 > **⚠️ Critical：**。兩邊都看得懂。
• 在 Word 裡後處理——用 Word 的快速樣式把引用區塊變成有底色的樣式方框。只有對外要交付的精緻文件才值得這麼折騰。

20 頁以內的文件我用第二種做法，其餘一律用第一種。

第四步：把 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 to Word 轉換器。它支援 GitHub Flavored Markdown（GFM）——包含表格、任務清單和註腳——也就是說，Obsidian 經過預處理後產出的所有標準特性它都涵蓋。圖片會被內嵌進去，程式碼區塊會保留語法高亮，標題會對應到 Word 的標題樣式，因此輸出的 DOCX 裡導覽窗格能正常使用。

如果筆記裡有 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 裡打開筆記，而是直接從檔案系統匯出——這時沒解析的模板就會漏出來。先在 Obsidian 裡打開筆記，讓它渲染一遍，再做匯出。

Canvas 檔案

Obsidian 的 Canvas（.canvas）檔案本質是 JSON，不是 Markdown，沒有任何 Markdown 轉換器會去碰它。對於 Canvas，可行的辦法是：把畫布縮放到你想要的比例後截圖，存成 PNG，再把這張圖嵌進一篇專門用來匯出的包裝 Markdown 筆記裡。如果你這種需求多到值得裝一個外掛，社群裡也有一些外掛直接提供「把 canvas 匯出為圖片」的功能。

Mermaid 圖表

標了 mermaid 的圍籬式程式碼區塊在 Obsidian 裡會渲染成圖表。大多數線上 Markdown-to-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. Callout 和 Mermaid——和標準匯出一樣會崩

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

疑難排解：東西崩了的時候怎麼辦

下面這些是我見得最多的失敗模式。想要更全面的參考，Markdown 轉換疑難排解指南詳細涵蓋了 15 個常見的轉換問題。

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

表格渲染成擠在一行的一團亂。 你的原始檔用的是 Obsidian 早期的表格格式，或者管道符不一致。用純文字編輯器打開 .md，確保每一列的管道符數量都相同。表頭分隔列也得對上：| --- | --- |。

程式碼區塊丟了語言著色。 檢查你的圍籬在開頭三個反引號後面緊跟了語言標籤（比如 python、js、bash）。轉換器靠這個標籤來套用語法高亮；沒有標籤的圍籬會預設走純文字。

匯出後雙向連結仍然顯示成 [[Note Name]]。 預處理沒跑，或者它沒涵蓋到這個檔案。確認設定裡 Use [[Wikilinks]] 已經關掉，然後用你在第二步裝的那個轉換外掛，針對這個具體檔案再跑一遍——大多數外掛都支援把範圍限定到單篇筆記，而不是整個 vault。

數學公式顯示成原始 LaTeX。 轉換器不支援公式渲染。要麼換個轉換器，要麼在 Obsidian 裡把渲染好的公式截圖，作為圖片嵌入——醜是醜，但靠譜。

給團隊用的現實工作流

如果你是團隊裡唯一用 Obsidian 的人，而這個團隊需要 Word 檔，那就搭一個可重複使用的流程，而不是寫一次性的匯出腳本。我在協作專案裡用的版本是這樣的：

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

目標是把你的思考空間（有著全部 Obsidian 專有能力的主 vault）和你的交付空間（說標準 Markdown 的 Exports/ 資料夾）分開。第一次重構成這種拆分結構花了我一小時，但從那之後每個月都給我省下好幾個小時。

如果你是從相反方向過來的——在用 Markdown 寫作，想把基本功練扎實——如何用 Markdown 寫作指南講了那些讓任何匯出都更順滑的基礎知識。而想更近距離看看流水線裡轉換這一側，Markdown to Word 完整指南會帶你走一遍那些對複雜文件真正重要的轉換器功能。

寫在最後

Obsidian 真正的強項在於它那些非標準功能——雙向連結、Callout、那些讓 vault 活起來的動態查詢。匯出到 Word 意味著放棄其中大部分。訣竅是不要再跟它較勁：接受 Word 版本注定是一個被壓扁的呈現，照這個前提去做預處理，然後在真正重要的地方用 Word 的樣式工具把質感重新搭回來。

一旦預處理變成習慣，整條流水線每篇筆記大約只要五分鐘。這就是「我回頭再弄」和今天就真的把文件發出去之間的差別。