As 5 partes de um `prompt` que realmente funciona

Muita gente junta prompt como quem junta cheat code: uma pasta cheia de frases "nível deus" pra colar e rezar. É o contrário disso. Um prompt não é feitiço, é briefing. E todo briefing que funciona tem as mesmas partes.

A própria Anthropic resume bem: trate o modelo como "um funcionário brilhante, mas recém-chegado, que não conhece as suas regras nem o seu jeito de trabalhar". Um contratado desse nível não precisa de palavra secreta. Precisa de um briefing decente. Quando você sabe nomear as partes de um, para de chutar — uma resposta fraca quase sempre é uma parte que faltou, e você aponta direto pra ela.

As cinco partes

As duas que mais gente pula são Contexto e Restrições — e são justamente as duas que decidem se a resposta serve ou não.

O teste pra saber se o seu prompt está pronto

Esse é o check mais rápido que eu conheço. Imagine entregar o seu prompt — só ele, sem conversa depois — pra um colega gente boa no primeiro dia dele. Ele daria conta da tarefa? Se não, o modelo também não dá. É por isso que a Anthropic manda você pensar num funcionário brilhante e recém-chegado: o modelo tem a competência, mas zero do seu contexto até você entregar. Quando a resposta decepciona, não discuta com a resposta. Volte pro briefing e ache a parte que ficou magra.

Um esqueleto pra reaproveitar

Você não monta isso do zero toda vez. Preencha os colchetes, apague as instruções, manda. Custa uns noventa segundos a mais que um prompt de uma linha, e muda a saída por completo.

Aja como [o especialista que a tarefa realmente pede — "um staff engineer que já
revisou milhares de PRs", não só "um dev". Escolha o julgamento que você quer, não
só o conhecimento].

A situação é a seguinte: [tudo que o modelo não tem como saber sem você — a stack,
pra quem é a saída, o que está em jogo, o que já deu errado. Três a seis frases. É
nessa camada que as respostas genéricas morrem].

Um exemplo do que é "bom": [cole uma amostra real no seu estilo — uma review antiga,
um doc, uma mensagem. Depois diga: siga esse formato e essa voz, não achate pra uma
média].

Regras:
- Nunca [o erro que você vê sempre: "deixar nitpick", "inventar uma API", "passar de 200 palavras"]
- Sempre [o que você sempre quer: "começar pelo problema de maior severidade", "mostrar o diff"]
- [limite de escopo ou tamanho: "no máximo os 5 achados principais", "uma tela de saída"]

Me dê:
1) [a coisa em si]
2) [variações onde fizer sentido: "duas linhas de assunto", "uma versão enxuta e uma detalhada"]
3) [o artefato que você vai querer logo depois: "as 3 objeções que um revisor vai
   levantar e como eu responderia cada uma", "um checklist antes de eu dar o merge"]

Mostre, não descreva — a linha que mais trabalha

"Profissional, mas amigável" não diz nada pro modelo; você não tem como medir isso. Um exemplo tem. Essa é a parte que quase ninguém adiciona, e é a de maior alavancagem. A Anthropic chama de few-shot (ou multishot) e é direta: exemplos são "uma das formas mais confiáveis de guiar o formato, o tom e a estrutura da saída do Claude", e a recomendação é de 3 a 5 que sejam relevantes pro seu caso real e variados o bastante pro modelo não pegar um padrão sem querer. Uma amostra real vale mais que um monte de adjetivo.

Três prompts, um esqueleto

Uma review de código. As cinco partes, porque o risco e a voz importam:

Aja como um staff engineer que revisa por correção e raio de impacto antes de estilo.
Situação: é um serviço de pagamentos em Go; o diff mexe em idempotency keys no fluxo
de refund; vai pra prod na sexta e o on-call é meu.
"Bom" é assim: [cole uma review minha antiga]. Siga isso: direto, uma linha por achado,
severidade primeiro.
Regras:
- Nunca aponte formatação que o linter já resolve
- Sempre dê um fix concreto ou um diff, não só "considere refatorar"
Me dê: 1) achados por ordem de severidade, 2) o modo de falha com mais chance de me
acordar às 3 da manhã, 3) o teste que está faltando.

Um incidente bagunçado, virando resumo. Pesado de contexto — você cola a timeline crua e deixa o Formato dar a forma:

Aja como um SRE escrevendo um postmortem sem culpados.
Situação: [cole a timeline do Slack]. O público é a liderança de eng; eles querem causa
e prevenção, não o lance a lance.
Regras: sem culpar ninguém, sem jargão que a liderança não conhece, menos de 300 palavras.
Me dê: 1) um resumo de duas linhas, 2) a causa raiz, 3) três action items com donos.

Uma decisão de arquitetura — onde você corta uma camada de propósito. Uma decisão não precisa da sua voz de escrita, então a camada de exemplo sai:

Aja como um arquiteto pragmático que já viu time se enrolar exatamente nessa escolha.
Situação: 20 mil usuários por dia, tráfego que dá picos, um time de 3 pessoas. Postgres
vs. DynamoDB pro banco principal. A gente manja de Postgres; ninguém rodou Dynamo na raça.
(Cortando a camada de exemplo — uma decisão não precisa do meu estilo de texto.)
Regras: escolha um na primeira frase; diga sua confiança e o que mudaria de ideia; se eu
estou fazendo a pergunta errada, fale isso antes.
Me dê: 1) sua escolha, 2) o argumento mais forte a favor e o mais forte contra, 3) o que
medir nos primeiros 30 dias pra saber se você acertou.

Essa última é a lição de verdade: o esqueleto é um cardápio, não uma obrigação. Corte as camadas que aquela tarefa não pede — mas nunca as que ela pede.

Deixe onde você vai pegar de verdade

Um esqueleto que você precisa caçar é um esqueleto que você não vai usar. Deixe num lugar que dá pra pegar em cinco segundos — um expansor de snippet, uma nota fixada, ou colado nas custom instructions da ferramenta (ou num CLAUDE.md no seu repo) pra que o próprio assistente te lembre do formato. Melhor ainda: mantenha uma versão já preenchida pra cada tarefa que você faz sempre — o seu prompt de review, o seu prompt de resumo de daily — pra você editar, nunca começar do zero numa caixa vazia.

Por que isso ganha de decorar truques

A estrutura vence as frases mágicas por causa de como esses modelos funcionam de verdade. A pesquisa de interpretabilidade da Anthropic mostrou que o modelo está "combinando fatos independentes pra chegar na resposta, em vez de regurgitar uma resposta memorizada" — e que ele planeja com antecedência, montando em direção a um destino em vez de escolher a próxima palavra no escuro. Não existe resposta guardada atrelada a uma palavra especial. A resposta é construída a partir do material que você entrega, então o ganho vem de entregar material melhor. É só isso que as cinco partes são: um checklist pra entregar material melhor.

Esta semana

Pegue o último prompt que te decepcionou. Não reescreva. Identifique qual das cinco partes estava faltando, adicione só ela e rode de novo. Você vai se surpreender com a frequência com que uma única linha faltando era o problema inteiro.

Fontes

• Anthropic — Claude prompting best practices
• Anthropic — Tracing the thoughts of a language model