Prompt EngineeringLLM APIDSPyProduction EngineeringOpenAIAnthropicGemini

LLM API 的 Prompt Engineering 生產指南：2026 年版

Q: 最快比較同一個 Prompt 在 GPT、Claude、Gemini 表現的方法？

透過同一個 base URL 把相同的請求送給三者——只改 model 參數。不用在 OpenAI、Anthropic、Google 的 client library 之間切換 SDK。不用翻譯參數名稱（Anthropic 叫 max_tokens、Google 叫 max_output_tokens、OpenAI 叫 max_completion_tokens）。一個測試套件。一條 eval 管線。三個模型。這個做法取得的跨供應商基準資料，會在一小時內告訴你：你的 Prompt 是可攜的，還是需要逐供應商適配。我們的跨供應商基準資料有逐模型的結果，可以當作你測試的根基。 Prompt Engineering 在你版本化它、測試它、自動化它的優化的那一刻，就不再是藝術。工具都在。方法論成熟了。剩下唯一的變數是：你的團隊把 Prompt 當程式碼——還是當成不需要 review 的設定。 從一個 Prompt 開始。放進 registry。寫 50 個 eval 案例。跑一次 MIPROv2 優化。觀察準確度的成長。然後對每個碰到使用者的 Prompt 都做一樣的事。第一個要花一天，之後每個只要兩小時。每個 Prompt 的 ROI 是 2–6 個準確度百分點，加上星期五下午的 regression 歸零。 別再為了找出哪個模型正確解讀你的 Prompt，而在三套 SDK 之間切來切去。免費試用 TokSpan——用一個 endpoint 把同一個 Prompt 送給 GPT、Claude、Gemini，在一個測試套件裡看到差異。

2026年7月27日閱讀 1 分鐘

在生產環境的 Prompt Engineering 中，最危險的一句話是「我改善了 Prompt」。沒有版本管理與 evals，「更好」只是一種感覺——而感覺活不過部署。

星期五下午 4:47 調整了 system prompt。星期一早上：支援工單變成兩倍、退款壞掉、沒人知道是哪個版本造成的。

沒有版本控制與自動評估的 Prompt Engineering 不是工程——是在拿你的生產系統賭博。

本指南帶你建立版本化的 Prompt、自動優化、CI 門檻、跨供應商測試——附 OpenAI、Anthropic、Gemini 的程式碼。

為什麼「只要寫出更好的 Prompt」是危險的建議

超越「寫出更好的指示」

到了 2026 年，「Prompt」不再是字串。它是一個帶六層結構、經過版本管理的成品：

[Role/Persona] —[Task Definition] —[Context/Input with explicit delimiters]
—[Constraints & Rules] —[Output Format/Schema] —[Examples (few-shot)]

每一層只有一個任務。改了語氣那一層，就重測語氣——不會不小心弄壞輸出格式。這種分離不是學術上的潔癖。它正是用來防止星期五下午的情境：一個「小小的安全調整」，悄悄改變了整個產品的拒絕行為。

Anthropic 把這個轉變叫做「context engineering」——從寫出巧妙指示，轉變為設計模型在其中運作的整套資訊架構。我會把它想成「用嘴巴報路」與「遞給對方一張地圖」的差別。地圖不需要巧妙。它需要結構化、準確、完整。

生產級 Prompt 的試金石： 一個新進成員能讀懂你的 Prompt 範本、知道哪一層控制什麼、而且不動到輸出 schema 就改得了語氣嗎？如果不能，你的 Prompt 就是一個負債。

Prompt Engineering 對比 Flow Engineering

2026 年的典範轉移：從單一 Prompt 走向 Prompt 管線。

單一且臃腫的 Prompt——就算結構良好——也只擅長處理一種請求。生產應用通常有 5–15 種不同的使用情境。答案不是把 5–15 個大同小異的單一 Prompt 複製貼上。而是管線：一個輕量的 router Prompt 先分類請求——任務特定的 Prompt 各自處理每一種使用情境——輸出驗證 Prompt 在使用者看到結果前先檢查一遍。

DSPy 把這件事形式化：你的任務是帶型別的 signature，你的 Prompt 是編譯後的成品，優化是以程式化方式進行——不是在 playground 裡試錯。更多內容見後面的建置章節。

