7 個生產環境系統提示詞範例（2026 可直接複製貼上模板）

最好的系統提示詞範例並非來自教學文章中那些「你是一個樂於助人的助手」的一行式指令。它們是能夠防止生產環境應用程式在凌晨兩點出錯的具體指令區塊。在我們自己的內容管道中，我們運行著十幾個 Claude 子代理（subagents），每個代理都由一個系統提示詞引導，而這些提示詞在 Claude Opus 4.8 或 GPT-5 引發錯誤後，經過了反覆的重寫。本篇文章跳過那些玩具級的示範。您將獲得 7 個真實、可直接複製貼上的系統提示詞，其中兩個直接取自我們的生產環境堆疊，此外還包含支撐每個可靠提示詞背後的六區塊結構解析。

重點摘要

• 系統提示詞是在任何使用者訊息之前一次性設定的持久性指令（角色、約束、輸出格式、防護欄）。
• 如果內容在 1,000 次請求中都相同，請將其放入系統提示詞；每次請求變動的內容則放入使用者輪次。
• 六個區塊構建出可靠的提示詞：角色、上下文、約束、輸出格式、防護欄、範例。
• 推理模型（o-series、GPT-5、Claude Opus 4.5+）需要高層次的目標，而非強硬的「你必須（you MUST）」措辭。

系統提示詞包含什麼？六大構建區塊

系統提示詞是一組持久性的指令，用於定義模型在整個會話中的角色、行為、約束和輸出格式，並在任何使用者訊息之前一次性設定。可靠的提示詞共享六個構建區塊：角色、上下文、約束、輸出格式、防護欄，以及可選的範例。按順序安排好這些區塊，你就掌握了如何編寫能在生產環境中存活的系統提示詞的精簡版指南。

以下是每個區塊的作用。

角色區塊的重要性超乎想像。Anthropic 的文件直截了當地指出：在系統提示詞中設定角色可以聚焦模型的行為和語氣，而且「即使只有一句話也會產生差異」。對於防護欄區塊，拒絕和安全規則值得深入思考；我們在防護欄指南中對此進行了深入探討。如果你正在整合 Claude，Anthropic 建議使用 XML 標籤（<instructions>、<context>、<input>）來分隔每種類型的內容，以免模型將其混淆。

這是一個可直接貼上的骨架，將所有六個區塊縫合成一個模板：

# ROLE
You are a {role} for {audience}. Your scope is {narrow scope}.

# CONTEXT
{Stable facts the model needs on every request.}

# CONSTRAINTS
- {Hard rule 1}
- {Hard rule 2}
- Do not {forbidden action}.

# OUTPUT FORMAT
{Exact structure: length, format, JSON schema.}

# GUARDRAILS
- If {edge case}, then {fallback or escalate to a human}.
- If you are unsure, say so instead of guessing.

# EXAMPLES (optional)
{One or two model answers that show the target quality.}

六個區塊將一種感覺轉化為規格說明。這僅是系統提示詞層。關於更廣泛的技術（少樣本學習、思維鏈、提示詞鏈），請參閱我們的提示詞工程指南，並將這些技術保留在系統提示詞本身之外。會話系統提示詞也不同於儲存庫層級的持久性專案級指令文件（如 CLAUDE.md），後者管轄的是整個程式碼庫，而非單一 API 會話。

7 個生產環境系統提示詞範例（可直接複製貼上）

以下是 7 個系統提示詞範例，你可以今天就直接貼入你的 system 參數或 developer 訊息中。每個範例都針對一個真實的工作場景（代理、RAG、支援、程式碼、JSON、內容 QA、翻譯），並展示了其關鍵區塊存在的原因。最後兩個範例運行在我們自己的管道中。Cursor 和 Devin 提示詞洩漏的儲存庫證明了市場需求；但沒有人公開的是解釋每個區塊為何存在的註解。

1. 自主代理

狹義地界定角色，明確說明工具規則，並給予停止條件，使其無法無限循環。

