Engenharia de Prompt no Claude Opus 4.6: Guia Prático

Se você já trabalha com modelos de linguagem, sabe que a diferença entre uma resposta medíocre e uma resposta excepcional está quase sempre no prompt. Com o lançamento do Claude Opus 4.6, a Anthropic elevou significativamente a capacidade de raciocínio, seguimento de instruções e geração de conteúdo estruturado. Mas para extrair o máximo desse modelo, você precisa dominar técnicas específicas de engenharia de prompt que funcionam com a arquitetura Claude — e muitas delas são diferentes do que funciona com outros LLMs.

Uso o Claude Opus como ferramenta principal de trabalho há mais de 8 meses, tanto para desenvolvimento de software quanto para produção de conteúdo técnico. O que percebi nesse período é que o Opus 4.6 responde de forma radicalmente diferente dependendo de como você estrutura a instrução. Prompts que funcionavam perfeitamente no GPT-4 ou mesmo no Claude 3.5 Sonnet produzem resultados completamente diferentes aqui — e na maioria das vezes, o Opus 4.6 entrega resultados superiores quando você entende as regras do jogo. A parte que ninguém comenta é que o modelo é extremamente literal: se você não pedir algo explicitamente, ele simplesmente não faz. Isso parece uma limitação, mas na prática é uma vantagem enorme para quem sabe escrever instruções precisas.

O que mudou no Claude Opus 4.6 em relação a versões anteriores

O Claude Opus 4.6 representa um salto qualitativo em relação às versões anteriores da família Claude. Segundo a documentação oficial da Anthropic, o modelo processa até 1 milhão de tokens de contexto, o que significa que você pode alimentá-lo com documentos extensos, bases de código inteiras e conversas longas sem perder informação. Mas o que realmente importa para engenharia de prompt são três mudanças fundamentais:

• Interpretação literal das instruções: o Opus 4.6 não tenta adivinhar o que você quer. Ele segue exatamente o que está escrito no prompt. Isso elimina comportamentos indesejados de "over-helping" que eram comuns em versões anteriores.
• Suporte nativo a pensamento estendido (extended thinking): o modelo pode raciocinar internamente antes de responder, produzindo respostas mais precisas em tarefas complexas de análise e código.
• Melhor aderência a formatos estruturados: JSON, XML, tabelas e código seguem o formato solicitado com muito mais consistência, reduzindo a necessidade de retry e parsing defensivo.

Na prática, isso significa que prompts vagos produzem resultados vagos — mas prompts bem estruturados produzem resultados excepcionais. O modelo recompensa precisão.

Estruturando prompts com XML Tags — a técnica mais eficaz

De todas as técnicas de engenharia de prompt disponíveis, a que produz os melhores resultados consistentes com o Claude Opus 4.6 é o uso de XML tags para estruturar o prompt. Conforme documentado nas melhores práticas oficiais da Anthropic, o Claude foi treinado para reconhecer e respeitar a hierarquia de tags XML como delimitadores semânticos.

Em vez de escrever um parágrafo longo com instruções misturadas, separe cada componente do prompt em tags específicas:

O motivo pelo qual XML funciona melhor que Markdown ou listas numeradas é que as tags criam fronteiras semânticas claras. O modelo sabe exatamente onde termina o contexto e onde começam as instruções, o que reduz drasticamente erros de interpretação.

Exemplo prático: prompt para revisão de código

Um prompt genérico como "revise este código e sugira melhorias" vai produzir uma resposta genérica. Compare com um prompt estruturado que especifica exatamente o que você espera:

<context>
Estou desenvolvendo uma API REST em Node.js com Express.
O código abaixo é um middleware de autenticação JWT.
Stack: Node 20, Express 4, jsonwebtoken 9.
</context>

<instructions>
Revise o código abaixo focando em:
1. Vulnerabilidades de segurança (OWASP Top 10)
2. Tratamento de erros incompleto
3. Performance em cenários de alta concorrência
</instructions>

<constraints>
- Não sugira migrar para outro framework
- Mantenha compatibilidade com Node 20
- Priorize segurança sobre legibilidade
</constraints>

<code>
// cole o código aqui
</code>

<output_format>
Para cada issue encontrada:
- Severidade: crítica / alta / média / baixa
- Linha(s) afetada(s)
- Problema
- Correção sugerida (com código)
</output_format>

A diferença de qualidade entre as duas abordagens é gritante. O prompt estruturado direciona a atenção do modelo para os aspectos que realmente importam e elimina respostas genéricas do tipo "considere adicionar mais testes".

Chain of Thought: quando e como usar pensamento estendido