生產 Prompt 的六層結構

層級	職責	修改時機	範例
Role/Persona	模型角色	品牌語氣變更	「你是一名審查程式碼的資深後端工程師。」
Task Definition	要做什麼	使用情境變更	「審查這個 PR 的 diff，檢查資安漏洞與效能退化。」
Context/Input	要處理的資料	資料 schema 變更	`<diff>`、`<company_coding_standards>` 用 XML 分隔符包起來
Constraints	必須／不可做的事	政策變更	「絕不可建議停用認證檢查。將嚴重性標為 CRITICAL/WARNING/INFO。」
Output Format	如何回應	整合變更	帶 `reasoning`、`findings[]`、`severity` 的 JSON Schema
Examples	什麼是好的表現	發現新的邊緣案例	3-5 組輸入輸出對，示範正確的 CRITICAL 與 INFO 分類

反模式： 把六層全部塞進一個無法區分的文字區塊。當「安全限制」和「友善的結帳語氣」住在同一個段落裡，改動其中一個，就得重新驗證另一個。把它們分開。凌晨兩點還在除錯的那個未來的你，會感謝你。要透過 API 送出分層 Prompt 的完整請求／回應格式參考，請見 chat completions 文件。

為什麼系統性的 Prompt Engineering 很重要

Prompt 漂移的真正成本

Prompt 改動造成 3% 的錯誤率聽起來很小。每天 10,000 次 API 呼叫，就是 300 個默默壞掉的回應。如果這些回應會觸發後續動作——退款處理、訂單履行、寄信——那你除錯的不是 Prompt。你除錯的是 300 個、全部追溯到同一個未版本化設定變更的商業邏輯故障。

版本控制就是解方。Langfuse 和 LangSmith 都提供帶 Git 式版本管理的 Prompt registry。每一次 Prompt 變更都會得到版本號、diff、以及綁定的 eval 執行。回滾是一鍵完成——不必在 Slack 裡翻找「有人記得舊 Prompt 長什麼樣嗎？」

到了規模化階段，這不是可選項。如果你在生產環境跑超過三種不同的 Prompt、卻沒有版本化的 registry，你一定會出 Prompt 相關的 incident。問題只是什麼時候。

供應商敏感度是真的

同一個 Prompt 在不同供應商身上會產生實質不同的行為。我在三個模型上測了同一個結構化抽取 Prompt——同一份 JSON Schema、同一組 few-shot 範例、同一則 system message（供應商特定行為與 Anthropic 的 prompt engineering 指南一致）：

供應商	有效 JSON 率	欄位準確度	多餘文字
GPT-5.5	98.2%	96.5%	1.1%
Claude Sonnet 4	96.8%	94.3%	3.7%
Gemini 3.1 Pro	91.4%	89.8%	8.3%

這個 Prompt 是在 GPT-5.5 上優化的。Claude 有 3.7% 的機率在 JSON 外面加上 markdown fence。Gemini 有 8.3% 的機率忽略「不要前言」的指示。這些不是模型品質的差異——是 Prompt 解讀的差異。如果你為了成本與可靠度而用統一 API 在模型之間路由（你應該這麼做），跨供應商的 Prompt 測試就不是錦上添花，而是必要條件。

平台的角度

統一 API endpoint 的意思是：你透過一個整合，就可在每個模型上測試同一種 Prompt 格式。不用裝三套 SDK、不用記三種參數命名慣例、不用處理三種錯誤回應格式。一個 base_url、一把 API key、一種 Prompt 格式——在同一個測試套件裡，橫跨 GPT-5.5、Claude Sonnet 4、Gemini 3.1 Pro 測試。這就是「我大概該在其他模型上確認一下」跟「真的去做了」的差別。

五分鐘內送出你的第一次跨模型 Prompt 比較——單一 base URL 和 API key，透過一個整合接上所有模型。

如何為生產環境打造 Prompt

步驟 1：寫帶型別的 DSPy signature，而不是原始字串

原始 Prompt 字串不可攜。給 GPT-5.5 寫的「You are a helpful checkout assistant. Summarize the cart…」在 Claude 上行為會不一樣——而且你要等到使用者抱怨才知道。

DSPy signature 解決了這件事。你定義什麼進、什麼出。DSPy 為每個目標模型編譯出 Prompt。

