Quarta-feira, 21h. O time financeiro me passa um prompt de 800 palavras que "estava bom semana passada" e agora devolve número errado para 3 em cada 10 notas fiscais. Eu abro o prompt, leio em voz alta, e identifico o problema em quatro minutos: alguém adicionou um exemplo no meio dos exemplos antigos, e o exemplo novo contradiz uma regra que estava em outra parte do texto. O modelo, coitado, está tentando agradar os dois lados.
Esse é o tipo de bug que engenharia de prompts resolve. Não é arte, não é "sussurrar para a IA" — é um conjunto de padrões repetíveis com nomes, contextos de uso e modos de falhar. Em 2026, quem trata prompts como código (com versionamento, testes e revisão) entrega resultado consistente. Quem ainda cola prompt em chat e reza está pagando o custo em retrabalho silencioso.
Por que isso importa para você
Se você usa LLM no trabalho, sua produtividade real depende menos do modelo (Opus, GPT-5, Gemini 2.5) e mais de como você fala com ele. A documentação oficial da Anthropic é explícita: a maior parte dos ganhos em qualidade vem de mudanças no prompt, não de troca de modelo. Andrej Karpathy chamou prompts de "a nova interface de programação", e Simon Willison vem documentando há dois anos como pequenos ajustes mudam o output.
Os 12 padrões abaixo são o que sobrou depois de descartar dezenas de outros que não passaram no nosso teste de produção: usar de novo daqui a 3 meses sem precisar relembrar contexto. Cada um tem nome, exemplo concreto, antes/depois, quando usar, quando NÃO usar, falha mais comum. Use como referência, não como receita.
Regras do jogo
Os exemplos abaixo são sanitizados de prompts reais em produção entre 2024 e maio de 2026, em pt-BR e en-US, com Claude (3.5 Sonnet, Opus 4.6, 4.7), GPT-4.1/5 e Gemini 1.5/2.5. Cada padrão tem pelo menos uma falha vista em campo. Quando importa o modelo, eu digo.
1. Role + Tarefa + Contexto + Formato (R-T-C-F)
O que é: a estrutura mais simples que existe. Quatro blocos no topo do prompt: quem o modelo é, o que ele precisa fazer, qual o contexto, e em que formato a saída deve vir.
Antes: "Resume isso aqui em bullets."
Depois: "Você é analista de M&A com 8 anos de experiência (role). Resuma o memorando em até 6 bullets focados em risco de execução (tarefa). O leitor é um diretor financeiro que viu o ativo uma vez (contexto). Markdown, bullets começando com o risco em negrito, sem introdução nem conclusão (formato)."
Quando usar: saída tem leitor específico e formato fixo.
Quando NÃO usar: brainstorm aberto — amarra cedo demais.
Falha comum: role com clichê ("especialista de classe mundial"). Não acrescenta nada. Use credenciais específicas — anos de experiência, contexto, audiência.
2. Few-shot honesto
O que é: dar exemplos concretos de input e output desejados. "Honesto" significa: os exemplos refletem variação real (incluindo um caso difícil), não apenas o caso fácil.
Antes: zero exemplos, modelo inventa o formato.
Depois: 3 exemplos, sendo o terceiro um caso ambíguo onde o output correto é "preciso de mais informação" em vez de chutar.
Quando usar: extração, classificação, formatação consistente.
Quando NÃO usar: tarefas criativas onde exemplos viesam o tom. Vimos: prompt de copy com 4 exemplos cujos assuntos terminavam com ponto de exclamação. O modelo passou a terminar TODOS os assuntos com exclamação, mesmo quando contraindicado.
Falha comum: exemplos com erro de digitação ou inconsistência de formato. O modelo replica o erro fielmente. Trate exemplos como código de produção — revise, teste, versione.
3. Chain-of-thought guiada (não livre)
O que é: pedir para o modelo pensar passo a passo, mas com etapas nomeadas. Não "pense passo a passo" e sim "siga estas 4 etapas: 1) extraia as datas, 2) identifique a parte responsável, 3) compare com a cláusula 4.2, 4) classifique o risco em alto/médio/baixo".
Antes: "Pense passo a passo antes de responder." → o modelo divaga 600 palavras e às vezes muda de tópico.
Depois: 4 etapas nomeadas → output linear, comparável entre execuções, fácil de debugar.
Quando usar: tarefas analíticas onde o caminho importa para revisão.
Quando NÃO usar: chat com cliente final. Em out/2024 deixamos um CoT aberto vazar para interface pública e o usuário viu o modelo "raciocinando" coisas como "o cliente provavelmente está irritado, preciso amaciar". Hoje, todo CoT em produto vai para campo escondido ou usa extended thinking nativo.
Falha comum: confundir CoT com qualidade. CoT ajuda em tarefas que pedem raciocínio. Em extração simples, só atrasa e custa tokens.
4. Contexto estruturado em XML (ou JSON)
O que é: separar partes do prompt com tags <contexto>, <exemplos>, <regras>, <entrada>, <formato>. Modelos da família Claude foram treinados para tratar XML como sinal forte de estrutura; GPT e Gemini também respondem bem.
Antes: parágrafos corridos onde regras, exemplos e entrada se misturam. Adicionar regra nova vira loteria.
Depois: <regras>...</regras> e <exemplos>...</exemplos> delimitados. Manutenção trivial.
Quando usar: prompts com mais de 200 palavras, mantidos por mais de uma pessoa, ou versionados em git.
Quando NÃO usar: chat informal. XML em prompt curto é overhead.
Falha comum: tag mal fechada. Em fev/2026 um prompt passou por review com <regras> aberto sem fechamento, e por duas semanas o modelo tratou TUDO depois daquele bloco como regra. Fix: linter de XML no CI dos prompts.
5. Regras vs exemplos: quando preferir cada um
O que é: decidir conscientemente se uma especificação vai como regra explícita ("não use mais de 80 caracteres por linha") ou como exemplo ("veja como o output deve ficar: ...").
Antes: misturar os dois sem critério. Quando regra contradiz exemplo, o modelo escolhe um sem você saber qual.
Depois: regra para restrições negativas e métricas verificáveis ("não cite USD", "máximo 3 frases"); exemplo para tom e "vibe". Regra quando "fácil descrever, difícil mostrar"; exemplo quando "fácil mostrar, difícil descrever".
Quando usar: sempre. É decisão de design.
Quando NÃO usar: nunca — a questão é qual, não se.
Falha comum: regras escritas como exemplos negativos longos ("não faça assim: [3 parágrafos]"). O modelo lê e replica o estilo. Restrições negativas: curtas e abstratas.
6. Refinamento iterativo (com diff explícito)
O que é: em vez de reescrever o prompt do zero quando algo está ruim, você diz ao modelo o que mudar em relação à última saída. "Mantenha tudo igual, mas reduza para 3 bullets e troque 'sinergia' por 'integração'."
Antes: "Faça de novo, melhor." → modelo redesenha do zero e perde o que estava bom.
Depois: diff explícito. Converge em 2-3 turnos.
Quando usar: edição de copy, polimento, ajuste fino de formato.
Quando NÃO usar: quando a estrutura está fundamentalmente errada — vale começar de novo.
Falha comum: contexto crescendo com 8 versões anteriores. Em algum ponto o modelo perde qual é a versão atual. Resuma e reinicie thread após 3 iterações.
7. Anti-padrões com critérios de rejeição
O que é: dizer o que constitui falha do output e instruir o modelo a se auto-rejeitar antes de entregar.
Antes: "Escreva um e-mail profissional."
Depois: "Escreva um e-mail profissional. Antes de entregar, verifique: (a) não usa 'aproveitar', 'sinergia' ou 'mover o ponteiro'; (b) tem 80-140 palavras; (c) termina com pergunta concreta. Se qualquer critério falhar, refaça antes."
Quando usar: outputs com restrições objetivas.
Quando NÃO usar: criatividade aberta. Critérios em poesia matam o que está bom.
Falha comum: critérios subjetivos ("não soe robótico"). O modelo não verifica isso. Use só critérios checáveis.
8. Padrão "atue como crítico"
O que é: depois de gerar a saída, o modelo muda de papel e critica com olhar de revisor sênior. Funciona em turno único usando blocos <rascunho> e <crítica>.
Antes: aceitar a primeira versão. Em copy comercial, vimos cifras erradas serem publicadas em pelo menos quatro projetos antes de adotar este padrão.
Depois: modelo entrega <rascunho> + <crítica> com 3-5 problemas específicos. Em ~70% dos casos a crítica encontra algo real (número incoerente, claim sem fonte, frase que se contradiz).
Quando usar: análises, copy comercial, código não-trivial.
Quando NÃO usar: classificação curta — não há o que criticar.
Falha comum: crítica vira teatro. Fix: "se nada estiver errado, escreva apenas 'sem problemas substantivos' — não invente".
9. Reformulação automática (rephrase-and-respond)
O que é: antes de responder, o modelo reescreve a sua pergunta com as próprias palavras.
Antes: pergunta ambígua → resposta confiante e errada.
Depois: "entendi sua pergunta como: [reformulação]. Se correto, prossigo." Você corrige antes de gastar tokens na resposta longa.
Quando usar: tarefas longas (>1000 tokens de output) com input ambíguo.
Quando NÃO usar: chat fluido com humano — atrapalha o ritmo.
Falha comum: reformulação superficial. Fix: exigir 2-3 entidades concretas do input na reformulação.
10. Verificação cruzada (cross-check)
O que é: gerar a resposta com um modelo (ou prompt) e validar com outro.
Antes: confiar em um modelo só. Em extração de cláusulas jurídicas com Claude Sonnet vimos ~12% de erro.
Depois: Claude extrai; segundo prompt ("você é revisor cético, marque qualquer claim que não esteja literalmente no texto") aprova ou rejeita. Erro caiu para ~2,3% em 200 contratos em mar/2026.
Quando usar: tarefas factuais com custo de erro alto (jurídico, financeiro, médico).
Quando NÃO usar: criatividade subjetiva — "verificar" título de blog não tem critério.
Falha comum: validador confiar demais no gerador. Fix: dar ao validador só o output e o input original, NÃO o raciocínio do gerador.
11. Cadeia adversarial (adversarial chain)
O que é: dois prompts em sequência com papéis opostos. Primeiro propõe, segundo tenta encontrar o pior caso onde a proposta falha.
Antes: aprovar a primeira versão. Vimos um anúncio sair com claim "100% de garantia" que o jurídico vetou — depois.
Depois: gerador propõe; "adversário" simulado lista 3 piores ataques (regulatório, reputacional, factual). Decisão documentada.
Quando usar: copy regulado (saúde, finanças, jurídico), pitch comercial, comunicação de crise.
Quando NÃO usar: tarefas internas de baixo risco — adversarial é caro em tokens.
Falha comum: adversário fraco. Fix: dar perfil específico — "você é o procurador do Procon mais rigoroso do país, procurando motivo para multar".
12. Padrão de teste tabular (eval-driven prompting)
O que é: prompt como código que precisa de testes. Você define tabela de casos (input, output esperado, critério de aceite) e roda contra ela toda mudança.
Antes: mudar prompt e "achar que melhorou". Em jan/2026 um colega "melhorou" um classificador de tickets e quebrou silenciosamente a categoria "reembolso", que caiu de 94% para 71% de acerto. Descoberto 9 dias depois.
Depois: 30-50 casos em CSV, script roda em cada um, comparação automática com gold standard. Regressão é bloqueada. Mesmo conceito de "evals" defendido por Hamel Husain, operacionalizado em ferramentas como Braintrust e LangSmith.
Quando usar: qualquer prompt em produção que afeta decisão real.
Quando NÃO usar: prompt usado uma vez para relatório descartável.
Falha comum: testes só cobrem o caso feliz. Inclua bordas: input vazio, adversarial, em outra língua, muito longo. Vimos prompt quebrar em pt-BR depois de seis meses funcionando em inglês porque ninguém testou com acentuação.
Aplicação prática: checklist de revisão de prompt em 7 perguntas
Quando recebo um prompt para revisar, passo por estas 7 perguntas, nesta ordem:
- R-T-C-F está claro? Role, tarefa, contexto e formato dão para ler em 30 segundos?
- Há regras e exemplos? Eles concordam entre si? Conflito silencioso entre regra e exemplo é a causa #1 de output inconsistente.
- As tags estruturais estão fechadas? XML/JSON delimitando blocos.
- Existe critério de aceite verificável pelo próprio modelo? Anti-padrões, comprimento, palavras proibidas.
- A chain-of-thought, se existe, está nomeada e oculta do usuário final?
- Existe um second-pass de crítica ou validação para tarefas de risco?
- Existe tabela de teste com pelo menos 20 casos, incluindo bordas?
Se você responder "não" para qualquer uma das 4 primeiras em prompt de produção, há retrabalho na sua frente.
Caveats honestos: onde esses padrões não se aplicam
Os padrões assumem três coisas:
- Você tem acesso ao prompt. Em produto SaaS com prompt embutido (Notion AI, copilots), você só controla a sua mensagem, não a engenharia interna.
- Você pode iterar. Em tempo real (chat de suporte, conversa ao vivo), não há tempo para refinamento iterativo nem cadeia adversarial. Tenha prompts pré-prontos.
- O custo de erro justifica o custo de tokens. Adversarial, cross-check e CoT custam tokens. Para tarefa de baixo risco em alto volume, prompt curto + retry humano sai mais barato.
E uma nota sobre tendências: extended thinking nativo (Opus 4.7 com thinking, GPT-5 com reasoning effort) reduz o ganho marginal de CoT manual. Janelas de 1M+ tokens (Gemini 2.5, Opus 4.7 1M) baixam o custo de few-shot mas aumentam o risco de o modelo "perder" instruções no meio. Os 12 padrões acima funcionam em maio de 2026 — em 12 meses, alguns serão obsoletos. Trate prompts como código vivo.
Para aprofundar
Se você quer levar a sério, recomendo: nosso curso de Engenharia de Prompts da AulasDeIA (cobre os 12 padrões com laboratórios práticos), nosso material sobre automação no-code com IA (onde esses padrões viram fluxos), e o comparativo de ChatGPT vs Claude vs Gemini para profissionais brasileiros. Para fontes externas, comece pela documentação oficial da Anthropic sobre prompt engineering e o blog do Simon Willison, que mantém um log público dos experimentos dele desde 2022.
Sobre os autores: a Equipe Editorial AulasDeIA mantém prompts em produção em finanças, jurídico, suporte e marketing em empresas brasileiras desde 2023. Ministra o currículo de Engenharia de Prompts da aulasdeia.com e roda revisões semanais de prompts internas. Os exemplos deste artigo são sanitizados de prompts reais, com números e contextos preservados quando possível.
Próximo passo prático
Teste o método com um caso real e depois consulte a biblioteca de prompts para continuar a prática com modelos revisáveis.
