Boas Práticas para o Claude Opus 4.7

A maioria das pessoas atualiza para o Opus 4.7 da forma preguiçosa. Mudam o ID do modelo e continuam a trabalhar exatamente como faziam no Opus 4.6.

Fica muita coisa na mesa.

A orientação da Anthropic para o Opus 4.7 é subtil mas importante: o modelo pensa mais a níveis de esforço mais altos, é mais seletivo em relação a chamadas de ferramentas e subagentes, lê as instruções de forma mais literal, e trabalha melhor quando o tratas como um engenheiro capaz a quem estás a delegar, e não como um par de programação que tu guias a cada trinta segundos.

Esta página é a versão prática desse conselho. Combina a orientação de lançamento da Anthropic, a documentação do Claude Code, e os padrões que importam em workflows de engenharia reais.

Para o breakdown do lançamento, vê Claude Opus 4.7. Para exemplos específicos por domínio, vê casos de uso do Claude Opus 4.7.

Ganho Rápido

Se queres um hábito imediatamente melhor com o Opus 4.7, usa isto:

Here is the task, the constraint set, the files that matter, and the definition of done.
Do the full job, validate before you report back, and call out missing information instead of guessing.

Esta mudança importa porque o Opus 4.7 trabalha melhor quando a primeira mensagem lhe dá espaço suficiente para pensar, planear e executar sem precisar de cinco correções a seguir.

1. Trata o Opus 4.7 como um Delegado, não como Pair Programmer

Esta é a mudança de mentalidade mais importante.

Os workflows antigos de codificação eram muitas vezes assim:

1. dás um prompt vago
2. esperas por uma tentativa parcial
3. acrescentas mais uma clarificação
4. corriges a abordagem
5. acrescentas mais uma restrição

Este estilo é caro no Opus 4.7 porque cada nova mensagem do utilizador acrescenta overhead de raciocínio e coloca o modelo num loop mais interativo do que ele realmente quer para trabalho difícil.

O padrão melhor é:

1. descreve o trabalho claramente na primeira mensagem
2. inclui as restrições reais e os critérios de aceitação
3. deixa o modelo avançar mais no trabalho antes de interromper
4. revê o resultado num checkpoint significativo em vez de microgerir cada passo

Primeira mensagem má:

Help me fix auth.

Primeira mensagem boa:

Fix the OAuth redirect loop where successful login returns users to /login instead of /dashboard.

Constraints:
- keep the existing session format
- do not change provider configuration
- update tests if needed

