Prompt Engineering 指南

最後更新：2026-08-12· 18 分鐘閱讀

🚀 快速通道

ChatGPT 國內版：點擊直達↗
穩定鏡像站：開啟鏡像↗
官方 ChatGPT：chatgpt.com ↗

更新時間：2026-08-12

導讀

在產品裡，Prompt 是可版本化的程式碼：它定義輸出格式、安全邊界與失敗模式。本文講如何把 prompt 工程化——可 Git 管理、可回歸測試、可觀測——而不是堆魔法句式。配合文字生成參數與 API 整合使用。

Prompt 四層結構

[靜態 system]     角色、策略、schema（低頻變更）
[動態 context]    RAG、使用者檔案（每請求）
[Few-shot]        可選格式示範
[user]            終端輸入

層級	變更頻率	儲存
system 模板	低	Git / CMS + 版本號
RAG context	高	向量庫 + 引用 id
user	每工作階段	DB
評測集	中	repo 內 JSONL

System message 設計

邊界清晰：能做什麼、不能做什麼、不確定怎麼說。
格式可解析：JSON key、列舉、表格列名寫死。
拒絕策略：資料外不編造；敏感轉人工。
與 tools 一致：function 名、參數與 system 描述對齊。

RAG 助手 system 模板

你是企業內部知識庫助手。
規則：
1) 只根據「context」回答；不得使用 context 外事實。
2) context 不足時回覆「資料中未提及」，並列出需補充資訊。
3) 輸出 Markdown；引用標註 [段落序號]。
4) 不得輸出 Key、內部 URL 或未公開財務資料。

Few-shot：何時有效

適合	不適合
固定格式（分類、抽取）	開放域事實問答
品牌語氣（1–2 段範例）	樣例過多占滿上下文

{
  "messages": [
    {"role": "system", "content": "工單分類為 BUG|FEATURE|QUESTION，只輸出標籤。"},
    {"role": "user", "content": "支付頁一直轉圈"},
    {"role": "assistant", "content": "BUG"},
    {"role": "user", "content": "能否支援暗色模式"},
    {"role": "assistant", "content": "FEATURE"},
    {"role": "user", "content": "{{actual_input}}"}
  ]
}

樣例應來自真實分布；理想化假樣例會導致過擬合。

Chain-of-Thought 的生產用法

複雜任務可要求「先分析再結論」，但注意：

對使用者隱藏推理：只回傳最終 JSON；中間步驟放日誌（若合規）。
成本：長推理增加 output token。
評測：golden set 對比「直接 JSON」vs「分步」準確率。

在內部 <analysis> 列出約束（不返回前端）；
最終只輸出 JSON 物件。

閘道可剝離 <analysis>；或改用文件推薦的 reasoning 模型（若適用）。

工具呼叫 Prompt 對齊

模型是否穩定調工具，取決於：

description 寫清何時呼叫
參數 schema 最小且明確
system 禁止「假裝已呼叫」

{
  "type": "function",
  "function": {
    "name": "lookup_order",
    "description": "使用者給出訂單號並詢問狀態時使用",
    "parameters": {
      "type": "object",
      "properties": {
        "order_id": {"type": "string", "description": "純數字訂單號"}
      },
      "required": ["order_id"]
    }
  }
}

Agent 場景：Agents SDK、Responses API。

版本管理與發布流程

prompt_id: order_intent_v2
model: gpt-4o-mini
temperature: 0
changelog: "區分改地址與改手機號意圖"
golden_set: tests/prompts/order_intent.jsonl

改 prompt → bump 版本
跑 golden set（自動 + spot check）
Canary 5% → 全量

評測指標

任務	指標
分類	準確率、混淆矩陣
JSON 抽取	Schema 通過率、欄位 F1
摘要	關鍵點覆蓋（rubric）
客服	幻覺率、轉人工率

用業務 rubric，勿只看 BLEU。

防 Prompt 注入

使用者輸入可能與 system 衝突。緩解：

system 宣告忽略「外洩 system / 改規則」類指令
輸入長度限制與模式偵測
工具執行前伺服器端權限校驗
金鑰、連線字串不進 prompt

ChatGPT 網頁 vs API

網頁	API
部分 system 不可見	完全控制 messages
模型策略隨產品更新	鎖定 model + 參數
難批次回歸	CI 跑 golden set

網頁適合探索；定稿後遷入 API 並寫評測。體驗對話：本站 Chat（行為可能與 API 不完全一致）。

常見問題

把規則寫進 user 可以嗎？

部分介面允許；仍建議 system 角色便於閘道統一管理與快取。

prompt 越長越好嗎？

否。冗長浪費 token、稀釋重點、增加衝突指令。

換 model 要重測嗎？

要。格式遵循、工具、中文表現因 model 而異。

Assistants 的 instructions 等同 system 嗎？

概念類似，但有檔案與工具体系；且 API 可能遷移，見 Assistants 指南。

多語言 prompt 怎麼管？

按 locale 維護 system；或單一 system 指定輸出語言 + 術語表。

官方資源

下一步閱讀

行動路徑

今天：把生產 system 匯出 Git 並加 prompt_id。明天：寫 10 條 golden case + 自動校驗腳本。本週：改 prompt 必須過 golden 回歸，日誌記錄 model / temperature / prompt_id。

導讀