antonio leandro

claude, na prática

Prompt engineering overview

tutorial · núcleo · 01 · o básico · Anthropic ·

a tese

prompt engineering é passo de otimização, não ponto de partida: sem critério de sucesso e sem eval, reescrever prompt é trocar uma opinião por outra

o que fica

  1. Prompt engineering pressupõe três coisas: critério de sucesso definido, uma forma de testar empiricamente contra ele e um rascunho a melhorar. Sem os dois primeiros, reescrita é opinião sobre opinião.
  2. Nem toda eval que falha é problema de prompt. A própria documentação manda resolver latência e custo trocando de modelo, não reescrevendo instrução.
  3. A página não ensina nenhuma técnica: ela é um índice. Clareza, exemplos, estruturação com XML, role prompting, thinking e prompt chaining ficam no guia de best practices, tratado como referência viva.
  4. Técnica de prompt tem prazo de validade — o guia aponta para ajuste específico dos modelos mais recentes, então checklist copiado hoje envelhece na próxima versão do modelo.
  5. Quem não tem nem o primeiro rascunho pode gerar um com o metaprompt do Claude Cookbook: o ponto de partida não precisa ser escrito à mão.

o problema

Prompt engineering virou o reflexo para qualquer coisa que o modelo faz errado. Saída fora do formato, resposta longa demais, conta alta, resposta lenta: mexe no prompt. O reflexo não tem critério de parada. Sem uma definição do que conta como sucesso, cada rodada de reescrita é uma opinião discutindo com outra, e o time conclui que “melhorou” porque os dois exemplos que alguém olhou na mão ficaram melhores. Na rodada seguinte, outros dois pioram e ninguém percebe.

O segundo problema é tratar prompt como ferramenta universal. Alguns critérios simplesmente não estão no alcance do texto que você manda. Esta página abre recusando o pedido: ela assume que o leitor já tem critério de sucesso, já tem como medir contra ele e já tem um rascunho de prompt. Se não tem, o encaminhamento é sair dali e ir definir isso primeiro.

a ideia

Prompt engineering é otimização, e otimização exige função objetivo e instrumento de medida. O paralelo honesto é profiling: ninguém otimiza código sem benchmark, porque sem benchmark você não sabe se ficou mais rápido nem sabe quando parar. O prompt tem o mesmo problema, agravado por a saída ser texto — sempre dá para achar que a nova versão “leu melhor”.

O movimento da página é se posicionar como portão, não como tutorial. Ela separa dois julgamentos que costumam vir grudados: este critério está falhando e este critério se conserta pelo prompt. O segundo é uma pergunta de triagem, e a resposta às vezes é não.

como funciona

O texto faz três coisas e nenhuma delas é ensinar técnica.

Primeiro, lista os pré-requisitos: critério de sucesso claro para o caso de uso, alguma forma de testar empiricamente contra esse critério, e um primeiro rascunho de prompt para melhorar. Faltando qualquer um, o encaminhamento é o guia de definir critérios de sucesso e construir evals. Faltando só o rascunho, o encaminhamento é o notebook de metaprompt do Claude Cookbook, que gera o primeiro rascunho a partir da descrição da tarefa.

Segundo, faz a triagem. O guia declara que cobre apenas critérios controláveis por prompt engineering e dá o exemplo em que isso falha: latência e custo às vezes melhoram mais fácil escolhendo outro modelo.

Terceiro, roteia. As técnicas — clareza, exemplos, estruturação com XML, role prompting, thinking, prompt chaining — ficam todas no guia de best practices, que o texto chama de referência viva e indica como ponto de partida, inclusive para o ajuste específico dos modelos mais recentes. Para quem aprende por exemplo, há dois tutoriais interativos: um repositório no GitHub e uma versão mais leve em planilha do Google.

A escolha de arquitetura da documentação é o conteúdo aqui: um overview estável que carrega a ordem das operações, e uma página separada, explicitamente mutável, que carrega a técnica.

o que isso custou

A página delega tudo. Ela não explica nenhuma técnica, não mostra um prompt antes e depois, não dá exemplo de critério de sucesso bem escrito. O valor está na moldura; quem chega procurando o conteúdo sai com uma lista de links.

Não é um estudo. Não há número, benchmark ou comparação — nada ali é evidência de que essa ordem produz prompt melhor que reescrever no olho. É recomendação de documentação, e vale o que vale a autoridade de quem escreveu.

“Controlável por prompt engineering” fica sem definição operacional. O único exemplo dado é latência e custo, que empurram para troca de modelo. Onde exatamente está a fronteira entre reescrever o prompt e mudar de abordagem, você descobre gastando as rodadas — que é justamente o desperdício que a triagem prometia evitar.

E o conselho tem prazo. Ao apontar para ajuste específico dos modelos mais recentes e chamar o guia de técnicas de referência viva, o texto admite que o conteúdo muda sem aviso. Um checklist de prompt copiado para o wiki interno é dívida com data de vencimento na próxima versão do modelo.

onde isso aparece hoje

Os artefatos para os quais a página aponta são públicos e reusáveis fora do contexto da Anthropic: o tutorial interativo de prompt engineering no GitHub, a versão em planilha e o notebook de metaprompt no Claude Cookbook. Para quem está montando treinamento interno, é material pronto.

A consequência prática para quem escreve prompt em produção é a inversão da ordem. Antes de abrir a página de técnicas, escreva o que é sucesso e monte o teste. Depois pergunte se o que está falhando cabe no prompt. Só então reescreva — e a essa altura você tem como saber se funcionou.

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