摘要： GPT-5.6 官方 prompt 指引的前提是模型可從 context 推斷目標與投入程度，因此應先寫目標、脈絡、限制與驗收標準，而不是逐步指令。文章引用 OpenAI 內部 coding-agent eval，稱精簡 system prompt 後分數升約 10–15%，token 用量和成本分別減少 41–66% 與 33–67%，並強調這些數字未經獨立驗證。做法上應保留規格與硬限制，每輪只移除一組指令、示例或工具後重跑同一批 evals。
「寫得少，成果反而更好」放到 GPT-5.6 之後的 prompt 設計上，已經不是口號，而是實際運作的機制。模型對意圖的掌握變得更深，會自己從 context 判斷你要什麼、該投入多少力氣；在這個前提下，逐步下指令反而成了一種限制——你指定了某一條路，模型原本可以自己挑更短的那條走。OpenAI 官方那份 prompting guidance 的所有建議都立足於此，這篇文章把它轉成能直接套用的整理版。
指示變少，效果為何不降反升
帶方向性的證據來自 OpenAI 自家的 coding-agent eval——這是廠商內部數據，並沒有獨立驗證背書：把 system prompt 改精簡之後，分數上升約 10–15%，token 用量減少 41–66%，成本減少 33–67%。這些百分比未必原樣出現在你的產品上，但機制說得通：同一條規則換三種措辭講三遍、與任務無關的工具描述、不影響輸出的示例，全都在吃掉模型的注意力額度。
不過「少寫」砍的對象不包括規格。domain context、hard constraints、approval boundaries、success criteria 這四項要完整保住；該拿掉的是步驟與重複，驗收標準一項都不能省。
從目標與驗收寫起
Outcome-first 的寫法依序排上：goal、必要的 context、constraints、required evidence、success criteria、output format。只有當順序本身就是業務或安全規定時，執行次序才需要固定。真正要緊的歧義若只剩少數幾處，仍該要求模型回頭提出釐清，不容許它自行猜測。這份骨架同時也是 Pro mode 的正確用法——不必加註「用 pro mode」或「想久一點」，目標與驗收寫得夠清楚，模型自然會分配推理深度。
刪減要一組一組來
想安全地精簡，別從零重寫，而是以一份本來就能運作的 prompt 為起點，每輪只抽掉一組指令、示例或工具，接著重跑同一批 evals。同一條指示講一次就夠；示例只保留能補住實測缺口的那些；工具只開放任務用得到的。語氣的調整理路相同：與其掛上 friendly、empathetic 這類模糊標籤，不如具體描述寫作選擇——答案該多麼直白、什麼時候要坦承辦不到、結尾需不需要 reassurance。
三層劃出授權界線
要讓模型自主工作，前提是把授權講明白，而三個層級就足以覆蓋：
讀取類（回答、解釋、review、diagnose、plan）：查閱相關材料並回覆，不動手做任何變更。
變更類（change、build、fix）：在指派範圍內完成本機修改，並執行非破壞性的驗證。
確認類（外部寫入、刪除覆寫、購買、擴大範圍）：動作前必須先拿到批准。把「讀檔、看 log、修改指定範圍的程式碼、跑測試」明文列成可直接執行的動作，比在 prompt 各處反覆寫 ask first 更穩——審批要求重複出現，反而害模型連正常的讀檔也停下來等確認。授權政策集中寫在一個地方，相互矛盾的規則自然無從出現。
工具怎麼路由、何時收手
Tool routing 屬於任務層級的設定，有四項值得寫明白：哪些階段有明確邊界、輸出 schema、並行與 retry 的上限，以及兩條路徑並存時唯一一次的 handoff 規則。每份 tool description 起碼要交代這個工具做什麼、關鍵的回傳欄位、型別，以及出錯時的行為。停止條件用具體句式最見效：「Stop when [condition]」「Retry transient failures at most [R] times」。另外補充一點：當 program_output 與最終訊息分開輸出時，兩邊都要納入測試；任何想省資源的設計，照樣以通過既有 evals 為前提。
什麼時候改用 PTC
Programmatic Tool Calling（PTC）的運作方式，是讓模型自己寫 JavaScript、在 hosted runtime 中呼叫工具並加工中間輸出；有界而且以工具為主角的階段最能發揮——filtering、joining、ranking、dedup、aggregation、validation 這種把大批結果壓縮成小結構的活。它與 ZDR 相容，也不會多出額外的 container 成本。留意一點：「呼叫次數很多」本身不構成採用理由——真正的判準在於中間結果能不能被程式化地收斂。反過來，一次直接呼叫就夠用、下一步要靠語義判斷、需要審批，或 citations 必須保留的情境，交給 direct tool call 通常更合適。
詳略、語氣與 Pro mode 的控制
跟 GPT-5.5 相比，GPT-5.6 的回應天生更精簡，遷移時該回頭檢查「Be concise」這類全面性要求是否已屬多餘；需要穩定掌控詳略，就改用 text.verbosity 的 low、medium、high。短答案的結構：結論打頭，接著必要證據、material caveat、next action；修剪的順序則是 introductions、repetition、generic reassurance、optional background。Pro mode 不必另找獨立的 Pro slug，在同一個模型上以 reasoning.mode: "pro" 開啟即可；mode 與 effort 彼此獨立，兩者省略時一律落在 medium，代價是 latency 變長與額外 tokens（計入 usage 標準費率）。
升級路徑與新功能盤點
升級第一步，把現行的 reasoning effort 原樣留著當 baseline，拿具代表性的任務分別測同一級與低一級，再下決定：none/low/medium/high/xhigh/max 六級裡，medium 是兼顧各方的起點，low 給 latency 敏感的情境，max 留給最難啃、以品質為先的工作。命名方面，gpt-5.6 會 alias 到旗艦 gpt-5.6-sol；gpt-5.6-terra 以較低價格提供高效能；gpt-5.6-luna 則面向高流量。Responses API 的 multi-agent（beta）能在單一 instance 裡並行調度多個 subagents 再彙整結果，讓 wall-clock time 變短。Explicit prompt caching 把 reusable prefixes 的 cache write 定為未快取輸入費率的 1.25 倍，read 享有另外的折扣，留存改由 prompt_cache_options.ttl 取代舊參數來管理。Persisted reasoning 自 GPT-5.6 起預設 all_turns，搭配 previous_response_id 使用；關閉儲存或處於 ZDR 模式時，改為重送 encrypted reasoning items。安全機制這塊，cyber 與 biology 的即時分類器可能攔下請求，或在中途審查時暫停數秒，dual-use 的請求偶爾會被誤傷；個人端應用建議附上 safety_identifier，讓防護有穩定的錨點。