Como escrever um bom prompt, com exemplos ruins e bons lado a lado

O que você leva deste artigo

• Prompt bom é especificação, não pedido: o que você tem na cabeça e não escreveu, o modelo não tem.
• Um exemplo do resultado desejado vale mais que três parágrafos descrevendo o resultado desejado.
• Diga o que fazer, não o que não fazer: proibição sem alternativa costuma ser ignorada.
• Coloque o texto longo antes da instrução, e a instrução por último.
• Dar um papel só funciona quando o papel muda o vocabulário, não quando é enfeite.
• Se a saída vai para um sistema, peça formato estruturado e valide antes de usar.

Por que a maioria dos prompts falha

A causa é quase sempre a mesma, e não é falta de técnica: omissão. Quem escreve tem na cabeça o cliente, o histórico, o objetivo, o tom da empresa e o formato esperado, e manda só a última frase daquele raciocínio. O modelo recebe a frase, não a cabeça.

Compare "escreve um e-mail pro cliente" com o que você realmente quer: um e-mail para um cliente que está há três semanas sem responder uma proposta, que já é cliente de outro serviço, que você não quer pressionar, com o objetivo de reabrir a conversa sem parecer cobrança, curto porque ele não lê e-mail longo, assinado pela empresa e não por você.

A segunda versão não é mais técnica, é só mais completa. E é isso que separa uma resposta genérica de uma resposta usável. O modelo é muito bom em atender uma especificação e péssimo em adivinhar a que não recebeu.

Existe um teste simples que resolve a maior parte dos casos: se você mandasse esse mesmo texto para um estagiário competente que acabou de chegar, ele conseguiria fazer? Se a resposta é não, o problema não é do modelo.

O modelo não adivinha o que ficou de fora. E quase tudo que decide a qualidade da resposta está justamente no que ficou de fora.

As quatro partes de um prompt que funciona

Não é fórmula rígida, é uma lista de verificação. Prompts bons quase sempre têm essas quatro coisas, em alguma ordem.

Contexto: qual é a situação, quem é o público, o que já aconteceu antes. É a parte que mais se omite e a que mais muda o resultado. "Para um cliente que já reclamou duas vezes do mesmo problema" reescreve a resposta inteira.

Tarefa: o verbo específico. Resumir, comparar, classificar, reescrever, listar, extrair. "Me ajuda com esse texto" não é tarefa. "Reduza para 150 palavras mantendo os três argumentos principais" é.

Formato: como a resposta deve chegar. Tamanho, estrutura, se tem título, se é lista ou texto corrido, se pode usar termo técnico. Sem isso, você recebe o formato médio da internet, que quase nunca é o seu.

Exemplo: uma amostra do resultado que você quer. É a parte que mais rende e a que quase ninguém faz, provavelmente porque dá trabalho na primeira vez. Vale o trabalho: um exemplo comunica tom, estrutura e nível de detalhe de uma vez só, sem você precisar descrever nada disso.

Ruim e bom, lado a lado

Três casos reais de uso em empresa, com o pedido que não funciona e o que funciona.

Caso 1, resposta a avaliação negativa. Ruim: "responde essa avaliação ruim de forma educada". Bom: "Sou dono de uma pizzaria. Um cliente avaliou com 2 estrelas dizendo que a pizza chegou fria e que o entregador foi seco. A reclamação procede, tivemos um problema de rota naquele dia. Escreva uma resposta pública de no máximo 4 linhas que reconheça o erro sem se justificar, ofereça resolver por mensagem direta e não use frases prontas de call center. Tom: dono de negócio falando, não empresa. Não prometa desconto."

Caso 2, triagem de mensagem. Ruim: "classifica essas mensagens". Bom: "Classifique cada mensagem de cliente em exatamente uma destas categorias: ORCAMENTO, SUPORTE, RECLAMACAO, OUTRO. Devolva uma linha por mensagem no formato numero|categoria|urgencia de 1 a 3. Se a mensagem não se encaixar claramente, use OUTRO em vez de escolher a mais próxima. Não explique a classificação."