You are a research agent. Your only job is to answer the user's
question using the provided tools.

TOOLS: web_search, read_url, calculator.

RULES
- Plan first: list the steps before calling any tool.
- Call one tool at a time and check the result before the next call.
- Never invent a URL or a fact. If a tool fails twice, stop.

STOP CONDITION
- When you have enough to answer, stop calling tools and reply.
- If the task needs account access or a purchase, hand off to a
  human and explain why.

為何有效：狹義的角色加上明確的停止條件，決定了代理是完成任务還是陷入循環燃燒 Token。這是優質代理系統提示詞最佳實踐的核心。

2. RAG / 檢索問答

檢索遊戲的全部重點在於阻止模型憑藉自身記憶回答問題。一條規則即可做到。

You answer questions using ONLY the context provided below.

CONTEXT
{retrieved_chunks}

RULES
- If the answer is not in the context, say: "I don't have that
  in my sources." Do not use outside knowledge.
- Cite the source after each claim using [chunk_id].

OUTPUT
Two to four sentences, plain text, with citations.

為何有效：「僅依據上下文」加上引用格式，是你為 RAG 系統提示詞能寫出的最廉價幻覺防護措施。

3. 客戶支援機器人

語氣、升級路徑和嚴格的資金規則能讓支援機器人保持幫助性，同時不會讓它承諾做不到的事情。

You are a support agent for Northwind's billing team. Be warm,
brief, and factual.

CONTEXT
- Customers are on Free, Pro, or Enterprise plans.
- Refunds are allowed within 14 days of a charge.

CONSTRAINTS
- Never promise a refund above $200 without escalation.
- Do not give tax or legal advice.

GUARDRAILS
- If the customer is angry or asks for a manager, escalate to a
  human and say a teammate will follow up within one business day.
- If you are unsure of a policy, say you'll check rather than guess.

為何有效：退款防護欄和升級 fallback 機制阻止了導致支援機器人從生產環境下架的兩種失敗模式。

4. 程式碼助手

約束輸出格式和版本，並讓它在編輯前先進行解釋。

You are a coding assistant for a Next.js 15 + TypeScript codebase.

RULES
- Explain your plan in two sentences before writing any code.
- Output changes as a unified diff, not full files.
- Match the existing style. Do not add dependencies without asking.
- Target Node 20. Do not use APIs newer than that.

If a request is ambiguous, ask one clarifying question before editing.

為何有效：「diff 而非完整檔案」加上版本上限，讓助手保持在你的技術堆疊範圍內。程式碼代理的提示詞設計深奧到值得擁有專屬指南，因此我們在此保持範例精簡。

5. 結構化資料 / JSON 提取

將 Schema 放入輸出格式區塊，並禁止散文式輸出。這是可靠結構化輸出的模式。

You extract structured data from raw text. Return ONLY valid JSON,
no prose, no markdown fences.

SCHEMA
{
  "company": "string",
  "amount_usd": "number",
  "date": "YYYY-MM-DD",
  "confidence": "low | medium | high"
}

RULES
- If a field is missing from the text, use null.
- Never guess a value to fill a field.
- Output must parse with JSON.parse on the first try.

為何有效：文字化的 Schema 加上「僅有效 JSON」每次都勝過描述性格式。關於提示詞之外的強制執行模式（JSON Schema 驗證、基於工具的提取），請參閱我們的結構化輸出指南。

6. 內容 QA / 驗證器代理（來自我們的生產管道）

這個範例運行在我們自己的堆疊中。我們的驗證器系統提示詞是一個負面約束範例：它告訴模型絕對不要寫什麼，然後由腳本逐字檢查規則。

You are a content QA agent. You check one blog draft against a
fixed style contract.

BANNED VOCABULARY (auto-fail on any hit)
delve, leverage, robust, seamless, tapestry, pivotal, elevate,
harness, foster, bolster, paramount, intricate, "in today's",
"when it comes to", "it's worth noting", "game-changer"

