GPT-5.5 Prompt 遷移指南：舊提示詞為什麼要先刪再改

OpenAI 在 API 文件裡更新了 GPT-5.5 prompting guide。這份文件最有價值的地方，不是又給了一套更長的提示詞模板，而是提醒開發者：遷移到 GPT-5.5 時，很多舊 prompt 反而應該變短。

官方文件地址：https://developers.openai.com/api/docs/guides/prompt-guidance

如果只看一句話，GPT-5.5 的提示詞方向是：少寫過程，多寫結果；少堆規則，多定義驗收；少用「永遠必須」，多寫清楚什麼時候停止、什麼時候驗證、什麼時候補證據。

舊 prompt 為什麼需要重寫

很多生產系統裡的 prompt 是一層層堆出來的。模型不穩定時，加一條規則；工具呼叫出錯時，再加一條禁止；輸出囉嗦時，再加一段格式要求。時間久了，系統 prompt 會變成一份厚重的操作手冊。

這種寫法在舊模型上有時有用，因為模型需要更多步驟約束才能不跑偏。但到了 GPT-5.5，OpenAI 的建議很明確：不要把舊 prompt stack 原樣搬過來。

原因很簡單。過度指定過程會帶來幾類副作用：

噪聲變多，模型要在大量舊規則裡找真正重要的約束。
搜尋空間變窄，模型不敢選擇更高效的解法。
輸出變機械，看起來像在執行腳本，而不是解決問題。
舊規則之間可能互相衝突，導致工具呼叫和最終回答都變笨。

GPT-5.5 更適合讓 prompt 描述目標狀態、約束、可用證據和最終輸出，而不是把每一步都寫死。

outcome-first：先定義什麼叫完成

官方文件反覆強調一個方向：GPT-5.5 最適合 outcome-first prompt。

也就是說，提示詞裡應該優先寫：

目標結果是什麼。
什麼條件算成功。
哪些約束不能突破。
目前可用上下文是什麼。
最終答案需要包含哪些欄位或部分。
證據不足時怎麼處理。

不太推薦的寫法是：

1

先檢查 A，再檢查 B，然後比較所有欄位，再思考全部異常情況，再決定呼叫哪個工具，再呼叫工具，最後解釋完整過程。

更適合 GPT-5.5 的寫法是：

1
2
3
4
5


解決使用者的問題。成功標準：
- 基於可用政策和帳戶資料完成判斷
- 如果允許執行操作，先完成操作再回覆
- 最終輸出包含 completed_actions、customer_message、blockers
- 如果缺少關鍵證據，只詢問最小必要欄位

這不是讓 prompt 變得含糊，而是把控制點從「過程順序」移到「結果和邊界」。模型可以自己選擇搜尋、推理和工具呼叫路徑，但必須對成功標準負責。

少用絕對規則，多寫決策規則

舊 prompt 裡常見大量 ALWAYS、NEVER、must、only。這些詞不是不能用，但應該只留給真正不可違反的約束，比如安全規則、必填欄位、禁止執行的動作。

對於「什麼時候搜尋」「什麼時候問使用者」「什麼時候繼續迭代」「什麼時候停止」這類判斷，GPT-5.5 更適合使用決策規則。

例如，不要只寫：

1

永遠先搜尋三次。

可以改成：

1

先做一次覆蓋核心問題的檢索。如果前幾個結果已經能支援關鍵事實，就停止檢索並作答。只有當證據衝突、缺失或不足以支撐結論時，才繼續搜尋。

這種寫法給了模型判斷空間，也給了它停止條件。對需要聯網、檢索、檔案搜尋或資料庫查詢的產品來說，這一點很關鍵，因為每多一輪工具呼叫都會帶來延遲和成本。

給檢索設定 retrieval budget

GPT-5.5 prompt 裡值得單獨加的一類規則是 retrieval budget。

它不是預算金額，而是檢索停止規則。它告訴模型：什麼時候證據已經足夠，什麼時候應該繼續找，什麼時候該承認缺證據。

一個實用寫法是：

1

普通問答先做一次寬檢索，關鍵詞要短且有區分度。如果前幾個結果已經能支援核心請求，就基於這些結果回答，不再繼續搜尋。只有當結果衝突、缺失關鍵事實或不能支援結論時，才追加檢索。

這類規則能減少兩種常見問題：

搜尋不夠，答案沒有證據。
搜尋過頭，模型在工具循環裡浪費時間。

更重要的是，文件還提醒：沒有搜到證據，不應該自動變成事實上的「否」。有時正確行為是說明證據不足，或者換一個更小的問題繼續查。

