O esqueleto de um bom pedido

As quatro partes, na ordem

A OpenAI documenta um esqueleto para uma boa mensagem, e ele é a coisa mais útil deste curso inteiro. São quatro partes, em ordem. A primeira é a Identidade: descreva o propósito, o estilo de comunicação e o objetivo geral do assistente. A segunda são as Instruções: as regras que ele deve seguir, o que deve fazer e o que nunca deve fazer. A terceira são os Exemplos: entradas possíveis junto com a saída desejada. A quarta é o Contexto: a informação adicional de que ele precisa. Quatro partes, quatro perguntas, e o pedido morno morre.

Uma ressalva importante antes de seguir. Esse esqueleto vem do guia da OpenAI voltado para quem programa, onde cada parte tem um lugar técnico específico. No ChatGPT que você usa no navegador não existe nada disso: você digita tudo na mesma caixa. E funciona igual. A Identidade e as Instruções podem ir direto na mensagem, ou ficar fixas nas instruções personalizadas das configurações, nas instruções de um projeto ou de um GPT, que é onde elas passam a valer para toda conversa sem você repetir. Os Exemplos e o Contexto quase sempre vão na própria mensagem.

Vale entender o que cada parte resolve, porque elas não são decoração. A Identidade responde quem está escrevendo e com que voz, e é o que mata o tom genérico. As Instruções respondem quais são as regras do jogo, e reparem que a formulação oficial pergunta explicitamente o que o modelo nunca deve fazer, ou seja, proibição faz parte da estrutura e não é um extra. Os Exemplos respondem qual é o formato certo, mostrando em vez de descrever. E o Contexto responde com qual material, que é o que impede o modelo de inventar dado que ele não tem.

O detalhe que quase todo mundo erra: o contexto vai no fim

Agora o achado que quase nenhum material em português menciona. Ao descrever a parte de Contexto, o guia oficial diz que esse conteúdo geralmente fica melhor posicionado perto do fim do seu prompt. Perto do fim. Leia de novo, porque a maioria das pessoas faz exatamente o contrário: cola o contrato de oito páginas primeiro e, lá embaixo, depois de todo o material, escreve resume isso pra mim. O pedido fica soterrado. As instruções viram um sussurro no rodapé de um documento gigante, disputando atenção com tudo que veio antes.

A ordem certa é o oposto: você diz quem ele é, dá as regras, mostra o formato com exemplos e só então despeja o material. Assim, quando o modelo chega no contrato, ele já sabe o que fazer com aquilo. É a mesma lógica de dar uma tarefa para uma pessoa: você explica o que quer e depois entrega a pasta de documentos. Ninguém entrega a pasta primeiro, deixa o colega ler tudo sem saber para quê e só no fim diz o que era para fazer. Parece detalhe bobo. Na prática, é uma das mudanças de maior efeito neste módulo.

PEDIDO RUIM (material primeiro, instrução soterrada no fim)
[oito páginas de contrato de aluguel coladas aqui]
resume isso pra mim

PEDIDO BOM (as quatro partes, com o contexto no fim)

# Identidade
Você é um assistente que explica contratos para quem não é da área jurídica, em português simples e direto, sem juridiquês.

# Instruções
- Resuma o contrato em no máximo 6 pontos.
- Destaque obrigatoriamente: valor do aluguel, prazo, índice de reajuste, multa por rescisão e quem paga o IPTU.
- Use SOMENTE o que está escrito no contrato abaixo.
- Se alguma dessas informações não estiver no texto, escreva NÃO CONSTA. Nunca preencha por conta própria.
- Não dê conselho jurídico e não diga se o contrato é bom ou ruim.

# Exemplos do formato de cada ponto
Prazo: 30 meses, com início em 01/08/2026. (cláusula 3)
IPTU: NÃO CONSTA.

# Contexto
Contrato a analisar:
[cole aqui as oito páginas do contrato]

As quatro partes montadas em um caso real. Repare que o contrato, que é o texto mais longo, é a última coisa do pedido.

Exemplos: mostrar vale mais que descrever

A parte dos Exemplos merece um parágrafo só dela, porque é a mais subutilizada das quatro. O nome técnico é few-shot, e a ideia oficial é simples: incluir um punhado de exemplos de entrada e saída no prompt faz o modelo captar o padrão implicitamente e aplicá-lo. Em português direto: em vez de gastar cinco linhas descrevendo como você quer o formato, escreva um exemplo pronto do jeito que você quer. Ele copia o padrão. Descrever formato é difícil e ambíguo. Mostrar formato é uma linha e não deixa dúvida.

Tem uma orientação oficial sobre quantos e quais exemplos usar, e ela é contraintuitiva. O guia recomenda mostrar uma variedade de entradas possíveis com as saídas desejadas. Variedade, não volume. Dez exemplos de clientes elogiando o produto ensinam o modelo a responder um tipo só de mensagem. Três exemplos diferentes, um elogio, uma reclamação e uma dúvida sobre prazo, ensinam o padrão de verdade, que é o seu jeito de responder qualquer coisa. Se você só vai usar dois ou três exemplos, faça eles serem o mais diferentes possível entre si.

Agora um aviso que muda como você usa tudo isso, e que quase nenhum material em português acompanhou. Durante anos a orientação da OpenAI foi ser específico, descritivo e o mais detalhado possível. A orientação atual, publicada para os modelos mais recentes, virou outra: favoreça prompts mais enxutos. O texto oficial diz que remover instruções e exemplos repetidos e simplificar descrições melhora o desempenho na tarefa e a eficiência de tokens. Em avaliações internas com agentes de código, prompts mais enxutos melhoraram a pontuação em torno de 10 a 15 por cento e reduziram os tokens entre 41 e 66 por cento. A própria OpenAI pede para tratar esses números como direcionais e validar no seu caso.

Isso não derruba o esqueleto, e entender por que é o que separa quem seguiu a moda de quem entendeu a coisa. Específico e prolixo não são a mesma coisa. Use um parágrafo de 3 a 5 frases é específico e curto ao mesmo tempo. Escrever a mesma regra três vezes com palavras diferentes é prolixo e, pela orientação atual, piora o resultado. A regra oficial é de uma linha: declare cada instrução uma vez. Aquela mania de reforçar, do tipo não invente nada e, mais embaixo, lembre-se de não inventar nada, sai do pedido. Tem até uma armadilha documentada: mandar ser conciso pode atrapalhar, porque os modelos atuais já são concisos por padrão e a ordem genérica de brevidade às vezes deixa a resposta curta demais.

Não confunda esqueleto com burocracia. Você não precisa escrever as quatro partes com título e tudo para pedir uma receita com o que tem na geladeira. O esqueleto é uma lista de checagem mental, e ele rende mais quanto mais a tarefa importa. Um pedido rápido pode ter só Instruções. Um e-mail delicado pede Identidade e Instruções. Uma tarefa que você vai repetir toda semana merece as quatro partes bem escritas, e aí vale guardar em um projeto ou num GPT, para não redigitar sempre. Quanto maior a consequência, mais partes valem o seu tempo.