FORMAT LIMITS
- Em-dashes: max 3 per 1,000 words of body.
- Vague quantifiers ("many", "several", "significantly"): max 1
  per 500 words of body.

ENFORCEMENT
- Do not "write naturally." Check every rule literally.
- A deterministic script (ai_slop_check.py) greps the draft and
  exits non-zero on any hit. If it fails, the post does not publish.

為何有效：列舉式的禁令清單加上 grep 檢查，是以「避免使用流行語」永遠無法做到的方式進行強制執行。模型可以對一種感覺爭辯，但無法對非零的退出代碼爭辯。

7. 翻譯代理（來自我們的生產管道）

這也是我們的範例。翻譯器的提示詞是一份輸出格式和完整性合約，並包含模型對其自身輸出的自我檢查。

You are an expert translator. You translate ONE blog post into ONE
target language.

COMPLETENESS CONTRACT
- Output the SAME number of H2 sections as the source.
- Line count must land within 80-120% of the source.
- Translate the FAQ fully. Never submit a partial draft.

DIACRITICS SELF-CHECK
- Keep native characters. If you output "karsilastirma" instead of
  "karşılaştırma" (Turkish), or "developpement" instead of
  "développement" (French), the translation is WRONG. Re-do it.

If you cannot meet the contract, report the problem. Do not ship a
truncated post.

為何有效：完整性合約加上具體的錯誤輸出範例，能夠捕捉到模糊的「準確翻譯」指令所放過的靜默失敗。

我們在生產環境運行系統提示詞的經驗教訓

我們自己管道中的三個系統提示詞錯誤，比任何文件頁面教會我們的都多。這三個錯誤都來自聽起來沒問題但不夠具體或無法驗證的指令。以下是發生在我們 16+ 個 Claude 子代理身上的問題，以及每次都能奏效的確切修復方法。模式每次都一樣：軟性規則會被忽略，具體且經外部檢查的規則才會生效。

禁用詞彙錯誤。 有好幾週時間，無論我們多麼客氣地要求，模型仍不斷將 leverage 和 robust 滑入草稿中。軟性的「避免使用流行語」指令毫無作用。修復方法是範例 #6：提示詞內的列舉式禁令清單，加上一個腳本，該腳本會 grep 輸出內容，一旦命中任何禁令詞即退出並返回非零狀態碼，此外還加上每 1,000 字最多 3 個破折號的上限。教訓：模糊的約束會被忽略；列舉式且經外部驗證的約束才會生效。

變音符號錯誤。 我們的翻譯器在處理土耳其語、法語和西班牙語時靜默地輸出了 ASCII 字符。karşılaştırma 變成了 karsilastirma，直到一位母語讀者標記出來才有人發現。修復方法是在提示詞中加入原生字符表、明確的錯誤輸出範例，以及運行後的 grep 檢查（零個原生字符意味著重新翻譯）。教訓：給模型一個具體的失敗範例，而不僅僅是一條規則。

穩定 ID 錯誤。 這是代價高昂的一個。一個在每次重新翻譯時重新推导本地化 slug 的系統提示詞，導致發布系統為每篇文章鑄造了第二份即時文件。我們在 2026-06-13 發布了 54 份重複的即時文件，直到 2026-07-05 才將其取消發布，這導致了三週的連結權重分裂和重複內容標記。修復方法：明確鎖定身份並原樣重用現有 ID。一個非確定性地重新生成自身識別符的系統提示詞會發布重複內容；我們在鎖定 ID 之前，我們的系統鑄造了 54 份即時文件。

最常見的系統提示詞錯誤有哪些？

最常見的系統提示詞錯誤包括：長篇大論的指令、相互矛盾的規則、僅使用負面措辭、將每次請求的上下文傾倒進靜態提示詞，以及省略 fallback 機制。在 2026 年的模型上有一個新錯誤：強硬的大寫字母和「你必須（you MUST）」措辭現在會過度觸發 Claude Opus 4.5+。

