適用於誰
- 搜「系統提示詞怎麼寫」「系統提示詞和用戶提示詞的區別」的人；
- 在做智能體、客服機器人、Dify / 釦子應用，或者在 ChatGPT 自定義指令、Claude 項目說明裏要寫一段「長期生效的設定」的人。
本文根據 OpenAI、Anthropic、Google 三家的官方提示詞文檔整理，資料核對於 2026-10-11。各家模型更新很快，官方自己也建議用測試來驗證提示詞的效果。
結論先說
- 系統提示詞是「規則」，用戶提示詞是「這一次的輸入」。OpenAI 的比喻最好記：前者像函數定義，後者像傳給函數的參數。
- 系統提示詞的優先級更高。OpenAI 文檔寫明，開發者消息優先於用戶消息。
- 官方推薦的結構是四段：身份 → 指令 → 示例 → 上下文（OpenAI）。
- 寫清楚、寫具體、解釋原因，比堆砌「必須」「絕對不要」有效（Anthropic）。
- 最關鍵的約束放在系統提示詞裏，或者放在最前面（Google）。
先分清幾個名字
| 你看到的叫法 | 出現在哪裏 | 是不是一回事 |
|---|---|---|
| system prompt / 系統提示詞 | Claude API 的 system 參數、多數開源工具 | 是 |
| developer message / instructions | OpenAI API | 是。OpenAI 文檔說明，新的推理模型用開發者消息取代了原來的系統消息 |
| System Instruction / 系統指令 | Gemini API、Google AI Studio | 是 |
| 自定義指令、項目說明、智能體的人設與回覆邏輯 | ChatGPT、Claude、各類智能體平台的介面 | 作用相同，都是對話開始前就生效的長期設定 |
OpenAI 對三種角色的定義：
developer：應用開發者提供的指令，優先於用戶消息；user：最終用戶提供的指令，優先級在開發者消息之後；assistant：模型自己生成的內容。
所以，「每次都要遵守」的東西放系統提示詞；「這一次要處理什麼」放用戶消息。把一次性的任務細節塞進系統提示詞，或者把長期規則每次重複寫在用戶消息裏，都是放錯了地方。
步驟
1. 按四段結構搭骨架
OpenAI 文檔給出的開發者消息結構，通常按這個順序：
| 段落 | 寫什麼 |
|---|---|
| Identity（身份） | 助手的用途、溝通風格、總體目標 |
| Instructions（指令） | 怎樣生成回答：遵守哪些規則、該做什麼、不該做什麼 |
| Examples（示例） | 幾組可能的輸入和你期望的輸出 |
| Context（上下文） | 模型需要的額外資訊，如私有資料。官方說明這部分通常放在靠後的位置，因為不同請求帶的上下文可能不同 |
各段之間用 Markdown 標題或 XML 標籤隔開。OpenAI 的說法是：Markdown 的標題和列表用來標出提示詞的不同部分和層級，XML 標籤用來標明一段內容（比如參考文檔）從哪裏開始、到哪裏結束。
2. 身份：一句話就有用
Anthropic 文檔的原話是：在系統提示詞裏設定角色，可以讓模型的行為和語氣聚焦到你的使用場景上，哪怕只有一句話也會有區別。官方示例就是一句「你是一個專精 Python 的編程助手」。
身份不需要寫成長篇人物小傳。說清它是誰、為誰服務、用什麼口吻就夠了。
3. 指令：清楚、具體、講原因
Anthropic 給的三條原則，對任何模型都適用：
- 把模型當成一位聰明但剛入職的新同事，它不了解你們的規範和流程。官方的「黃金法則」是：把提示詞給一位不了解背景的同事看，如果他會困惑，模型也會；
- 順序或完整性重要時，用編號列表寫成步驟；
- 說明原因。官方的對比例子：只寫「絕對不要用省略號」效果較差；寫成「你的回答會被語音合成引擎朗讀，所以不要用省略號，引擎不知道該怎麼讀」效果更好，因為模型能從解釋裏舉一反三。
另一條來自 Anthropic 的格式建議：告訴它要做什麼，而不是不要做什麼。與其寫「不要用 Markdown」，不如寫「回答請用連貫的段落來寫」。
Google 對 Gemini 3 的建議方向一致：目標要說得精確直接，避免不必要的、過度勸說式的措辭；有歧義的術語和參數要明確解釋。
4. 示例：放兩三個，格式統一
示例是控制輸出格式最可靠的辦法之一。怎麼挑、放幾個、怎麼排，見《少樣本提示怎麼寫》。
5. 把最重要的約束放對位置
Google 文檔的建議：關鍵的行為約束、角色定義和輸出格式要求，放在系統指令裏，或者放在用戶提示詞的最開頭。資料很長時則相反，先放全部資料，把具體問題放在最後。
一份可以直接改的模板
# 身份
你是［公司名］的售後客服助手，面向購買了［產品］的普通用戶，語氣禮貌、簡潔。
# 指令
1. 只回答與［產品］的使用、退換貨、保修有關的問題。
2. 回答必須依據下方「資料」中的內容。資料裏沒有的，直接說
「這個問題我需要轉給人工客服」，不要自行推測。
（原因：錯誤的售後承諾會給用戶和公司都帶來損失。）
3. 每次回答不超過 150 字；需要操作步驟時用編號列表。
4. 用戶情緒激動時，先表示理解，再給解決辦法。
# 示例
<user_query>我的耳機左邊沒聲音了</user_query>
<assistant_response>抱歉給您帶來不便。請先試這兩步：
1. 把耳機放回充電盒，合蓋 10 秒後再取出；
2. 在手機藍牙裏刪除裝置後重新配對。
仍然沒有聲音的話，告訴我購買日期，我幫您看是否在保修期內。</assistant_response>
# 資料
<policy>
［在這裏粘貼售後政策全文］
</policy>改寫要點：身份一兩句話；指令編號、帶原因；示例和真實場景盡量接近；資料用標籤包起來放在最後。
常見問題
Q：系統提示詞是不是越長越好？
不是。Google 建議避免不必要的措辭；Anthropic 也提醒過度提示會帶來副作用，比如「拿不準就用某工具」這類兜底指令會讓新模型過度調用工具。寫完後逐條問自己：刪掉這一句，結果會變差嗎？
Q：要不要用全大寫的「必須」「絕對」來強調？
按官方的思路，優先解釋原因、把要求寫具體。強調語氣不是不能用，但不該是主要手段。
Q：用戶能看到或者套出系統提示詞嗎？
應當假設可能被套出來。不要把密鑰、內部連結、不能公開的規則寫進系統提示詞；真正的權限控制要放在程序裏做。
Q：不同模型要寫不同的系統提示詞嗎？
核心原則通用，細節有差別。OpenAI 文檔說明，推理模型和普通 GPT 模型的最佳寫法不同：前者只給高層目標效果就很好，後者更需要精確的指令；並建議在生產環境固定模型版本、建立評測，換模型時重新測試。
Q：在 ChatGPT、Claude 的聊天介面裏怎麼用上這些？
對應的入口是 ChatGPT 的自定義指令和項目說明、Claude 的項目說明等，見站內《ChatGPT 自定義指令怎麼設定》和《Claude Projects 怎麼用》。站內提示詞庫（/prompts）裏的提示詞，很多可以直接放進去當系統提示詞用。
參考資料
- OpenAI 文檔：Prompt engineering（消息角色、Markdown 與 XML 格式）— https://developers.openai.com/api/docs/guides/prompt-engineering
- Anthropic 文檔：Prompting best practices — https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
- Google 文檔：Prompt design strategies — https://ai.google.dev/gemini-api/docs/prompting-strategies
0 條評論
還沒有評論，來搶沙發～