Caso 3, texto de página. Ruim: "escreve um texto sobre nossos serviços de manutenção". Bom: "Escreva o texto de uma página de serviço sobre manutenção preventiva de ar condicionado para condomínios. Público: síndico, não técnico, que decide por custo e por risco de multa. Estrutura: um parágrafo de abertura sobre o problema, três subtítulos com dois parágrafos cada, e um fechamento com chamada para orçamento. Entre 400 e 500 palavras. Não invente números de economia nem prazos. Não use travessão."

Repare que nenhum dos exemplos bons usa técnica sofisticada. Eles só dizem o que a pessoa já sabia e não tinha escrito.

Diga o que fazer, não o que não fazer

Instruções negativas funcionam pior do que instruções positivas, e o motivo é prático: uma proibição fecha uma porta sem abrir outra, e o modelo precisa preencher aquele espaço com alguma coisa.

"Não seja formal demais" deixa em aberto o que é para ser. "Escreva como quem explica para um colega no corredor" resolve. "Não use jargão" é mais fraco que "se precisar usar um termo técnico, explique entre parênteses na primeira vez".

A exceção é a proibição concreta e verificável, que funciona bem justamente porque não deixa ambiguidade: não citar preço, não prometer prazo, não usar travessão, não passar de 300 palavras. São regras que a pessoa consegue conferir olhando o resultado.

Uma variação valiosa dessa ideia é autorizar a saída de emergência. Em vez de proibir o modelo de inventar, dê a ele o que fazer quando não souber: "se a informação não estiver no material fornecido, escreva NAO ENCONTRADO e siga para o próximo item". Isso reduz invenção muito mais do que a proibição genérica, como explicado em alucinação de IA.

A ordem importa, e mais do que parece

Quando você manda um texto longo junto do pedido, um contrato, um relatório, uma transcrição, a posição da instrução muda o resultado.

A ordem que funciona melhor é: material longo primeiro, instrução por último. O modelo processa o texto na sequência, e a instrução no fim fica fresca no momento de responder. Instrução no começo de um documento de vinte páginas tem chance real de ser diluída.

Isso conversa com uma limitação medida desses sistemas: eles prestam mais atenção ao começo e ao fim do que foi enviado do que ao meio. Informação crítica enterrada no meio de um bloco enorme é a mais fácil de ser ignorada. Quando puder, recorte o trecho relevante em vez de mandar o documento inteiro.

E existe uma razão de custo para a mesma ordem, que vale para quem constrói sistema: se o bloco fixo vem primeiro e nunca muda, ele pode ser guardado em cache e cobrado por uma fração do preço nas chamadas seguintes. Colocar a data de hoje no começo da instrução quebra isso, como detalhado em token e janela de contexto.

• Material longo e fixo no começo, para caber em cache e não se diluir.
• Contexto e regras no meio.
• A tarefa específica no fim, imediatamente antes de o modelo responder.
• Exemplos entre as regras e a tarefa, marcados de forma clara.

O que é técnica de verdade e o que é lenda

Dar um papel funciona quando muda o vocabulário. "Você é um advogado tributarista" muda o repertório usado e é útil. "Você é o melhor redator do mundo" não muda nada, porque não aponta para um repertório específico. O teste é: esse papel corresponde a um jeito reconhecível de escrever ou é só elogio?

Pedir para pensar passo a passo ainda ajuda, com ressalva. Em modelos antigos, era um ganho grande. Em modelos com raciocínio embutido, ele já faz isso internamente e o pedido só engorda a resposta. Onde ainda rende é para ver o raciocínio quando você precisa conferir a lógica.

Ser educado não melhora o resultado. Por favor e obrigado não mudam a qualidade da resposta. Não fazem mal, e não são técnica.