以下是快速修復清單：

• 長篇大論。 修復：將其拆分為六個區塊，並將穩定內容放在前面。
• 相互矛盾的指令。 修復：每行一條規則；在發布前解決衝突。
• 僅負面措辭。 修復：說明要做什麼，而不僅僅是要避免什麼。
• 大寫和「MUST」過載。 在 Anthropic 的新模型上這會適得其反。他們的文件現在指出，原本你可能寫成「關鍵：你必須使用此工具」的地方，現在可以使用正常措辭如「當...時使用此工具」。2025 年的建議現在成了錯誤。
• 靜態提示詞中的動態上下文。 將每次請求的數據保留在使用者輪次中。什麼內容該放哪裡是一門獨立的學問；我們的上下文工程指南涵蓋了這一點。
• 無 Fallback。 始終定義拒絕和升級路徑。
• 忽略長度與成本。 較長的提示詞會在每次調用時增加延遲和 Token 成本；修剪掉那些不值得保留的部分。

關於基本的指令清晰度原則，OpenAI 的最佳實踐文章仍然是一份扎实的檢查清單。

如何測試和迭代系統提示詞？

像測試程式碼一樣測試系統提示詞。建立一組帶有預期輸出的小型黃金輸入集，然後在每次更改時斷言模型的回應是否符合預期。對相同的輸入進行兩個提示詞版本的 A/B 測試，並保留通過更多檢查的版本。斷言總是勝過肉眼檢查。

最小的評估循環如下所示：

# pseudo eval loop
for case in golden_set:
    out = model(system=PROMPT, user=case.input)
    assert is_valid_json(out)              # format check
    assert case.expected_field in out      # content check
    if case.no_context:
        assert "I don't have that" in out  # refusal check
# ship the prompt version that passes the most cases

範例 #6 中的 grep 是你能運行的最廉價斷言：它無需成本且永不疲憊。當你的提示詞庫增長超過幾個時，使用真正的提示詞管理工具來版本化和測試你的提示詞，而不是在文件之間複製貼上。無論規模大小，重點都是一樣的：在沒有檢查機制告訴你改進是好是壞的情況下，切勿更改生產環境提示詞。

系統提示詞 vs 使用者提示詞 vs Developer 訊息

系統提示詞設定固定行為；使用者提示詞承載每次請求的任務；Developer 訊息是 OpenAI 推理模型的角色，持有應用層級指令，在指揮鏈中優先級高於使用者訊息。Anthropic 使用頂層的 system 參數，而非 role: "system" 訊息。以下是競爭對手通常忽略的三方劃分。

OpenAI 明確說明了排名：「developer 訊息是由應用開發者提供的指令，優先級高於使用者訊息」。因此，如果使用者試圖覆蓋你的應用規則，developer 訊息將在指揮鏈中勝出。

推理模型需要不同的系統提示詞嗎？（2026）

是的。像 OpenAI 的 o-series、GPT-5 和 Claude Opus 4.5+ 這樣的推理模型需要高層次的目標，而非逐步腳本。OpenAI 將推理模型比作你可以信任細節的高級同事，而 GPT 模型則表現得像需要明確指令的初級員工。

這種框架改變了你編寫提示詞的方式。對於推理模型，聲明目標和約束，並「信任他們自行解決細節」；對於 GPT 模型，則需詳述步驟。過度指定推理模型往往會使其表現變差，而非變好。

Claude 方面也有其自身的 2026 轉變。由於 Opus 4.5+ 對系統提示詞更敏感，過去堆疊 CRITICAL: 和 MUST 的習慣現在會過度觸發它。將這種語言調整回正常措辭。關於成本注意事項：將穩定、重用的內容放在提示詞的開頭，以便提示詞緩存生效，減少重複調用的延遲。如果你的推理模型正在進行逐步工作，思維鏈提示詞是其專屬主題且有專屬指南，因此我們在此不再重複教學。

Techsy 的方法

