GPT-5.5 相較於 GPT-5.4 的新變化
較短、以結果為導向的提示，通常比偏重流程的提示堆疊效果更好。
更高效率的推理能力意味著，在提升推理強度之前，應重新評估使用 low 和 medium 的設定。
在工具密集的 Responses 工作流程中，前置說明（preamble）、phase 階段處理，以及助理訊息項目的回放仍然非常重要。
明確的人格設定、檢索預算與驗證規則，有助於塑造面向使用者的體驗與代理行為（agent UX）。
GPT-5.5 在提示中明確定義「目標成果」，並保留讓模型自行選擇高效解法的空間時表現最佳。
相較於舊版模型，你通常可以使用更短、更聚焦結果的提示：描述理想成果、重要限制、可用證據，以及最終答案應包含的內容。
避免直接沿用舊有提示結構。
過去的提示通常會過度規範流程，因為舊模型需要更多引導。在 GPT-5.5 中，這些可能會造成干擾、縮小搜尋空間，或導致答案過於機械化。
若需更多 GPT-5.5 行為變化細節，請參考《Using GPT-5.5》指南。本文件重點在於提示詞調整。
本文所提供的模式僅為起點，請依你的產品介面、工具、評估方式與使用者體驗目標進行調整。
使用 Codex 自動遷移
Codex 可透過 OpenAI Docs Skill 自動實作本指南中的變更。
$openai-docs migrate this project to gpt-5.5
若要在其他 coding agent 中使用，請從 OpenAI skills repository 下載。
人格與行為
GPT-5.5 預設風格為高效率、直接、任務導向。
這對生產系統很有幫助：回應更聚焦、行為更易控制，也避免不必要的對話填充。
對於面向使用者的應用（客服、支援流程、教學體驗等），應同時定義「人格」與「協作風格」。
人格決定助理的語氣，例如：
- 溫度
- 直接程度
- 正式度
- 幽默感
- 同理心
- 精緻度
協作風格決定助理的工作方式，例如：
- 何時提問
- 何時做合理假設
- 主動程度
- 提供多少背景資訊
- 是否檢查工作
- 如何處理不確定性與風險
兩者都應保持簡潔。
人格用來塑造使用者體驗，協作風格用來塑造行為。
兩者都不能取代清楚的目標、成功條件、工具規則或停止條件。
範例：穩定且任務導向的助理人格
你是一位能力良好的協作者：親切、穩定且直接。假設使用者是具備能力且善意的，並以耐心、尊重與實務幫助回應。
當需求已足夠明確時，優先推進而非停下來詢問。只有在缺失資訊會實質影響結果或造成風險時才提問，且問題應精準。
保持簡潔但不失禮。提供足夠背景讓使用者理解與信任答案，然後停止。必要時使用範例或比喻。
當需要糾正或不同意時，要誠實且具建設性。若出現錯誤，直接承認並修正。
在專業範圍內匹配使用者語氣。除非使用者明確要求，避免使用表情符號或粗俗語言。
範例：更具表現力的助理人格
採用生動且具對話感的風格：聰明、好奇、適時帶點趣味，並關注使用者思考。
當問題不明確時，提出好問題；當資訊足夠時，果斷決策。
保持溫暖、協作與精緻。對話自然流暢，但不為聊天而聊天。提供觀點，而非單純附和。
在需要綜合分析或建議時，應具深度與穩定性。當資訊足夠時給出明確建議，說明關鍵取捨，並指出不確定性。
使用前置說明提升回應速度
在串流應用中，使用者會感受到第一段文字出現的速度。
GPT-5.5 可能會先進行推理或準備工具呼叫，導致延遲。
對於多步驟或耗時任務，建議先輸出簡短前置說明：
簡要回應請求並說明第一步。
例如：
在進行工具呼叫前，先提供 1～2 句說明。
結果導向提示與停止條件
GPT-5.5 在以下提示方式表現最佳：
- 定義目標
- 定義成功條件
- 定義限制
- 提供上下文
讓模型自行選擇最佳路徑。
建議寫法
解決客戶問題直到完成。
成功條件：
- 根據政策與帳戶資料做出判斷
- 可執行動作需先完成
- 最終輸出包含：
- completed_actions
- customer_message
- blockers
- 若缺資料，只詢問最小必要欄位
避免過度規則
避免過度使用「一定要」、「永遠」、「只能」等絕對語句。
只在真正必要時使用，例如安全規則或必須輸出欄位。
停止條件
每次取得結果後問自己：
「我現在是否能用足夠證據回答核心問題？」
若可以，立即回答。
缺少證據時的行為
使用最少但足夠的證據，並精確引用，然後停止。
格式
預設使用自然段落。
僅在需要時使用：
- 標題
- 粗體
- 條列
明確指定輸出要求
例如：
為高階商業讀者撰寫，限制 400 字內。
先給結論，再說明原因，最後補充風險。
編輯與改寫
優先保留：
- 原內容
- 長度
- 結構
- 類型
只優化清晰度與流暢度，不新增內容或改變語氣。
檢索與引用
應明確定義引用規則。
檢索預算（retrieval budget）
- 先進行一次搜尋
- 若結果足夠則直接回答
- 僅在以下情況再搜尋：
- 無法回答核心問題
- 缺少關鍵資訊（日期、ID 等）
- 使用者要求完整列表
- 需要特定文件
- 否則會產生未支持的事實
避免為了潤飾語句再次搜尋。
創作內容規範
- 事實需有來源支持
- 不得虛構數據或成果
- 若無證據，使用通用描述或標示假設
前端與視覺品質
應考慮：
- 使用情境
- 設計系統一致性
- 響應式設計
- 避免常見錯誤（如過度裝飾）
要求模型自我檢查
程式碼
修改後需執行：
- 單元測試
- 型別檢查
- build 測試
若無法執行，需說明原因。
視覺輸出
需檢查：
- 排版
- 間距
- 遺漏內容
規劃任務
需包含：
- 需求對應
- 使用資源
- 資料流
- 驗證方式
- 失敗處理
- 安全與隱私
- 未解問題
Phase（階段）機制
長流程任務可使用：
commentary：中間更新final_answer：最終答案
若手動回放訊息，需保留原始 phase，不可更動。
建議提示結構
- Role（角色）
- Personality（人格）
- Goal（目標）
- Success criteria（成功條件）
- Constraints（限制）
- Output（輸出）
- Stop rules（停止條件）
