A OpenAI publica a directiva de prompts do GPT-5.6: apenas dá resultados e linhas vermelhas, deixando o resto para o modelo

A OpenAI publica as Directrizes de Prompting do GPT-5.6; em testes internos, foi descoberto que, ao simplificar um prompt system demasiado extenso, as pontuações não só não diminuem como até aumentam 10% a 15%, e o consumo de tokens ainda é reduzido em 41% a 66%. Em outras palavras, quando se pede ao modelo para “fazer um pouco menos de preparação”, ele acaba por correr mais rápido e responder com mais precisão.

Este é o ponto principal descrito nas Directrizes de Prompting do GPT-5.6 publicadas oficialmente pela OpenAI; abaixo, o autor compila três pontos: por que razão instruções mais curtas são mais eficazes, qual é a nova forma de escrita recomendada pela OpenAI e como os programadores devem, na prática, alterá-las.

Quanto menos instruções, mais preciso o modelo?

A intuição dos engenheiros ao escrever prompts era: “quanto mais detalhado, mais obediente o modelo”, incluindo todos os passos e cada excepção, temendo que o modelo falhasse em alguma coisa. Mas a OpenAI destaca, nas directrizes, que esta intuição falha no GPT-5.6. O grupo de engenharia testou e verificou que um system prompt — em termos simples, um conjunto de instruções de configuração ocultas que o programador coloca no modelo antes de iniciar a conversa com o utilizador — se estiver “cheio” de regras repetidas, avisos de estilo sem impacto real no comportamento, exemplos desnecessários e orientações de processo que o modelo já conseguiria executar, ao removê-los o desempenho do modelo melhora.

A abordagem concreta nas directrizes é “começar pela versão que funciona e ir removendo gradualmente”: manter o prompt actual e ir retirando, por uma parte de cada vez, os trechos suspeitos, enquanto se observa o eval (pontuação de avaliação quantitativa de IA). Em resumo, usa-se um conjunto de tarefas fixas para fazer o modelo correr e medir, com pontuações, se as respostas ficam boas e se não há quedas.

O que deve realmente ser mantido é: os resultados visíveis pelo utilizador, critérios de sucesso e de paragem, limitações de segurança e comerciais, regras de selecção de ferramentas que variam conforme o contexto e o formato de saída exigido. O resto, na maior parte das vezes, é apenas redundância com a qual os engenheiros se sentem confortáveis.

As directrizes também apontam um aspecto frequentemente ignorado: a descrição das ferramentas também faz parte do prompt. Quanto mais ferramentas se der ao modelo e quanto mais vaga for a descrição, maior o custo para o modelo decidir qual ferramenta usar. A OpenAI recomenda dar apenas ferramentas relacionadas com a tarefa e explicar, em cada descrição, o que fazer, quando deve ser usado e como o modelo deve agir quando houver erros. Por outras palavras, a simplificação não é apenas de “instruções”; até “a caixa de ferramentas” deve ser afinada.

Não escrevas passos; escreve “o destino”

A frase mais central nas directrizes é: “definir o resultado, limitações importantes, evidência utilizável e critérios de conclusão; depois, deixar espaço para o modelo escolher, de forma eficiente, o seu próprio caminho.” Em resumo, diz-se ao modelo para onde ir e quais são as linhas vermelhas que não pode ultrapassar, sem especificar como ele deve fazer cada passo.

O exemplo dado pela OpenAI é: “resolver o pedido com o mínimo de ciclos úteis de ferramenta, mas sem deixar que a redução do número de ciclos sacrifique a correcção, as evidências necessárias ou as citações”; é uma regra de decisão do tipo “se X então Y”, e não uma ordem rígida.

Outro detalhe fácil de ignorar é que o GPT-5.6, por defeito, responde de forma mais concisa. Antes, os engenheiros escreviam no prompt “responde de forma breve”; agora, isso pode ser redundante ou até prejudicial. As directrizes recomendam trocar por um parâmetro text.verbosity; ou seja, controlar separadamente quanto tempo a resposta do modelo deve ter, tratando o tom à parte. Divide-se a extensão em três níveis — low, medium e high — controlados por um único parâmetro para o comprimento; já o tom e a formalidade são descritos separadamente como personalidade, e ambos devem ser escritos de forma curta.

