Principais destaques
- Menos regras, mais intenção: modelos mais recentes do Claude lidam melhor com instruções curtas, claras e contextualizadas do que com listas intermináveis de comandos.
- “Não faça isso” perdeu força: dizer diretamente qual resultado você quer tende a funcionar melhor do que acumular restrições negativas sobre o que o modelo deve evitar.
- Autonomia ganhou um novo caminho: o comando
/goal permite definir um estado final verificável para que o Claude continue trabalhando até atingir o objetivo ou chegar ao limite de turnos.
Durante anos, uma espécie de receita dominou o prompting: escreva tudo em detalhes, enumere cada etapa, mande o modelo revisar o próprio trabalho e crie uma longa lista de coisas que ele jamais deveria fazer.
Só que os modelos ficaram melhores.
E isso cria um problema curioso: algumas técnicas que antes ajudavam podem agora atrapalhar.
A nova orientação da Anthropic para o Claude parte justamente dessa mudança. Em vez de tentar controlar cada movimento do modelo, a ideia é explicar a intenção, o contexto e o resultado esperado.
É menos “faça exatamente estas 17 coisas nesta ordem” e mais “este é o problema, este é o motivo e é assim que saberemos que terminou”.
Por que a receita antiga começou a envelhecer? 🔄
A mudança acompanha a evolução dos próprios modelos.
Modelos mais antigos precisavam de mais orientação explícita. Instruções passo a passo, pedidos para verificar novamente cada resultado e extensas listas de “faça” e “não faça” podiam funcionar como uma espécie de corrimão.
Os modelos mais recentes têm maior capacidade de interpretar contexto e fazer julgamentos por conta própria.
🧠 A virada é esta: quanto mais capaz fica o modelo, menos sentido faz tentar transformar o prompt em um manual de operação completo.
Isso não significa simplesmente “escreva menos”. Significa escreva melhor.
Uma instrução precisa transmitir o que realmente importa, em vez de gastar espaço descrevendo cada possibilidade imaginável.
Mandar o Claude “revisar tudo” pode piorar o resultado? 🔎
Essa talvez seja uma das mudanças mais contraintuitivas.
Era comum colocar no final de um prompt algo como: “antes de concluir, revise cuidadosamente todo o trabalho e confira cada número”.
A recomendação atual da Anthropic para os modelos mais recentes é abandonar esse tipo de verificação explícita em muitos casos.
O motivo é simples: esses modelos já fazem verificações internas.
Adicionar uma segunda ordem para que eles “dupliquem a checagem” pode criar uma nova passagem de trabalho, tornando a resposta mais lenta e potencialmente levando o modelo a questionar ou contradizer algo que já havia produzido corretamente.
💡 A ideia mudou: em vez de pedir ao modelo que pense sobre o próprio processo o tempo todo, defina claramente o resultado que precisa ser alcançado.
É uma diferença pequena na redação, mas grande na filosofia do prompt.
E aquele velho “não faça isso”? 🚫
Outro hábito que perde espaço é a dependência de instruções negativas.
- “Não use bullets.”
- “Não escreva frases longas.”
- “Não coloque reticências.”
- “Não faça uma introdução.”
O problema é que cada uma dessas frases diz ao modelo o que evitar, mas não necessariamente explica o que deveria ocupar aquele espaço.
Uma alternativa mais direta seria:
✍️ Dê um alvo positivo: em vez de “não use bullet points”, diga “escreva em parágrafos corridos”.
Em vez de apenas proibir reticências, explique o motivo quando ele for relevante: se o texto será convertido em áudio por um sistema de texto para fala, por exemplo, essa informação ajuda o modelo a entender que o problema não é apenas aquele sinal específico.
A justificativa cria uma regra mais ampla.
E isso importa porque o Claude pode encontrar uma situação que você nunca imaginou ao escrever o prompt.
Por que explicar o motivo funciona melhor? 💡
Imagine uma instrução dizendo:
“Nunca use reticências.”
Ela é específica, mas limitada.
Agora acrescente o contexto: as reticências não devem ser usadas porque o texto será lido por um mecanismo de conversão de texto em fala que pode interpretá-las inadequadamente.
O modelo passa a ter uma razão para a regra.
Isso permite que ele faça uma inferência: outros recursos de formatação que prejudicarem a leitura em voz alta também podem precisar ser evitados.
É a diferença entre entregar uma lista de proibições e explicar o princípio que está por trás dela.
🗣 A regra de ouro da Anthropic: se um colega que não conhece o projeto receber seu prompt e ficar sem entender o que fazer ou por quê, há uma boa chance de Claude também ficar confuso.
Esse teste simples ajuda a identificar prompts excessivamente rígidos.
Então, como deveria ser um prompt em 2026? 🧩
A orientação atual pode ser condensada em quatro hábitos.
| Abordagem | Tendência atual |
|---|---|
| Instruções negativas | Diga diretamente o resultado desejado |
| Procedimentos rígidos | Explique a intenção e o contexto |
| Regras sem justificativa | Mostre por que a regra existe |
| “Master prompts” gigantes | Use instruções curtas e claras |
A estrutura também pode ser mais leve.
Um bom ponto de partida é incluir três elementos:
• A tarefa: o que precisa ser feito e para quem.
• A necessidade: qual problema o trabalho precisa resolver.
• O resultado final: como será possível reconhecer que o trabalho está concluído.
O restante só deveria entrar quando realmente acrescentar informação.
O problema dos prompts que parecem contratos 📜
Existe uma tentação natural de transformar preferências em regras.
Uma regra para títulos. Outra para parágrafos. Outra para tom. Mais cinco para formatação. Depois exceções para as regras anteriores.
No fim, o prompt vira praticamente um contrato de 200 linhas.
A orientação atual vai na direção contrária.
⚠️ Se uma regra está sendo ignorada, não presuma imediatamente que precisa repeti-la em letras maiores.
Pode ser justamente o tamanho do conjunto de instruções que está prejudicando a execução.
Modelos mais recentes tendem a responder melhor a instruções curtas e claras do que a enormes arquivos com dezenas de restrições.
E existe outro detalhe: expressões de urgência e importância excessiva também podem produzir reações indesejadas. Se algo é realmente importante, vale mais explicar o motivo do que repetir que aquilo é “CRÍTICO”, “OBRIGATÓRIO” ou “MUITO IMPORTANTE”.
E o /goal? Aqui a história fica mais interessante ⚙️
Para quem trabalha com sessões longas e tarefas relativamente objetivas, Claude ganhou uma possibilidade particularmente interessante: o comando /goal.
A lógica é diferente de simplesmente dizer “continue trabalhando até terminar”.
Você define um estado final mensurável, explica como esse estado pode ser comprovado e, opcionalmente, determina um limite de turnos.
Um formato básico é:
/goal [estado final mensurável]
Prove it by: [critérios de verificação, mostrando o resultado]
Constraints: stop after [n] turnsDepois de cada turno, um modelo separado avalia a conversa e determina se o objetivo foi alcançado.
Há três possibilidades:
1️⃣ Ainda não atingiu: Claude recebe a indicação e continua trabalhando.
2️⃣ Atingiu: a sessão pode ser encerrada.
3️⃣ Parou pelo limite: quando um limite de turnos foi definido, a execução pode terminar por essa restrição.
A separação entre quem executa e quem verifica é uma parte importante do desenho.
O modelo responsável pelo trabalho não é simplesmente quem decide sozinho que já acabou.
Quando deixar Claude trabalhar sozinho faz sentido? ☕
A abordagem é mais adequada quando “pronto” pode ser comprovado objetivamente.
Imagine uma tarefa de desenvolvimento em que o resultado esperado é uma aplicação funcionando de ponta a ponta e disponível em uma URL.
Nesse caso, existe algo concreto para verificar.
Já em uma tarefa criativa aberta, a situação muda. Como determinar mecanicamente se um conto, uma campanha ou uma identidade visual chegou ao ponto exato de “concluído”?
Fica muito mais subjetivo.
🔧 O melhor encaixe do /goal está nas tarefas repetíveis e verificáveis, especialmente quando há um critério operacional claro de sucesso.
Há também uma condição prática: a execução autônoma precisa funcionar em um modo que não interrompa o processo a cada etapa para pedir autorização manual. Caso contrário, a pessoa continua tendo de supervisionar cada movimento, reduzindo justamente a vantagem da autonomia.
E os Projects? Menos “Frankenstein”, mais foco 🗂️
A mesma lógica vale para os Projects do Claude.
Um projeto reúne instruções, arquivos de referência, memória e tarefas agendadas. Isso pode ser extremamente útil, mas também cria um risco: colocar tudo dentro do mesmo projeto.
Trabalho de cliente, produção de conteúdo, programação e assuntos pessoais, por exemplo, podem exigir contextos completamente diferentes.
Por isso, uma das recomendações é organizar um projeto por fluxo de trabalho, em vez de criar um único espaço gigantesco para tudo.
Quanto mais claramente definido o contexto, menor a chance de instruções de uma atividade contaminarem outra.
Seu Project também não precisa de um manual de 300 linhas 📚
A recomendação se repete aqui: mantenha as instruções principais curtas.
Se há preferências de voz, estilo ou procedimentos específicos, elas podem ficar em arquivos de referência separados, em vez de transformar o conjunto principal de instruções em um documento interminável.
Isso também facilita a manutenção.
Uma mudança no estilo não precisa obrigatoriamente exigir a reconstrução de todo o sistema de instruções.
🛠️ E existe um atalho: em vez de tentar descobrir sozinho quais instruções escrever, deixe o próprio Claude entrevistá-lo.
A ideia é fazer o modelo perguntar sobre seu papel, objetivo do projeto, público, voz, procedimentos e outras informações relevantes.
O resultado tende a ser mais próximo das necessidades reais do trabalho do que tentar imaginar, de uma vez, todas as regras que você gostaria de colocar no prompt.
No fim, prompting virou menos “programação” e mais briefing 🎯
A mudança mais interessante talvez seja essa.
Um prompt moderno não precisa prever cada movimento do modelo.
Precisa transmitir intenção suficiente para que o modelo tome boas decisões quando aparecer algo que você não previu.
Isso também explica por que justificar uma regra pode ser mais poderoso do que simplesmente adicioná-la à lista.
Se o modelo entende o motivo, consegue aplicar o princípio em situações novas.
Se recebe apenas uma proibição, precisa lembrar daquela proibição específica.
E quanto maior fica a lista, maior fica também a chance de alguma instrução se perder no meio do caminho.
O que fica para quem escreve prompts hoje? 🤔
A velha mentalidade era algo próximo de: “Como faço o modelo obedecer exatamente ao que escrevi?”
A abordagem mais recente é outra: “Como explico o trabalho de maneira que o modelo entenda o que realmente importa?”
Isso muda a construção desde a primeira linha.
- Menos procedimento artificial.
- Mais contexto.
- Menos “não faça”.
- Mais resultado desejado.
- Menos pedido para conferir novamente cada detalhe.
- Mais definição objetiva de quando a tarefa terminou.
E, quando o trabalho permitir, um objetivo que possa ser verificado automaticamente.
No passado, um prompt enorme parecia uma forma de controlar a IA. Agora, ele pode acabar funcionando como um congestionamento: há tanta sinalização na estrada que fica mais difícil enxergar para onde realmente se deve ir.
A pergunta para 2026 talvez não seja mais “quantas regras cabem no meu prompt?”, mas sim: “se eu sumisse depois de apertar Enter, Claude saberia exatamente o que significa terminar?”