Relevant areas:
- src/lib/auth.ts
- src/middleware.ts
- app/login/*

Definition of done:
- login succeeds
- user lands on /dashboard
- no redirect loop
- tests pass

Isto não é teatro de prompt engineering. É simplesmente um melhor handoff.

2. Coloca Tudo na Primeira Mensagem

O post de boas práticas da Anthropic sobre o Opus 4.7 volta sempre a este ponto: se o trabalho é real, dá ao modelo o brief completo logo no início.

A primeira mensagem deve geralmente incluir:

• a tarefa em concreto
• como é o sucesso
• o que não pode mudar
• quais ficheiros, serviços ou diretórios são relevantes
• quaisquer referências ou padrões existentes a seguir
• como o resultado deve ser validado

Estás a tentar eliminar dois modos de falha:

• sub-especificação: o modelo tem de adivinhar o que quiseste dizer
• correção turn a turn: o modelo continua a pagar o custo de raciocínio para incorporar correções que deviam ter estado no brief original

Boa estrutura:

Task:
[what to build, fix, review, or investigate]

Constraints:
- [what must stay true]
- [what must be avoided]

Relevant context:
- [files, routes, services, tickets, docs]

Definition of done:
- [observable outcome]
- [verification step]

Este padrão funciona para codificação, revisão, segurança, documentação e trabalho multimodal.

3. Usa xhigh como Padrão, não max

O Opus 4.7 adicionou um novo nível de esforço xhigh e o Claude Code moveu o padrão para lá por uma razão.

O xhigh é o melhor padrão para a maioria do trabalho de codificação sensível à inteligência porque captura a maior parte do upside do raciocínio mais profundo sem o pior comportamento de "pensamento descontrolado" que o max pode desencadear em tarefas longas.

Regra prática:

Se não tiveres a certeza, começa no xhigh.

Desce para high quando:

• estás a correr várias sessões ao mesmo tempo
• a tarefa é difícil mas não crítica
• queres melhor controlo de despesa

Sobe para max apenas quando:

• a tarefa é invulgarmente difícil
• o custo de errar é alto
• precisas mesmo do teto do modelo, não apenas "provavelmente melhor"

O erro comum é deixar o max ligado porque parece mais seguro. Geralmente não é. Muitas vezes apenas torna o modelo mais lento e mais verboso do que o necessário.

4. Indica a Quantidade de Raciocínio que Queres

O Opus 4.7 usa pensamento adaptativo, o que significa que o modelo decide quando pensar mais e quando avançar rapidamente. Geralmente é bom. Ainda é orientável.

Quando queres mais raciocínio:

This problem is subtle. Think carefully and step by step before acting.
Verify assumptions before you edit anything.

Quando queres menos raciocínio:

Prioritize a direct answer over deep reasoning.
Be concise and only inspect additional files if necessary.

Usa isto com parcimónia. Não empilhes doze meta-instruções. Uma ou duas linhas chegam.

Bons casos de uso para mais raciocínio:

• mudanças de arquitetura
• migrações
• revisão de código
• análise de segurança e risco
• investigações com evidências incompletas

Bons casos de uso para menos raciocínio:

• uma edição específica num ficheiro que já nomeaste
• perguntas rápidas de referência
• refactors mecânicos simples

5. Diz ao Opus 4.7 Quando Usar Ferramentas

A Anthropic diz explicitamente que o Opus 4.7 usa ferramentas menos frequentemente por padrão e raciocina mais antes de agir. Geralmente é uma melhoria. Também significa que o modelo pode inspecionar menos do que esperas, a não ser que o digas.

Se queres uma investigação agressiva, diz-o.

Em vez de:

Review this service for bugs.

Usa:

Review this service for bugs.
Read the relevant implementation files before concluding.
Use search and file reads aggressively where needed.
Do not rely on assumptions if you can verify them from the codebase.

Isto importa para:

• revisão de código
• debugging
• revisão de segurança
• investigação de codebases grandes
• escrita baseada em fontes

O modelo não é "mau com ferramentas" agora. É simplesmente mais seletivo. Dá-lhe a política que queres.

6. Diz-lhe Quando Usar Subagentes

A Anthropic também diz que o Opus 4.7 cria menos subagentes por padrão. Novamente, geralmente é racional. Não é sempre o que queres.

Se o trabalho beneficia de paralelismo, diz-o na primeira mensagem.

Exemplo:

Use subagents when the work naturally splits.
Spawn multiple subagents in the same turn when fanning out across independent files or domains.
Do not spawn a subagent for work you can complete directly in one response.

Boas alturas para forçar paralelismo:

• rever vários ficheiros independentes
• comparar vários docs ou logs
• auditar domínios diferentes separadamente: frontend, backend, base de dados
• ler a codebase em paralelo antes de implementar

Más alturas para forçar paralelismo:

• uma correção num único ficheiro
• edições fortemente acopladas
• tarefas onde o output do passo B depende do passo A

O Opus 4.7 é mais criterioso por padrão. Tudo bem. Ainda precisas de especificar a tua política de orquestração quando o workflow depende disso.

7. Reduz as Mensagens em Trabalho Interativo

Esta é uma das recomendações mais claras da Anthropic e uma das mais fáceis de ignorar.

Cada mensagem extra acrescenta overhead. Se estás a trabalhar interativamente, agrupa as tuas perguntas e correções em vez de as dar aos pingos.

Mau:

Actually change the schema too.

depois:

Also update tests.

depois:

Do not touch the billing UI.

Melhor:

Update the auth flow and schema, update tests, but do not modify the billing UI.
Keep the session format unchanged.

Isso não significa "nunca interrompas." Significa interromper em pontos úteis, não a cada poucos segundos.

8. Usa o Modo Auto Apenas com um Brief Sólido

O modo auto e o Opus 4.7 são uma combinação forte para tarefas longas, mas apenas quando o âmbito é claro.

O modo auto faz mais sentido quando:

• a tarefa é bem especificada
• a repo ou o ambiente é familiar
• confias na direção geral
• queres menos interrupções de permissão

O modo auto é um mau encaixe quando:

• a tarefa toca produção ou infraestrutura partilhada
• o objetivo ainda é vago
• esperas muitas decisões de julgamento humano
• o ambiente em si não é de confiança ou é desconhecido

A sequência que funciona:

1. escreve um bom brief na primeira mensagem
2. verifica que o plano parece sensato
3. muda para modo auto para execução se a tarefa for bem delimitada

Não uses o modo auto para compensar um brief fraco. Isso apenas deixa o modelo mover-se mais depressa na direção errada.

9. Elimina o Atrito de Permissões em vez de Clicar Sempre

Uma das melhores dicas de lançamento de Boris Cherny para o Opus 4.7 foi operacional, não ao nível do modelo: se o modelo vai correr por mais tempo e de forma mais autónoma, o workflow antigo de permissões torna-se o bottleneck.

Há dois remédios limpos:

Modo auto para trabalho bem delimitado

Se a tarefa é clara e o ambiente é de confiança, o modo auto remove a maior parte do loop "aprovar, aprovar, aprovar" enquanto mantém verificações de segurança em background.

Bom encaixe:

• refactors longos numa repo familiar
• trabalho de implementação com uma definição clara de done
• investigações onde confias na direção geral

Mau encaixe:

• ambientes desconhecidos
• trabalho sensível de produção
• tarefas vagas onde o modelo ainda precisa de muita orientação

Para as mecânicas em maior detalhe, vê Claude Code Auto Mode e a documentação oficial de modos de permissão.

/fewer-permission-prompts para comandos seguros repetidos

Boris também destacou uma nova skill /fewer-permission-prompts. A ideia é simples: analisa o que o Claude tem sido repetidamente bloqueado de fazer, depois transforma os comandos obviamente seguros e repetitivos em regras de permissão explícitas em vez de clicar neles para sempre.

Este é um workflow muito melhor do que qualquer um dos extremos:

• aprovar manualmente o mesmo comando inofensivo 20 vezes
• saltar diretamente para modo de bypass total

O objetivo certo não é "sem segurança." É "menos interrupções inúteis."

10. Usa Recaps e Modo Foco em Execuções Longas e Autónomas

O Opus 4.7 trabalha melhor quando o deixas correr. Isso torna dois hábitos ao nível da UI muito mais valiosos.

Recaps

O Claude Code lançou recaps na versão 2.1.108, mesmo antes do Opus 4.7. Boris destacou-os por uma razão: se voltas a uma sessão longa depois de dez minutos ou duas horas, um recap curto é melhor do que tentar reconstruir o estado a partir do scrollback.

Os recaps são especialmente úteis quando:

• colocas uma tarefa em background
• voltas a uma sessão mais tarde no dia
• uma execução longa tocou em muitos ficheiros ou fases
• queres o resumo "o que aconteceu / o que vem a seguir" rapidamente

Pensa nos recaps como re-entrada de sessão, não apenas sumarização.

Modo foco

Boris também destacou o novo modo foco na CLI. O timing faz sentido: uma vez que confias no Opus 4.7 para investigar, editar e verificar de forma mais independente, o detalhe do transcript pode tornar-se ruído visual.

O modo foco é útil quando:

• te importas mais com o resultado final do que com o transcript ao vivo
• o modelo está a correr uma longa sequência de comandos corretamente
• queres rever o estado final, não assistir a cada ação intermédia

Esta é uma mudança de workflow que vale a pena fazer. Modelos mais fortes movem o bottleneck de "consegue fazer o trabalho?" para "quanto do trabalho preciso mesmo de observar?"

11. Configura o Esforço de Forma Deliberada

O thread de Boris também reforçou algo que a documentação da Anthropic agora deixa muito mais claro: trata o esforço como um controlo de primeira classe, não como uma configuração escondida.

Regra prática:

• esforço menor para respostas rápidas e menor despesa
• esforço maior para trabalho de engenharia e revisão mais difíceis
• não assumas que "esforço máximo" é sempre o melhor workflow

Isso importa mais no Opus 4.7 porque o pensamento adaptativo permite ao modelo escalar muito mais naturalmente do que o estilo antigo de orçamento fixo.

Mantém estes padrões:

• low ou medium para edições rápidas e Q&A leve
• high quando queres um tier de trabalho mais barato mas ainda capaz
• xhigh para engenharia séria do dia a dia
• max para tarefas genuinamente difíceis onde o custo de errar é alto

Se ignorares o esforço, estás a deixar um dos maiores controlos do Opus 4.7 por usar.

12. Começa uma Nova Sessão Quando a Tarefa Muda

O Opus 4.7 tem uma janela de contexto de 1M tokens. Isso não significa que deves manter cada trabalho numa sessão imortal.

A própria orientação de gestão de sessões da Anthropic é simples: quando a tarefa muda, começa uma nova sessão.

Usa a sessão atual quando:

• o próximo passo é parte da mesma tarefa
• o contexto atual ainda é relevante
• reler os mesmos ficheiros seria um desperdício

Começa uma nova sessão quando:

• estás a mudar para uma tarefa diferente
• a sessão acumulou várias abordagens falhadas
• já corrigiste o modelo duas ou três vezes
• o contexto agora contém mais ruído do que sinal

Usa as ferramentas de forma agressiva:

• /clear para tarefas não relacionadas
• /rewind quando o último ramo de trabalho estava errado
• /compact em milestones naturais, não a meio de debugging frágil
• subagentes para investigação, para que o thread principal fique limpo

O contexto grande ajuda. A corrupção de contexto ainda é real.

13. Dá ao Opus 4.7 um Harness de Verificação

Este ponto ficou claro no thread de Boris e alinha-se com a própria orientação da Anthropic: se queres o maior salto do Opus 4.7, dá-lhe uma forma de verificar se realmente teve sucesso.

Um dos melhores traços do Opus 4.7 é que está mais disposto a verificar o seu próprio trabalho. Ajuda-o.

Acrescenta linguagem de validação explícita:

Before you report done:
- verify assumptions you relied on
- run the relevant tests
- check the final changed files for consistency
- list remaining risk, if any

Isto é especialmente importante para:

• migrações
• mudanças de auth
• correções de concorrência
• revisão de segurança
• análise baseada em documentos

O modelo verifica mais o seu próprio trabalho do que versões anteriores. Ainda queres que "concluído" signifique algo concreto.

Exemplos concretos de um harness de verificação:

• trabalho de backend: um comando de teste, verificação curl, ou build tipada
• trabalho de frontend: uma verificação no browser, diff de screenshot, ou lint/build a passar
• refactors: compilar + testar + grep pela superfície antiga da API
• docs ou conteúdo: uma checklist de afirmações a verificar contra o material fonte

Sem um caminho de verificação, mais autonomia significa principalmente mais execução não verificada. Com um, torna-se autonomia útil.

14. Usa Task Budgets para Execuções Longas

A Anthropic introduziu task budgets como beta público porque trabalho agêntico mais longo precisa de um orçamento visível pelo modelo, não apenas um hard cap de output que ele não consegue ver.

Se corres agentes ou workloads de API, testa task budgets em:

• refactors mais longos
• trabalhos de pesquisa + implementação
• automação em background
• loops de revisão e reparação de código

A melhor prática não é "usa sempre o maior orçamento." É:

• dá ao modelo espaço suficiente para terminar
• mantém o orçamento finito
• mede quais classes de trabalho realmente precisam de mais

Isto torna-se mais importante no Opus 4.7 porque o modelo gosta de gastar mais pensamento em esforços mais altos em execuções difíceis.

15. Ajusta para a Realidade dos Tokens, não para o Preço de Marketing

O Opus 4.7 manteve o preço de lista do Opus 4.6. Isso não significa que o teu workload custa o mesmo.

O teu custo real é afetado por:

• o novo tokenizer
• a maior despesa de raciocínio em níveis de esforço mais altos
• o pipeline de imagens maior
• quantas mensagens de utilizador crias
• com que frequência o modelo tem de recuperar de prompts ambíguos

As melhores práticas aqui são simples:

• faz benchmark nos teus workloads reais
• testa high versus xhigh
• usa esforços menores em trabalhos menores
• reduz a amostragem de imagens que não precisas em full fidelity
• para de tratar clarificações repetidas do utilizador como gratuitas

Alguns parceiros reportaram melhor qualidade em esforços mais baixos do que o Opus 4.6 precisava. É daí que vêm as poupanças de custo na prática.

16. Três Templates de Prompt que Vale Guardar

Template 1: Implementação de Alta Importância

Implement [task].

Constraints:
- [must preserve]
- [must avoid]

Relevant files:
- [file/path]
- [file/path]

Working style:
- think carefully before acting
- verify assumptions from code, not guesses
- use subagents only when the work naturally splits

Definition of done:
- [observable outcome]
- [test or verification]

Template 2: Revisão e Investigação

Investigate [problem].

Use tools and file reads aggressively where needed.
Do not guess if the codebase can answer the question.

I want:
- root cause
- files involved
- likely fix
- edge cases or risks

Template 3: Análise com Documentos

Review these materials and produce a decision memo.

Requirements:
- separate facts from interpretation
- call out ambiguity explicitly
- list what evidence is missing
- cite the exact source section when possible

17. Os Maiores Erros a Evitar

Os hábitos que desperdiçam mais o Opus 4.7:

• primeiras mensagens vagas
• deixar o max ligado para trabalho de rotina
• manter o atrito de permissões padrão mesmo depois de saberes quais os comandos seguros
• ignorar os recaps e depois reorientar manualmente dentro de sessões longas
• observar cada linha do transcript quando o modo foco tornaria a revisão mais fácil
• assumir que o modelo vai investigar de forma agressiva sem que lho digas
• assumir que vai criar subagentes automaticamente como os workflows antigos faziam
• deixar tarefas não relacionadas acumular numa única sessão
• julgar o custo apenas pelo preço de lista em vez do comportamento real de tokens

A maioria das queixas de "o Opus 4.7 é demasiado caro" são na verdade queixas de workflow com uma etiqueta de preço.

Fontes

• Best practices for using Claude Opus 4.7 with Claude Code
• Using Claude Code: session management and 1M context
• Claude Code best practices docs
• Claude Code permission modes
• Claude Code changelog
• Claude Code commands
• Boris Cherny, thread de lançamento no X sobre dicas de workflow do Opus 4.7, 16 de abril de 2026
• Introducing Claude Opus 4.7

Páginas Relacionadas

• Claude Opus 4.7
• Casos de uso do Claude Opus 4.7
• Preços e Uso de Tokens do Claude Code
• Claude Code Auto Mode
• Modelos do Claude Code