OpenAI 為一般使用者發布 GPT-5.6 提示詞指南：別想太多，先講結果
OpenAI 針對最新的 GPT-5.6 系列推出提示詞撰寫指南，同時涵蓋一般 ChatGPT 介面與 Codex。不同於先前著重 API 參數與複雜提示詞架構的開發者文件，這份指南主打「從小處著手、說出你要什麼、必要時才加規則」。
怎麼用：提示詞可包含四個要素——目標、脈絡、風格、界限；但以「目標」為導向的簡短提示詞通常就夠用，大型任務的提示詞才需要四個要素備齊。
對誰有用：所有 ChatGPT 一般使用者，特別是常覺得「提示詞寫不好」的非技術工作者。
注意事項：跨對話都適用的偏好應設定在「設定 > 個人化」的自訂指令中，任務專屬的要求才放進提示詞。
這份指南同時涵蓋一般 ChatGPT 介面與 Codex，以單一框架呈現，其語氣與 OpenAI 近期針對 GPT-5 和 GPT-5.5 的開發者文件明顯不同——後者聚焦 API 參數、推理強度等級與繁複的提示詞架構，而這份使用者指南則強調：從小處著手，說出你要什麼，只在必要之處加上規則。
提示詞的四大基本要素
OpenAI 將提示詞結構化為「目標、脈絡、風格、界限」四要素。建議使用者與其詳細描述每個步驟，不如描述最終目標。當提示詞明確指出「理想結果」的標準時，GPT-5.6 通常能夠自行選擇高效率的搜尋、工具或推理路徑。只有處理較大的任務時，提示詞才需要注意四項要素均要備齊。
本指南建議以「結果」而非「步驟順序」開頭：「只有當流程本身很重要時才描述流程。否則，請留給 ChatGPT 空間去搜尋、比較資訊並調整做法。」指定目標或輸出格式，對成果的影響遠大於鉅細靡遺的操作指令。
限制條件勝過逐步腳本
相較於我們過去習慣為每個動作寫腳本，OpenAI 建議只需用一、兩條強制性規則來阻擋不想要的行為，例如：「保持已核准的日期與預算數字不變」、「將訊息準備成草稿，不要寄出」；但也要避免不必要的絕對規則。像是「ALWAYS、NEVER、must 和 only」僅用於真正的不變事項，例如安全規則、必填欄位或絕對不能執行的操作。
對於不同對話／專案需要判斷的情況，例如何時搜尋、詢問、使用工具或繼續迭代，使用者必須提供明確的決策規則，讓模型根據上下文或模式進行推理，避免模型去使用通用預設值、關鍵字對應或是廣泛語意捷徑（broad semantic shortcuts），造成結果誤差。
脈絡資訊不用多
同樣，「少即是多」的邏輯也適用於提供給 AI 模型的脈絡資訊：使用者只須附上真正會影響答案的資訊來源即可，包括試算表、PDF、圖片、網路搜尋與共用專案檔案，以及 Google Drive、Gmail、Slack 和 GitHub 的外掛程式等等。
明確定義個性和協作風格
例如，對於服務客戶的助理和協作產品，使用者需要定義其個性和協作風格。
個性決定了語調、熱情、直接程度、正式程度、幽默感、同理心和表達技巧。
協作風格決定了模型何時提問、何時做出假設、何時主動採取行動、何時解釋權衡取捨、何時檢查工作以及何時處理不確定性。
兩者都應簡潔明瞭。前者用來塑造使用者體驗；後者則是用來引導任務行為。兩者都不能取代明確的目標、成功標準、工具規則或終止條件。此外在設定上，諸如「友好」或「善解人意」這類詞可能造成模稜兩可，使用者使最好直接定義產品語氣的寫作選擇，像是「如何直接陳述答案、何時承認問題，以及是否應該給予保證或結語」等等；也應避免「始終以使用者的語言進行回覆」這類一概而論的語言規則。
確立模型的自主權和審核權限範圍
GPT-5.6 能夠主動且持續地執行多步驟任務。所以使用者必須定義每個請求授權的操作級別，以便模型能夠在安全、符合範圍的前提下持續工作，避免不必要的暫停，並在執行外部的、具有破壞性的或代價高昂的操作之前及時停止。
在指定安全的本機操作，例如讀取檔案、檢查日誌、編輯範疇內的程式碼以及執行測試時，建議將策略集中在一處，每條規則只需聲明一次就好。假如不斷重複「先詢問」、「禁止修改」或「等待批准」這類指令，可能會導致對安全且預期操作產生不必要的批准請求。
完成工作前的檢查與提示詞建議
對於高風險工作，OpenAI 建議請 ChatGPT 驗證自己的輸出，GPT-5.6 能夠存取可以驗證輸出的工具，並說明哪些驗證是重要的。
編寫程式：
After making changes, run the most relevant validation available:
- targeted tests for changed behavior
- type checks or lint checks when applicable
- build checks for affected packages
- a minimal smoke test when full validation is too expensive
If validation cannot be run, explain why and describe the next best check.
（進行變更後，執行最相關的驗證：
- 針對變更行為的針對性的測試 / 目標式測試
- 適用時進行類型檢查或程式碼檢查
- 對受影響的套件進行建置檢查
- 當完整驗證成本過高時，進行最小的冒煙測試
如果無法執行驗證，請解釋原因並描述次優檢查。）
視覺設計方面：
Render the artifact before finalizing. Inspect layout, clipping, spacing, missing content, and visual consistency. Revise until the rendered output matches the requirements.
在最終定稿前渲染模型。檢查版面、裁切、間距、缺失內容和視覺一致性。反覆修改，直到渲染結果符合要求。
建議的提示結構：
將此結構作為複雜提示的起點，每個部分都要簡短，並僅在會改變行為的地方添加細節。
Role: [the model's function and context]
Personality: [tone and collaboration style]
Goal: [user-visible outcome]
Success criteria: [what must be true before the final answer]
Constraints: [policy, safety, business, evidence, and side-effect limits]
Tools: [which tools to use, when, and what not to use]
Output: [sections, length, format, and tone]
Stop rules: [when to retry, fallback, abstain, ask, or stop]
角色：[模型的功能和背景]
個性：[語氣和協作風格]
目標：[使用者可見的結果]
成功標準：[最終答案必須滿足的條件]
限制：[政策、安全性、業務、證據和副作用限制]
工具：[使用哪些工具、何時使用以及不使用哪些工具]
輸出：[章節、長度、格式和語氣]
停止規則：[何時重試、備援 / 備用方案 / 回溯、放棄、詢問或停止]
Chat 處理快速任務，Work 負責繁重工作
本指南劃出一條界線：Chat 用於快速提問與改寫文字，Work 則用於需要整合多個來源、進行變更或產出較大交付成果（如報告）的任務。Work 任務會消耗比較多 token 額度，但只要能節省時間或支援重要決策時就值得。針對重複性任務，OpenAI 建議先手動優化提示詞，再進行自動化。使用者不需要第一次就把提示詞寫到完美，後續追問本來就是修正輸出的正常方式。跨對話都適用的偏好應放在「設定 > 個人化」的「自訂指令」中，任務專屬的要求則留在提示詞裡。
（首圖來源：OpenAI）