🧬 Anatomia de mega-prompt
Mega-prompt não é "prompt comprido". É um documento técnico com componentes canônicos.
Anthropic recomenda separar com XML tags (<role>,
<context>, etc.) pra evitar que o modelo misture seções.
📐 Os 6 componentes canônicos
- Role: persona e domínio de expertise ("engenheiro Python sênior")
- Context: background do problema, empresa, usuário
- Task: instrução principal com verbo de ação claro
- Constraints: restrições (tamanho, tom, o que evitar)
- Output format: estrutura da saída (markdown, JSON, lista)
- Examples: 1-3 pares input/output esperados (k-shot)
📜 Esqueleto com XML tags
<role>
[persona e expertise]
</role>
<context>
[background, situação, restrições do ambiente]
</context>
<task>
[verbo de ação + objetivo]
</task>
<constraints>
- [restrição 1]
- [restrição 2]
</constraints>
<output_format>
[estrutura esperada]
</output_format>
<examples>
[1-3 pares input/output]
</examples>✓ Cada componente protege contra
- ✓Role: tom genérico, falta de autoridade técnica
- ✓Context: suposições erradas, alucinação
- ✓Task: ambiguidade no entregável
- ✓Constraints: saída fora do escopo
- ✓Output: formato que quebra downstream
- ✓Examples: estilo e tom indefinidos
📌 Por que XML tags > markdown
- Anthropic treina Claude pra reconhecer XML como separador estrutural
- Markdown pode se confundir com conteúdo do usuário
- XML deixa explícito onde uma seção começa e termina
- Funciona melhor com inputs grandes (contratos, código)
⚖️ Quando vale escrever mega vs simples
A regra dos 10 usos: se vai usar mais de 10 vezes OU se outra pessoa vai usar, escreva mega-prompt. Pra exploração ad-hoc ou uso pessoal pontual, prompt simples basta. Sem critério claro, gente sobre-investe e sub-investe ao mesmo tempo.
✓ Vale escrever mega-prompt
- ✓Tarefa repetida em produção (cache hit 80-95%)
- ✓Saída alimenta sistema downstream (JSON, código)
- ✓Múltiplos usuários, mesmo fluxo
- ✓Consistência é requisito (jurídico, marca, compliance)
- ✓Vai virar Cowork project ou system prompt persistente
✗ Prompt simples basta
- ✗Exploração ad-hoc, uso pessoal pontual
- ✗Tarefa única sem reuso
- ✗Contexto radicalmente diferente a cada input
- ✗"Brainstorm me dá 5 ideias"
- ✗Pergunta única que cabe em uma frase
📊 Investimento × retorno
- Escrever mega-prompt: 30-60 min de pensamento estruturado
- Custo de manter: zero — uma vez bom, fica bom
- Ganho por uso (após o 10º): 3-5x menos retrabalho, output consistente, cache hit
- ROI claro a partir do 10º uso; spettacolare a partir do 50º
💡 Dica prática
Mantenha uma pasta de mega-prompts versionados em markdown. Cada um com nome descritivo (revisao-pr.md,
extracao-contrato.md). Vira biblioteca pessoal — e patrimônio.
💸 ROI com prompt caching (60-90% economia)
O multiplicador escondido. Mega-prompt sem caching já é melhor que prompt ruim. Mega-prompt com caching tem ROI maior que qualquer outra otimização.
💵 Mecânica do caching
Multiplicadores sobre o preço de input padrão:
Cache write (5 min): 1.25x → +25% no write
Cache write (1 hora): 2.00x → +100% no write
Cache read (hit): 0.10x → -90% por leitura
Break-even:
Cache 5 min: paga após 1 leitura
Cache 1 hora: paga após 2 leituras
Em produção real:
System prompt fixo → cache hit 80-95%
Economia efetiva → 60-90% no input🧮 Exemplo numérico: chatbot de suporte
- System prompt mega: 50k tokens (mesmo em toda chamada)
- 1000 chamadas/dia, modelo Sonnet 4.6 ($3/MTok input)
- Sem caching: 1000 × 50k × $3/M = $150/dia só no system prompt
- Com caching (cache hit 90%): ~$22/dia
- Economia: $128/dia = $3,8k/mês — só de caching
✓ Como estruturar pra cachear bem
- ✓System prompt fixo (não varia entre chamadas)
- ✓Conteúdo variável só no user turn
- ✓Cache breakpoint após examples grandes
- ✓Cache de 1h pra workloads contínuos
✗ Padrões que matam cache hit
- ✗Timestamp/data no system prompt (muda hash)
- ✗User context misturado no system
- ✗Conteúdo dinâmico antes do estável
- ✗Reescrever prompt a cada deploy
🚧 7 erros típicos catalogados
Taxonomia de prompt defects baseada em pesquisa acadêmica (arxiv 2509.14404) e literatura aplicada. Reconhecer o defeito pelo sintoma corta tempo de debug em 80%.
Vague task
Sintoma: resposta genérica, cobre tudo superficialmente. Causa: verbo de ação ausente ("fale sobre X").
Missing context
Sintoma: suposições erradas, alucinação de premissas. Causa: modelo não sabe pra quem, pra quê, em que situação.
No output spec (#1 mais custoso em produção)
Sintoma: output varia a cada run, não integra com sistemas. Causa: sem formato, tamanho ou estrutura definidos.
Role mixing
Sintoma: conflito de objetivos, resultado confuso. Causa: persona misturada com instrução ("você é um especialista, escreva um email").
Overloaded single prompt
Sintoma: tarefa fácil recebe atenção, difícil é negligenciada. Causa: muitas tarefas num prompt ("faça X, depois Y, e também Z").
No examples
Sintoma: estilo, tom e formato variam. Causa: instruções sem calibração k-shot.
Contradiction
Sintoma: modelo escolhe arbitrariamente o que seguir. Causa: instrução que se anula ("seja breve mas detalhe tudo").
💡 Dica prática
Ao debugar prompt, rode o sintoma na taxonomia. "Output varia entre runs" → defeito #3, no output spec. "Resposta cobre tudo superficialmente" → defeito #1, vague task. Soluções óbvias quando você sabe o nome do defeito.
👁️ Exemplo lado-a-lado: revisão de código
A diferença fica óbvia quando você vê os dois prompts e os outputs que cada um produz.
✗ Prompt ruim
Revise esse código Python e me diga
o que está errado.Sem role → tom genérico. Sem context → sugestões irrelevantes (ex: "use async" sem saber da RAM). Sem output spec → 80% do output em nitpicks de estilo. Inútil pra ticket de issue.
✓ Mega-prompt
<role>
Engenheiro sênior Python, especialista em
performance e segurança de APIs REST.
</role>
<context>
Endpoint Flask em produção, ~10k req/dia,
container 512MB RAM.
</context>
<task>
Revise o código e produza relatório
estruturado de problemas.
</task>
<constraints>
- Foco: bugs, segurança, performance
- Ignore: estilo cosmético
- Não reescreva, só aponte
</constraints>
<output_format>
Por problema:
- Severidade: CRITICAL/HIGH/MEDIUM/LOW
- Linha(s) afetadas
- Descrição
- Risco concreto
</output_format>🎯 Por que o mega ganha
- Role: ativa o domínio correto, não um generic "assistente"
- Context: evita sugestões irrelevantes (não sugere async com RAM limitada)
- Constraints: poda nitpicks de estilo que comem 80% do output
- Output format: resultado vira ticket de issue tracker sem reformat
📄 Exemplo lado-a-lado: extração de contrato
Caso clássico de saída que alimenta sistema downstream. Sem output spec rigoroso, parsing quebra em produção.
✗ Prompt ruim
Extraia as informações importantes
desse contrato."Importantes" é subjetivo. Output varia: às vezes prosa, às vezes lista, às vezes tabela. Em produção, o parser quebra. Modelo pode "adivinhar" campos ausentes — erro silencioso.
✓ Mega-prompt
<role>
Analista jurídico, contratos de
prestação de serviços de TI no Brasil.
</role>
<task>
Extraia os campos listados. Se campo
não estiver presente, retorne null.
</task>
<constraints>
- Não interprete, não infira — só
extraia texto literal
- Datas em ISO 8601 (YYYY-MM-DD)
- Valores em centavos (int) + moeda
</constraints>
<output_format>
JSON com schema:
{
"partes": {"contratante": str,
"contratada": str},
"objeto": str,
"valor_total": {"centavos": int,
"moeda": "BRL"},
"prazo_inicio": "YYYY-MM-DD" | null,
"prazo_fim": "YYYY-MM-DD" | null,
"clausula_multa": str | null,
"foro": str | null
}
</output_format>🎯 Por que esse mega salva produção
- JSON determinístico: vai direto pro banco sem parsing adicional
- "Não interprete": evita o modelo "adivinhar" campos ausentes — fonte de erros silenciosos
- null explícito: sistema downstream sabe distinguir "ausente" de "vazio"
- Formatos canônicos: ISO 8601, centavos — sem parsing de moeda/data
💡 Dica prática
Em prompts que alimentam banco, defina o schema antes do prompt. Pense como contrato de API. Output que quebra parser em produção é o erro mais caro do catálogo.
📋 Resumo do Módulo
Próximo Módulo:
2.6 — 🧭 IA é direção, não mágica (caso Replit, humano-no-loop, e como sair do palco)