"Seja claro, conciso e específico."
Esse é o conselho que aparece em praticamente todo guia de prompt engineering para iniciantes — e não está errado. Mas também não é suficiente para quem está escrevendo prompts que vão rodar em produção, gerando output para usuários reais, em escala, dentro de um produto.
A diferença entre um prompt que funciona razoavelmente bem em demo e um prompt que funciona de forma consistente em produção está nos detalhes: como você define o papel do modelo, como você estrutura restrições, como você comunica o formato de saída esperado, e como você lida com os casos em que o input do usuário não é o que você esperava.
Este artigo não é uma introdução ao que é um prompt. É um mapeamento dos padrões que fazem diferença real no output — com exemplos concretos de antes e depois — para quem já usa IA em produto e quer melhorar a qualidade e consistência do que entrega.
Nota: se você busca o lado de gestão de prompts — versionamento, testes, propriedade — esse tema é coberto em detalhe no artigo Engenharia de prompts em produto: por que prompt precisa de versão, teste e dono.
Padrão 1: definir papel antes de definir tarefa
O erro mais comum em prompts de produto não é a tarefa mal descrita — é a ausência de um papel bem definido antes da tarefa.
O modelo de linguagem não tem um "modo padrão" fixo. Ele vai interpretar o contexto e adotar uma postura com base no que inferir. Se você não define o papel explicitamente, ele vai inferir — e a inferência pode não ser o que você quer.
Antes:
Revise o texto abaixo e melhore a clareza. [texto do usuário]
Depois:
Você é um editor técnico sênior especializado em documentação de software para times de engenharia. Seu estilo é direto, preciso e sem jargão desnecessário. Revise o texto abaixo mantendo a intenção original. Corrija ambiguidades, elimine redundância e melhore a estrutura de frases longas. Não adicione informações que não estejam no texto original. [texto do usuário]
A diferença no output não é marginal. O primeiro prompt vai produzir uma revisão genérica. O segundo vai produzir uma revisão contextualizada para o tipo de texto e o estilo desejado — e a restrição "não adicione informações que não estejam no texto original" evita o comportamento de alucinação que é particularmente problemático em revisão de documentação técnica.
[INSERIR COMPARATIVO REAL: output do prompt antes vs. depois com o mesmo texto de entrada]
Padrão 2: restrições negativas explícitas para comportamentos indesejados
Prompts sem restrições negativas deixam o modelo livre para comportamentos que são razoáveis em geral, mas problemáticos no contexto específico do produto.
O comportamento mais frequentemente problemático é a inferência de dados não fornecidos. Quando o usuário não fornece uma informação, o modelo tende a completar de forma plausível. Em um chatbot de conversa, isso é razoavelmente tolerável. Em um gerador de documentos profissionais, é crítico: o modelo vai inventar métricas, responsabilidades e tecnologias.
Antes:
Com base nas informações fornecidas, escreva a seção de "Experiência Profissional" do currículo. [dados do usuário]
Depois:
Com base EXCLUSIVAMENTE nas informações fornecidas abaixo, escreva a seção de "Experiência Profissional". Restrições absolutas: - Não inclua nenhuma métrica, número ou resultado que não tenha sido explicitamente fornecido pelo usuário - Não infira tecnologias, responsabilidades ou conquistas além do que está nos dados - Se uma informação relevante estiver ausente, omita a referência a ela em vez de completar com inferência - Não use expressões genéricas como "contribuiu significativamente" sem embasamento nos dados fornecidos [dados do usuário]
As restrições negativas são a diferença entre um produto que o usuário pode usar com confiança e um produto que o usuário precisa revisar com desconfiança. No segundo caso, o tempo economizado na geração é parcialmente consumido na revisão defensiva.
Padrão 3: formato de saída como instrução, não como expectativa
Um dos erros mais custosos em produto é assumir que o modelo vai formatar o output da forma que você precisa sem que você especifique. Em ambiente controlado, geralmente funciona. Com dados variados de usuários reais, o modelo vai produzir formatos inconsistentes — e inconsistência de formato quebra parsers, quebra renderização e gera retrabalho de normalização.
Antes:
Analise o texto e extraia as informações principais.
Depois:
Analise o texto abaixo e extraia as informações principais no seguinte formato JSON:
{
"titulo": "string — título principal identificado, ou null se não houver",
"pontos_principais": ["array de strings — máximo 5 itens, cada um com no máximo 20 palavras"],
"tom": "formal | informal | tecnico | neutro",
"adequado_para_publicacao": true | false
}
Retorne APENAS o JSON válido, sem texto adicional antes ou depois, sem blocos de código markdown.
A especificação do formato tem três componentes que importam: a estrutura exata do output, os tipos de cada campo, incluindo valores possíveis para campos enumerados, e a instrução explícita sobre o que não incluir além do formato definido.
A última parte é frequentemente ignorada e é a que mais causa problema: o modelo tem tendência a envolver o JSON em blocos de código markdown ou adicionar uma frase introdutória como "Aqui está a análise:". Ambos quebram o parse do output se você não fizer sanitização.
Padrão 4: exemplos dentro do prompt para casos difíceis
Few-shot prompting — incluir exemplos no prompt — é um dos padrões mais poderosos e menos usados em produto. A maioria dos prompts de produto são zero-shot: descrevem a tarefa sem mostrar nenhum exemplo do que é um bom output.
Isso funciona bem para tarefas simples. Para tarefas com nuances que são difíceis de descrever em palavras, um exemplo faz mais do que três parágrafos de instrução.
Caso de uso típico: distinção de tom em geração de texto
Você está gerando descrições de experiência profissional para currículos. O tom deve ser assertivo e orientado a resultado, sem ser exagerado. Exemplo de tom INADEQUADO: "Fui responsável por diversas atividades na área de desenvolvimento, contribuindo para o sucesso do time em projetos importantes." Exemplo de tom ADEQUADO: "Desenvolvi e mantive APIs de integração entre sistemas de pagamento e ERP, reduzindo o tempo de processamento de 20 horas para 8 horas." Note que o exemplo adequado usa verbos de ação específicos, descreve a ação concreta e ancora resultados em métricas fornecidas pelo usuário — nunca inventadas. Agora gere a descrição com base nos dados abaixo:
O exemplo negativo é tão importante quanto o positivo. Mostrar o que você não quer, com o mesmo formato do que você quer, é mais eficaz do que descrever o problema em linguagem abstrata.
Padrão 5: tratamento explícito de input inesperado
Em ambiente de produto, o usuário vai fornecer inputs que você não antecipou. O que o modelo faz nesses casos — sem instrução explícita — vai depender do que ele inferir ser razoável. Isso raramente é o comportamento que o produto deve ter.
As categorias de input inesperado mais comuns são: input vazio ou insuficiente, input em idioma diferente do esperado e input com conteúdo fora do escopo.
Input vazio ou insuficiente:
Se os dados fornecidos forem insuficientes para gerar [X] com qualidade adequada, responda exatamente: "DADOS_INSUFICIENTES: [liste especificamente quais informações estão faltando]" Não tente gerar [X] com dados incompletos.
Input em idioma diferente do esperado:
Se o texto fornecido não estiver em português brasileiro, responda exatamente: "IDIOMA_NAO_SUPORTADO" Não tente processar nem traduzir o input.
Input com conteúdo fora do escopo:
Se o conteúdo fornecido não for relacionado a [domínio específico do produto], responda: "FORA_DO_ESCOPO: Este sistema processa apenas [descrição do domínio]."
A instrução "responda exatamente: [texto específico]" é importante. Ela permite que o sistema que recebe o output do modelo identifique com segurança esses casos e trate programaticamente — em vez de tentar interpretar uma resposta em linguagem natural que pode variar entre execuções.
As armadilhas que aparecem em produção
Drift de instrução em documentos longos
Em prompts longos — system prompt extenso, template detalhado, dados do usuário volumosos — o modelo tende a dar mais peso às instruções mais próximas do final. Instruções importantes no topo do system prompt podem ser "esquecidas" quando o input do usuário é longo.
Mitigação: repetir as restrições mais críticas tanto no início do system prompt quanto imediatamente antes dos dados do usuário. Especialmente para restrições negativas de alto risco, como "não invente dados".
Falsa obediência ao formato
O modelo pode confirmar que vai seguir o formato especificado e depois não seguir. Isso acontece especialmente quando o formato especificado entra em conflito com o comportamento padrão do modelo para aquele tipo de conteúdo.
Exemplo: especificar saída JSON pura e o modelo retornar JSON envolvido em markdown é um caso clássico. A instrução foi lida, foi "confirmada" implicitamente, e ignorada na execução.
Mitigação: validação de formato no sistema, não confiança na instrução. O código que recebe o output deve verificar se o formato está correto antes de usar — e acionar regeneração ou fallback se não estiver.
Instruções que o modelo interpreta como opcionais
Certas construções linguísticas fazem o modelo tratar a instrução como sugestão em vez de restrição. Palavras como "tente", "prefira", "quando possível" sinalizam flexibilidade que você pode não querer dar.
Compare:
Fraco: Tente manter o texto abaixo de 200 palavras. Forte: O texto deve ter no máximo 200 palavras. Se o conteúdo necessário ultrapassar esse limite, priorize [X] e omita [Y].
A versão forte define o limite como regra, não como preferência, e especifica o critério de decisão quando há conflito — eliminando a ambiguidade que o modelo usaria para justificar ultrapassar o limite.
Sobre "prompt engineering" como habilidade em 2026
O valor de saber escrever prompts está mudando — não desaparecendo, mas se redistribuindo.
Com modelos mais capazes, prompts simples produzem resultados razoáveis em tarefas simples. O que isso elimina é a necessidade de expertise em prompting para uso casual e exploratório.
O que não elimina é a necessidade de prompts bem construídos em contextos de produto, onde o output precisa ser consistente, previsível, seguro e adequado ao domínio específico. Esses contextos têm exigências que não são resolvidas por um modelo mais inteligente — são resolvidas por um prompt mais preciso.
A habilidade que vai continuar sendo diferencial não é saber "como conversar com a IA". É saber especificar comportamento com precisão suficiente para que o sistema seja confiável — o que é fundamentalmente a mesma habilidade de escrever especificações de software, aplicada a um tipo diferente de componente.
Aprendizados práticos
Papel antes de tarefa — sempre. Um modelo sem papel definido vai inferir um, e a inferência raramente é otimizada para o seu contexto.
Restrições negativas são tão importantes quanto instruções positivas. O comportamento padrão do modelo para dados ausentes é completar com inferência — que é o comportamento errado em quase todo produto que lida com dados pessoais ou profissionais.
Formato de saída como instrução, não como expectativa — especifique estrutura, tipos e o que não incluir. Inclua a instrução de não adicionar texto além do formato.
Few-shot com exemplo negativo — quando o tom ou estilo importam, um par de exemplos, bom e ruim, faz mais do que três parágrafos de descrição.
Inputs inesperados precisam de tratamento explícito — com saída padronizada que o sistema possa identificar programaticamente.
Validação de formato no código, não confiança no prompt — o prompt instrui, o código verifica.