為什麼文件轉成 Markdown 會更適合 AI？我的 Universal Markdown 極簡轉檔器實作分享

作者：亞瑟 3月 29, 2026

好一陣子沒來部落格發文了，感覺我的網誌都快長草了。

三月這段時間，我一方面在準備外部邀約授課，另一方面也花了不少時間在研究 AI agent、Agent Coding，以及把自己手上的 AI 工作環境整理得更有系統一點。也因為這樣，這陣子比較少輸出內容。如果你是平常有固定在看我文章的朋友，這邊先跟大家說聲不好意思。

不過，換個角度看，這段時間雖然發文變少，但其實不是停下來，而是把不少時間拿去做一些更底層、但我覺得長期會很有幫助的事情。今天想跟大家分享的，就是這段時間我自己做出來的一個小工具：Universal Markdown 極簡轉檔器。

這不是什麼很炫的大型專案，也不是那種只有工程師才會用得到的工具。它解決的其實是一個很實際的問題：當我們想把各種文件丟給 AI 讀取時，怎麼做會更有效率、更省成本，也更好用？

為什麼我會開始在意「文件轉成 Markdown」這件事？

最近這段時間，我花了不少時間在接觸各種 AI 協作工具。除了先前提過的 Google Antigravity 之外，後來也陸續摸了 OpenAI 的 Codex、Anthropic 的 Claude Code，還有最近非常多人在討論的 OpenClaw（俗稱龍蝦）。

用久了之後，我有一個很明顯的感受：不同平台、不同模型，各自都有強項。實際在用的時候，常常不是只選一個工具打天下，而是會根據需求、成本、API 串接方式、模型特性，去做比較靈活的配置。

而在這些 AI 協作流程裡，有一個場景其實非常常出現，就是：我要把我手上的文件提供給 AI 參考。

這些文件有很多種。最常見的像是 Word、PDF、Excel、PowerPoint，有時候也會有 TXT、CSV、JSON 這類比較偏純文字的資料。問題是，這些格式雖然對人類使用者很熟悉，但如果直接拿來給 AI 讀，未必是最有效率的方式。

也因為這樣，我開始認真思考一件事：如果我能先把這些文件整理成 Markdown，是不是會更適合拿來餵給 AI？

為什麼 Markdown 對 AI 更友善？

這件事如果用白話來講，會比較好理解。

1. 很多富文本格式，對 AI 來說其實有不少雜訊

像 Word、Office 文件，甚至很多 PDF，底層都不是單純只有文字而已。裡面通常還包了很多排版資訊、樣式設定、結構標記，甚至還有圖片、表格、各種內嵌資料。

這些東西對人類來說當然有意義，因為我們需要看到字體大小、粗體、顏色、版面配置。但對 AI 來說，很多時候它真正要理解的核心，還是文字內容本身。

換句話說，那些多出來的格式資訊，很多時候反而像是雜訊。

2. Markdown 很乾淨，但又不是只有純文字而已

Markdown 的好處是，它雖然本質上是純文字，但又不是那種完全沒有結構的純文字。

它可以保留很多重要的語意層次。像是：

哪裡是標題
哪裡是小節
哪裡是列表
哪裡是重點段落
哪裡有超連結

所以對 AI 來說，Markdown 是一種很剛好的格式。

它不像 Word 那樣帶著一堆視覺排版雜訊，但也不像最原始的 TXT 一樣，只剩一整坨文字。它保留了足夠的結構，也盡量減少不必要的負擔。

3. Markdown 也比較省 token

這點關乎你的荷包。

現在大家在用 AI，不管是訂閱制、API 計費，還是各平台內部的使用額度，本質上很多都跟 token 消耗有關。

如果你丟給 AI 的檔案裡面，有很多排版層、XML 標籤、樣式資訊，那某種程度上就等於把不少 token 浪費在那些不是你真正想讓 AI 理解的內容上。

但如果先轉成 Markdown，很多雜訊就會被清掉，token 會更集中花在真正重要的文字內容上。

這不只是「看起來比較乾淨」而已，實際上也會影響：

成本
讀取效率
AI 能一次吃進多少有效內容
最後理解的品質

我自己實際測試過，同樣一份文件，在轉成 Markdown 之後，檔案大小可以差非常多。原本十幾 MB 的文件，轉完後可能只剩大約一百多 KB，但完整文字內容都一樣。這種差異，對 AI 協作來說其實很有感。

我一開始怎麼找解法？

