情境是這樣的：你寫了一份 Markdown —— 可能是內部教學、可能是給新人的上手文件，也可能就是這 30 天的某一篇。然後有人問你要 Word，有人問你有沒有 簡報，有人說 傳個連結給我就好。

比較糟的處理方式，是開三個不同格式的檔案各寫一次。一段時間之後，檔案開始不同步，三份內容互相矛盾，而且通常你不會馬上發現 —— 是三個月後某個同事拿著舊版本來問你才發現。

所以今天的做法只有一條：**Markdown 是唯一真相，其他格式都從它轉出來，而且永遠可以整份重生。**下面把三條路徑實際走一遍，而且是可以照抄的走法。

練習一：變成一個可以傳給任何人的網頁

第一條用一支 Python 腳本，產出一個可以直接傳給別人的單一網頁。我最推薦先做這條，因為它零安裝。

# 先把腳本抓下來(純標準庫,不用裝任何東西)
curl -O https://gist.githubusercontent.com/n913239/7ae7d88cfbc51d5540201891bb1ff6f4/raw/md_to_single_html.py

python3 md_to_single_html.py 你的文章.md out.html

預期輸出：

輸出: out.html (0.06 MB)

檔案大小跟著你內嵌的圖片走 —— 沒有圖的話會小很多。

三個檢查點：

• [ ] 產出只有一個檔 —— 沒有跟著一包圖片資料夾
• [ ] 用瀏覽器打開，圖片有正常出現(圖片是 base64 內嵌進去的)
• [ ] 把這個檔案傳到手機、用別的瀏覽器開，還是一樣

我實跑的時間是 0.025 秒。這個數字重要的不是「快」，而是它沒有相依—— 純標準庫，不用 pip install 任何東西。

練習二：變成 Word

給主管、給行政、給要在上面改追蹤修訂的人。

pandoc input.md -o output.docx

但你八成會卡在這裡。 我在自己機器上跑的結果是：

pandoc: command not found

這台電腦沒裝 pandoc，先裝：brew install pandoc(3.11)。裝完把 Day 2、Day 3 當時的草稿丟進去轉，每篇大約 0.1 秒。

轉出來會遇到兩件事，而且它們都不會報錯：

• 表格只剩標題列一條底線。 不是完全沒有框線 —— pandoc 預設的表格樣式 只給標題列一條 bottom，儲存格之間沒有框線。兩篇草稿、13 張表，tblBorders 是 0 個。
• 欄寬會擠壞。 containerization 被折成兩行、ContainerizationError 折成三行 —— 它按內容平均分欄，不管哪一欄裝的是不能斷的長字。

第二件事我差點漏掉。一開始我是把 .docx 解開，直接讀 XML 驗的：每一欄的寬度都正常，最窄也有 0.75 吋，於是判斷欄寬沒問題。轉成 PDF 真的看一眼，containerization 才斷成 containeri / zation 兩行 —— 那一欄裝的是 16 個字元、中間沒有任何斷點的英文字。數字是對的，結論是錯的。 讀 XML 告訴你檔案裡寫了什麼；看渲染結果，才是使用者真正會看到的 —— 所以下面的檢查點全部改成「打開來看」，一個都不靠讀 XML。

檢查點(每一個都要真的把檔案打開)：

• [ ] 表格有完整框線(預設只有標題列那一條)
• [ ] 最長的那個英文字沒有被折斷(中文不會有這個問題，英文型別名會)
• [ ] 程式碼區塊還是等寬字，沒有被套成內文樣式

同一件事，交給官方 docx skill

pandoc 是「一行指令」的代表；另一個代表是 Anthropic 官方的 docx skill(Day 4 裝來試的那包 document-skills 裡的一個)。它的做法完全不同：Claude 讀你的 md，寫一支 docx-js 腳本、跑一次，再照 skill 裡的流程轉 PDF、出圖、自己看一遍。 同一份 day02.md，我用 claude -p 無人值守跑了一次，要求跟上面三個檢查點一樣：

同一張表，兩邊渲染出來長這樣(LibreOffice 轉 PDF 後截的)：

三個檢查點它全過，而且過的方式值得記：欄寬不是平均分，是先量每一格最長的不可斷 token保底，剩下的再按比例分；塞不下就把那張表的字級縮 0.5pt 直到剛好 —— 這正是 pandoc「按內容平均分欄」做不到的事。