Se, de facto, for preciso uma resposta ainda mais curta, as directrizes sugerem que se diga claramente “o que manter” e “o que cortar”, em vez de lançar apenas, de forma vaga, “menos”. Quanto ao esforço de raciocínio do modelo — isto é, reasoning effort, ou quanta “força de pensamento” o modelo deve usar antes de responder — as directrizes dividem-no em cinco níveis: low, medium, high, xhigh e max. Antes de aumentar, a OpenAI recomenda verificar se o prompt já define claramente os critérios de sucesso e o ciclo de verificação; muitas vezes, “explicar bem” é mais eficaz do que “forçar o modelo a pensar mais”.

Da “pilha de instruções” ao “ajuste orientado por medição”

O impacto mais prático para os programadores é o fluxo de migração de prompt incluído nas directrizes.

A OpenAI é muito directa: ao mudar de modelo, não reescrevas de uma só vez todo o prompt. O motivo é que, se ao mesmo tempo se alterarem o modelo, as definições de inferência, o prompt e o conjunto de ferramentas, depois já não se consegue distinguir que variação causou que alteração no comportamento. A ordem correcta é: primeiro trocar o modelo, mantendo as definições de intensidade de raciocínio originais; correr uma eval representativa como linha de base; depois remover andaimes obsoletos e instruções repetidas, fazendo apenas a correcção mínima para os pontos em que a eval mostre, de facto, uma regressão; e então medir novamente e, sempre que se alterar um factor, medir de novo — sem mexer em várias coisas ao mesmo tempo.

As directrizes também exigem que os programadores definam claramente “quanto o modelo pode decidir por conta própria”, em vez de ficar tudo muito vago. A política de exemplo da OpenAI é: para pedidos como responder, explicar e rever, o modelo só pode verificar e reportar — não pode mexer; para pedidos que envolvam alterações ou correcções, o modelo pode, dentro do âmbito, fazer alterações locais e executar validações não destrutivas; para pedidos que envolvam, de facto, escrita para fora, acções destrutivas ou ampliar o âmbito da tarefa, é obrigatório parar e pedir confirmação antes.

Quanto mais instruções se escrevem, foi durante muito tempo o método que dava tranquilidade aos engenheiros. Agora, parece que isso pode acabar por atrasar o modelo e também pressionar as contas. Quanto mais inteligente o modelo fica, mais os humanos têm de aprender a falar menos, e deixar o esforço para a medição e a validação.

OpenAI 公布 GPT-5.6 提示詞指南，內部測試發現，把冗長的 system prompt 精簡之後，分數不降反升 10% 到 15%，token 用量還省下 41% 到 66%。指南建議開發者只給模型結果、限制與停止標準，不用規定每一步該怎麼走。
（前情提要：GPT-5.6 秘密測試瘋傳：ChatGPT 突變聰明、用戶測試碾壓 Fable 5）
（背景補充：Harness Engineering（AI駕馭工程）入門篇：OpenAI最新程式設計標準，教你輕鬆做到Lv.1）

本文目錄

Toggle

• 指令越少，模型越準？
• 別再寫步驟，寫「終點」就好
• 從「堆指令」到「量測式調整」

OpenAI 內部測試顯示，把一份原本落落長的 system prompt 大幅精簡之後，分數不但沒有掉，反而上升 10% 到 15%，同時 token 用量還省下 41% 到 66%。換句話說，叫模型「少做一點準備動作」，它反而跑得更快、答得更準。

這是 OpenAI 官方發布的 GPT-5.6 提示詞指南裡說明的重點，下文筆者整理三個重點：為什麼精簡指令反而更有效、OpenAI 建議的新寫法是什麼、以及開發者實際上要怎麼改。

指令越少，模型越準？

