O Que Não Pode Faltar Em Uma Instrução

Prompt engineering na prática: o que realmente funciona quando você pede algo para uma IA

Você já percebeu que a maioria das instruções ruins são tão genéricas que poderiam ser enviadas a qualquer sistema? Não é sobre usar palavras mágicas. É sobre eliminar ambiguidade antes que ela entre no modelo. A regra mais importante que eu descobri depois de quebrar a cabeça por meses é que o contexto vazio é o maior inimigo do resultado. Existem quatro componentes que eu nunca consigo pular sem ver o resultado piorar. O primeiro é o papel. Se você não disser ao modelo quem ele é supposed ser, ele vai assumir um tom médio que não serve para nada específico. Eu aprendi isso da forma difícil quando precisei gerar documentação técnica para uma API REST e o modelo respondeu como se estivesse escrevendo para iniciantes absolutos, ignorando completamente que o público-alvo eram desenvolvedores seniores. O segundo componente é o formato de saída. Descrever o formato esperado elimina cerca de 70% dos retrabalhos. Eu costumo especificar explicitamente se quero JSON, tabela, lista numerada ou texto corrido. Sem isso, o modelo escolhe o caminho preguiçoso dele, que raramente é o que você precisa na segunda iteração.

O terceiro é o contexto situacional. Quantas vezes você já viu alguém pedir "escreva um e-mail profissional" e receber algo que soa robótico porque não havia informações sobre o destinatário, o objetivo real ou o histórico da relação? Eu sempre incluo três linhas de background: quem é o receptor, qual é a situação atual e qual ação eu quero que a pessoa tome após ler. O quarto é a restrição explícita do que não fazer. Parece contra-intuitivo, mas dizer ao modelo o que evitar é frequentemente mais eficaz do que descrever apenas o que deseja. Quando eu preciso de código, digo explicitamente para não usar bibliotecas externas, não adicionar comentários explicativos e manter a função com menos de vinte linhas. Essas restrições funcionam como âncoras que impedem o modelo de divagar. Existe uma nuance que poucos mencionam: o modelo responde melhor a instruções positivas do que a negações, mas as negações são essenciais para limitar escopo. A combinação ideal é começar com o que você quer, depois adicionar as restrições como camadas subsequentes. Eu estruturo meus prompts nessa ordem: papel, tarefa, contexto, formato, restrições.

Outro insight que não aparece em nenhum tutorial é sobre a densidade de informação. Instruções muito longas perdem eficácia porque o modelo dá peso desproporcional às partes iniciais e finais. Eu mantenho prompts entre cem e duzentas palavras, e quando preciso de algo mais complexo, divido em múltiplas interações em vez de um único texto gigante. Isso reduz erros de alinhamento em algo perto de quarenta por cento no meu experiência. O problema prático mais chato que eu encontrei envolve ambiguidade temporal. Quando peço para gerar um relatório mensal sem especificar o período exato, o modelo inventa datas ou usa o mês corrente de forma inconsistente. A solução foi padronizar o uso de rangos explícitos: "período de 01/03/2025 a 31/03/2025" em vez de "março". Pequeno detalhe que elimina metade dos bugs de geração. Se você quer testar isso na prática, pode usar qualquer interface de chat com IA generativa. O que muda é a qualidade da saída, não a ferramenta. Eu recomendo começar com um template fixo que você copia e preenche toda vez, ajustando apenas as variáveis. Depois de algumas semanas, você vai perceber que leva menos de dois minutos para montar uma instrução que gera resultados utilizáveis na primeira tentativa.