reasoning effort 不要一上來拉高

GPT-5.5 的推理效率更高，所以 OpenAI 建議重新評估 low 和 medium，不要一遇到品質問題就直接把 reasoning effort 往上加。

更穩的順序是：

先確認 prompt 是否寫清楚了目標、輸出格式和停止條件。
加上驗證循環，比如測試、引用、複核或渲染檢查。
為工具呼叫補上持久性規則和完成標準。
仍然不夠時，再提高 reasoning effort。

換句話說，reasoning.effort 更像最後的調參旋鈕，不應該替代清晰的 prompt 設計。

如果任務是短分類、欄位抽取、支援工單分流、格式轉換，可以先從低推理成本開始。如果是長文件綜合、多源衝突判斷、策略寫作、複雜研究，再考慮 medium 或更高。

text.verbosity 控制輸出，不等於控制思考

GPT-5.5 對輸出格式很可控。官方文件建議使用 text.verbosity 配合 prompt 裡的輸出要求。

預設 text.verbosity 是 medium。如果產品需要更短、更乾淨的回覆，可以使用 low。但這不意味著所有內容都要變短。

一個典型做法是：

面向使用者的狀態更新和最終總結保持簡短。
程式碼、配置、結構化結果需要清楚時，仍然要求可讀性。
不要為了「簡短」犧牲欄位完整性、引用和必要 caveat。

這對程式碼類產品尤其有用。可以讓聊天回覆短一點，但要求生成的程式碼保持可讀變數名、清楚結構和必要註釋。

preamble 和 phase：讓長任務更可感知

GPT-5.5 在複雜任務中可能先做推理、計畫或準備工具呼叫，然後才輸出可見文字。對流式產品來說，使用者會明顯感知首 token 等待時間。

官方建議是：對多步驟、工具密集或長時間執行的任務，讓模型先發一個短 preamble。它不需要解釋完整計畫，只要告訴使用者「我會先做什麼」。

例如：

1

我會先檢查相關檔案和現有配置，然後再給出修改方案。

在 Responses API 的長任務或工具密集工作流裡，還要注意 assistant item 的 phase。如果應用使用 previous_response_id，API 會自動保留前序 assistant 狀態；如果應用手動回放 assistant 輸出，就要保留原來的 phase 值。

常見約定是：

phase: "commentary"：中間狀態更新。
phase: "final_answer"：最終答案。
不要給 user message 添加 phase。

這部分看起來像底層實作細節，但對有工具呼叫、狀態更新和最終回答的產品很重要。手動回放時弄丟 phase，容易讓模型分不清中間進度和最終結論。

提示模型檢查自己的工作

GPT-5.5 guide 裡還有一條非常實用：在可以驗證的任務裡，給模型驗證工具和驗證規則。

對程式碼 Agent，可以明確要求：

修改後執行相關單元測試。
必要時執行 type check 或 lint。
影響套件較大時跑 build。
全量驗證太貴時，至少做最小 smoke test。
如果驗證無法執行，要解釋原因和下一個最好檢查方式。

對視覺或頁面產物，可以要求先渲染再檢查布局、裁切、間距、缺失內容和視覺一致性。

對工程方案，可以要求計畫裡包含需求對應關係、涉及檔案/API/系統、狀態流轉、驗證命令、失敗行為、隱私和安全考量，以及真正影響實作的開放問題。

這類規則比「請認真一點」有效得多。它把「認真」落到了可執行檢查上。

一個更適合 GPT-5.5 的 prompt 骨架

OpenAI 文件給出的結構可以簡化成這樣：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


Role:
你是什麼角色，要在什麼上下文裡工作。

# Personality
語氣、協作方式、是否需要溫度或觀點。

# Goal
使用者可見的目標結果。

# Success criteria
最終回答前必須滿足的條件。

# Constraints
安全、業務、證據、權限、成本和副作用邊界。

# Output
輸出結構、長度、語氣、欄位要求。

# Stop rules
什麼時候繼續、什麼時候重試、什麼時候降級、什麼時候詢問、什麼時候停止。

這個骨架的重點不是「每個 prompt 都要寫這麼多標題」。它真正想表達的是：複雜任務的 prompt 應該讓模型知道目的地、邊界和交付物，而不是把每一步都硬編碼進去。

遷移舊 prompt 的實際順序

如果你現在有一套 GPT-4.1、GPT-4o、GPT-5.2 或 GPT-5.4 的舊 prompt，不建議一次性大改。

