Você digita a mesma pergunta de dois jeitos diferentes e recebe duas respostas de qualidade completamente diferente. Não é sorte, nem humor da máquina. É que o jeito como você pede muda o que você recebe — e aprender a pedir bem tem até nome: engenharia de prompt.
O que é engenharia de prompt (e por que virou uma habilidade)
Engenharia de prompt é a prática de escrever instruções para um modelo de linguagem de forma que ele entregue o que você precisa. Só isso. Nada de mágica, nada de "palavras secretas".
Virou uma habilidade valorizada por um motivo simples: o modelo não lê a sua mente. Ele responde ao texto que você dá — e a distância entre um pedido vago e um pedido bem montado costuma ser a distância entre uma resposta inútil e uma resposta que você aproveita direto no trabalho.
O modelo mental que muda tudo: o LLM prevê texto
Se você entender uma coisa só deste artigo, que seja esta: um LLM é um preditor de texto guiado por contexto. Ele olha tudo o que veio antes — sua pergunta, suas instruções, os exemplos — e calcula qual a continuação mais provável, pedaço por pedaço.
Ele não "sabe" a resposta como um banco de dados sabe. Ele gera a continuação mais plausível dado o que você escreveu. Por isso o contexto pesa tanto: mude o contexto e você muda a probabilidade do que vem a seguir. Um prompt bom é basicamente um contexto que empurra o modelo na direção da resposta certa.
Os quatro blocos de um bom prompt
A maioria dos prompts que funcionam tem quatro peças. Você não precisa das quatro toda vez, mas vale conhecê-las:
- Tarefa — o que você quer, dito de forma direta. "Resuma", "reescreva", "gere", "classifique". Comece pelo verbo.
- Contexto — o que o modelo precisa saber pra acertar. Para quem é? Qual o tom? Quais restrições? É aqui que você mata a ambiguidade.
- Exemplos — um ou dois casos de entrada e saída. Nada ensina o formato desejado tão rápido quanto mostrar um exemplo do resultado.
- Formato — como você quer a resposta. Lista? Tabela? JSON? Três frases? Se você não pedir, o modelo escolhe por você — e nem sempre bem.
Exemplo rápido, do ruim pro bom. Ruim: "fale sobre cache". Bom: "Explique o que é cache para uma pessoa júnior (contexto), em até 4 frases (formato), com uma analogia do dia a dia (tarefa)". A segunda versão não é mais esperta — só é mais específica.
O que dá pra esperar — e o que não dá
Dá pra esperar: rascunhos, resumos, reescritas, explicações, geração de código boilerplate, transformação de formato. Coisas onde "a continuação mais provável do texto" é justamente o que você quer.
O que não dá pra esperar: verdade garantida. O modelo prevê texto plausível, e texto plausível às vezes está errado com toda a confiança do mundo — é o famoso "alucinar". Ele também não tem acesso ao que não está no contexto (seus arquivos, o que aconteceu depois do treino) a menos que você forneça. E prompt nenhum conserta um pedido que nem você sabe explicar. Se o objetivo está confuso na sua cabeça, vai sair confuso na resposta.
A regra prática: trate o resultado como rascunho de um estagiário rápido e bem-intencionado, não como oráculo. Você revisa, sempre.
Como começar hoje sem enrolação
Pega uma tarefa real e pequena — resumir um texto, gerar um trecho de código, reescrever um e-mail. Escreve o prompt do jeito preguiçoso primeiro. Olha o resultado. Aí adiciona um bloco de cada vez: um pouco de contexto, um exemplo, o formato desejado. Observa o que muda.
Quando errar, não jogue mais adjetivos no prompt ("seja detalhado, completo, profissional"). Pergunte-se qual bloco faltou: o modelo não sabia o público? Faltou contexto. Saiu no formato errado? Faltou pedir o formato. Debugar prompt é diagnóstico, não feitiçaria.
Engenharia de prompt não é decorar truques — é aprender a comunicar uma intenção com clareza suficiente pra uma máquina que só prevê texto. A boa notícia: essa é uma habilidade que você já usa com gente. Aqui você só está sendo mais explícito. Comece hoje, com uma tarefa pequena, e deixa o resto vir na prática.
