AI 們的柴米油鹽：爲什麼一句“加粗”也要精打細算

2004 年，一個叫 John Gruber 的程序員拍出了一份 Perl 腳本。他的本意很簡單：寫博客的人不用每回都手敲 HTML 尖括號，該多好。

那個時候，沒人把這份腳本當回事。但二十一歲的年輕人萬萬沒有想到，2026 年，橫跨硅谷到中關村的全部 AI 巨頭——從 ChatGPT 到 Claude，從 GitHub Copilot 到飛書裏的智能體——早已把這份腳本演化出的語法，當成了他們與人溝通的“統一電報碼”。

這樁陳年的輕量級標記語言，就是 Markdown。而那些滿嘴高算力、大吞吐的 AI 模型們，偏偏對這種純文本格式愛得深沉。這並不是因爲智能體的審美停留在某個極客聚集的遠古 BBS 時代。恰恰相反，在無數種表達可能性之中，Markdown 恰好是那個最現實的生存策略。

賬本上的底線星號

在大廠高管的辦公室裏，或許看不到一行 Markdown 代碼，但在各大雲服務的財務後臺，AI 對 Markdown 的選擇極爲精明。對一個大語言模型來說，每一段輸出的背後都是冰冷的 Token 計費。表達同樣的結構，能省一個字絕不多花一個字。

以加粗爲例：HTML 格式下要寫成尖括號加屬性名，耗費 10 個字符；而 Markdown 只需前後各兩個樸素的星號，硬是省下近一半的字節消耗。單個看這完全不是回事，但如果算上天量級的對話請求，哪怕每次只省下微不足道的幾十個 Token，一年累計下來的成本差就能讓財務總監們側目。

同時，輕量化帶來的不僅是省錢，更帶來響應速度的躍升。更短的輸出意味着更少的逐 Token 生成次數，大模型在零點幾秒內就要決策如何最經濟地表達強調與層次時，那些井號和星號就像它在符號叢林裏下意識的安全區。如果非要讓 AI 輸出一份格式嵌套混亂、屬性值缺失的複雜 HTML，它會像考場上找不着筆的學生，產生更高的困惑度，輸出的內容隨時可能崩壞。

一條文本，各自表述

但如果認爲 Markdown 的統治純粹是因爲摳門，那也小看了這些 AI 的狡猾。

對於那些穿越在聊天泡泡、飛書文檔、Notion 頁面和開發者筆記深處的一條文本來看，適配的廣度纔是真正的護城河。很多開發者曾做過思想實驗：將同一份食譜分別用純文本、HTML 以及 JSON 輸出，結果各自見了分曉。純文本是一堵毫無輕重緩急的字牆；HTML 在多數不解析它的聊天窗裏，只會暴露出一堆醜陋的代碼標籤；至於 JSON，那冰冷的數據結構，註定把“菜名”變成晦澀的字段名，任何非技術圈的用戶都只會立刻關掉窗口。

只有 Markdown，在聊天窗裏被渲染得乾淨有序；複製到筆記軟件裏，它落地生花，變成一份格式利落的人類文檔；甩給靜態博客生成器，它又搖身變爲一抹耐看的網頁。這種“一次寫作，各處可用”的橫跨能力，卸掉了智能體與人類之間對於審美的暗中較勁，讓格式甘心退讓，把“想說什麼”重新浮到水面上。

而更深遠的影響在於，這種適配的廣度撬動了更深一層的利益鏈。從 Slack 到 Discord，從飛書到 GitHub，全球對話基礎設施早已給 Markdown 鋪好了上好的軌道。當全世界的平臺都用腳投了票，AI 智能體根本沒得選，只有把列車開上去纔算上道。

星號底下的共謀

其實，Markdown 還暗地裏替 AI 充當了一層緩衝劑。它將表達圈定在簡潔的層級、列表和鏈接裏，斷然捨棄了花裏胡哨的字體與頁邊距。這種極致的單調，反而成爲交流中一種理所應當的坦誠——沒人會苛求一個只能用井號做標題的助手去做海報。於是輸出的內容被心安理得地安放在“草稿”或“信息”的心理位置上，弱化了機械套用模板的僵硬感，也拉大了容錯的生存空間。

當然，隨着交互前端進入 2026 年，也有人不服。Claude 內部的工程師就在吹新風：HTML 的多媒體交互性與卡片式的表達能力遠遠超越 Markdown，Markdown 早該退場了。但即便在那篇極盡鼓吹之能事的論文裏，寫作者也在文本的底層承認道：HTML 只是前臺呈現方案，並沒有挑戰 Markdown 作爲底層工作記憶、上下文載體的地位。

所以，當你的智能體助手又在某個深夜鉚着執拗的勁頭髮來一排“### 核心結論”時，先別嫌它冷冰冰。那一排齊整的井號背後，站着的是一整串由 Token 成本、平臺生態、人類閱讀習慣和工具鏈條環環相扣的邏輯鏈。

這些不起眼的星號，代替了無數真實世界裏需要砸下去的真金白銀推理時長，替無數深夜趕報告的苦命人省去了繁雜的重新排版。AI 並非非得用 Markdown，只不過在所有它能說的語言裏，這是目前唯一一種能讓算賬、做事與對話三者同時保持體面與溫飽的方式。