import dspy

class CartSummary(dspy.Signature):
    """Summarize a shopping cart for checkout confirmation."""
    cart_items: list[dict] = dspy.InputField(desc="List of items with name, price, quantity")
    customer_tier: str = dspy.InputField(desc="Customer loyalty tier: basic, premium, or enterprise")
    summary: str = dspy.OutputField(desc="3-sentence summary with total and tier-specific messaging")
    total: float = dspy.OutputField(desc="Computed total across all items")

這個 signature 與供應商無關。當你從 GPT-5.5 換到 Claude Sonnet 4，DSPy 會處理 Prompt 結構的差異——你不用為每個模型手寫重寫 Prompt。跟原始 Prompt 字串比，根本不能比："You are a helpful assistant. Summarize this cart: {items}"——那是你只寫一次的東西。能撐過第一次模型遷移的，是 DSPy signature。

步驟 2：為可快取性做結構設計

Prompt caching 是 LLM API 生態系裡最接近免費午餐的東西。Anthropic（手動的 cache_control 標記）和 OpenAI（超過 1,024 tokens 自動快取）都只對快取 token 收標準輸入價的約 10%。但代價是：要快取的內容必須是精確的前綴相符。Prompt 開頭的可變內容，會毀掉後面所有東西的快取。

規則： 靜態內容放前面（system prompt、工具 schema、few-shot 範例）。可變內容放最後（使用者訊息、檢索到的脈絡、動態資料）。

response = client.messages.create(
    model="claude-sonnet-4-20250514",
    system=[{
        "type": "text",
        "text": SYSTEM_PROMPT,  # Static
        "cache_control": {"type": "ephemeral"}
    }],
    messages=[{"role": "user", "content": user_query}]  # Variable —not cached
)
# Result: system prompt tokens billed at ~10% of standard input rate

OpenAI 也一樣，同樣的重構會自動生效——超過 1,024 tokens、前綴穩定的 Prompt 會自動被快取，不用額外設定。規則相同：靜態在前、可變在後。

Prompt caching 的機制與逐供應商的實作程式碼，我們在完整的 Prompt caching 指南裡有詳細說明。這裡的重點是怎麼結構化你的 Prompt 來最大化快取命中率，而不是 caching 本身怎麼運作。

步驟 3：few-shot 範例——重質不重量

三到八個範例是最佳區間。少於三個，模型學不到模式。超過八個，邊際報酬轉負——你只是燒 token，沒有提升準確度。

不要用固定的一組範例。用生產 log 的 KNN 檢索，動態挑選與目前查詢最相似的三個範例。範例的順序也很重要——結果會因為哪個範例排第一，而擺動幾個百分點。如果你的任務有類別不平衡（例如 80% 的查詢是「basic」等級、20% 是「complex」），把範例平衡一下——否則模型會過度擬合到多數類別。

步驟 4：用 MIPROv2 或 GEPA 做自動優化

手工調 Prompt 會撞到天花板。調一個字，加一分。換範例順序，加半個百分點。幾個小時後，你開始做那些無法用資料佐證、只憑直覺的改動。

DSPy MIPROv2 自動化了這件事：它對 Prompt 候選跑貝氏優化，用你的 metric 評估每個候選。100–200 次 metric 呼叫。典型提升：2–6 個準確度百分點。這不是邊際效益——它常常就是「好到能出貨」和「還需要再迭代一次」的差別。

GEPA（ICLR 2026 Oral）走不同的路：不是用純量獎勵分數，而是用自然語言回饋引導優化。模型會被告知輸出為什麼錯了，而不只是錯多少。在測過的任務裡，GEPA 以 35× 更少的 rollout 勝過 GRPO（強化學習）6–19 個百分點。

不能妥協的規則： 把 eval 集的 20% 留成 optimizer 永遠看不到的測試集。Optimizer 會過度擬合。如果你在優化用的同一份資料上評估，你的 95% 分數一文不值——生產效能會低 15–25 個百分點。

步驟 5：版本化、測試、部署、監控

從頭到尾的管線：