更穩的遷移順序是：

先切模型，固定目前 reasoning effort 和輸出參數。
跑已有 eval 或真實樣例，找出行為變化。
刪除明顯過時、重複、互相衝突的過程規則。
把「步驟要求」改成「成功標準」和「停止條件」。
補上檢索預算、引用規則和缺證據行為。
為工具任務加驗證循環。
最後再調 reasoning.effort 和 text.verbosity。

如果沒有 eval，至少準備一組典型任務：簡單問答、複雜檢索、工具呼叫、格式化輸出、拒答/降級、長任務完成。不要只用一個 demo case 判斷 prompt 好壞。

一張舊 prompt 遷移清單

真正遷移舊 prompt 時，可以先按這張清單過一遍。它的目標不是把 prompt 改得更短，而是把無效約束刪掉，把關鍵約束改成更可驗證的形式。

檢查項	常見問題	建議處理
重複規則	同一件事在不同段落反覆出現，甚至措辭不一致	合併成一條清晰規則，只保留最終版本
絕對詞	到處都是 `ALWAYS`、`NEVER`、`must`、`only`	只給安全、合規、權限、必填欄位保留絕對約束
無停止條件	要求模型持續搜尋、持續分析、持續修復，但沒寫什麼時候停	增加 stop rules，例如證據足夠、驗證通過、達到輪次或成本上限
無驗證命令	只寫「確保正確」，沒有測試、lint、引用或檢查方式	改成具體檢查：執行測試、類型檢查、建置、引用來源或 smoke test
過程太細	把每一步都寫死，模型只能照流程走	改成目標、成功標準、邊界和輸出要求
舊模型補丁	為舊模型弱點寫的限制仍然保留	先刪除，再用 eval 判斷是否真的還需要
工具規則模糊	只寫「必要時使用工具」	寫清楚何時呼叫、何時停止、失敗時怎麼降級
輸出格式漂移	有格式要求，但沒有欄位完整性要求	明確必填欄位、可選欄位、缺證據時的占位或說明

如果你只能做一件事，優先檢查「無停止條件」和「無驗證命令」。這兩項最容易讓 GPT-5.5 在長任務裡變成無限工具循環，或者在沒有證據時給出看似完整但不可驗證的答案。

GPT-5.5 prompt 示例對比

下面這幾組不是完整系統 prompt，而是遷移時常見的局部改寫方式。

例子 1：檢索問答

舊寫法：

1

回答前必須搜尋至少 3 次。必須閱讀所有相關結果。必須給出完整解釋。

新寫法：

1

先做一次覆蓋核心問題的檢索。若前幾個結果已經能支援關鍵事實，停止檢索並回答。若結果衝突或缺少關鍵事實，再追加檢索。最終回答說明依據；證據不足時明確說證據不足。

區別在於，新寫法把「搜尋次數」改成了「證據是否足夠」。它給模型繼續查的理由，也給模型停下來的理由。

例子 2：程式碼修改

舊寫法：

1

仔細修改程式碼。不要破壞現有邏輯。完成後告訴我改了什麼。

新寫法：

1
2
3
4
5


完成使用者要求的最小必要程式碼修改。成功標準：
- 只修改與任務相關的檔案
- 保持現有公開接口相容，除非使用者明確要求變更
- 修改後執行相關單元測試；如果無法執行，說明原因和下一個最好驗證方式
- 最終總結改動、驗證結果和剩餘風險

區別在於，新寫法沒有泛泛要求「仔細」，而是把謹慎落到檔案範圍、接口相容、測試命令和風險說明上。

例子 3：結構化輸出

舊寫法：

1

請輸出 JSON。不要輸出多餘內容。欄位要完整。

新寫法：

1
2
3
4
5
6


輸出嚴格 JSON，不要添加 Markdown。必須包含：
- status: "ok" | "needs_more_info" | "blocked"
- answer: string
- evidence: string[]
- missing_info: string[]
如果證據不足，status 使用 "needs_more_info"，不要編造 evidence。

區別在於，新寫法不僅要求 JSON，還定義了缺證據時的合法輸出路徑。這樣模型不用在「必須完整」和「證據不足」之間硬編。

參數怎麼配

reasoning.effort 和 text.verbosity 不應該孤立看。前者影響模型投入多少推理，後者影響輸出有多詳細。一個常見誤區是：品質不夠就先把 reasoning.effort 拉高，輸出太長就把 prompt 寫得更凶。更穩的做法是按任務類型配。

