o problema
Prompt de produção não é uma pergunta solta. É uma pilha: papel do assistente, regras da casa, três exemplos, o documento que o usuário subiu e, lá no fim, o pedido. O modelo recebe tudo isso como um bloco contínuo de texto e precisa deduzir sozinho onde acaba o exemplo e começa o dado real. Quando essa dedução falha, o erro é do tipo caro: o modelo responde sobre o exemplo em vez do input, ou devolve o formato do exemplo anterior porque não percebeu que aquele trecho era ilustração. Nada disso quebra o build. Sai uma resposta bem escrita e errada.
O caso pior é a variável interpolada. {{ANNUAL_REPORT}} no meio das suas instruções é conteúdo que você não controla, colado exatamente onde o modelo espera comando. Some a isso o prompt que cresce por sedimentação — mais uma regra aqui, mais um caso de borda ali — e você tem um texto em que instrução, dado e exemplo têm exatamente a mesma aparência tipográfica.
a ideia
Embrulhar cada tipo de conteúdo na sua própria tag: <instructions>, <context>, <input>. A analogia honesta não é schema nem parser — é nomear variável. Nada valida a tag, nada rejeita XML mal formado, não existe erro de sintaxe. O que a tag faz é dar ao modelo uma fronteira explícita e um rótulo: isto é exemplo, aquilo é documento, o de baixo é a pergunta. A documentação vende isso como redução de má interpretação em prompts que misturam instrução, contexto, exemplo e entrada variável — ou seja, em qualquer prompt de aplicação real.
A régua da página é social: mostre seu prompt para um colega com pouco contexto e peça que ele siga. Se ele ficaria confuso, o modelo também fica.
como funciona
Duas regras de uso. Nomes descritivos e consistentes entre os seus prompts. Aninhamento quando o conteúdo tem hierarquia natural — documentos dentro de <documents>, cada um dentro de <document index="n">, com metadado em subtag:
<documents>
<document index="1">
<source>annual_report_2023.pdf</source>
<document_content>
{{ANNUAL_REPORT}}
</document_content>
</document>
</documents>
Analyze the annual report. Identify strategic advantages.A ordem importa junto com a tag. Em entradas grandes, acima de 20 mil tokens, o documento vai no topo, acima da pergunta, das instruções e dos exemplos; a pergunta no fim chega a melhorar a resposta em 30% nos testes citados, sobretudo com múltiplos documentos.
A tag também serve como grampo de raciocínio. Para tarefa sobre documento longo, peça primeiro os trechos relevantes dentro de <quotes> e só depois a análise dentro de <info>: o modelo se ancora no que citou e ignora o resto. Exemplos few-shot vão em <example>, o conjunto em <examples>, de três a cinco. Dentro deles, <thinking> mostra o padrão de raciocínio que você quer que ele generalize.
Do lado da saída, a tag vira indicador de formato — pedir prosa dentro de <smoothly_flowing_prose_paragraphs> funciona melhor do que proibir markdown. E no system prompt, ela vira nome de política: os blocos de exemplo da própria Anthropic são todos assim, um comportamento por tag nomeada.
o que isso custou
A tag não obriga nada. Não existe validação, não existe garantia de que a saída venha bem formada. Quando você precisa de estrutura garantida, a documentação te manda para outro lugar: structured outputs, ou tool com campo enum para classificação. A tag XML é heurística de leitura, não contrato.
O ganho também não está quantificado. O único número da página é os 30% da pergunta no fim, e ele é sobre ordenação, não sobre a tag. Quem te vender porcentagem de melhoria por marcar <context> não tirou daqui.
Há um efeito colateral de estilo: o formato do prompt contagia a resposta. Markdown no prompt puxa markdown na saída, o que significa que sua estrutura não é neutra.
E o bloco nomeado envelhece mal entre modelos. O mesmo <avoid_excessive_markdown_and_bullet_points> que ajuda em um modelo suprime estrutura necessária no Fable 5.1, que já formata menos. Linguagem imperativa dentro da tag — “CRITICAL: You MUST” — resolvia subdisparo de ferramenta em modelos antigos e causa sobredisparo nos novos. No Opus 5 com thinking desligado, o modelo às vezes emite tags internas na saída visível: a fronteira que você desenhou vaza para o usuário.
onde isso aparece hoje
A prova está na própria página: quase todo prompt de exemplo publicado é um bloco XML nomeado. Virou o dialeto de escrita de system prompt da casa.
A remoção do prefill nos modelos 4.6 em diante — requisição com mensagem de assistente pré-preenchida no último turno devolve 400 — empurrou para cá boa parte de quem usava prefill para forçar formato ou cortar preâmbulo. As rotas de migração oficiais são structured outputs, tool calling e pedir a saída dentro de uma tag. O mesmo vale para chain-of-thought manual quando thinking está desligado: <thinking> e <answer> separando raciocínio de resposta.