O Chain of Thought (CoT) é uma técnica onde você instrui o modelo a raciocinar passo a passo antes de entregar a resposta final. No Claude Opus 4.6, essa técnica é potencializada pelo recurso de extended thinking, que permite ao modelo processar internamente antes de gerar a saída visível.

Segundo a documentação da Anthropic, o extended thinking funciona melhor com configurações adaptativas em vez de forçar manualmente um bloco de pensamento. Na prática, isso significa que para tarefas complexas — análise de bugs, decisões de arquitetura, problemas matemáticos — você deve habilitar o thinking e deixar o modelo decidir a profundidade do raciocínio.

No entanto, para tarefas simples como conversão de formato, tradução direta ou geração de boilerplate, o extended thinking adiciona latência desnecessária. A regra prática é: se a tarefa exige raciocínio multi-etapa, habilite; se é uma transformação direta, desabilite.

Quando o CoT faz diferença real

• Debugging complexo: peça ao modelo para analisar o fluxo de dados passo a passo antes de sugerir a correção
• Decisões de arquitetura: instrua-o a listar prós e contras antes de recomendar uma abordagem
• Análise de requisitos: peça para identificar ambiguidades e dependências antes de propor a solução
• Problemas de performance: solicite que trace o caminho crítico de execução antes de otimizar

Few-Shot Prompting: calibrando o formato da resposta

Few-shot prompting consiste em fornecer exemplos concretos de entrada e saída desejada dentro do prompt. No Claude Opus 4.6, essa técnica é especialmente poderosa porque o modelo é excelente em identificar padrões e replicá-los com consistência. Conforme descrito no tutorial interativo de prompt engineering da Anthropic, os exemplos devem ser realistas e específicos — não genéricos.

A técnica funciona melhor quando você precisa de um formato de saída muito específico que é difícil de descrever apenas com instruções textuais. Em vez de explicar o formato em três parágrafos, mostre dois exemplos e o modelo vai replicar o padrão.

Um erro comum é fornecer exemplos triviais demais. Se seus exemplos são simples mas o caso real é complexo, o modelo vai simplificar a resposta para corresponder ao nível dos exemplos. Sempre use exemplos que representem a complexidade real do que você precisa.

Enquadramento positivo: diga o que fazer, não o que evitar

Uma descoberta importante documentada pela comunidade de usuários do Claude é que o modelo responde significativamente melhor a instruções positivas do que a negações. Em vez de listar o que o modelo não deve fazer, descreva explicitamente o que ele deve fazer.

Outro ponto crítico: linguagem agressiva prejudica a qualidade. Frases como "CRITICAL!", "YOU MUST", "NEVER EVER" podem parecer enfáticas para humanos, mas no Claude Opus 4.6 elas causam over-triggering — o modelo fica tão focado em evitar o erro que compromete a qualidade geral da resposta. Instruções calmas e diretas produzem resultados consistentemente melhores.

Prompt Chaining: dividindo tarefas complexas em etapas

Prompt chaining é a técnica de dividir uma tarefa grande em múltiplas chamadas sequenciais ao modelo, onde cada chamada recebe o resultado da anterior como contexto. Segundo a Anthropic, essa abordagem é especialmente eficaz para tarefas que envolvem múltiplas etapas de raciocínio ou transformação.

Na prática, prompt chaining funciona como um pipeline de dados onde cada etapa tem uma responsabilidade única e bem definida. Por exemplo, para gerar documentação técnica a partir de código-fonte, você pode encadear:

• Etapa 1: analisar o código e extrair a estrutura (classes, funções, dependências)
• Etapa 2: gerar descrições para cada componente com base na análise
• Etapa 3: montar o documento final com formatação e exemplos de uso
• Etapa 4: revisar consistência e completude do documento gerado

Cada etapa produz um resultado intermediário que é mais fácil de validar e corrigir do que tentar obter o documento final em uma única chamada. Além disso, se uma etapa produzir resultado insatisfatório, você pode re-executar apenas aquela etapa sem desperdiçar tokens nas outras.

Quando usar chaining vs. prompt único

Nem toda tarefa precisa de chaining. Use prompt único quando a tarefa é autocontida e o formato de saída é simples. Use chaining quando há dependências entre etapas, quando o resultado intermediário precisa de validação, ou quando a janela de contexto de um único prompt não comporta todas as informações necessárias.

Gerenciamento de contexto em prompts longos

Com 1 milhão de tokens de contexto, é tentador simplesmente jogar toda a informação disponível no prompt e deixar o modelo se virar. Mas isso é um erro. Mesmo com janela de contexto massiva, a organização da informação impacta diretamente a qualidade da resposta.

