Exemplo didático: uma equipe financeira recebe um prompt que contém regras contraditórias. Um novo exemplo pede um formato diferente do restante das instruções. O exercício é localizar a contradição, corrigir o pedido e conferir a saída com uma pequena tabela de testes. A situação é ilustrativa, não um relato de cliente.
Engenharia de prompts organiza instruções, contexto, exemplos e critérios de revisão. Os padrões abaixo são opções para testar no seu cenário. Eles não garantem precisão, produtividade nem resultados comerciais; a escolha do modelo, os dados disponíveis e a revisão humana também importam.
Por que isso importa para você
Para tarefas de trabalho, comece definindo o resultado esperado e como você vai conferir a resposta. A documentação de prompting da Anthropic oferece orientações complementares. Compare as instruções com as recomendações do modelo que você realmente usa.
Os 12 padrões abaixo têm nome, exemplo antes/depois, contexto de uso e uma possível falha. Use-os como repertório para experimentar e avaliar, sem presumir que todos serão adequados à mesma tarefa.
Regras do jogo
Os exemplos são demonstrações didáticas com situações e dados fictícios. Não representam projetos de alunos, clientes, testes de produção ou resultados medidos. Troque o contexto pelo seu, use dados autorizados e confira a saída antes de aplicá-la.
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: "Atue como assistente de análise de um memorando de aquisição (papel). 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. Defina a tarefa, o contexto e a audiência; atribuir credenciais fictícias ao modelo não lhe dá qualificação profissional.
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. Exemplo de risco: quatro assuntos de e-mail terminam em exclamação e induzem o mesmo estilo nas respostas seguintes.
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. Etapas verificáveis
O que é: dividir uma tarefa em entregas que você consiga revisar: 1) listar datas citadas, 2) identificar a parte responsável, 3) apontar o trecho relevante, 4) marcar informações ausentes. Peça resultados verificáveis e justificativas breves baseadas nas fontes, sem exigir raciocínio interno do modelo.
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: quando etapas adicionais apenas repetem uma tarefa simples. Em uma conversa com cliente, mostre a resposta útil e as informações que precisam de confirmação.
Falha comum: confundir uma explicação longa com evidência de correção. Compare cada entrega com a fonte e com seus critérios.
4. Contexto estruturado em XML (ou JSON)
O que é: separar partes do prompt com tags <contexto>, <exemplos>, <regras>, <entrada>, <formato>. A documentação da Anthropic sobre tags XML mostra formas de delimitar esses blocos. Teste o formato na ferramenta escolhida.
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 ou blocos contraditórios. Confira delimitadores e teste uma entrada pequena antes de ampliar o uso.
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: descreva a alteração e compare a nova versão com a anterior. Repita somente enquanto a comparação mostrar progresso.
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 sem conferir números ou fontes.
Depois: peça um rascunho e uma revisão separada que aponte números incoerentes, afirmações sem fonte e contradições. Confira os alertas: a revisão também pode errar.
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: aceitar uma extração de cláusulas sem compará-la com o documento original.
Depois: um prompt extrai os trechos; outro compara cada afirmação com o documento e marca o que não tem apoio textual. Uma pessoa responsável confere as divergências. Não há taxa de precisão demonstrada por este exemplo.
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 um anúncio com uma garantia que a oferta real não concede.
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: tratar a crítica simulada como aprovação jurídica. Peça riscos factuais e informações ausentes; decisões regulatórias exigem revisão de profissional habilitado.
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 um classificador de tickets e avaliar só as respostas que parecem boas, sem rever casos de reembolso, ambiguidade ou entrada incompleta.
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. Inclua acentuação e variações do português brasileiro na tabela de testes.
Aplicação prática: checklist de revisão de prompt em 7 perguntas
Use estas sete perguntas como ponto de partida para revisar um prompt:
- 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? Conflitos entre regra e exemplo podem produzir saídas inconsistentes.
- 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.
- As etapas produzem resultados verificáveis, sem depender de raciocínio interno do modelo?
- 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.
Ferramentas e modelos mudam. Antes de reutilizar um prompt, confirme os recursos disponíveis na sua conta e repita os testes com o modelo escolhido. Preserve versões anteriores para comparar as respostas.
Para aprofundar
Se você quer levar a sério, recomendo: o curso ChatGPT Workflows, que propõe organizar etapas, critérios de revisão e aprovação humana em um fluxo de trabalho, 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.
Responsabilidade editorial: Aulas de IA. Conheça quem ensina e a empresa responsável. Revisão desta página em 22/09/2026: exemplos didáticos, clareza das limitações e recomendações do catálogo. Uma mudança nos cursos recomendados, nas ferramentas citadas ou nos resultados dos exercícios exige nova revisão.
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.