場景	reasoning.effort	text.verbosity	說明
欄位抽取、分類、短格式轉換	`none` 或 `low`	`low`	追求低延遲，重點是輸出 schema 清楚
客服分流、簡單工具路由	`low`	`low` 或 `medium`	規則明確時不需要高推理，保留必要解釋即可
普通問答、輕量檢索總結	`low` 或 `medium`	`medium`	需要一點判斷，但不必預設高推理
多文件綜合、衝突判斷	`medium`	`medium`	先保證證據規則和引用，再考慮提高 effort
複雜程式碼修改、長任務 Agent	`medium` 或 `high`	使用者回覆 `low`，程式碼輸出要求清晰	聊天更新可以短，程式碼和 diff 要可讀
策略、方案、風險分析	`medium` 或 `high`	`medium` 或 `high`	需要解釋取捨、風險和假設

對大多數應用來說，可以先從 low 或 medium 開始。只有當 prompt 已經寫清楚成功標準、停止條件和驗證規則，模型仍然遺漏關鍵約束時，再提高 reasoning.effort。

text.verbosity 也不是越低越好。低 verbosity 適合狀態更新、客服短答、操作結果摘要；但對於程式碼、配置、遷移方案、審計說明，過低的輸出會讓結果難以審查。

哪些規則適合保留

遷移到 GPT-5.5 不是把舊 prompt 全部刪掉。下面這些規則通常應該保留，而且要寫得更明確。

安全規則：不能執行的動作、不能生成的內容、需要拒絕或降級的場景。
合規規則：行業政策、地區限制、年齡限制、審計要求、審批要求。
隱私規則：個人資訊處理、敏感資料脫敏、日誌記錄限制、資料不得外傳。
輸出欄位：API 回應、JSON schema、表格欄位、前端元件需要的固定結構。
業務邊界：退款規則、帳號權限、服務等級、合約範圍、人工客服升級條件。
工具權限邊界：哪些工具能呼叫、哪些工具必須先確認、哪些工具禁止呼叫。
引用和證據規則：什麼時候必須引用來源，證據衝突時怎麼處理。

這些規則不是舊包袱，而是產品契約。區別只在於，遷移時要把它們從長篇口號改成可執行約束。

例如：

1

不要洩露使用者隱私。

可以改成：

1

不要在最終回答中輸出完整手機號、身分證號、access token、API key 或內部使用者 ID。需要引用時只顯示脫敏版本，例如手機號保留後 4 位。

哪些內容不要誤刪

刪 prompt 時最危險的不是刪掉廢話，而是把真正的系統邊界一起刪掉。下面這些內容即使看起來「很老」，也不應該輕易刪除。

隱私與資料處理要求：尤其是日誌、匯出、跨系統傳輸、第三方工具呼叫相關規則。
安全和權限限制：刪除資料、轉帳、發郵件、改權限、執行 shell 命令等高風險動作的確認規則。
引用格式：如果產品依賴 citation、腳註、來源列表或審計鏈路，不要只因為它占空間就刪掉。
工具呼叫邊界：哪些工具唯讀、哪些工具可寫、哪些工具必須使用者確認。
失敗行為：API 超時、資料缺失、檢索失敗、權限不足時應該怎麼降級。
業務硬規則：價格、退款、封禁、風控、合規審核這類不能由模型自由發揮的規則。

一個簡單判斷方法是：如果刪掉某條規則只會讓輸出風格變一點，可以考慮刪；如果刪掉後可能導致越權、洩露、誤操作、錯誤承諾或審計斷鏈，就應該保留，並改寫得更精確。

總結

GPT-5.5 prompting guide 的核心不是「寫更高級的提示詞」，而是把舊 prompt 裡過度指定過程的部分刪掉。

更適合 GPT-5.5 的提示詞應該做到：

目標優先，而不是步驟優先。
成功標準明確，而不是泛泛要求「做好」。
有停止條件，而不是無限搜尋或無限工具循環。
有證據預算，而不是查不到就亂答或一直查。
有驗證規則，而不是只靠模型自覺。
參數調優靠後，而不是一上來拉高 reasoning effort。

如果你的舊系統 prompt 已經很長，遷移到 GPT-5.5 的第一步可能不是加內容，而是刪內容。把真正不可違反的規則留下，把過程細節改成結果、邊界和檢查項，通常比繼續堆提示詞更有效。

參考資料

OpenAI Prompt guidance：https://developers.openai.com/api/docs/guides/prompt-guidance
OpenAI Using GPT-5.5：https://developers.openai.com/api/docs/guides/latest-model