GPT-5.6 Prompt 怎麼寫？OpenAI 官方提示詞教學、實戰範例與 Evals 優化
GPT-5.6 Prompt 怎麼寫？整理 OpenAI 官方提示詞指南，教你精簡冗長規則、設定成功標準與 Stop rules，並用 3 組範例和 Evals 優化結果。
GPT-5.6 Prompt 怎麼寫？重點不是把提示詞寫得更長，而是說清楚成果、限制、驗收標準與停止條件。
OpenAI 在最新的 GPT-5.6 Prompting guidance 中，給出的方向很直接：先定義要完成的成果、重要限制、可用證據與驗收標準，再讓模型自行選擇有效率的執行路徑。
這和過去常見的 Prompt 教學差很多。以前我們習慣替 AI 指定角色、列出十幾個步驟，再補上一長串「一定要」與「絕對不能」。但對 GPT-5.6 來說，規則重複、工具過多、範例互相矛盾，反而可能讓結果更不穩定。
真正值得學的，不是一條新的萬用咒語，而是把 Prompt 從「操作手冊」改寫成一份可驗收的工作 Brief。這也是 Prompt Engineering（提示工程）的實際用途：用可以測試、比較與持續修改的方法，讓模型輸出更穩定地符合產品需求。
GPT-5.6 提示詞的核心：寫清楚終點，不要遙控每一步
OpenAI 建議的基本結構，可以整理成以下 8 個區塊：
| 區塊 | 要回答的問題 | 什麼時候需要寫 |
|---|---|---|
| Role | 模型在這個任務中負責什麼？ | 角色會影響判斷責任或專業視角時 |
| Personality | 回覆要呈現什麼語氣與合作方式？ | 對外客服、品牌內容、協作型產品 |
| Goal | 使用者最後要得到什麼成果？ | 幾乎所有任務都需要 |
| Success criteria | 怎樣才算完成？ | 需要驗收、交付或自動化時 |
| Constraints | 有哪些政策、風險與權限邊界？ | 高風險、正式資料或外部操作 |
| Tools | 哪些工具何時可以使用？ | Agent、搜尋、程式或多工具流程 |
| Output | 要用什麼格式、長度與順序交付？ | 結果要進入下一個工作流程時 |
| Stop rules | 何時重試、換方法、詢問或停止？ | 搜尋、Agent 與長任務特別重要 |
這 8 個區塊不是必填表格。簡單任務可能只需要 Goal 與 Output；只有任務複雜、會操作工具或涉及外部風險時，才逐步補上其餘內容。
我的判斷是：這套架構真正改善的不是「文案品質」，而是產品可維護性。當成功標準、工具規則與停止條件各自有明確位置，團隊更容易知道哪一條指令造成行為改變，也比較容易做版本管理與測試。
第一個原則：先刪 Prompt，再考慮加規則
OpenAI 建議從一套已經能工作的 Prompt 開始，每次只移除一組指令、範例或工具，再重跑相同的評估案例。
可以先刪掉：
- 同一條規則的重複說法。
- 不會改變輸出的風格或流程指令。
- 沒有實際影響行為的範例。
- 模型本來就能穩定完成的步驟說明。
- 與當前任務無關的工具與工具描述。
必須保留：
- 使用者最後會看到的成果。
- 成功標準與停止條件。
- 安全、商業、證據與權限限制。
- 會隨情境改變的工具路由規則。
- 必要的輸出格式與驗證方式。
OpenAI 公開的 GPT-5.6 Prompt 指南列出一組內部 coding-agent 評估結果：較精簡的 system prompt，在該組測試中讓分數提高約 10～15%，總 Token 減少 41～66%，成本降低 33～67%。這些數字只能當方向參考，不代表每個產品都會得到相同改善；官方也強調，仍要用自己的真實任務驗證。
這裡最容易誤解的是「精簡」。精簡不是把 Prompt 縮成一句模糊要求，而是刪掉不會改變行為的文字，保留真正影響結果的合約。
第二個原則：用 Success criteria 取代冗長步驟
比較以下兩種寫法。
較弱的寫法
你是一位世界級產品經理。
請先閱讀訪談，再整理需求，再分類問題，再分析優先級，
接著提出功能，最後寫成報告。每一步都要非常仔細，不能遺漏。
問題不在於它太短，而是「非常仔細」與「不能遺漏」無法驗收。模型完成了很多步驟，也不代表報告真的能幫團隊做決策。
較好的寫法
Goal：
把 8 份使用者訪談整理成 PM、設計與工程可共同審查的產品洞察報告。
Success criteria：
- 列出最重要的 5 個問題。
- 每個問題附上受訪者原話、影響流程與嚴重度。
- 區分重複出現的問題與單一案例。
- 最後列出仍需驗證的假設。
Constraints：
不要推測受訪者沒有說出口的動機，也不要把單一意見寫成市場共識。
Output：
先給一頁結論，再附完整證據表。
後者沒有規定模型一定要先做哪一步，但交付內容與驗收方式都很清楚。這正是 Outcome-first，也就是「成果優先」Prompt 的精神。
第三個原則：把停止條件寫進 Prompt
很多 Agent 卡住，不是能力不足，而是 Prompt 沒有說明何時可以停。
例如搜尋型任務若只寫「請完整研究」，模型可能為了追求完整而持續查找；如果只寫「盡量少用工具」，又可能在證據不足時太早回答。
可以改成：
用最少但足夠的搜尋完成任務，但正確性、必要證據與引用優先於減少工具呼叫。
每次取得結果後，先判斷核心問題是否已有足夠證據。
若已足夠就回答；若仍缺少必要日期、負責人、ID 或原始來源，
只補做最小範圍的查詢。若官方來源仍無法確認，明確說明缺少什麼，不要猜測。
Stop rules 的價值在於控制成本與可靠性，而不是單純要求模型「快一點」。它也讓工程團隊能把重試次數、fallback 與人工介入點寫成可測試的行為。
第四個原則：人格與合作方式要分開
OpenAI 把 Personality 與 Collaboration style 分成兩件事：
- Personality 決定語氣、溫度、正式程度、幽默與同理方式。
- Collaboration style 決定何時提問、何時合理假設、是否主動執行、如何解釋取捨與檢查成果。
只寫「友善、專業、有同理心」通常太模糊。更實際的寫法是描述具體行為：
直接說明結論。若使用者回報問題，先指出你理解的具體問題，再提供下一步。
只有在能減少焦慮或避免誤解時才加入安撫語句，不要使用空泛稱讚或制式結尾。
若缺少的資訊不會大幅改變結果，採用合理假設並清楚標示；
若選項會造成不同成本、外部寫入或不可逆結果，再詢問使用者。
對產品團隊來說，後半段通常比前半段更重要。語氣影響品牌感受，合作方式則直接影響完成率、打斷次數與操作風險。
第五個原則：把權限邊界集中寫一次
GPT-5.6 能持續處理多步工作，因此 Prompt 要說清楚什麼請求授權了哪些行動。
一個實用的分層方式是：
回答、解釋、審查、診斷或規劃：讀取相關資料並回報結果，不要自行實作變更。
修改、建立或修復：完成要求範圍內的本機變更，並執行相關、非破壞性的驗證。
外部寫入、刪除資料、付費操作或明顯擴大範圍：執行前取得確認。
這比在 Prompt 各處重複「先問我」「不要亂改」「未經同意不可執行」更容易維護，也比較不會讓模型對安全的本機讀取與測試過度詢問。
第六個原則：工具越多，不代表 Agent 越強
OpenAI 建議只提供與任務相關的工具。工具描述至少應包含：
- 工具能做什麼。
- 什麼情況應該使用。
- 哪些回傳欄位最重要。
- 空結果、部分結果與錯誤要怎麼處理。
如果多個讀取彼此獨立，可以平行執行；若前一個結果會決定下一步，就應保持循序處理。工具回傳空白或結果異常狹窄時，可以嘗試一到兩個有意義的替代方法，而不是立刻宣布「沒有資料」。
至於 Programmatic Tool Calling（PTC），它適合大量資料的篩選、排序、去重、彙總與重複驗證，不是看到多個工具就全部改成程式化呼叫。若中間結果需要語意判斷、引用必須保留，或操作需要批准，直接工具呼叫通常更適合。
第七個原則：長任務不要一直重新塞滿 Prompt
長流程還有兩個常被忽略的成本來源：狀態與快取。
第一，OpenAI 建議在長任務的重要里程碑後才做 compaction，也就是把歷史壓縮成較短狀態；不要每一輪都壓縮。過去的 reasoning 只有在目標、假設與優先順序仍然相同時才有價值，否則舊推理可能增加 Token、拖慢速度，甚至讓模型被過期方向綁住。
第二，Prompt Caching只能命中完全相同的 Prompt 前綴。因此固定的系統規則、工具與範例應放在前面，使用者資料與每次不同的內容放在後面。GPT-5.6 的 cache write 會以未快取輸入費率的 1.25 倍計費，cache read 則仍有折扣，所以不能只看有沒有開快取，還要追蹤 cache_write_tokens 與 cached_tokens 是否真的划算。
對維護者來說，這代表 Prompt 結構也會影響成本：穩定前綴比每次重排段落更容易得到快取效益。
第八個原則：先修 Prompt，再提高 reasoning effort
遇到錯誤時，最直覺的做法是把 reasoning.effort 往上調。但 OpenAI 建議先檢查 Prompt 是否缺少：
- 成功標準。
- 必要的依賴順序。
- 工具路由規則。
- 驗證迴圈。
GPT-5.6 model guidance列出 none、low、medium、high、xhigh 與 max 六種 reasoning effort。官方建議保留既有設定作為 baseline，再測試同一設定與低一級的效果；medium 可作為平衡起點，max 則留給真正困難、品質優先，而且經 Evals 證明有提升的任務。
另外，GPT-5.6 預設比 GPT-5.5 更精簡。若 API（應用程式介面，也就是產品用程式呼叫模型的方式）需要穩定控制詳略，可以用 text.verbosity 設定 low、medium 或 high，再在 Prompt 補上這次任務不能省略的內容。不要只寫「簡短一點」，而是說明必須保留結論、證據、重大限制與下一步，優先刪除背景、重複與客套語。
GPT-5.6 Prompt 實戰模板
下面這份模板適合研究、客服、內容產出與工具型 Agent。實際使用時，刪掉不會影響行為的區塊。
Role：
[模型在此任務中的責任與使用情境]
Personality：
[語氣，以及何時提問、假設、主動處理與說明不確定性]
Goal：
[使用者最後要得到的成果]
Success criteria：
- [可以驗收的條件 1]
- [可以驗收的條件 2]
- [可以驗收的條件 3]
Constraints：
[安全、商業、證據、權限與不可更動內容]
Tools：
[什麼情況使用哪些工具；空結果與錯誤怎麼處理]
Output：
[格式、長度、排序、必要欄位與語言]
Stop rules：
[何時回答、重試、fallback、詢問、拒絕或停止]
範例一：AI 閱卷系統的異常題目分析
Goal：
根據本批次的題目、學生作答、OCR 結果與人工複核紀錄，找出最可能造成分數異常的原因，供 PM 與工程團隊決定是否重跑。
Success criteria：
- 區分 OCR 錯誤、答案 mapping 錯誤、評分規則錯誤與資料缺漏。
- 每個判斷都附 examId、題號與證據欄位。
- 列出可直接重跑、需人工確認、不可自動處理三類。
- 不把相關性寫成已證實的因果。
Constraints：
只做診斷，不修改成績。缺少原始影像時標記 evidence_missing，不猜測手寫內容。
Output：
先給異常數量摘要，再輸出 JSON 明細與建議處理順序。
Stop rules：
若核心證據已足夠，直接完成報告；只有缺少會改變分類的 examId、原始影像或規則版本時才補查。查無資料時列出缺口，不持續無限重試。
範例二：有引用的技術研究文章
Goal：
撰寫一篇給台灣產品與工程團隊閱讀的 GPT-5.6 Prompt 教學文章。
Success criteria：
- 說明成果優先、成功標準、工具規則與停止條件。
- 至少提供 3 組可直接改寫的 Prompt。
- 所有產品能力、參數與數字都有 OpenAI 官方來源。
- 清楚區分官方事實與作者解讀。
Constraints：
不要用搜尋摘要作為唯一來源。找不到官方證據時縮小主張，不補造數字、案例或功能。
Tools：
先讀指定官方頁面；只有必要事實缺失時，再搜尋 OpenAI 官方網域。
Output：
繁體中文，先講結論，包含 H1、Meta description、正文、FAQ 與資料來源。
Stop rules：
核心主張已有一手證據就停止擴張搜尋；不要為了增加篇幅加入無關背景。
範例三：請 Codex 修復可重現 Bug
Goal：
修復設定頁顯示 Saved，但重新整理後資料未保留的問題。
Success criteria：
- 先重現問題並定位原因。
- 實作最小範圍修正，不改 API shape。
- 補上能防止同類問題復發的測試。
- 重跑重現步驟、相關測試與 lint，回報實際結果。
Constraints：
保留既有元件與設計系統，不修改無關檔案，不執行外部部署。
Tools：
先讀相關程式與測試；重現後再修改。若完整測試成本過高，至少執行最小相關測試與 smoke test。
Output：
先說修復結果，再列根因、變更檔案、驗證結果與仍存在的風險。
Stop rules：
驗證通過即可停止。若環境或權限阻擋重現，回報阻擋點與下一個最小可行檢查，不猜測已修復。
從舊 Prompt 遷移到 GPT-5.6：最穩定的 5 步驟
OpenAI 的遷移建議可以整理成以下流程：
- 先切換模型，保留目前的 reasoning effort。
- 在不修改 Prompt 的情況下，先跑一輪代表性 Evals。
- 一次刪除一組過期 scaffolding、重複指令或無關工具。
- 只有在測到明確 regression 時，才補上最小範圍的針對性指令。
- 每次改 Prompt 或 reasoning 設定後，重跑同一組案例。
Evals 就是用固定案例與評分標準檢查模型是否真的變好。OpenAI 的 Evaluation best practices建議採用 eval-driven development：提早建立貼近正式流量的測試、保留 Log、能自動評分的項目盡量自動化，再用人工判斷校準。最不可靠的做法，是只看一兩次輸出後覺得「好像比較好」。
還有一個 2026 年的重要維護提醒：OpenAI 已在 Prompt engineering 文件公告逐步停用 API 的 reusable prompt objects，並建議將正式 Prompt 放回應用程式碼，用 typed inputs、code review、測試與既有部署流程管理。舊 Evals 平台中的 dataset-backed Prompt Optimizer也在停用時程內。若現在才建立新流程，將 Prompt 寫進小型模組、加入代表性 fixtures 與 Evals，會比綁定即將下線的舊功能更耐用。
常見錯誤
錯誤一：把「你必須」寫滿整份 Prompt
ALWAYS、NEVER、must 與「只能」應留給真正不能破壞的安全規則、必要欄位與禁止操作。搜尋、提問、重試與迭代屬於判斷題，應改寫成 decision rules，也就是有條件的決策規則。
錯誤二：留下互相衝突的規則
例如同時要求「不得省略任何細節」與「一律控制在 100 字內」，模型無論怎麼做都會違反其中一條。GPT-5 類模型會更緊密地遵守 Prompt contract，因此衝突規則可能比少寫一條還不穩定。
錯誤三：先把 reasoning effort 拉到最高
如果 Prompt 沒說清楚成功標準或驗證方式，增加推理量可能只是讓模型更久地處理一個模糊問題。先補 Prompt，再用 Evals 判斷是否值得提高 effort。
錯誤四：要求「一步一步思考」
OpenAI 的 Reasoning best practices建議使用簡單直接的 Prompt，不必要求模型輸出 chain-of-thought。與其叫它「想得更仔細」，不如寫清楚最終目標、限制與可驗收條件。
錯誤五：一次重寫整套 Prompt stack
模型、reasoning、Prompt、工具與 runtime 同時修改，出問題時就無法知道是哪一層造成。一次只改一個變因，才符合 MVP 迭代與實際維護需求。
FAQ：GPT-5.6 Prompt 常見問題
GPT-5.6 提示詞要怎麼寫？
先寫清楚 Goal 與 Success criteria，也就是最後要完成什麼，以及怎樣才算完成。任務涉及工具、外部操作或多步流程時，再補上 Constraints、Tools、Output 與 Stop rules。每個區塊只保留會改變模型行為或驗收結果的內容。
GPT-5.6 Sol、Terra、Luna 的 Prompt 寫法一樣嗎？
本文的成果導向原則適用 GPT-5.6 模型家族，但不同模型與 reasoning effort 的品質、速度和成本取捨不一樣。實際遷移時應先保留既有設定作為 baseline，再用同一組 Evals 比較，而不是預設所有任務都使用最高規格。
GPT-5.6 的 Prompt 一定要使用 8 個區塊嗎？
不用。官方把這套結構定位成複雜 Prompt 的起點，並要求每個區塊保持簡短。只有會改變行為的資訊才需要加入；小任務通常只要說清楚 Goal 與 Output。
Prompt 越短，效果一定越好嗎？
不一定。應該刪除的是重複、無效與互相衝突的內容，不是安全限制、成功標準、證據要求與輸出格式。判斷是否改善，仍要看代表性 Evals。
要怎麼降低 GPT-5.6 的幻覺？
說清楚哪些主張需要來源、哪些來源可信、證據不足時怎麼處理，並要求引用只能附在實際取得的資料上。查不到不代表事實一定不存在，應改為回報證據缺口，而不是武斷回答「沒有」。
text.verbosity 可以取代 Prompt 的字數要求嗎？
不能完全取代。text.verbosity 適合控制預設詳略；特定任務仍應在 Prompt 中寫清楚必要段落、不能省略的資訊與長度上限。
Prompt Optimizer 優化後可以直接上線嗎？
不建議。官方要求優化後仍要做人工審查與 Evals，因為新 Prompt 可能在部分輸入上比原版更差。若使用舊 Evals 平台的 dataset-backed Prompt Optimizer，也要留意 2026 年停用時程。
結語：最好的 Prompt，比較像驗收單，不像遙控器
GPT-5.6 Prompt 的真正升級，不是多加幾個厲害形容詞，也不是把流程寫得更細。
更實際的做法是：先說清楚成果，再定義成功標準、證據、工具與權限；最後補上驗證與停止條件。模型負責選擇路徑，人負責定義什麼叫做完成，以及哪些風險不能越過。
如果你正在維護正式產品，先不要一次重寫全部 Prompt。保留 baseline，從刪除重複規則與無關工具開始，每次只改一件事，然後用相同 Evals 比較品質、Token、延遲與成本。
這種做法不華麗，但最符合 MVP：改得快、看得出差異，也容易回復與持續迭代。
