GPT-5.5

GPT-5.5 提示工程指南：從「技巧堆疊」轉向「規格設計」

探討 GPT-5.5 時代提示工程的典範轉移，從下意識的技巧堆疊轉向精準的規格定義，建立可驗證、可維護、可擴充的 AI 互動規格。

GPT-5.5 prompting guide 的核心訊息，不是「prompt 不重要了」，而是「prompt 的角色改了」。在 GPT-4／4o 乃至 GPT-4.1 時代，很多團隊習慣用長 prompt 把規劃、格式、工具路由、語氣、引用與停損規則全部寫死；在 GPT-5.5 時代，官方更鼓勵你把高層契約寫清楚，把格式交給 Structured Outputs，把工具知識放進 descriptions，把長狀態交給 Responses API 與 compaction，把品質控制交給 evals。真正好的 GPT-5.5 提示，不是比較長，而是比較像一份可驗證、可維護、可擴充的產品規格。

GPT-5.5 時代的典範轉移：Prompt 角色已變

GPT-5.5 prompting guide 的真正訊息，不是「prompt 不重要了」，而是「prompt 的角色改了」。在 GPT-4／4o 乃至 GPT-4.1 時代，很多團隊習慣用長 prompt 把規劃、格式、工具路由、語氣、引用與停損規則全部寫死；在 GPT-5.5 時代，官方更鼓勵你把高層契約寫清楚，把格式交給 Structured Outputs，把工具知識放進 descriptions，把長狀態交給 Responses API 與 compaction，把品質控制交給 evals。真正好的 GPT-5.5 提示，不是比較長，而是比較像一份可驗證、可維護、可擴充的產品規格。

核心策略：最小可行 Prompt 與 Eval 驅動

這張表最值得記住的一點是：GPT-5.5 並沒有淘汰 CoT、few-shot、fine-tuning 或安全護欄；它淘汰的是「下意識地先把所有技巧都加上去」。正確順序應是：先用最小 prompt 達成 baseline，再用 eval 確認你缺的是 planning、retrieval、formatting 還是 long-run stability，最後再選最小的新增機制。

技巧重構：CoT 與 Tool Use 的正確用法

技巧	在 GPT-5.5 時代的正確用法	何時值得用	風險與注意事項	依據
Chain-of-Thought	把 CoT 視為「必要時才顯式化的分解策略」，不是預設。先用簡潔、結果導向 prompt；若 eval 顯示模型常跳步、漏步，再加有限度的 step decomposition 或要求簡短 rationale。若需要可觀察推理，可優先考慮 reasoning summary，而不是要求完整思維外露。	複雜規劃、文件多跳推理、需要可審核的分解步驟	對具內建推理能力的模型，強迫「think step by step」未必有助益，還可能增加成本或妨礙表現；而原始 hidden CoT 也不是公開介面	官方與論文
Tool use	把工具當成 prompt 的延伸，而不是額外附加功能。高層 prompt 負責 operating policy；tool description 負責用途、時機、輸入、副作用、retry safety；多輪時保留 reasoning / function items。	需要最新資料、私有資料、執行外部動作、數學或程式驗證	工具描述太模糊時，模型會錯用或不用；人工裁切 tool/reasoning items 會讓多輪品質下降	官方與論文

精準對齊：Few-shot 與 Instruction Tuning

技巧	在 GPT-5.5 時代的正確用法	何時值得用	風險與注意事項	依據
Few-shot	先 zero-shot，再視需要加入少量、對齊且有代表性的 examples。examples 要短、明確、風格一致，且與正式指令不能矛盾。	術語一致、輸出格式、分類標準、品牌口吻	示例與正式規則不一致時，模型反而更不穩；示例太多也會擠壓上下文與快取效益	官方與論文
Instruction tuning	當問題不是 context 缺乏，而是行為一致性、格式穩定性、域內語氣長期不穩時，再從 prompt 升級到 SFT。官方建議先用 prompt 建 baseline，再從 50+ 個具代表性的 examples 起步。	穩定格式、特定翻譯風格、固定工作流輸出	若你其實缺的是知識，不是行為，一味 fine-tune 只會學到錯誤自信；資料品質比數量更重要	官方與論文

安全與倫理：多層次護欄與人機協作

技巧	在 GPT-5.5 時代的正確用法	何時值得用	風險與注意事項	依據
Safety / Guardrails	把安全分成多層：Model Spec 的 chain of command、moderation、adversarial testing、human in the loop、輸入約束與 token 限制。高風險任務要把「何時拒答、何時升級人工、何時只提供一般資訊」寫清楚。	客服、醫療、金融、法務、青少年或公共風險場景	只靠 prompt 防線不夠；沒有 moderation、紅隊測試與人工覆核，很難抵禦 jailbreak 與高風險誤答	官方

實務應用與倫理安全

若從產品落地的角度看，GPT-5.5 最適合放在「高價值、長脈絡、需要工具與驗證」的工作上，例如研究、程式碼、資料分析、長文件綜合與多步代理。官方模型頁把 GPT-5.5 定位為複雜專業工作用的 frontier model，reasoning 文件則建議大多數 reasoning workload 從 GPT-5.5 起手；相對地，GPT-4o 仍是多數一般任務的高智慧旗艦選項，當你的核心需求更偏向速度、成本與較輕量的任務執行時，4o 或更小模型仍然合理。

場景	建議組合	為何
企業知識問答	GPT-5.5 + file search + citation rules + retrieval budget	明確控制證據邊界，避免多輪亂搜
研究或報告生成	GPT-5.5 + outcome-first prompt + Structured Outputs / citations	結構穩、可核查、可直接進工作流
工程代理	GPT-5.5 + Responses API + function tools + validation commands + compaction	多步任務、工具流與長時間 debug 更穩
客服或營運代理	GPT-5.5 + preamble + stop rules + blockers schema + HITL for high-impact actions	兼顧效率、完成率與風險治理

隱私與狀態：Responses API 的深度管理

在隱私與狀態管理上，官方文件也給了很具體的實務邊界。Responses objects 預設保存 30 天，但可透過 store=false 關閉；API 資料不會在未經明確同意下用於訓練。另一方面，若你在 store=false 或零資料保留流程中仍要跑 reasoning / agentic workflow，就必須保留必要的 reasoning items、assistant items 或 compacted state，否則多輪品質會下降。也就是說，GPT-5.5 的提示工程，已經不只是「寫 prompt」，而是「設計狀態、證據、工具與保留策略」。

結論與行動清單

從最小可行 prompt重新起稿，不要整包搬舊模板；靜態規則放前面、動態上下文放後面，且 GPT-5.5 不必再額外塞當前日期。
每個複雜 prompt 至少要有 Goal、Success criteria、Constraints、Stop rules 四件事。
盡量用 outcome-first 寫法；只有當 eval 證明必要時，才補上顯式流程分解。
把 personality 和 collaboration style 拆開，並且都寫短。
先從 reasoning.effort=low 或 medium 測起，不要本能地直上更高 effort。
需要穩定格式時，用 Structured Outputs / function schema，不要靠 prose 描述 JSON 結構。
對知識型任務加上 citation rules、retrieval budget、缺證時的 fallback，並要求只追問最小缺失資訊。
對程式碼、資料分析、前端或表格任務，要求 test / lint / build / render / formula checks。
長文本與長會話不要硬塞單輪；用 chunking、file search、phase、compaction 管理上下文。
每次改 prompt 都跑 evals；只有當資料顯示問題是 context 或 behavior bottleneck 時，才升級到 RAG 或 fine-tuning。