當我開始有這個需求之後，第一件事當然不是自己寫程式，而是先去看有沒有現成工具可以用。

因為我的原則是：

不需要重複造輪子，但是要站在前人的肩膀上往上爬。

一開始我先查的，主要還是最常見的 Word 轉 Markdown。畢竟在一般工作場景裡，Word 文件還是最常見，也最容易先碰到。

那時候大概看了幾條路。

Pandoc

Pandoc 幾乎是轉檔界的經典工具。功能很強，支援格式也很多。

但它比較偏命令列工具。如果你本來就習慣用 CLI，那沒什麼問題；但如果你是希望日常工作裡快速、直覺地處理文件，對一般使用者來說還是有一點門檻。

Writage

這個方案的優點是，它可以直接整合進 Word 裡，讓你像平常另存新檔一樣直接輸出 Markdown。

順是很順，但它是付費工具。對我來說，這種需求不是不能付費，而是我會先思考：有沒有更彈性、可延伸、而且能符合我自己工作流的方式？

Typora、Obsidian、MarkText 這類 Markdown 編輯器

這一類工具其實也能解決部分問題。你可以把 Word 裡的內容複製貼上，很多時候它會幫你轉成相對乾淨的 Markdown 結構。

如果只是偶爾轉個一兩份，這樣其實可以。

但如果你處理的文件量變多，或者你希望工作流程再順一點，就會開始覺得：每次都要手動開軟體、複製、貼上、再另存，還是有點不夠絲滑。

所以後來，我乾脆自己開發一個

我後來的想法很簡單。

既然需求是明確的，而且我也已經知道目前現成方案各自卡在哪裡，那不如就自己做一個比較符合我使用習慣的小工具。

一開始，我先做的是 Word 轉 Markdown 這件事。

那時候我先用 mammoth 這個方向去做。它的好處是，對 Word 文件的語意化轉換表現不錯，會盡量保留標題、段落、列表這些真正有用的結構，同時減少不必要的格式雜訊。

然後我再把這個轉換核心包成一個簡單的 GUI 小工具，讓操作方式可以直覺一點。像是直接拖曳檔案、快速轉換，而不是每次都要開終端機下指令。

做到這裡，其實第一版就已經能用了。

但後來我又開始覺得，光只有 Word 還不夠......（過癮）。

後來我發現：需求其實不只 Word

如果只是處理 docx，那還只是解決其中一小塊。

真正開始大量和 AI 協作之後，你會發現手上的文件格式很雜。除了 Word 之外，PDF、Excel、PowerPoint、CSV，甚至一些 HTML、JSON、XML 之類的格式，都很可能會出現在實際工作流裡。

也就是說，我真正想解的問題不是「怎麼把 Word 轉成 Markdown」，而是：

有沒有一種更單純的方式，可以把各種常見文件都更方便地轉成 Markdown？

後來我就注意到微軟開源的 MarkItDown 這個專案。

坦白說，這個工具本身很強。它支援的格式很多，也很符合現在 AI 時代大家對文件前處理的需求。

但它原本的使用方式還是偏工程師。比較像是你會在 Python 環境或 CLI 裡使用它，而不是一般使用者打開就能直接拖檔操作的那種工具。

所以我後來的想法就變成：

既然底層已經有成熟能力了，那我真正想做的，不是重新發明輪子，而是把這些能力整理成一個更好上手的工具。

Universal Markdown 極簡轉檔器，我想做的是什麼？

所以，後來就有了這個 Universal Markdown 極簡轉檔器。

它的定位其實很單純。

我不是要重新發明什麼新的轉檔技術，也不是要去跟那些成熟的開源專案比誰底層更厲害。比較像是，我把幾個已經很有價值的能力整合起來，做成一個對一般使用者更直覺的 Windows GUI 小工具。

這個工具目前主要整合了兩條技術路線：

mammoth：主要負責 Word .docx -> Markdown
MarkItDown：處理更多常見文件格式，並支援進一步的 OCR / Vision 延伸能力

講白話一點，這個工具的重點不是底層名詞本身，而是它幫你把原本偏工程師思維的流程，整理成一個比較像日常工具的使用方式。

你不需要自己研究一堆 Python 指令，也不用每次切不同工具處理不同格式。很多時候，就是開啟、拖曳、轉換，然後去看結果。

這才是我覺得它真正有價值的地方。

這款工具有哪些我自己覺得實用的地方？

我先不講太多技術細節，直接講我自己覺得比較實用的點。

1. 它是 Windows 圖形化介面

這件事很重要。

