昨天談 Function Calling 時，我們看到 AI 可以把自然語言轉成程式能處理的工具請求。
使用者可能只說：
幫我安排下週二下午兩點，和小明開一小時的會。
程式收到的內容卻可能長成：
{
"title": "與小明開會",
"start_time": "2026-08-11T14:00:00+08:00",
"duration_minutes": 60
}
第一次看到難免會想：
大家都是文字，為什麼不能好好講中文？
因為人類聽到「下週二」，會自己找日曆。程式通常不想靠氣氛猜答案，它需要清楚的欄位、數值與邊界。
不過，這是否代表 AI 時代的使用者要先學會 Markdown、JSON、YAML 和 HTML，才有資格聊天？
當然不是。否則 AI 還沒替我們省下時間，在學這些東西的途中已經放棄了。
AI 已經可以代寫格式了，人類為什麼還要知道這些格式？
先說結論：一般使用者不需要全部會寫，但要知道 AI 產出的內容，下一步是給人閱讀、給程式處理、拿來設定系統，還是做成可以互動的成品。格式選擇的重點不是哪個看起來最專業，而是下一位接手的人是誰。
平常使用 ChatGPT、Claude 或 Gemini，直接說人話通常就好。
你不需要這樣問午餐：
{
"location": "Hsinchu",
"budget": 150,
"request": "hot_lunch_not_Mcdonald"
}
直接說：
我在新竹，午餐預算 150 元，除了麥當勞以外，想吃熱的，有什麼選擇？
自然語言很適合表達還在形成中的想法，刻意把每句話寫成 JSON 反而增加負擔。
格式特別有用的時機，是內容開始出現固定欄位、重複項目、明確限制，或要交給下一個工具繼續處理。它不是每餐都要拿出來的銀製餐具；便當用筷子就好，真的不用先畫餐桌配置圖。
如果只選一種先學，我會選 Markdown。
Markdown 用純文字符號表示標題、清單、強調、連結與程式碼區塊。這篇文章本身就是 Markdown。它最實用的地方，不是讓 AI 突然變聰明，而是讓人和 AI 都容易看出內容的分區。
例如，把 Prompt 全部擠在一起：
幫我整理資料，不要增加內容，使用繁體中文，每一列都要有來源，沒有資料就寫未知，最後用表格輸出。
改成：
## 任務
整理提供的資料。
## 限制
- 不得增加原文沒有的內容
- 使用繁體中文
- 沒有資料時填寫「未知」
- 每一列保留來源
## 輸出格式
使用表格。
資訊沒有增加，但「要做什麼」、「不能做什麼」與「最後長什麼樣子」被分開了。格式不能保證模型百分之百照做，卻能減少它需要猜測的地方。
初學者先記得幾個符號就很夠用：
#：標題-：項目1.：步驟**文字**：強調Markdown 適合 Prompt、筆記、README、文章草稿與會持續修改的內容。原始檔直接打開就能閱讀，Git 也容易看出哪一行被改動。它像整理過的書桌：東西還在桌上，但各自有明確位置。
JSON 比較像一張有固定欄位的表單，常見於 Function Calling、API、程式設定與結構化輸出。
例如查天氣工具可能需要：
{
"action": "get_weather",
"city": "Taipei"
}
一般使用者不必從空白開始手寫這段。像 Day 6 的例子，AI 可以根據自然語言產生工具名稱和參數，開發者也可以請 AI 幫忙建立資料格式。
但「不用手寫」不等於「完全不用看」。如果 AI 把城市填成 Tokyo，或者把「先草擬，不要寄出」轉成 send_email，格式再完美也做錯事情。看得懂欄位和值，至少能在工單送出去前發現它寄錯部門。
先知道三件事即可：
{} 通常包住一個物件[] 表示一串項目"city": "Taipei" 表示欄位名稱與它的值JSON 的優點是規則明確，程式容易解析與驗證；缺點是少逗號、多括號或引號錯誤，都可能讓解析器拒收。它適合交給程式，不適合拿來寫三千字心得。
還要特別提醒：結構正確不代表內容正確。 JSON 可以確保欄位叫做 temperature，卻不能保證裡面的 35 度真的來自天氣 API。格式解決的是邊界問題，不會自動消滅幻覺。
HTML 用標籤描述網頁的標題、段落、圖片、表格、按鈕與其他結構。例如：
<article>
<h1>AI 學習筆記</h1>
<p>今天學習 Function Calling。</p>
</article>
一般使用者未必需要手寫 HTML，卻可以直接要求 AI：
把這份研究整理成一個 HTML 報告，加入目錄、並排比較表和可收合的補充說明。
這正是 AI 時代讓 HTML 重新受到注意的地方。以前選 Markdown，是因為人類容易逐行撰寫與修改；現在有些工作變成由 AI 生成，人類主要負責閱讀、比較、決策，再用自然語言請 AI 修改。這時候，一份有視覺層次甚至能互動的 HTML，可能比很長的 Markdown 更容易使用。
Anthropic Claude Code 團隊工程師 Thariq Shihipar 在原始發文The Unreasonable Effectiveness of HTML中分享，他逐漸把部分 AI agent 輸出從 Markdown 改成 HTML。重點不是 Markdown 突然壞掉，而是那些文件主要用來閱讀與操作，不再由人類逐行編輯。HTML 可以呈現並排比較、色彩、圖表、互動元件，甚至做成一次性的小工具。
他也提到這種做法的代價：HTML 可能多花 2 到 4 倍時間生成、使用更多 token，而且標籤與樣式會讓 Git diff 比 Markdown 更難 review。HTML 檔也需要瀏覽器正確呈現，分享時可能還要找地方託管。
因此，比較合理的結論不是「HTML 取代 Markdown」，而是：
如果只是寫購物清單，真的不用請 AI 蓋一間線上商城；但如果要讓同事比較三個方案，一個清楚的互動頁面可能比五百行文字更容易被看完。
那 YAML 呢？如果你目前完全沒碰過，答案很簡單：不用為了 AI 特地先學。
YAML 常見於 GitHub Actions、自動化流程與工具設定。它看起來像比較少括號的設定表：
model: example-model
temperature: 0.2
tools:
- search
初學者先知道「它通常是設定」以及「縮排就是結構」就好。空白在這裡不是休息，而是有職務的空白；多縮兩格，內容可能就被分到另一個部門。
等到 GitHub Actions、工具設定或專案配置真的出現時，再學會修改需要的那一小段。AI 可以協助解釋每個欄位與產生草稿，你負責確認設定是否符合自己的環境。沒有遇到需求前，不必先背完 YAML 規格替未來的空白焦慮。
當然可以直接給。現在許多 AI 產品都能摘要 PDF、回答文件問題，也能讀取或產生 DOCX。
但「可以上傳」不代表模型拿到的內容，和人眼看到的頁面完全相同。
PDF 的強項是固定版面，適合正式報告、論文、列印與最終交付。可是雙欄排版、頁首頁尾、註腳、跨頁表格或掃描頁面，可能需要額外解析或 OCR；擷取後的文字順序也可能和人類閱讀順序不同。
DOCX 適合多人編輯、追蹤修訂、留言與辦公協作。AI 系統讀取時，仍要從文件結構、樣式、表格與圖片中整理出可用內容。
這些格式不是不好，而是用途不同：
因此，多一道轉換，就多一個可能失去結構、順序或細節的地方。不過也不用因此恐懼 PDF；清楚的標題樣式、合理的閱讀順序、可搜尋文字與簡單表格，都能讓 AI 比較容易理解。
在day07_practice.ipynb 放上了一個簡單的例子，來模擬說AI在解析PDF時，會出來什麼樣的產物，可以思考一下，這樣的文字與結構適合拿來直接給AI做文字接龍嗎？裡面有沒有出現錯誤的轉譯？有的話，你覺得正確的方式應該如何執行？
| 下一步 | 建議格式 |
|---|---|
| 寫作、修改與版本控制 | Markdown |
| 交給程式讀固定欄位 | JSON |
| 視覺呈現與互動 | HTML |
| 設定工具或自動化流程 | YAML，遇到再學 |
| 正式交付與辦公協作 | PDF／DOCX |
這不是法律條文。同一份內容可以先在 Markdown 中整理，再轉成 HTML 給人閱讀，最後輸出 PDF 交付。格式可以轉換，真正要守住的是內容、來源與使用目的。
AI 時代的格式知識，比較像交通規則，不是駕照考試的引擎拆解題。
你不需要親手打造每一輛車，但要知道紅燈不能衝、方向盤和煞車分別做什麼。同樣地，你不必默寫完整 HTML 或 YAML 規格，卻應該知道：
自然語言讓我們表達意圖，格式幫助我們固定重要的邊界。AI 可以替我們寫括號、標籤與縮排，但「這份東西下一步要去哪裡」仍然需要人來決定。
所以初學者不用一次學完四種格式。先會用 Markdown 整理需求、看得懂 JSON 工單；需要漂亮或互動的成果時，請 AI 產生 HTML；真的遇到設定檔，再回來認識 YAML。
格式不是考試科目，而是替下一位接手的人選一個不容易誤會的容器。便當不用裝進保險箱，正式報告也別寫在餐巾紙上。
明天，我們會回到自然語言，開始談 Prompt Engineering：你已經知道利用格式來開工單了，那我們究竟要怎麼把一件工作交代清楚？
參考資料
iThome鐵人賽
看影片追技術