申請補助的文件拿去不同機關送件，欄位怎麼填、章蓋在哪一格，常常不是同一套規矩。內容一個字都沒改，換一個受理窗口就得重新排一次版，格式沒對規定，多半只等著補件。
丟給 AI 模型的指令，其實也在玩類似的遊戲。網路上流傳著「Claude 認 XML 標籤」、「GPT 偏好 JSON」這類說法，你可能也聽過，卻搞不清楚這是玄學，還是真的會影響輸出品質。這正是結構化提示詞寫法要處理的問題，也就是說，同一句指令換成標籤、鍵值物件、或標題階層這幾種固定排版方式餵給不同模型，理解效果確實可能出現落差。提示詞裡同時混著背景資料、範例、變數輸入的時候，模型誤判哪一段是規則、哪一段是資料的機率就會拉高。
搞懂這幾種寫法，你就能在提示詞真的需要更嚴謹的地方選對格式，不用每次都憑感覺賭一把。先從三種主流寫法本身長什麼樣講起，再看一份公開實測有沒有真的驗證出差異，最後留一份能直接套用的模板。
結構化提示詞是什麼？跟一般寫法有什麼差異？
結構化提示詞寫法說的是一件很具體的事，把指令、背景資料、限制條件、範例、使用者輸入這幾種不同角色的內容，用固定格式各自分開擺放，讓模型不用自己去猜「這句話講的是規則，還是要處理的資料」。相對的寫法，是把這些內容全部堆進同一段文字裡，句子接句子往下寫，彼此沒有任何分隔。提示詞短、內容單純的時候，這樣寫不成問題；但提示詞一旦變長，背景資料、範例、變數輸入同時塞進同一段，模型就容易分不清楚邊界在哪裡。
Claude 官方文件把這個問題講得很直接，提示詞混雜了指令、脈絡、範例、變數輸入的時候，模型最容易誤讀內容的邊界，把每種內容各自包進對應的標籤裡能有效降低誤判。Google 的 Gemini 官方文件也把結構一致性列為核心提示原則之一，例如要求少樣本範例的格式全部維持一致，避免模型學到不該學的格式規律，同時也各自示範了 Markdown 標題與 JSON 鍵值兩種排版寫法。
這篇要講的三種主流寫法，長相各自不同：XML 標籤式，替每一段內容各自貼一張標籤；JSON 鍵值式，把內容整理成一組組鍵值配對，填進結構化的物件裡；Markdown 標題式，靠 #、## 這類階層直接分段落。三種寫法要解決的問題相同，做法卻差很多，標籤式的分隔感最強，從這一種先看起，後面兩種的邏輯會更容易對照。
用 XML 標籤寫提示詞，怎麼下手？
XML 標籤式的做法很直接，挑幾個能望文生義的標籤名稱，把提示詞裡同一種角色的內容整段包進去，模型看到成對的開合標籤，就知道這一段內容扮演什麼角色，不用自己從上下文猜。Claude 官方文件把這個寫法列為主要建議之一，舉的做法是把指令包進 <instructions> 標籤、背景資料包進 <context> 標籤、要處理的資料包進 <input> 標籤，範例則用 <example>（多個範例用 <examples>）包起來，尤其在提示詞同時混著指令、脈絡、範例、變數輸入的時候，效果最明顯。
一份簡單的結構大概長這樣，把角色設定、背景資料、任務各自包成一組標籤，標籤名稱可以照這份提示詞實際的內容自己取：
<role>
你是一位資深的客服訓練教練。
</role>
<context>
以下是這位客服人員本週處理的三則對話紀錄。
</context>
<task>
指出這三則對話裡，哪一則最容易讓顧客覺得沒被聽懂，並說明原因。
</task>Code language: HTML, XML (xml)模型不需要額外提示就能分辨：<role> 裡的內容是身分設定，<context> 是背景資料，<task> 才是真正要執行的指令。就算三段文字前後緊貼著擺在同一份提示詞裡，也不會被混在一起解讀。
標籤怎麼命名，模型才看得懂？
標籤名稱要挑讀起來就懂的語意化名字，不要用「區塊一」、「區塊二」這種編號式命名。模型看不出「區塊一」代表什麼角色，連你自己隔幾週回頭改提示詞，也得重新想一次每個區塊原本是什麼。同一類內容建議全篇統一用同一組標籤名，這也是官方的建議，譬如所有使用者提問都固定包進同一個標籤裡，不要這次叫 <question>、下次換成 <user_input>。名字挑得越具體，模型跟你自己都省事。
巢狀結構什麼時候該用？
標籤要不要往裡面再包一層，關鍵看內容之間是不是真的有「整體包含個體」的關係。官方文件舉的例子是同時要放進好幾份文件，外層包一個 <documents> 標籤，裡面每一份各自再包一層 <document index="n">，並各自用 <source>、<document_content> 這些子標籤標出檔名與內容。這種結構才需要巢狀，因為這幾份文件本來就是一組文件底下各自的個體。
如果內容彼此獨立、沒有真正誰包誰的關係，單純只是想要視覺上分層，那就用同一層級的並列標籤就夠了，不必硬湊出母子關係。巢狀也別疊得太深，疊超過兩三層，提示詞會變得像層層嵌套的括號，連自己回頭核對每個標籤屬於哪一層都要花時間；真的需要標註額外資訊，用屬性（像 index="1" 這樣）標示，通常比再開一層新標籤更乾淨。
換成 JSON 物件，提示詞怎麼安排？
如果這份提示詞的輸出最後要直接被程式接手處理，JSON 鍵值式通常是更好的選擇，把整段內容包進大括號裡，每個欄位寫成一組鍵對應一個值。這種寫法特別適合原本就要接程式處理、要被解析、或要送進資料庫、API 的情境，模型產出的東西不是給人讀的散文，而是給下一步的程式直接吃進去的資料。
Google 的 Gemini 官方文件示範過一個點餐的例子：使用者說要兩個漢堡、一杯飲料、一份薯條，模型只要把有點的品項轉成鍵值配對就好，其他沒被點的品項完全不用列出來。
{
"hamburger": 2,
"drink": 1,
"fries": 1
}Code language: JSON / JSON with Comments (json)這個例子剛好點出鍵值設計最重要的原則，只留有意義的資訊，其餘全部省略，這樣後續要解析這份輸出的程式才好處理，不用先寫一堆判斷式去過濾空值或沒用到的欄位。
鍵值怎麼設計，才不會被誤判？
鍵名同樣要挑語意清楚的名字，「訂單品項」顯然比「data1」好懂，模型跟負責解析這份輸出的程式都能一眼對上欄位的意思。巢狀鍵值也別疊太多層，欄位嵌欄位嵌到第三、第四層，程式要往下取值時路徑會寫得又長又繞，讀起來也不輕鬆；能攤平成同一層級的欄位，就別硬要包出多層結構。
什麼情境該上 JSON Schema？
在提示詞裡手寫一段 JSON 範例，跟真的用 API 的 JSON Schema、或 OpenAI 所稱的 Structured Outputs 功能鎖住格式，是兩件不同的事。前者只是給模型一個參考樣式，模型仍可能漏欄位、欄位型別選錯、或給出不在列舉範圍內的值；後者是由 API 端強制約束，輸出保證符合你定義的欄位與型別。
OpenAI 官方文件指出，Structured Outputs 不需要額外驗證或重試格式錯誤的回應，這點是舊版 JSON mode 做不到的。JSON mode 只保證回傳的是一段合法的 JSON，不保證欄位符合你要的結構。凡是輸出要直接串接工具呼叫、或程式必須原封不動解析這份結果的情境，官方建議改用 API 本身的結構化輸出功能鎖定格式，而不是只靠提示詞文字去要求模型照著寫。
想用 Markdown 標題，提示詞怎麼組織？
三種寫法裡，Markdown 標題式讀起來最順，少了成對標籤跟大括號的語法開銷，字數通常也最省。靠 #、##、### 這類階層記號，把提示詞拆成角色設定、背景、任務、輸出格式幾個區塊，段落之間搭配清單或分隔線做區隔。
# 角色
你是一位品牌設計顧問。
## 背景
客戶是一個剛成立的手沖咖啡品牌，目前只有一個文字商標。
## 任務
建議三個延伸應用的方向，並各自說明理由。
## 輸出格式
用條列方式呈現，每個方向不超過兩句話。Code language: plaintext (plaintext)Google 的 Gemini 官方文件也用類似的寫法示範過，把身分設定放進 # Identity 這樣的標題底下，再用 # Constraints 這類標題交代限制條件；官方同時提到 XML 風格標籤跟 Markdown 標題兩種做法都可以，重點是選一種、在同一份提示詞裡維持一致，不要這段用標籤、那段又換成標題，風格混著來。
標題階層怎麼分段落？
階層用得對，提示詞讀起來就像一份結構清楚的文件，而不是一整塊文字牆。最外層的 # 通常擺身分設定，因為它決定模型接下來要用什麼角色回應；## 拆出背景資料跟任務這兩塊，分別交代模型知道什麼、模型要做什麼；如果輸出格式有特別要求，再開一個 ## 獨立列出來，不要塞進任務那段裡一起講。階層分得越清楚，你自己隔一段時間回頭改提示詞，也比較容易找到該動哪一段。
清單和表格，什麼時候比段落好用？
OpenAI 的 GPT-5 提示指南給了一條清楚的判準，只在語意上真的說得通的地方用 Markdown，具體列出的場景包括行內程式碼、程式碼區塊、清單、表格。多條並列的限制條件、或是要放多組對照資料，拆成清單或表格會比塞進同一段文字好讀得多；但需要語氣、需要脈絡的角色設定，還是留白用整段文字說明比較自然，硬要拆成條列，反而會把原本該有的語氣感切碎。
XML、JSON、Markdown，實測表現真的有差嗎？
網路上有兩種說法都很極端。一種說格式完全不重要，別浪費時間糾結；另一種說選錯格式，模型理解力差很多。
2026 年 3 月，一份叫 Delimiter Hypothesis 的公開實測剛好把這兩種極端說法都拆穿。測試團隊 Systima 找來四個前沿模型（GPT-5.2、Claude Opus 4.6、MiniMax M2.5、Kimi K2.5），分別用 XML、Markdown、JSON 三種格式跑十項任務，第一輪四項基礎任務、第二輪六項壓力測試，總共六百次模型呼叫、六百次評分，程式碼跟原始數據也都公開在 GitHub 上供人複查。
兩輪合併的總分，XML 拿 97.1%、Markdown 95.4%、JSON 97.3%，乍看 JSON 領先一截，但這個落差其實集中在一個模型身上，不是全面性的現象。拿掉 MiniMax M2.5 之後，GPT-5.2、Claude Opus 4.6、Kimi K2.5 這三個模型在三種格式間的分數差距都在 0.3 個百分點以內。對這三個模型來說，即使在進階壓力測試底下，格式幾乎不影響它們分辨提示詞邊界的能力。
真正的例外是 MiniMax M2.5。這個模型在第二輪進階壓力測試的整體分數，XML 拿 96.4%、JSON 同樣 96.4%、Markdown 卻只有 84.0%，落差主要來自其中一項稱作「同格式偽裝注入」的任務。這項任務單獨測試時，XML 與 JSON 都拿到 100% 的滿分，Markdown 格式初測只有 40%，團隊懷疑數字太極端所以又追加二十次驗證，結果確認這個模型在 Markdown 輸入下的實際失敗率大約是 20%，等於每五次有一次會把混進提示詞裡、偽裝成正常內容的注入指令當真執行。這是整份實測裡唯一一個具體、可重現、而且明確追溯到格式本身造成安全弱點的案例，而且只出現在 MiniMax 這一個模型面對 Markdown 輸入的時候。
實測裡也有一項叫「跨部門招募委員會」的任務，把職缺說明、六位面試官的專長與排程限制、兩份履歷、人資政策、多元雇用準則、預算備忘錄，十二個區塊同時塞進同一份提示詞裡要模型綜合判斷，這項任務不管用哪種格式，四個模型都拿不到 84.4% 以上的分數，格式間差異也壓在 1.1 個百分點內，反映的其實是模型的推理容量到了極限，不是格式解析出了問題。
換句話說，選錯格式在多數情況下不會讓你的提示詞效果大打折扣，除非你的場景剛好同時撞上兩個條件，一是用著對格式敏感的模型，二是提示詞會被餵進外部或使用者輸入的內容。下一節把這個結論對應到三大平台各自的官方建議上。
Claude、GPT、Gemini，分別該選哪一種？
三大官方文件對格式的態度不完全一樣，先各自看一遍，再對回上一節的實測結論。
Claude 官方文件建議挑幾個語意清楚的標籤，把指令、背景資料、要處理的資料、範例各自包起來，官方舉的例子包括 <instructions>、<context>、<input>，多個範例則包進 <example>／<examples> 這組標籤，尤其在提示詞同時混雜指令、脈絡、範例、變數輸入的時候，官方特別強調這個寫法的效果最明顯。
GPT 這邊的態度比較特別。OpenAI 的 GPT-5 提示指南寫明，GPT-5 在 API 裡預設不會把最終答案格式化成 Markdown，理由是要維持跟不支援 Markdown 渲染的應用程式相容，如果你要 GPT-5 穩定輸出分層的 Markdown，得在提示詞裡明講。這份指南還收錄了 AI 程式編輯器 Cursor 團隊調校 GPT-5 系統提示詞的實測心得，他們把提示詞改成類似 <[instruction]_spec> 這種結構化的 XML 寫法，發現指令遵從度提升了，這剛好是「GPT-5 並非只吃 Markdown」的具體反例。至於輸出要直接串接工具呼叫、或程式必須原封不動解析結果的情境，OpenAI 官方一律建議改走 JSON Schema，也就是 Structured Outputs 功能，不建議只靠提示詞文字硬性要求格式。
Google 的 Gemini 官方文件的立場比較中立，明白寫出 XML 風格標籤跟 Markdown 標題兩種做法「同樣有效」，重點在於選一種、並且在同一份提示詞裡維持一致，並沒有強制指定要用哪一種。
把這幾份官方建議對回上一節的實測結果，大致的落地方式並不複雜，多數情況下三種格式效果確實相近，官方偏好更多是哪一種寫起來順手、跟這個模型的訓練習慣比較搭這種層次的建議，不是用錯了輸出就會爛掉。唯一真正會影響到安全性的情境，是你的專案剛好用著像 MiniMax 這類對 Markdown 敏感的模型，而且提示詞會接受使用者貼上來的外部內容，例如網頁爬回來的文字、或使用者上傳的檔案。這種情境下，優先選 XML 或 JSON，盡量避開把外部內容直接嵌進 Markdown 段落裡。
知道該挑哪一種之後，接下來的問題是怎麼把這幾種寫法揉進同一份提示詞裡，而不是每次都從頭重新決定格式。
一份能直接複製套用的分隔符模板
多數提示詞其實不必只選一種寫法，三層混著用反而最實際。外層用 Markdown 標題分大區塊，好讀也好維護；需要跟外部或使用者輸入內容畫清界線的地方，改用 XML 標籤包起來；如果這段提示詞的輸出要直接被程式接手處理，最後那段輸出格式規格再用 JSON 鎖死欄位。
# 角色
你是一位電商客服訓練教練，負責檢查客服對話紀錄。
## 背景
以下是本週隨機抽出的三則真實對話紀錄，逐字保留原始內容。
<external_input>
[貼上實際對話紀錄原文]
</external_input>
## 任務
指出這三則對話裡哪一則最容易讓顧客覺得沒被聽懂，並說明原因。
## 輸出格式
請用以下結構回覆，欄位不可省略：
{
"worst_case_id": "對話編號",
"reason": "簡短說明",
"suggested_fix": "具體修改建議"
}Code language: plaintext (plaintext)這份骨架分三層，各自對應不同的需求。最外層的 #、## 負責把角色、背景、任務這幾個大區塊分開，這部分給人讀也給模型看，字數最省、也最不容易讀錯。中間那段貼上真實對話紀錄的地方，改包進 <external_input> 標籤裡，這段內容是從外面搬進來的，跟你自己下的指令性質不一樣，模型看到標籤邊界，不會把對話紀錄裡顧客隨口講的一句話誤當成新的指令來執行。最後輸出格式那段用 JSON 列出欄位，這段不是寫給人看的，是寫給接手處理這份輸出的程式看的，欄位名稱、欄位數量都先講清楚，程式解析起來才不會漏東西。
這個骨架背後呼應的正是前面實測的結論，格式選擇多數時候是可讀性決策，只在提示詞會接觸外部輸入、又用著對格式敏感的模型時，才會變成安全性決策。用 Markdown 顧好讀起來順不順，再用 XML 顧好邊界，兩邊同時兼顧，不用為了安全，犧牲掉整份提示詞的可讀性。
下次要動筆寫一份新的提示詞，可以先問自己三個問題：這份提示詞會不會同時混雜指令、背景資料、使用者輸入這幾種角色的內容？會不會有從外部貼進來的內容，需要跟你自己下的指令畫出清楚的界線？這份輸出最後是要給人讀，還是要直接餵給下一步的程式？
把這三個答案想清楚，結構化提示詞寫法該選哪一種通常就自己浮出來了，不用照抄某個模型官方規定的格式，也不必為了跟風換一次就把整份提示詞重寫一遍。格式從來不是決定提示詞好不好用的關鍵，你想清楚要模型做什麼、又打算怎麼處理它的輸出，才是真正決定效果的地方。