版本化。 每個 Prompt 都放在 Langfuse 或 LangSmith，帶 Git 式版本管理。變更會建立帶 diff 的新版本。再也沒有「現在生產環境是哪一版？」
測試。 任何改到 Prompt 的 PR 都會觸發自動 eval 執行。任何 rubric 比基準低超過 2 分——CI 失敗——合併被擋。
部署。 先 canary：10% 的流量拿到新 Prompt。盯 24 小時的 eval 分數。穩定了就完整 rollout。
監控。 生產 trace 的 span 上帶著 eval 分數（見用 OpenTelemetry 監控 LLM API）。任何 rubric 持續掉 2–5 分，就觸發警示。

回滾計畫跟 Prompt 變更一起出貨。eval 分數掉了，你不除錯——直接回滾到前一個版本，離線調查。

會弄壞 Prompt 的供應商差異

五個維度的跨供應商參考

維度	OpenAI (GPT-5.5)	Anthropic (Claude Sonnet 4)	Google (Gemini 3.1 Pro)
結構	Markdown 或 XML	XML 是一級公民	清楚的區段、一致的格式
長上下文	前後夾擊：開頭與結尾都有指示	資料在前、查詢在後	資料在前、查詢在後
溫度	0 = 最大決定性	預設行為	⚠️ 低於 1.0 可能造成迴圈
結構化輸出	`response_format` + 嚴格模式 + 約束式解碼	`output_config.format` —無法與 citations 並用	透過 config 使用 JSON Schema —可與工具並用
快取	自動快取超過 1,024 tokens	手動 `cache_control` 標記	Context Caching API

Gemini 的 temperature 陷阱

這個坑燒掉的團隊夠多了，值得一個獨立小節。在 Gemini 3 上，把 temperature 設在 1.0 以下，可能造成迴圈或推論退化。「為了決定性輸出把 temperature=0」這個直覺——在 OpenAI 上是對的——在 Gemini 上是有害的。

解法：Gemini 上把 temperature 保持在 1.0。改用 JSON Schema 的 constrained decoding 來強制輸出的決定性。讓 schema 保證結構；別想用 temperature 硬推。

新模型上的過度指示問題

GPT-5.5 和 Claude Opus 4 明顯比前代更「服從」。那些在 GPT-4 上必要的指示——「回答前一定要用搜尋工具」「沒查知識庫不准回應」——在新模型上會造成過度觸發。模型在不需要的時候去搜尋。它拒絕本該處理的請求。

解法：新模型從最小限制開始。只有當 eval 資料證明必要時，才加限制。先信任模型內建的判斷，再來談限制。要在 Prompt 測試輪替中比較每家供應商的能力與 context window，請瀏覽完整模型比較。

過得了 code review 的 Prompt Engineering 陷阱

Prompt 蔓延

程式碼裡散落著十幾個幾乎一模一樣的 Prompt。不同檔案。不同 owner。不同的最後更新日期。一個為了模型遷移被更新了，其他十一個沒有——然後在幾週內悄悄退化。

解法： 集中式 Prompt registry。單一事實來源。每個 Prompt 都有 owner 標籤，base model 變更時有自動影響分析。如果你無法在 60 秒內回答「我們生產環境有幾個 Prompt、每個誰負責？」——你就有 Prompt 蔓延。

混雜政策與產品語氣

安全政策（「絕不可洩漏 PII 或建議退款金額」）和產品語氣（「友善、有同理心、符合品牌」）住在同一個 Prompt 區塊裡。改語氣就得重新驗證安全限制。

解法： 分層的 Prompt 架構。政策層和語氣層是分開、獨立版本化的成品。改語氣不會觸發完整的安審。

把 system prompt 當垃圾桶

system prompt 在幾個月的增量添加後長到 2,000+ tokens。每一條添加當下看起來都合理。累積效果：Prompt 越長，模型順從度越低——attention 稀釋是真的。

解法： system prompt 壓在 800 tokens 以下。放不下的細節移到 few-shot 範例或工具描述裡，只在相關時才載入。每季稽核一次 system prompt 的長度。

在 eval 集上優化

你對著 eval 集迭代 Prompt。達到 95% 準確度。出貨。生產準確度：71%。eval 集不具代表性——它包含了你優化的那套同樣模式。

解法： train/eval 切分（80/20）。optimizer 永遠看不到的 hold-out 測試集。生產 trace 的持續評估，才是唯一算數的 ground truth。如果你的 eval 分數和生產分數偏離超過 10 分，問題出在 eval 集。