但這張表要整張看，不能只看打勾。它用 12 分鐘和 $3.64 換來的東西，是一支之後 0.19 秒就能重跑的腳本 —— 所以它跟今天的規則不衝突：md 還是唯一真相，腳本存進 repo，產物一樣整份重生。衝突的只有一件事：那支腳本本身不是決定性產物，下次再叫它寫，長出來的不會是同一支。所以腳本要存，不要每次重生。

練習三：變成簡報

npx --yes @marp-team/marp-cli --no-stdin input.md -o slides.html

--no-stdin 不是可有可無的。 我第一次照官方那行寫(沒加它)，在腳本裡跑 —— 它掛了 37 分鐘。

不是在下載。套件早就抓完了，129 MB 躺在 ~/.npm/_npx/ 裡。我去看那個 process：**CPU 0%、沒有任何網路連線、狀態 S(睡眠)。**它在等 stdin，而腳本裡沒有 tty，所以它會等到天荒地老。

加上 --no-stdin：1.38 秒。

37 分鐘和 1.38 秒的差別，是一個旗標。而它「失敗」的樣子是安靜地不結束 —— 沒有錯誤訊息可以 Google。

Marp 的規則是用 --- 分頁，所以你的 Markdown 得先為它調整 —— 這條路對原始檔的侵入性最高：它會逼你把文章寫成投影片的節奏。

而「侵入性最高」具體長這樣。我丟一頁 15 個項目符號進去：

• 顯示到第十一點半，第十二點以後被切掉。
• 沒有警告、沒有錯誤，slides.html 照樣產出來。

程式碼區塊倒是沒被切 —— Marp 會自動縮字級去把它塞進去。兩行都塞下了，代價是字變小；行再長一點就會小到看不清楚。

檢查點：

• [ ] 每一頁都要真的看過 —— 溢出不會報錯，只會安靜地少一截
• [ ] 程式碼區塊縮小之後還讀得出來
• [ ] 分頁的位置是你想要的，不是它猜的

要把每一頁輸出成圖來檢查：npx --yes @marp-team/marp-cli --no-stdin --images png input.md—— 但這一步會叫起 Chrome(5.73 秒)，純 HTML 那步不用。

三條路之外：其他工具，和反方向

上面三條是我實跑過的。同一件事還有很多人用別的工具做，列在這裡讓你挑；這一節我沒跑，只查了。星數是 2026-09-16 從 GitHub 抓的，會一直變，看量級就好：

還有一個**「反方向」的類別，跟今天的規則剛好互補：把別人給你的 Word、PDF、簡報變回 Markdown**。MarkItDown(微軟，184k)、Docling(IBM，66.5k)、MinerU(80.0k)都是為了餵 LLM 而生的。一行 markitdown 檔案.docx > 檔案.md，就能把「唯一真相」搬回 .md。你接手一份只有 Word 的文件時，第一步就是它 —— 先變回真相，再從真相往三條路產。

那些圖是怎麼來的

前面都在處理文字。但你的文章不是只有文字 —— 有封面、有流程圖，而這兩種圖的來源完全不同，能不能重生也完全不同。

一、封面：圖不可重生，但 prompt 可以

封面和插畫交給 Gemini 或 ChatGPT，這件事它們比任何程式都強。問題在於：同一個 prompt 跑兩次，你不會拿到同一張圖。

所以它牴觸了今天那條規則 —— 產物要能整份重生，而生成的圖不能。

解法不是放棄，而是把 prompt 跟圖放在一起：

<!-- Gemini prompt: 科技／專業簡報風格、深藍灰底、扁平化、無襯線黑體白字、16:9，
     一個人的剪影站在一張巨大的知識圖前面，圖上只有三個節點是亮的 -->

你保住的不是那張圖，是「再產一張同風格的圖」的能力。

而畫風那一串要寫死。我固定用「科技／專業簡報風格、深藍灰底、扁平化、無襯線黑體白字、16:9」，三十篇下來才會看起來像同一個系列 —— 一致性靠的不是模型的記性，而是那行註解。

二、流程圖：Claude 不能生圖，但能畫圖

這裡要先講一個很多人搞混的區分。

