Markdown不是新東西，但貼錯地方就是閱讀負擔：從社群暗號到教學現場的「格式同理心」

這兩年滑開Threads、Facebook或是學校的LINE行政群組，你一定常看到一種長相奇特的貼文：

每一段開頭都帶著三個井字號###，重點詞彙左右兩邊夾著兩顆星號**重點**，條列清單前面還掛著破折號或奇怪的縮排。

內行人看一眼就知道發生了什麼事：發文者剛才去問了ChatGPT、Claude或Gemini，拿到回覆後，連改都沒改，直接按下Ctrl+C與Ctrl+V，把整段內容原封不動貼進了社群平台的純文字輸入框裡。

因為大型語言模型在底層輸出時，預設採用的是Markdown輕量級標記語言。但問題在於，多數一般社群平台的貼文區與即時通訊軟體，根本沒有內建Markdown渲染器。

於是，那些原本在編輯器裡用來幫文字「排版降噪」的語法符號，到了不支援的平台上，瞬間變成了刺眼的「視覺雜訊」。

一、 Markdown不是新黑科技，放錯位置就是雜訊

有些剛接觸生成式AI的朋友，誤以為那些井字號與星號是AI時代才發明的某種特殊格式。

其實Markdown早在2004年就由John Gruber與Aaron Swartz共同設計出來了，至今已經超過二十年。它的初衷非常純粹：讓寫作者不需要頻繁移動滑鼠去點選Word上面的粗體或標題按鈕，只要用簡單的純文字標記，就能轉換成結構乾淨的HTML網頁。

在支援它的環境裡——例如GitHub、Notion、HackMD、方格子（Vocus）或是我們寫Python常用的Google Colab筆記本——Markdown真的非常好用。打下#，畫面就呈現大標題；打下**，文字就自動變粗體。

但任何好工具都有它的「環境邊界」。

當你把帶有Markdown語法的文字，直接貼進Facebook貼文、Threads串文、LINE對話框或是傳統的公文表單時，這些平台不會幫你把星號變成粗體，只會老老實實把那一堆**與###印在讀者的眼前。

Markdown 語法的環境錯位

支援渲染的環境 (GitHub / Notion / Colab) ──> 符號自動隱形 ➔ 呈現乾淨階層 (降低認知負荷)

不支援的純文字區 (LINE / FB / Threads) ───> 符號原樣裸露 ➔ 滿屏井字與星號 (增加閱讀負擔)

在認知心理學中，Sweller（1988）提出的認知負荷理論（Cognitive Load Theory）將教材設計不良所帶來的額外阻力，稱為「外在認知負荷（Extraneous Cognitive Load）」。

當讀者在讀你的文章時，他的大腦除了要理解你文字裡的邏輯，還得同時分神去「人肉過濾」那些刺眼的井字號與星號。每遇到一個**，視線就會卡頓一下。這種把機器原始碼直接丟給真人肉眼解析的做法，本質上就是把發文者自己省下的十秒鐘排版時間，轉嫁成數百位讀者的閱讀負擔。

二、 社群上的「自己人」暗號？一種意外的受眾篩選器

當然，如果我們換個幽默一點的角度看社群生態，這種「不消星號直接貼」的行為，有時候也產生了一種奇妙的社交篩選效果。

在Threads或特定技術討論串裡，當一個人貼出滿篇帶有###與程式碼區塊標記```的貼文時：

• 一般大眾滑過去，覺得眼花撩亂、充滿距離感，直接略過不看；
• 而同樣每天泡在VS Code、GitHub或跟AI協作的開發者滑到時，大腦已經練就了自動腦補渲染的本能，看著那些符號反而會心一笑：「唉唷！這格式一看就知道剛從Claude或Gemini那裡搬過來的，自己人啦，自己人🤣！」

如果你經營社群的目的，本來就是為了建立某種技術同溫層的辨識度，用原始語法當作篩選器，把不習慣看代碼標記的受眾自然過濾掉，那確實也是一種方式。

但我們心裡必須非常清楚：社群同溫層的默契，絕對不能直接搬進教學與培訓現場。

三、 認知落差的根源：資訊工程論壇 vs. 真實教學現場

為什麼有些工程背景或重度AI使用者，會覺得「直接貼Markdown有什麼關係，大家不都這樣看嗎？」

這就是典型的「領域認知落差」。

