什麼是提示中的 XML 標籤？
提示中的 XML 標籤，就是像 <context>、<task>、<output_format> 這樣的簡單標記，用來把指令的每一部分包起來。它清楚告訴 AI 哪段是背景、哪句是請求、哪條是規則，讓所有內容不再混成一團。
大多數人寫提示時，都是把所有內容塞進一段文字，然後期望模型自己理清。事實上它往往做不到，只能猜哪一句才是真正的任務，而在狀態不好時，它就會猜錯。
解決方法很簡單，卻幾乎沒有人用：替每一段內容加上標籤。你在 HTML 裡見過這些角括號，在這裡它做的是同一件事，給模型一張清晰的提示地圖，而不是一堵文字牆。
為什麼 XML 標籤能讓 AI 輸出更穩定？
XML 標籤能讓輸出更穩定，因為它消除了歧義。當背景、任務與規則各自處於一個有標記的區塊時，模型不必再推斷哪裡是分界。它是在解析你的意圖，而不是猜測。
Anthropic 官方的提示工程文件，就把 XML 標籤列為建構複雜提示的主要方法，並指出模型經過專門訓練，會對這種結構有良好反應。
這對日常工作之所以重要，關鍵在於可重複性。一個只成功一次的提示，是運氣；一個第五十次仍然可用的提示，才是工具。結構，正是把前者變成後者的那一步。
換個角度想：沒有結構的提示，是要求模型讀心；有標籤的提示，是遞給它一份清單。清單永遠勝出。
你實際上應該用哪些 XML 標籤？
你不需要龐大的詞彙。三到五個標籤就能應付幾乎所有真實任務：<context> 放背景、<task> 放請求、<instructions> 放規則、<example> 放範例答案、<output_format> 放你想要的輸出形式。
並沒有一份官方的「正確標籤名稱」清單。Anthropic 的建議很單純：用能描述內容的名稱，並在你所有提示中保持一致。
一個合理的順序，貼近模型的閱讀方式：先放 <context>，再放 <task>，接著 <instructions>，最後 <output_format>。先交代情境，再提出請求，然後才是限制。
當某一類內容包含多個項目時，把標籤巢狀化。將多份參考文件包在 <documents> 內，每一份再放進自己的 <document>。這種層級關係對模型和你自己都一目了然。
如何用 XML 標籤重寫一個雜亂的提示？
拿一個典型的長串提示來拆解。所有描述情境的內容放進 <context>；那一句說明你要什麼的話放進 <task>；每一條規則與限制放進 <instructions>；想要的輸出形式放進 <output_format>。
以下是一個完整、可直接複製貼上的範本，你今天就能貼進 ChatGPT、Claude 或 Gemini，並改成任何任務：
試試這個提示：
<context>
我在香港一家 40 人的軟件公司負責市場推廣。我們的受眾是對新工具持謹慎態度的中小企老闆。品牌語氣要平實、溫暖，絕不誇張。
</context>
<task>
為一封宣佈全新報表儀表板的產品更新電郵，撰寫三個標題。
</task>
<instructions>
- 每個標題不超過 20 個字。
- 不用驚嘆號，不用表情符號。
- 一句以具體好處開頭，一句以好奇心切入，一句用平實描述。
- 避免使用「革命性」、「顛覆」、「解鎖」這些字眼。
</instructions>
<output_format>
以編號清單列出三句標題。每句之後，用一句簡短說明它採用了哪種角度。
</output_format>
你會發現，模型現在已無處游移。它知道受眾、確切的交付物、硬性限制，以及答案的形式。連跑五次，輸出都停留在同一條軌道上。
這招只適用於 Claude，還是 ChatGPT 和 Gemini 都有效？
這招到處都有效。雖然 Anthropic 主要為 Claude 明文說明 XML 標籤，但背後的好處是通用的：任何大型語言模型，只要提示把背景、任務與規則拆成有標記的區塊，而非一整段文字，輸出都會更穩定。
實際使用上，Claude 對這種結構的反應最明顯，因為它就是用這種結構訓練出來的。GPT 與 Gemini 同樣受益顯著，尤其在資料抽取，以及任何需要每次都拿回相同格式的任務上。
你並不是在寫必須通過驗證的真正 XML，而是在給模型視覺上的錨點。少一個結束標籤不會弄壞任何東西，不過把標籤關好，能讓長提示對你自己更易讀。
如果你手上已有幾個常用提示，把它們重新加上標籤一次即可。這套結構，你往後幾個月都會反覆沿用。
使用 XML 標籤時的常見錯誤有哪些？
最大的錯誤是過度加標籤。把每一句都包進獨立標籤只會製造雜音，把真正的重點埋沒。標籤是用來區分本質不同的內容，不是拿來裝飾。對大多數提示而言，三到五個標籤最恰當。
第二個錯誤是名稱不一致。若你在這個提示叫 <instructions>，下一個卻叫 <rules>，就會失去這技巧最值得採用的那份可重用性。選定名稱，然後貫徹到底。
第三個陷阱是替簡單問題加標籤。若你的提示只有一行，純文字就夠了。結構的價值，體現在複雜、多部分的提示，而不是「幫我摘要這段文字」。
最後一個是把指令放進 <context>。藏在背景區塊裡的規則，會被當成背景處理。把每一條限制都留在 <instructions> 裡，模型才會在它預期的位置找到它們。
立即試做：把一個你常用的提示重新加上標籤
挑一個你經常用、但大概只有一半機會給出好結果的提示。用上面的範本，把它拆成 <context>、<task>、<instructions> 與 <output_format>。新舊兩個版本並排，各跑五次。
你會在波動幅度上感受到差別。加了標籤的版本不再讓你意外。這份可預測性正是重點所在，因為一個你能信任的流程，勝過一個你無法重現的巧招。
這是一個回報遠超投入的小習慣。當你的提示有了結構，往後的一切，從範本到團隊共用的提示庫，都會更容易建立。
在 UD，我們相信好的工具不該冰冷，而應成為你工作中的夥伴。懂AI，更懂你，UD相伴，AI不冷。
準備好提升你的 AI 技能了嗎？
結構化提示只是其中一項技能，還有許多值得掌握，而成長最快的方法，是先看清自己今天的水平。UD 的 AI IQ 測試能在數分鐘內評估你目前的 AI 熟練度，再告訴你下一步該加強什麼。我們手把手帶你完成每一步，由第一個結果，到一套你能信賴的可重複流程。