Claude 沒有影像生成模型。 它畫不出封面，也畫不出插畫。但它可以用程式碼畫圖 —— mermaid、SVG、p5.js，都是文字。claude.ai 上的 Claude Design 也是同一類：它畫的是 HTML，不是像素。

flowchart LR
    MD[index.md] --> HTML[單一 HTML]
    MD --> DOCX[Word]
    MD --> SLIDES[簡報]

這四行就是一張流程圖。而它跟「貼給 ChatGPT 生一張流程圖」差在哪？

改一個框。 生成的圖要重講一次 prompt、重生整張、還不保證其他地方不變；這四行你改一個字就好，而且 git diff 看得出來改了什麼。

**生成的圖適合「感覺」，畫出來的圖適合「結構」。**而技術文章裡需要精確的那些 —— 流程、架構、狀態 —— 全部是結構。

順帶一提，生成式的圖還有一個具體的毛病：**它寫不好字。**把流程圖交給生圖模型，方框裡的中文常常會變成「像字但不是字」的東西。

寫的時候不用另外裝東西就看得到圖：VS Code 從 1.121(2026-05)起，把 Mermaid 預覽內建進 Markdown 預覽；GitHub 的 README 與 issue、Notion 的程式碼區塊選 Mermaid，也都直接畫。

三、圖是產物，那行字才是真相

兩種圖，來源不同、工具不同，但真相全部都是文字：

圖是產物。產物壞了可以重生，前提是產生它的那句話還在。

而那句話該放哪裡？跟文章放在一起，放在 .md 裡 —— 因為那份 .md 本來就是唯一真相。

總結

一份 md 走三條產出路徑，相依與代價差很多：

• 零安裝那條最快，而另外兩條都曾在「成功了」的外表下出錯
• 三條路的檢查點都不一樣：HTML 檢查「是不是真的只有一個檔」，Word 檢查「表格框線在不在」，簡報檢查「有沒有溢出」—— 沒有通用的驗收標準，每種產出要驗的東西都不同
• 而三條路的錯誤有一個共同點：它們都不報錯。 表格沒框線、欄寬折斷、投影片少一截 —— 指令全部回傳成功，檔案全部產得出來
• 官方 docx skill 三個檢查點全過，代價 12 分鐘、$3.64；換來的是一支 0.19 秒可重跑的腳本 —— 腳本要存，不要每次重生
• 圖也是產物，但有一種圖不能重生：生成式的封面。所以收的不是圖，是那行 prompt —— 而 prompt 是文字，進得了 git

這一篇留下的心法：

Markdown 是唯一真相，產物永遠可以整份重生。

選工具先算相依：一年跑兩次的挑功能最強的，**每天要跑的挑明年還會在的那個。**而遇到不能重生的產物 —— 像生成的圖 —— 就把產生它的那句話收進 .md，那句話才是真相。

順帶一提，這篇本身就是這條規則的產物 —— 它是一份 md，等一下會變成 iThome 上的一篇文章。如果哪天要變成別的格式，重生一次就好。

參考資料

• md_to_single_html.py(225 行，純標準庫，無第三方相依)：gist.github.com/n913239/7ae7d88c… 要重現本文這一版，用釘住 revision 的網址(內容永遠不變)：raw/7a8942d6…/md_to_single_html.py
• 官方 docx skill 那次的 prompt、md2docx.js、cost 與兩版渲染頁：原始檔未另外公開，數字如正文(Claude Code 2.1.271，Opus 5，2026-09-16)
• Pandoc 3.11：pandoc.org
• Marp CLI(@marp-team/marp-cli，本文用 npx --yes 現抓)：github.com/marp-team/marp-cli
• Claude Design(2026-04-17 上線，Pro / Max / Team / Enterprise；本文未實跑，2026-09-16 查)：claude.ai/design
• VS Code 1.121 release notes(內建 Mermaid Markdown Features，2026-05-20；2026-09-16 查)：code.visualstudio.com/updates/v1_121
• LibreOffice 24.8.4.2 —— 本文所有「打開來看」的檢查都是用它轉 PDF 再出圖的
• 延伸閱讀：AI 不只會寫 code — 用 Claude Code 把一份 Markdown 變成講義、簡報、網頁 —— 同一條規則用在一門真實課程的教材上