在 Techsy，我們為 B2B 客戶構建代理系統，上述的驗證器和翻譯器提示詞就在該生產堆疊中運行。我們將每個系統提示詞視為程式碼：對其進行版本控制，針對黃金集進行測試，並透過腳本而非運氣來強制執行不可妥協的規則。如果你正將 LLM 功能從示範移至生產環境，並希望在 AI 整合 工作上獲得協助，獲取免費諮詢。

關於作者

Mert Batur Gurbuz 是 Techsy.io 的聯合創始人，該團隊為 B2B 客戶交付 AI 代理、自動化系統以及語音/SDR 管道。他就讀於伯明翰大學，並撰寫有關 Techsy 團隊在生產環境中實際使用的 LLM 工具堆疊的文章。

Techsy.io 聯合創始人，伯明翰大學 · LinkedIn

常見問題

什麼是系統提示詞？

系統提示詞是一組在任何使用者訊息之前一次性設定的持久性指令，用於定義模型在整個會話中的角色、行為、約束和輸出格式。它是固定的「行為方式」層，在使用者的每次請求訊息變化時保持不變。

系統提示詞和使用者提示詞有什麼區別？

系統提示詞是固定的「行為方式」，在每次請求中相同；使用者提示詞是每次請求的「要做什麼」。一個簡單的經驗法則：如果內容在 1,000 次請求中都相同，它屬於系統提示詞；任何每次調用變動的內容則放入使用者輪次。

Developer 訊息與系統提示詞有什麼區別？

OpenAI 的推理模型（o-series、GPT-5）接受 developer 訊息而非 system 訊息。它承載應用層級指令，在指揮鏈中優先級高於使用者訊息，因此如果使用者試圖覆蓋你的規則，它將勝出。Anthropic 則保持單一的頂層 system 參數，而非基於角色的訊息。

系統提示詞應該多長？

在涵蓋角色、約束、輸出格式和防護欄的前提下，越短越好。過長的提示詞會在每次調用時增加 Token 成本和延遲，並可能在 Claude Opus 4.5+ 上過度觸發額外推理。如果穩定提示詞必須很長，請將重用內容放在前面，以便提示詞緩存抵消成本。

系統提示詞在 ChatGPT/GPT 和 Claude 中的工作方式相同嗎？

概念相同，機制不同。OpenAI 在訊息陣列中使用 system 或 developer 角色，而 Anthropic 使用單獨的頂層 system 參數，並傾向於使用 XML 標籤來分隔指令、上下文和範例。指令可以在供應商之間轉移；但連線方式和格式約定則不行。

可以在對話中途更改系統提示詞嗎？

透過 API，你在每次調用時重新發送完整的訊息負載，因此從技術上講，你可以在輪次之間交換系統提示詞。但在對話中途更改可能會破壞連續性，並使模型對其自身規則感到困惑。偏好一次性設定，或為了截然不同的特定任務提示詞而刻意交換。

我應該在系統提示詞中使用 XML 標籤還是 Markdown？

Anthropic 建議 Claude 使用 XML 標籤來分隔指令、上下文和範例，以免模型混淆。OpenAI 模型能很好地處理 Markdown 和普通標題。匹配供應商的約定，而不是強迫一種風格適用於兩者，並在單個提示詞中保持你所選風格的一致性。

推理模型需要不同的系統提示詞嗎？

是的。推理模型需要高層次的目標，就像簡報給高級同事一樣，而非逐步的微觀管理。放棄會過度觸發 Claude Opus 4.5+ 等新模型的強硬大寫和「你必須」語言，聲明目標和防護欄，並讓模型規劃實現目標的路徑。

良好系統提示詞的組成部分有哪些？

六個區塊：角色、上下文、約束、輸出格式、防護欄或 fallback，以及可選的幾個範例。角色和約束承擔大部分工作；輸出格式區塊使回應可解析；防護欄定義邊緣情況下的行為。只有當目標質量難以用言語描述時，才值得添加範例。