A melhor prática é fornecer um "roteiro" no início do prompt que indica ao modelo o que ele vai encontrar e o que deve priorizar. Algo como:

<roadmap>
Este prompt contém:
1. Especificação da API (seções 1-3): contexto do projeto
2. Código atual do módulo de pagamentos (seção 4): código a ser revisado
3. Logs de erro recentes (seção 5): evidência do bug
4. Instruções de revisão (seção 6): o que você deve fazer

Priorize a seção 6 para entender a tarefa.
Use as seções 1-3 como referência quando necessário.
</roadmap>

Essa técnica de "indexação" do prompt é especialmente útil quando você está trabalhando com documentos longos ou múltiplos arquivos de código. O modelo consegue navegar melhor pelo contexto quando sabe antecipadamente o que está disponível e onde encontrar cada informação.

Prefill: controlando o início da resposta

Prefill é uma técnica avançada onde você pré-define o início da resposta do modelo. No Claude, isso é feito através do parâmetro de mensagem do assistente na API. O modelo continua a partir do ponto onde você parou, o que garante o formato exato desde a primeira linha.

Casos de uso práticos para prefill:

• Forçar formato JSON: inicie a resposta com { para garantir que o modelo retorne JSON válido
• Definir idioma: comece com uma frase no idioma desejado para evitar que o modelo responda em inglês
• Estruturar análise: inicie com o cabeçalho da primeira seção para garantir que o modelo siga a estrutura solicitada
• Eliminar preâmbulo: evite respostas que começam com "Claro, vou ajudar com isso!" ao pré-definir o início com conteúdo direto

O prefill é particularmente útil em automações e integrações via API, onde você precisa de respostas parseable que sigam um formato rígido sem variações.

Erros comuns que destroem a qualidade do prompt

Depois de meses trabalhando intensivamente com engenharia de prompt no Claude Opus 4.6, identifiquei os erros mais frequentes que levam a resultados ruins — mesmo com um modelo tão capaz:

• Instruções contraditórias: pedir "seja conciso" e "explique em detalhes" no mesmo prompt. O modelo tenta satisfazer ambos e não satisfaz nenhum.
• Falta de especificidade no formato: dizer "formate bem" sem definir o que "bem" significa. Especifique: Markdown, JSON, tabela, bullets, parágrafos.
• Excesso de restrições: cada restrição adicional reduz o espaço de solução. Inclua apenas restrições que realmente importam para o resultado.
• Contexto irrelevante: incluir informação que não é necessária para a tarefa dilui a atenção do modelo. Menos contexto relevante é melhor que muito contexto genérico.
• Não iterar: engenharia de prompt é um processo iterativo. O primeiro prompt raramente é o melhor. Teste variações, compare resultados, refine progressivamente.

Um aprendizado pessoal importante: eu costumava escrever prompts enormes com dezenas de restrições e exemplos, achando que mais contexto sempre significaria melhor resultado. Com o Opus 4.6, descobri que o oposto é verdadeiro. Os melhores prompts que uso no dia a dia têm entre 200 e 500 palavras — claros, estruturados com XML tags, com no máximo 2-3 exemplos e restrições cirurgicamente escolhidas. A qualidade do prompt está na precisão, não no volume.

Template prático para começar

Para facilitar a adoção dessas técnicas, aqui está um template que uso como ponto de partida para a maioria dos meus prompts profissionais. Adapte conforme a complexidade da tarefa:

<role>
Você é um [especialidade] com experiência em [domínio].
</role>

<context>
[Informação de fundo relevante para a tarefa]
</context>

<task>
[Descrição clara e específica do que deve ser feito]
</task>

<constraints>
- [Restrição 1]
- [Restrição 2]
</constraints>

<output_format>
[Formato exato esperado — idealmente com exemplo]
</output_format>

Esse template funciona para 80% dos casos de uso. Para tarefas mais complexas, adicione tags de <example> e <thinking_instructions>. Para tarefas simples, remova o que não for necessário — o Claude Opus 4.6 não precisa de cerimônia quando a tarefa é direta.

Conclusão

Engenharia de prompt com o Claude Opus 4.6 não é sobre truques ou hacks — é sobre comunicação clara e estruturada com um modelo que recompensa precisão. As técnicas que realmente fazem diferença são surpreendentemente simples: use XML tags para estruturar, seja específico no que quer, forneça exemplos representativos, prefira instruções positivas e itere sobre seus prompts como faria com qualquer outro artefato de engenharia. O modelo é uma ferramenta extraordinariamente poderosa, mas como qualquer ferramenta, a qualidade do resultado depende de quem a opera. Invista tempo em aprender a se comunicar com ele e os retornos serão exponenciais na sua produtividade diária.