因為很多工具不是不能用，而是卡在「你要先會部署、先會 CLI、先會處理環境問題」。對熟悉這些的人來說沒差，但對很多一般使用者來說，那個門檻其實不小。

做成 GUI 之後，操作門檻就低很多。

2. 支援拖曳操作

這一點就是很直觀。

你不需要記指令，不需要切到終端機。很多情況下就是把檔案拖進去，讓它處理。

3. 不只 Word，還能處理更多常見格式

這是我後來很在意的一點。

因為如果今天只有 Word 能轉，那工具的適用場景就還是偏窄。現在如果 PDF、Excel、PowerPoint、CSV 等常見文件都能處理，實際工作流就會順很多。

4. OCR / Vision 可以視需要啟用

有些文件本身就是純文字，這種時候你不一定需要額外開 OCR，直接快速轉換就好。

但如果文件裡面有比較多圖片、掃描頁、截圖、圖表，這時候 OCR / Vision 類能力就會很有幫助。

這種做法的好處是：

你可以根據需求決定要不要開
不會每次都被迫走最重、最慢的流程
工作流比較有彈性

5. Provider 可自訂，不綁死單一服務

這點也是我自己很在意的。

因為現在 AI API 的世界變化很快，不同平台、不同模型、不同費率和能力，都各有優缺點。

如果工具一開始就綁死單一服務，之後彈性會差很多。現在把 Provider 做成可以自訂，未來在使用上會更有延展性。

6. 可以選擇原始碼部署，也可以直接用 Portable 版

對熟悉 Python 的人，可以直接抓原始碼自己部署。

如果你不想碰環境問題，也可以直接下載我打包好的 Portable 版，解壓縮就能用。

這兩種方式我都保留，主要就是讓不同背景的人都比較好上手。

實際要怎麼下載與使用？

使用方式其實不複雜。

方式一：原始碼部署

如果你本來就有 Python 環境，也習慣自己跑專案，可以直接從 GitHub 抓原始碼，照 README 的方式手動安裝或請 AI 自動安裝相依套件後即可執行。

方式二：直接下載 Portable 版

如果你只是想快速試用，不想自己處理 Python 環境，那直接下載我釋出的 Portable 版會更方便。

解壓縮之後，直接執行就可以開始用。

基本使用流程

整體流程大概就是：

開啟工具
把要轉換的文件拖曳進去
視需要選擇模式
等待轉換完成
開啟輸出資料夾查看結果

如果你處理的是純文字為主的文件，通常飛快。

如果你開了 OCR / Vision 模式，尤其是圖片、掃描頁比較多的文件，那就要給它一點時間。這不是當掉，而是因為它確實要做更多事情。而 OCR 解析圖片的速度也會根據你的 API 供應商以及選擇的模型而有差異。

我自己怎麼看這個工具？

對我來說，這個工具的意義其實不只是「我又做出一個小工具」而已。

更大的意義是，我覺得這件事很像是在把這段時間我對 AI 協作的理解，真正落到一個實際可用的工作流裡。

以前很多人談 AI，容易停在概念、停在 demo、停在「這個好像很厲害」。但如果真的要讓 AI 變成日常工作的一部分，你最後還是會回到很具體的問題：

我的資料怎麼整理？
我的文件怎麼提供？
我的成本怎麼控制？
我的流程怎麼變順？

Universal Markdown 極簡轉檔器，某種程度上就是我對這些問題的一個實作回答。

另外，這也是我第一次把自己做的 coding 小工具，算是比較正式地放上 GitHub 跟大家分享。過程中除了工具本身，也順手學了不少像是 GitHub repository 整理、Release 發佈、Portable 打包、README 撰寫這些實務細節。

所以這篇文章如果要講得更白話一點，重點不是「我做了一個多厲害的工具」，而是：

我最近真的很常遇到這個需求，所以乾脆把它做成一個自己也會想一直用下去的工具。

如果你也常需要把文件丟給 AI，這工具可以試試看

如果你平常也常常需要把 Word、PDF、Excel、PowerPoint 這些文件內容整理給 AI 讀，不管是拿來摘要、分析、整理重點，還是當作後續寫作或知識整理的材料，那這個工具你可以試試看。真的會幫你省下很多 token 和算力，也會省下很多 AI 讀取文件的時間。

它不一定是要取代所有既有工具，而是提供一個更直覺、更接近日常工作流的選項。

如果你試用之後有什麼 feedback，或有什麼你覺得未來可以再優化的地方，也歡迎再跟我分享。