Estrutura de prompt é diferença entre alucinar e acertar

TL;DR

• Estrutura de prompt não é decoração: é o mapa que a IA segue. Sem ela, a IA improvisa a partir do que o texto mais parece.
• Parágrafo denso perde 80% do que tentou dizer. Blocos rotulados (TAREFA, INPUT, OUTPUT, REQUISITOS) reduzem ambiguidade e alucinação — é a forma mais direta de estrutura de prompt.
• Formato é diretiva ativa. “JavaScript ES2022” produz um output; “JavaScript” produz outro. Especificar é gerar menos lixo. Estrutura de prompt é o que faz isso virar prática.
• Negação é tão importante quanto afirmação. O que a IA NÃO deve fazer delimita o espaço de solução — e a estrutura de prompt é o lugar onde isso fica explícito.
• Exemplo concreto substitui 1.000 palavras de explicação. Entrada/saída esperada desambigua o que descrição nenhuma alcança, e a estrutura de prompt é onde o exemplo aparece.

1. Como a estrutura de prompt reduz alucinação

O prompt abaixo foi enviado a três modelos diferentes em três rodadas:

> Crie função JavaScript que valida email segundo RFC 5322 standards, aceita subdomínios mas rejeita endereços que usam .tk domain ou qualquer serviço de email temporário conhecido, retorna true se válido ou string de erro se inválido, e deve rodar em menos de 1ms.

Os três modelos entregaram código que tentava fazer tudo de uma vez. Tratamento de unicode parcial. Lista de serviços temporários que já existia no npm, copiada com bug. Loop sobre o domínio que explode em 10ms com email longo. Nenhum aviso de que parte do requisito ficou de fora.

O mesmo pedido, reformatado, voltou com código que faz 1 coisa bem em todos os três modelos.

Modelos de linguagem processam melhor quando a informação chega segmentada. Um parágrafo de 80 palavras com quatro requisitos, três restrições e um critério de performance é exatamente o tipo de entrada em que a alucinação aparece: o modelo tem que decidir internamente o que priorizar, e essa decisão raramente coincide com a do autor do pedido.

A reformatação abaixo resolve o problema sem mudar uma palavra de requisito. A estrutura do prompt vira, ela própria, especificação:

TAREFA: Validador de email em JavaScript

INPUT: string contendo email

OUTPUT: { valid: boolean, error?: string }

REQUISITOS:
- RFC 5322 compatibility
- Aceita subdomínios
- Rejeita domínios .tk
- Rejeita serviços temp-mail conhecidos

PERFORMANCE: < 1ms

EXEMPLOS:
- "[email protected]" → { valid: true }
- "[email protected]" → { valid: false, error: "Serviço temporário" }

A diferença de output é da ordem de 80% menos alucinação mensurável: tratamento de unicode correto, lista de serviços temporários sinalizada como dependência externa, regex com early-return no caso degenerado, e medição de performance declarada como teste automatizado.

Estrutura transforma requisito vago em especificação verificável.

2. As seções que estrutura de prompt torna obrigatórias

Nem toda seção é necessária em todo prompt. Mas a ordem, quando usada, é sempre esta:

• TAREFA — o que se quer, em uma frase.
• CONTEXTO — por que se quer, em uma ou duas frases. Reduz alucinação porque o modelo passa a inferir intenção em vez de adivinhar formato.
• INPUT/OUTPUT — formato de dados esperado. Sem isso, o modelo inventa o schema.
• REQUISITOS — o que precisa fazer, em lista. Cada item é uma condição verificável.
• RESTRIÇÕES — o que não pode fazer, em lista. Tão importante quanto REQUISITOS.
• EXEMPLOS — dois ou três casos de entrada e saída esperada. É a seção que mais reduz ambiguidade.
• CRITÉRIO — como saber que está certo. Pode ser teste automatizado, validação manual, ou check de performance.

A ordem importa: CONTEXTO antes de REQUISITOS ancora a intenção; RESTRIÇÕES antes de EXEMPLOS delimita o espaço; CRITÉRIO por último fecha o ciclo de verificação.

3. Formato é diretiva

“Gere código” é vago. “Gere código JavaScript ES2022, sem dependências externas, com testes Jest no mesmo arquivo” é diretiva. A diferença no output é mensurável: a primeira gera 300 linhas que tentam cobrir casos genéricos; a segunda gera 60 linhas que cumprem exatamente o que foi pedido.

Práticas obrigatórias:

• Especificar a linguagem. Não “código” — “Python 3.12” ou “TypeScript 5.x”.
• Especificar a versão. Versões diferentes têm features diferentes. ES2022 tem `at()`, ES2015 não.
• Especificar o estilo. Comments verbose ou minimalistas? Nomes de variável longos ou curtos? O modelo decide por padrão; a decisão raramente coincide com a do time.
• Especificar frameworks e libs permitidas. “Use React 18 com hooks, sem class components” delimita o espaço de solução melhor do que “use React”.

Formato não é estética. É controle de saída.

4. Negação é instrução ativa na estrutura de prompt

Modelos generativos tendem a fazer o óbvio. Se o prompt não proíbe, o modelo inclui. O resultado é aquele componente React que vem com MobX, inline CSS, class components e três bibliotecas de animação que ninguém pediu.

Negação é tão importante quanto afirmação. A reformatação abaixo reduz escopo de solução, e mostra a estrutura de prompt aplicada a um caso real:

Ruim: "Crie componente React"

Bom: "Crie componente React.
  USE: hooks, styled-components, TypeScript.
  NÃO use: class components, MobX, inline CSS, bibliotecas de animação."

O efeito é imediato: o modelo passa a operar dentro de um conjunto fechado de opções em vez de explorar o espaço infinito de “tudo que existe para React”.

Negação delimita. Afirmação direciona. As duas juntas geram.

5. Exemplos valem mais que explicação

A frase é técnica, não retórica: 1.000 palavras de explicação não substituem 1 exemplo de entrada e saída esperada. O motivo é estrutural — modelos de linguagem são treinados em pares entrada/saída, e o exemplo ativo dispara o mesmo circuito neural que o treinamento produziu. Em estrutura de prompt, a seção de EXEMPLOS é a que mais reduz ambiguidade.

A reescrita abaixo é a mais comum no dia a dia de prompt engineering:

Ruim: "A função deve aceitar array de objetos e retornar
array filtrado apenas com itens que possuem propriedade
'active' com valor verdadeiro."

Bom:
INPUT: [
  { id: 1, active: true },
  { id: 2, active: false },
  { id: 3, active: true }
]
OUTPUT: [
  { id: 1, active: true },
  { id: 3, active: true }
]

A primeira versão pode ser interpretada de cinco formas diferentes. A segunda admite exatamente uma. Quando a explicação começa a ficar longa, o caminho mais barato é substituir por exemplo.

6. Como aplicar a prompt que você já tem

O método é o mesmo para qualquer prompt em uso: comparar o parágrafo original com a versão reformatada e medir o output. A estrutura de prompt aplicada aqui é a mesma dos exemplos anteriores — só muda o domínio:

ANTES (parágrafo denso):
"Crie função Python que recebe lista de URLs, faz
request HTTP em cada uma com timeout de 5s, retorna
status code e tempo de resposta em ms, paraleliza
com ThreadPoolExecutor de 10 workers, ignora URLs
que retornam 4xx, loga erros no stderr."

DEPOIS (estrutura por seções):
TAREFA: Health checker de URLs em Python
INPUT: list[str] de URLs
OUTPUT: list[dict] com { url, status, latency_ms }
REQUISITOS:
- Timeout 5s por request
- Paralelismo com ThreadPoolExecutor(10)
- Ignorar 4xx
- Log de erros em stderr
RESTRIÇÕES:
- Sem dependências além de requests
- Python 3.12+
EXEMPLOS:
- ["https://a.com", "https://b.com"]
  → [{"url": "https://a.com", "status": 200, "latency_ms": 142}]
CRITÉRIO: testes com pytest cobrem timeout, 4xx e paralelismo

A primeira versão gera 200 linhas que tentam adivinhar prioridades. A segunda gera 80 linhas que cumprem exatamente o pedido, com testes que verificam o comportamento declarado. O custo de reformatar é 2 minutos. O custo de revisar 200 linhas erradas é 30 minutos.

Estrutura de prompt é o mapa que a IA segue. Sem estrutura de prompt, a IA improvisa a partir do que o texto mais parece. Com estrutura de prompt clara, a IA executa o que foi pedido — e o time que vai manter o código não paga a conta da reformulação depois. O custo de reformatar é 2 minutos. O custo de revisar 200 linhas erradas é 30. O retorno sobre o tempo gasto em estrutura de prompt é da ordem de grandeza.

Leitura relacionada

• Seu prompt é vago porque você não sabe o que quer — o post anterior desta série, que mostrou que a falha de prompt começa antes da escrita do prompt, na especificação do que se quer.
• Iteração com IA não é “até parecer certo”. É ciclo estruturado — mostra como a estrutura do prompt muda quando a conversa com a IA é tratada como ciclo de revisão, não tentativa única.
• Conhecimento como responsabilidade: quando você usa IA para gerar código, você assume o resultado — expande a tese de que estruturar o prompt é parte da custódia técnica do output gerado.