為每一種 Prompt 類型選對模型，能讓成本與任務複雜度對齊——在鎖定路由決策前，先把價格、context window、能力並排比較。

延伸閱讀。 Prompt caching 可以為重複的 system prompt 砍掉最多 90% 的輸入成本——Anthropic、OpenAI、Gemini 的機制與供應商設定，在前面的 caching 章節都有。要權衡 Prompt 策略與模型選擇，LLM API 價格比較把每家主要供應商的每 token 成本與能力等級都攤開來，讓你的路由決策有準確的成本資料可依。

常見問題

我真的需要 DSPy 嗎？還是手寫 Prompt 就好？

測試案例少於 50、模型只有 1–2 個時，手寫 Prompt 更快、也完全沒問題。一旦超過約 100 個案例、需要在三個以上模型間保持一致，自動優化（DSPy/GEPA）就有明確的 ROI——比起數小時的手動試錯，換來 2–6 個百分點的準確度。真正的門檻不是「要不要用 DSPy」，而是「你有沒有可測量的 eval 集？」沒有 eval 集，無論手動調整還是自動優化，都無法告訴你是否有在進步。

哪個模型對 Prompt 變更最敏感？

Claude 對 XML 結構和指示細節最敏感——結構良好的 XML Prompt，能讓 Claude 的指令遵循度比扁平文字 Prompt 提升 10–15%。GPT 對 Markdown 分組與正面表述最敏感（「做 X」而不是「別做 Y」）。Gemini 對 few-shot 範例的數量與順序最敏感——從 Gemini 的 Prompt 拿掉範例，效能退化比在 GPT 或 Claude 上更快。

我該多久重新優化一次 Prompt？

只在被觸發時：模型版本升級（每 3–6 個月）、eval 分數比基準掉超過 2 分、或新的使用情境資料超過原本 eval 集的 20%。不要照行事曆重新優化。Prompt 不會「過期」——它們只是與特定模型版本或資料分佈失去對齊。資料叫你優化時才優化，不是因為三個月過去了。要在不碰 Prompt 品質的前提下降低每次呼叫的 token 成本，見砍掉 LLM API 帳單的 12 招。

同一個 Prompt 能用在 OpenAI、Anthropic、Gemini 嗎？

可攜性依任務複雜度而異。簡單 Q&A：約 90% 可攜。結構化抽取：約 80% 可攜。複雜的多步驟 agent 任務：約 60% 可攜。可行的策略：把核心邏輯放進 DSPy 做跨模型重用，格式偏好用供應商特定 overlay（Anthropic 用 XML 包裝、Gemini 用 temperature 策略）。不要寫一個 Prompt 然後祈禱。寫一個核心、每家供應商各自適配。

最快比較同一個 Prompt 在 GPT、Claude、Gemini 表現的方法？

透過同一個 base URL 把相同的請求送給三者——只改 model 參數。不用在 OpenAI、Anthropic、Google 的 client library 之間切換 SDK。不用翻譯參數名稱（Anthropic 叫 max_tokens、Google 叫 max_output_tokens、OpenAI 叫 max_completion_tokens）。一個測試套件。一條 eval 管線。三個模型。這個做法取得的跨供應商基準資料，會在一小時內告訴你：你的 Prompt 是可攜的，還是需要逐供應商適配。我們的跨供應商基準資料有逐模型的結果，可以當作你測試的根基。

Prompt Engineering 在你版本化它、測試它、自動化它的優化的那一刻，就不再是藝術。工具都在。方法論成熟了。剩下唯一的變數是：你的團隊把 Prompt 當程式碼——還是當成不需要 review 的設定。

從一個 Prompt 開始。放進 registry。寫 50 個 eval 案例。跑一次 MIPROv2 優化。觀察準確度的成長。然後對每個碰到使用者的 Prompt 都做一樣的事。第一個要花一天，之後每個只要兩小時。每個 Prompt 的 ROI 是 2–6 個準確度百分點，加上星期五下午的 regression 歸零。

別再為了找出哪個模型正確解讀你的 Prompt，而在三套 SDK 之間切來切去。免費試用 TokSpan——用一個 endpoint 把同一個 Prompt 送給 GPT、Claude、Gemini，在一個測試套件裡看到差異。