過去工程師寫 prompt 的直覺是「講越細，模型越聽話」，把每一個步驟、每個例外狀況都寫進去，深怕模型漏做什麼。但 OpenAI 在指南裡點名，這套直覺在 GPT-5.6 身上失靈了。工程團隊實測發現，一份 system prompt，簡單來說就是，開發者在用戶對話開始前，先塞給模型的一段隱藏設定指令，如果塞滿重複規則、對行為沒有實質影響的風格叮嚀、多餘範例，以及模型本來就做得到的流程指導，拿掉之後模型的表現反而更好。

指南給的具體做法，是「從能跑的版本開始逐步刪」：先留著目前有效的 prompt，一段一段拔掉可疑的部分，同時盯著 eval（AI 量化評估分數），簡單來說就是，拿一組固定任務讓模型跑，用分數衡量它答得好不好，有沒有掉。

真正該留下來的，是用戶看得到的結果、成功與停止的判斷標準、安全與商業上的限制、依情境變化的工具選用規則，以及要求的輸出格式。其餘的，大多是工程師自己心安用的贅字。

指南同時點出一個常被忽略的環節：工具描述本身也是 prompt 的一部分。給模型的工具越多、描述越含糊，模型判斷該用哪個工具的成本就越高。OpenAI 建議只給任務相關的工具，每個工具描述都要交代做什麼、何時該用、出錯時怎麼表現。換句話說，精簡的物件不只是「指令」，連「工具箱」本身都該一起瘦身。

別再寫步驟，寫「終點」就好

指南裡最核心的一句話是：「定義結果、重要限制、可用證據、完成標準，然後留空間讓模型自己選有效率的路徑。」簡單來說就是，只告訴模型要去哪裡、有哪些不能碰的紅線，不用規定它每一步該怎麼走。

OpenAI 舉的範例是「用最少的有用工具迴圈解決請求，但不能讓減少迴圈次數犧牲正確性、必要證據或引用」，這是一條「若 X 則 Y」的決策規則，而不是一條死命令。

另一個容易被忽略的細節，是 GPT-5.6 預設回答就比較精簡。以前工程師寫在 prompt 裡的「請簡短回答」這類叮嚀，現在可能是多餘甚至有害的。指南建議改用引數 text.verbosity，簡單來說就是，單獨用一個引數控制模型回答要多長，跟語氣分開處理，分成 low、medium、high 三檔專門管長度，語氣與正式度則另外描述個性，兩者都寫短。

如果真的需要更短的答案，指南建議明講「留什麼、砍什麼」，而不是籠統丟一句「短一點」。至於模型要花多少力氣思考，也就是 reasoning effort，簡單來說就是，設定模型回答前要花多少『思考力氣』，指南把它分成 low、medium、high、xhigh、max 五級。調高之前，OpenAI 建議先檢查 prompt 本身有沒有寫清楚成功標準與驗證迴圈，很多時候「把話講清楚」比「加碼讓模型多想」更有效。

從「堆指令」到「量測式調整」

對開發者最實際的影響，是指南附的一套 prompt 遷移工作流。

OpenAI 講得很直白：換模型時不要一次重寫整套 prompt，原因是如果同時改模型、推理設定、prompt、工具集，之後根本分不出行為變化是哪一項造成的。正確順序是先換模型、保留原本的推理強度設定，跑一次代表性的 eval 當基準，再拿掉過時的鷹架與重複指令，只針對「eval 顯示真的退步」的地方做最小幅度的修正，然後重新測一次，每改一個變因，就重新量測一次，絕不同時亂動。

指南也要求開發者把「模型能自己做多少決定」寫清楚，而不是模糊帶過。OpenAI 給的範例政策是：回答、解釋、檢視這類請求，模型只能檢查與回報、不能動手改；涉及變更或修復的請求，可以在範圍內自行做本地變更並跑非破壞性的驗證；真正牽涉對外寫入、破壞性動作或擴大任務範圍的，一律要先停下來詢問。

指令越寫越多，曾經是工程師求心安的方式。現在看來，這可能會拖慢模型、也在拖累帳單。模型越聰明，人反而該學會少說話，把力氣留給量測與驗證。