Ameaçar ou apelar não funciona. Dizer que o seu emprego depende disso, prometer gorjeta ou insistir com urgência circula em tutorial e não produz melhora consistente. O que produz melhora é especificar melhor.

Reclamar do resultado não conserta. "Ficou ruim, faz de novo" devolve outra coisa igualmente aleatória. Diga o que estava errado e o que deveria estar no lugar: "os dois primeiros parágrafos ficaram genéricos, substitua por exemplos concretos de condomínio".

Quando a saída vai para um sistema

Prompt para uma pessoa ler e prompt para um programa consumir são coisas diferentes, e misturar os dois é uma fonte silenciosa de erro em produção.

Se a resposta vai ser lida por código, peça um formato estruturado explícito, defina cada campo, e diga o que fazer quando o campo não existir. "Devolva JSON com os campos nome, valor e vencimento; use null quando a informação não estiver no documento" é muito mais confiável do que esperar que o modelo escolha um formato razoável.

E valide sempre antes de usar. O modelo pode devolver um campo a mais, um texto de explicação antes do JSON, ou um valor no formato errado. Código que confia na saída do modelo sem verificar quebra em produção no dia em que chega uma entrada diferente.

A regra que vale a pena guardar: o que é verificável por máquina deve ser verificado por máquina. Se o modelo devolveu um valor, recalcule. Se devolveu uma data, valide o formato. Se devolveu um código de produto, confira se ele existe no cadastro.

Se você está montando um fluxo desses e quer definir onde ficam as validações antes de virar código, é esse tipo de decisão que a consultoria em IA da ROO3 resolve no começo do projeto, quando ainda é barato mudar.

Perguntas frequentes

Existe uma fórmula de prompt que sempre funciona?

Não existe fórmula mágica, mas existe uma lista de verificação que resolve a maior parte dos casos: contexto da situação, tarefa com verbo específico, formato esperado da resposta e pelo menos um exemplo do resultado desejado. A maioria dos prompts ruins falha por omitir um desses quatro.

Ser educado com a IA melhora a resposta?

Não. Por favor e obrigado não alteram a qualidade do resultado. Não fazem mal nenhum, mas não são técnica. O que melhora a resposta é especificar melhor o contexto, a tarefa e o formato.

Vale a pena dizer "você é um especialista em X"?

Vale quando o papel aponta para um vocabulário reconhecível, como advogado tributarista ou engenheiro de segurança do trabalho, porque isso muda o repertório usado. Não vale quando é só elogio, como "você é o melhor redator do mundo", que não corresponde a nenhum jeito específico de escrever.

Por que a IA ignora parte das minhas instruções?

Normalmente por três motivos: instruções demais competindo entre si num prompt muito longo, instrução importante enterrada no meio de um texto grande, ou instrução negativa que fecha uma porta sem abrir outra. Reduzir, mover para o fim e trocar proibição por orientação positiva resolve a maioria dos casos.

Preciso pedir para a IA pensar passo a passo?

Em modelos com raciocínio embutido, ele já faz isso internamente e o pedido só engorda a resposta. O pedido continua útil quando você precisa ver o raciocínio para conferir a lógica, ou em modelos mais simples que não raciocinam por padrão.

Como faço a IA devolver sempre o mesmo formato?

Peça o formato de forma explícita, defina cada campo, mostre um exemplo completo da saída e diga o que fazer quando um campo não existir. E valide a resposta por código antes de usar, porque nenhum formato é garantido só por ter sido pedido.

Fontes

• Anthropic: guia de engenharia de prompt
• OpenAI: guia de boas práticas de prompt

Rodrigo Fávaro

Fundador da ROO3, agência de marketing e tecnologia em São José do Rio Preto. Constrói produtos com IA em produção (Tobia, gerar.app, Pense Mercado) e mantém o AI Benchmark, ranking público de modelos de IA. Veja a consultoria em IA da ROO3.

X @rodmf LinkedIn rodrigofavaro