在純資訊工程的論壇（如Stack Overflow、GitHub Issues或各大開源社群）裡，參與者清一色是技術人員。大家每天面對的就是終端機與純文字檔，看見#自動在腦中轉為H1標題，看見|---|---|自動在腦中對齊成表格，這是長年在特定領域浸泡出來的肌肉記憶。

但回頭看我自己走過的軌跡，雖然我也寫程式、串API、架系統，但我平時主要接觸的論壇與人群，卻不習慣這種呈現方式。甚或我身邊常交流、偏向大眾化應用的工程師朋友們，在對外溝通時也極少把原始標記直接攤在檯面上。

尤其當我們走進真正的「教學現場」，面對以下三種核心受眾時，這種格式落差帶來的阻力會被放到最大：

在教學現場，學習新觀念、跨出舒適圈本身就已經夠累了。

身為站在台上的教學者，如果我們連最基本的「把教材轉成一般人習慣閱讀的教育文件格式」都懶得做，卻要求台下的學生與進修老師去適應機器的原生語法，這不是在推廣科技，這是在製造新的數位高牆。

四、 多走最後一哩路：將AI產出轉為友善教育格式的實務作法

既然知道Markdown貼錯地方會造成負擔，我們在與AI協作準備教材、講義或社群貼文時，只需要多做一個不到十秒鐘的「格式轉譯」動作，就能徹底消除這個痛點。

以下分享三個我在準備課程講義與專案交付時最常用的實務方法：

1. 下指令時直接鎖死「純文字與全形標點」（適合LINE / FB / Threads貼文）

如果你確定這段內容是要貼到不支援Markdown的社群或通訊軟體，請在System Instructions（系統指令）或提示詞結尾加上這道限制：

輸出格式限制：

本內容將直接張貼於不支援Markdown渲染的純文字平台（如LINE或Facebook）。

1. 嚴禁使用任何Markdown語法標記（禁止出現 #、*、**、-、` 等符號）。

2. 請改用繁體中文標準階層標號（如：一、二、1. 2. (1) (2)）以及全形符號（如：【】、●、◆）來區分段落階層與重點。

3. 段落之間請保留適當空行，確保在手機螢幕上的閱讀舒適度。

2. 善用介面內建的「複製格式」或匯出功能（適合Word / Google Docs教材）

現在主流的AI網頁介面（如Gemini或ChatGPT）在對話框下方都有一個「複製（Copy）」小圖示：

• 千萬不要直接反白文字按Ctrl+C（或是點錯成複製Markdown原始碼）：如果你直接把原始碼貼進Word，你就會得到一堆星號。
• 善用Gemini底部的「匯出至Google文件（Export to Docs）」：這是我個人在備課時最喜歡的功能。點一下，系統就會在雲端硬碟直接生出一份標準的Google Docs，裡面的標題一、標題二、粗體與表格全部都已經幫你轉換成標準文書格式，直接就能印出來當課堂講義，或是另存成PDF發給學員。

3. 要求AI輸出HTML標籤，貼上Word完美保留排版（進階教材排版技巧）

如同我先前在《寫作與教材產出：AI提示詞與技能指令實戰指南》中分享過的技巧：當你需要把複雜的分析結果或表格放進正式的教育文件時，可以要求AI「將內容輸出為包含<h1>、<h2>、<ul>、<table>的HTML格式」。 接著在瀏覽器打開渲染後的畫面，直接全選複製、貼進Microsoft Word裡，所有的標題階層、粗體與表格框線都會乾乾淨淨地保留下來，完全不會殘留任何一顆星號。

結語：真正的專業，藏在替對方省力的細節裡

科技工具的演進，是為了幫人類省力，而不是為了讓人類去遷就機器的習慣。

Markdown本身是一項極其優秀的工程發明。在寫代碼、管專案、建置靜態網站時，我依然天天使用它；但當我轉過身，面對課堂上的學生、前來進修的老師，或是企業裡的行政夥伴時，我會把這套工程語言收進幕後，換上大家最熟悉、讀起來最不費力的標準文件格式。

這無關技術高低，這只是一份很單純的「教學同理心」。

多花十秒鐘，幫讀者把那些多餘的井字號與星號清掉；或者在發布前，把檔案轉成對方打開就能直接閱讀的PDF與Word講義。

當你願意在這些微小的格式細節上替別人多想一步，你傳遞出去的知識，才不會被冰冷的符號擋在門外，也才能真正帶著溫度，安穩地走進讀者的心裡。