O que mudou (e o que não mudou)
Em 2023, "prompt engineering" virou meme. Em 2024, foi declarado morto. Em 2026, com modelos mais capazes mas também mais caros e com janelas de contexto absurdas, a disciplina nunca foi tão importante — só que mudou de forma. Não é mais sobre achar a frase mágica que destrava o modelo. É sobre estruturar contexto de forma que o modelo entregue resposta consistente, auditável e barata.
Este artigo destila as técnicas que ainda funcionam em 2026, baseadas no que a Anthropic, OpenAI e Google publicam em suas docs oficiais e no que aparece em código de produção real.
Princípio 1: Seja específico, não educado
Modelos não precisam de "por favor" e "obrigado". Precisam de instruções claras sobre formato, escopo e critérios de sucesso.
Ruim:
Me ajude a escrever um email para um cliente.
Bom:
Escreva um email em português formal para um cliente B2B brasileiro
informando que a fatura #1234 está atrasada há 5 dias. Tom: cordial
mas firme. Máximo 120 palavras. Inclua um CTA claro para pagamento.
A diferença não é polidez — é o número de decisões que o modelo precisa tomar sozinho. Quanto mais decisões implícitas, mais variabilidade na saída.
Princípio 2: Use estrutura XML
A Anthropic recomenda XML para delimitar seções porque o tokenizer do Claude trata tags com atenção especial. OpenAI e Gemini também lidam bem com isso.
<context>
A empresa vende software B2B para escritórios de advocacia.
</context>
<task>
Gerar 3 títulos de blog post sobre LGPD.
</task>
<rules>
- Cada título tem no máximo 60 caracteres
- Não use clickbait
- Foque no benefício prático
</rules>
<output_format>
JSON com array "titulos"
</output_format>
Por que funciona: os marcadores eliminam ambiguidade entre instruções e dados, e dão ao modelo "ganchos" cognitivos pra organizar o raciocínio.
Princípio 3: Few-shot > zero-shot
Sempre que a tarefa tem um padrão, mostre 2-5 exemplos antes do input real. A precisão sobe drasticamente.
Classifique o sentimento como POSITIVO, NEGATIVO ou NEUTRO.
Texto: "Adorei o produto, chegou rápido."
Sentimento: POSITIVO
Texto: "Atendimento ok, nada demais."
Sentimento: NEUTRO
Texto: "Quebrou no segundo dia. Lixo."
Sentimento: NEGATIVO
Texto: "{input_real}"
Sentimento:
Regra: cubra os edge cases nos exemplos. Se você só mostra positivos e negativos, o modelo vai forçar um deles em casos neutros.
Princípio 4: Chain-of-thought controlado
"Pense passo a passo" virou clichê, mas funciona — desde que você direcione o pensamento. Modelos como Claude têm um modo thinking nativo onde o raciocínio é separado da resposta final.
Antes de responder, em <scratchpad>:
1. Liste as informações relevantes do contexto
2. Identifique o que está sendo perguntado
3. Verifique se há contradições
4. Formule a resposta
Depois, em <answer>, dê apenas a resposta final em 2 frases.
Você ganha duas coisas: respostas mais corretas (porque o modelo "rascunha") e saída limpa (porque você só renderiza a tag <answer> no produto).
Princípio 5: Role priming com substância
"Você é um especialista em X" sozinho não faz nada. O que funciona é descrever o tipo de raciocínio que você quer.
Vazio:
Você é um especialista em segurança.
Útil:
Você é um auditor de segurança no estilo OWASP. Quando recebe código,
primeiro identifica vetores de ataque (injection, XSS, deserialização),
depois propõe a correção mais simples possível. Não generaliza — cita
linha e função específicas.
A diferença é entre "atue como" e "raciocine como".
Princípio 6: Use saídas estruturadas
Se você precisa de JSON, peça JSON com schema. Modelos modernos suportam structured output nativo (Claude tem tool_use, OpenAI tem response_format, Gemini tem responseSchema). Sair de "parse manual de markdown" para "JSON validado" reduz bugs em 90%.
tools = [{
"name": "salvar_classificacao",
"input_schema": {
"type": "object",
"properties": {
"categoria": {"type": "string", "enum": ["A", "B", "C"]},
"confianca": {"type": "number", "minimum": 0, "maximum": 1},
"justificativa": {"type": "string", "maxLength": 200},
},
"required": ["categoria", "confianca", "justificativa"],
},
}]
Você "engana" o modelo a sempre devolver no formato certo, porque ele acha que está chamando uma função.
Princípio 7: Teste como código
O maior erro de quem começa em prompt engineering é tratar prompt como texto descartável. Trate como código: versionado, com testes de regressão, com métricas.
- Salve prompts em arquivos versionados (não hardcoded em strings).
- Tenha um dataset de 20-50 casos representativos.
- Para cada mudança, rode o dataset e compare resultados.
- Use ferramentas como
promptfooou implemente um avaliador simples.
Sem isso, toda otimização é "achômetro".
O que NÃO fazer mais
- Não use jailbreaks "criativos" — modelos modernos são treinados contra eles e você só perde tempo.
- Não chame o modelo 5 vezes pra refinar quando uma chamada bem estruturada resolve.
- Não confie em "temperature: 0" como sinônimo de determinismo — ainda há variabilidade entre runs.
- Não despeje 200k tokens quando 10k bem selecionados funcionam melhor.
Conclusão
Em 2026, prompt engineering virou disciplina de engenharia, não arte. Quem trata como código, mede resultados e itera com método extrai o máximo dos modelos pelo menor custo. Quem ainda procura "o prompt mágico" gasta 10x mais e entrega menos.
