ChatGPT、Claude、Gemini 指令寫法差異：三家官方文件對照與原創範例
ChatGPT、Claude、Gemini 的官方提示詞文件各推不同寫法：角色分層、XML 標籤、永遠放 few-shot。本文全程根據三家官方文件對照，各附一個原創範例，並點出兩家罕見一致的長文件共識。
ChatGPT、Claude、Gemini 三家都有官方的提示詞工程文件，而且寫法建議真的不一樣——不是玄學，是白紙黑字的官方立場差異。這篇全部根據三家官方文件對照整理，各附一個可以直接改用的原創範例。
一張表看差異
| 面向 | OpenAI（ChatGPT） | Anthropic（Claude） | Google（Gemini） |
|---|---|---|---|
| 結構建議 | Markdown 與 XML 都行；developer 訊息順序 Identity → Instructions → Examples → Context | XML 標籤是核心建議：<instructions>、<context> 等 | 一致結構＋清楚分隔符，關鍵指令放 system prompt |
| 招牌技巧 | 角色權限分層（developer、user、assistant）；reasoning 模型與 GPT 系列分流 | 先引用原文再作答；解釋「為什麼」提升遵循度 | 「永遠放 few-shot 範例」；prefix 接龍 |
| 長文件 | 用 RAG 補 context | 長資料放最上面、問題放結尾（官方稱測試中最多提升 30%） | 1M tokens；大量 context 放前面、查詢放最後 |
| few-shot 立場 | 建議使用 | 建議使用（<example> 標籤） | 立場最強：「always include few-shot examples」 |
OpenAI：角色分層、結構分區、模型分流
OpenAI 官方指南有三個重點。第一，訊息有權限層級：developer、user、assistant 三種角色有「不同層級的權限」，系統規則寫在 developer 層、用戶內容放 user 層，不要混在一起。第二，用 Markdown 標題或 XML 標籤劃分提示詞的邏輯區塊，官方建議的 developer 訊息順序是 Identity → Instructions → Examples → Context。第三是模型分流：reasoning 模型「給高層目標就好」，GPT 系列則要精確的逐步指令——同一段提示詞不該不分模型直接搬。
原創範例（developer 訊息、Markdown 分區）：
# Identity
你是電商客服助理，語氣簡潔。
# Instructions
- 只處理訂單、退貨、運送問題
- 超出範圍時，引導用戶聯絡真人客服
# Examples
用戶：包裹什麼時候到？
助理：請提供訂單編號，我查目前的物流狀態。
# Context
[貼上退貨政策全文]
Anthropic：XML 標籤、長文件放頂部、引用再作答
Claude 官方文件最有識別度的建議是 XML 標籤：用 <instructions>、<context>、<example> 這類標籤把提示詞切乾淨，官方說法是幫 Claude「毫無歧義地解析複雜的提示詞」。官方還有一條「golden rule」：把你的提示詞拿給不熟脈絡的同事看，他會困惑的地方，Claude 也會。
長文件是 Claude 的強項（官方文件：標準 200K context、較新模型可達 1M）。官方的長文件技巧很具體：兩萬 token 以上的長資料放在提示詞最上面、問題放在結尾——官方原文說這在測試中「可提升回應品質最多 30%」；也可以要求 Claude 先引用文件原文（quotes）、再根據引用作答。最後一招是解釋「為什麼」：官方舉例，與其說「不要用刪節號」，不如說「因為 TTS 唸不出刪節號，所以別用」，遵循度更好。
原創範例（XML 標籤、文件在前、問題在後）：
<instructions>
你是法務助理。先引用合約原文，再用白話總結風險。
</instructions>
<contract>
[貼上合約全文]
</contract>
請先引用與「智慧財產權歸屬」相關的條款原文，
再條列我方需要注意的三個風險。
Google：永遠放 few-shot、查詢放最後
Gemini 官方文件對 few-shot 的立場是三家中最強的：「We recommend to always include few-shot examples in your prompts」——不是可以加，是永遠要加。第二招是 prefix／completion：給模型部分輸入或回應的開頭，讓它接龍，順便鎖住輸出格式；官方也建議明示輸出格式（表格、條列或段落）。針對 Gemini 3，官方額外強調一致的結構與清楚的分隔符、關鍵指令放 system prompt。長 context 是它的主打：1M tokens（官方換算約 5 萬行程式碼或 8 本英文小說），官方同樣建議大量 context 全放前面、查詢放在提示詞最後，重複使用的 context 可用 context caching 省成本。
原創範例（few-shot＋prefix 接龍）：
把客訴分類成「物流」「品質」「客服態度」三類。
輸入：等了兩週還沒出貨
分類：物流
輸入：杯子收到就裂了
分類：品質
輸入：客服已讀不回三天
分類：
最後一行故意停在「分類：」，讓模型直接接答案——這就是官方教的 prefix 技巧。
三家的共同點，和一條值得記的共識
共同點：三家官方都推「清楚的指令＋few-shot 範例」，這是底線。更值得記的是一條罕見的跨家共識：Anthropic 和 Google 的官方文件都建議——長資料放提示詞前面、問題放最後。兩家官方文件分別這樣寫，處理長文件時可以當成通用習慣。其餘的就入境隨俗：給 ChatGPT 用 Markdown 分區加角色分層、給 Claude 用 XML 標籤、給 Gemini 永遠帶 few-shot。站上的聊天提示詞可以在提示詞庫按工具篩選，改寫前先看它原本是為哪一家寫的。
FAQ
Q1：同一段提示詞可以三家通用嗎？
基本結構（清楚指令＋few-shot）三家都吃，但招牌技巧不通用：OpenAI 的角色分層、Claude 的「引用再作答」、Gemini 的 prefix 接龍都是各家官方文件特別推的，搬家時照各家習慣改寫效果較好。
Q2：XML 標籤只有 Claude 能用嗎？
不是。OpenAI 官方也建議用 Markdown 或 XML 劃分區塊；差別在 Anthropic 把 XML 標籤當核心建議、官方文件著墨最深。
Q3：長文件該放提示詞的前面還是後面？
放前面、問題放最後。這是 Anthropic 與 Google 官方文件少見的一致建議；Anthropic 並稱在測試中可提升回應品質最多 30%。