antonio leandro

claude, na prática

Claude prompting best practices

tutorial · 03 · contexto · Anthropic · · ~35 min de leitura do original

a tese

prompt bom para o modelo passado vira bug no modelo novo: a parte que mais rende hoje é apagar instrução — anti-preguiça, prefill, budget_tokens, "verifique antes de terminar" — e não escrever mais

o que fica

  1. Instrução escrita para corrigir preguiça de modelo antigo vira overtrigger no modelo novo: "CRITICAL: você DEVE usar esta ferramenta" precisa virar "use esta ferramenta quando…".
  2. Prefill de resposta acabou: a partir dos modelos 4.6, mandar uma mensagem parcial do assistente no último turno retorna 400, e o substituto é structured outputs ou instrução direta.
  3. O budget_tokens está deprecado e retorna 400 no Claude 4.7 em diante; o controle de raciocínio migrou para o parâmetro effort com adaptive thinking.
  4. Em contexto longo o documento vai no topo e a pergunta no fim — a doc relata até 30% de ganho de qualidade em testes com entradas multidocumento.
  5. Pedir sugestão e pedir ação são prompts diferentes: "sugira melhorias" faz o modelo listar, "mude esta função" faz ele editar.
  6. A verbosidade deixou de ser uniforme na família: o Opus 5 escreve demais e não encurta via effort, enquanto o Fable 5.1 escreve de menos entre chamadas de ferramenta.

o problema

Por alguns anos a engenharia de prompt foi tratada como uma lista fixa de truques: seja específico, dê exemplos, use XML, atribua um papel, peça passo a passo. A lista funcionava porque os modelos tinham defeitos estáveis. Eles eram preguiçosos com ferramentas, então você escrevia “CRITICAL: você DEVE usar esta ferramenta”. Eles não raciocinavam sozinhos, então você pedia cadeia de pensamento explícita. Eles não conferiam o próprio trabalho, então você anexava “antes de terminar, verifique sua resposta”.

O defeito sumiu e a correção ficou. Um prompt afinado em 2024 hoje empurra o modelo para o lado oposto: ferramenta demais, subagente demais, raciocínio demais, arquivo demais. Pior, o desvio deixou de ser igual entre modelos da mesma geração — o Opus 5 responde longo por padrão, o Fable 5.1 responde curto demais em loop agêntico. Escrever um prompt só para a família virou impossível, e boa parte do que ainda circula como boa prática já não é neutra: é dívida.

a ideia

A página inverte a ordem que todo guia anterior usava. Primeiro vem a orientação por modelo, com uma tabela que aponta para a página específica de cada um e diz em uma linha o que muda ali. Só depois vêm as técnicas gerais. E há uma ressalva que vale como método: quando uma técnica cita um modelo, trate-a como medida naquele modelo e recheque nos seus próprios evals antes de aplicar em outro.

O efeito prático é que a engenharia de prompt fica subtrativa. Migrar não é acrescentar instrução nova, é caçar a instrução velha que virou incentivo perverso.

como funciona

O núcleo estável ainda cabe em pouca coisa. A regra de ouro é mostrar o prompt a um colega sem contexto: se ele se confunde, o modelo também. Explicar o motivo funciona melhor que proibir — “nunca use reticências” rende menos que “a resposta será lida por um motor de text-to-speech, que não sabe pronunciar reticências”. Exemplos: 3 a 5, relevantes, diversos, dentro de tags <example>. Tags XML para separar instrução, contexto e input. Papel no system prompt. Em contexto longo, documento no topo, pergunta no fim, e um pedido para citar trechos antes de responder.

O resto são alavancas de calibração, quase todas para segurar o modelo. Um bloco <use_parallel_tool_calls> leva a taxa de chamadas paralelas para perto de 100%; outro prompt faz o inverso, executa em sequência. <default_to_action> e <do_not_act_before_instructions> são os dois lados do mesmo botão. Há bloco pronto contra overengineering, contra criação de arquivos temporários, contra hardcode que só faz o teste passar, e contra alucinação sobre código não lido. Para trabalho longo, o padrão é sistema de arquivos como estado: tests.json estruturado, progress.txt em texto livre, git como log, e uma instrução dizendo que o contexto será compactado automaticamente para que o modelo não encerre a tarefa cedo por medo de acabar o orçamento.

Duas mudanças são de API, não de estilo. Prefill no último turno do assistente retorna 400 a partir dos modelos 4.6. E budget_tokens retorna 400 do Claude 4.7 em diante: o pensamento agora é adaptativo e a profundidade se controla por effort, com max_tokens como teto duro.

o que isso custou

O guia admite que se contradiz de propósito. O bloco que suprime markdown excessivo, útil em vários modelos, suprime estrutura necessária no Fable 5.1. O “peça para o modelo se autoverificar”, que a própria seção recomenda, deve ser removido ao migrar para o Opus 5, porque lá causa verificação em excesso. Detalhe fino demais para ser confortável: com pensamento desligado, o Opus 4.5 é sensível à palavra “think”, e a sugestão é trocar por “consider” ou “evaluate”.

Nada disso vem com número. Fora o “até 30%” da ordem em contexto longo e o “~100%” das chamadas paralelas, o texto é qualitativo, e transfere a verificação para você: rode seus evals. Também não elimina os comportamentos, só os amortece — o modelo continua propenso a subagente e a exploração excessiva, e o prompt é um amortecedor, não um interruptor. Quem tem prompt em produção paga a conta duas vezes: uma no 400 do prefill, outra na caça às instruções herdadas que agora funcionam ao contrário.

onde isso aparece hoje

É a página que costura as demais: Prompt engineering overview para o quando, Use XML tags to structure your prompts e Let Claude think para as técnicas base, Extended thinking para o parâmetro que virou legado e Structured outputs para o que substituiu o prefill. A parte agêntica remete a Tool use with Claude, Effective context engineering for AI agents e Effective harnesses for long-running agents; a orientação de recalibrar com evals próprios é o assunto de Define your success criteria.

lido na íntegra por pipeline de llm, revisado por antonio leandro antes de publicar ·