Prompt bom não é sorte nem palavra mágica: é método. A maioria dos resultados ruins vem de instrução preguiçosa, não do modelo.
Seja específico e dê contexto
O modelo não adivinha o que você tem na cabeça. "Escreva sobre marketing" devolve genérico porque o pedido é genérico. Diga quem lê, com que objetivo, em que tom, com qual restrição. Compare "resuma esse texto" com "resuma em 3 bullets para um gerente sem tempo, foco em decisões, sem jargão": o segundo entrega algo útil porque você fez o trabalho de pensar antes de pedir. Contexto vale mais que capricho na redação — cole o material relevante, diga o que já foi tentado e aponte o que você não quer.
Mostre exemplos (few-shot)
Descrever o resultado desejado ajuda; mostrar um exemplo ajuda mais. Se você quer classificar tickets como "urgente / normal / spam", dê dois ou três casos já rotulados antes de soltar o real. O modelo capta o padrão — formato, nível de detalhe, critério — muito melhor de exemplo do que de adjetivo. Um ou dois exemplos bem escolhidos costumam valer mais que um parágrafo de instrução. Só cuidado para eles serem representativos: se todos forem fáceis, ele tropeça nos casos de borda.
Peça um formato
Se você vai consumir a resposta em código, colar numa planilha ou revisar rápido, diga o formato explícito: JSON com essas chaves, tabela com essas colunas, lista numerada, no máximo X palavras. Sem isso, cada rodada volta diferente e você perde tempo limpando. Um "responda só com o JSON, sem texto ao redor" evita aquele "Claro! Aqui está:" que quebra o seu parser. Formato explícito também é a maneira mais barata de deixar a saída testável.
Quebre tarefas difíceis em partes
Pedir "analise esse contrato, ache os riscos, reescreva as cláusulas e gere um resumo executivo" num prompt só costuma dar uma sopa morna de tudo. Separe: primeiro extraia as cláusulas, depois avalie o risco de cada uma, depois reescreva. Cada passo fica mais fácil de verificar e de corrigir. Para raciocínio, pedir para "pensar passo a passo" antes de responder ajuda em problemas de lógica — não por mágica, mas porque força o modelo a não pular pro chute. Tarefa grande e vaga é onde os erros se escondem.
Itere e avalie
Primeiro prompt raramente é o melhor. Trate como código: rode, veja onde falhou, ajuste uma coisa, rode de novo. O erro comum é mudar cinco coisas de uma vez e não saber o que funcionou. Se você usa o mesmo prompt com frequência, monte um conjunto de casos de teste — entradas com a resposta esperada — e passe o prompt por eles sempre que mexer. "Ficou melhor?" no olho não escala; um punhado de exemplos com gabarito, sim.
Conheça os limites
O modelo inventa com confiança. Ele preenche lacunas com o que soa plausível — nomes, números, citações, APIs que não existem. Pedir educadamente para ele não alucinar não resolve. O que resolve: dar a fonte no próprio prompt (grounding), pedir que ele avise quando não sabe e verificar tudo que for factual ou sensível antes de usar. Data de corte, viés dos dados de treino e falta de acesso ao seu contexto privado são limitações reais, não opinião. Use como um estagiário rápido e incansável: ótimo para rascunho, péssimo para assinar embaixo sem revisar.
No fim, engenharia de prompt é menos truque e mais clareza: quanto melhor você define o problema, menos o modelo precisa adivinhar. A ferramenta é boa — só não terceirize o pensamento.
