Melhores Práticas para o Claude Opus 4.7

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

Isso é deixar muito dinheiro na mesa.

A orientação da Anthropic para o Opus 4.7 é subtil mas importante: o modelo pensa mais com esforço maior, é mais seletivo com chamadas de ferramentas e subagentes, lê instruções de forma mais literal, e tem melhor desempenho quando o tratas como um engenheiro capaz a quem delegas trabalho, em vez de um colega de pair programming que guias a cada trinta segundos.

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

Para a análise 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 este:

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.

Essa mudança importa porque o Opus 4.7 tem melhor desempenho quando a primeira interação lhe dá espaço suficiente para pensar, planear e executar sem precisar de cinco follow-ups corretivos.

1. Trata o Opus 4.7 como um Delegado, Não como um Colega de Pair Programming

Esta é a mudança de mentalidade mais importante.

Workflows de código mais antigos costumavam ser assim:

1. dar um prompt vago
2. esperar por uma tentativa parcial
3. acrescentar mais uma clarificação
4. corrigir a abordagem
5. acrescentar mais uma restrição

Este estilo é caro no Opus 4.7 porque cada nova interação do utilizador adiciona 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. dizer claramente o trabalho na primeira interação
2. incluir as restrições reais e os critérios de aceitação
3. deixar o modelo levar o trabalho mais longe antes de interromperes
4. rever o resultado num ponto de controlo significativo em vez de microgerir cada passo

Má primeira interação:

Help me fix auth.

Boa primeira interação:

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 uma entrega melhor.

2. Carrega a Primeira Interação à Frente

O post de melhores práticas da Anthropic para o Opus 4.7 volta sempre a este ponto: se o trabalho é real, dá ao modelo o briefing completo à partida.

A primeira interação deve normalmente incluir:

• a tarefa real
• o que é sucesso
• o que não pode mudar
• quais ficheiros, serviços ou diretórios importam
• 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 custo de raciocínio para incorporar correções que deviam ter estado no briefing 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 código, revisão, segurança, docs 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 aí por uma razão.

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

Regra prática:

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

Desce para high quando:

• estás a gerir várias sessões ao mesmo tempo
• a tarefa é difícil mas não existencial
• queres melhor controlo de gastos

Vai para max apenas quando:

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

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

4. Usa Prompts para a Taxa de Pensamento que Queres

O Opus 4.7 usa pensamento adaptativo, o que significa que o modelo decide quando pensar mais e quando avançar depressa. Isso é normalmente bom. Ainda é ajustável.

Quando queres mais pensamento:

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

Quando queres menos pensamento:

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

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

Bons casos de uso para mais pensamento:

• 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 pensamento:

• uma edição específica num ficheiro que já nomeaste
• perguntas rápidas de referência
• refatorações mecânicas 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. Isso é normalmente uma melhoria. Também significa que o modelo pode inspecionar menos do que esperas a menos que o digas.

Se queres investigação agressiva, diz isso.

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.

Isso importa para:

• revisão de código
• debugging
• revisão de segurança
• investigação de codebase grande
• 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. Mais uma vez, isso é normalmente racional. Nem sempre é o que queres.

Se o trabalho beneficia de paralelismo, diz isso na primeira interação.

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 o codebase em paralelo antes da implementação

Más alturas para forçar paralelismo:

• uma correção de ficheiro único
• 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 Interações do Utilizador no Trabalho Interativo

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

Cada interação extra do utilizador adiciona overhead. Se estás a trabalhar de forma interativa, agrupa as tuas perguntas e correções em vez de as ir dando aos poucos.

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 Quando o Briefing é Bom

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 está bem especificada
• o repositório ou ambiente é familiar
• confias na direção geral
• queres menos interrupções de permissões

O modo auto é má escolha quando:

• a tarefa toca produção ou infraestrutura partilhada
• o objetivo ainda está vago
• esperas muitas decisões que requerem julgamento humano
• o ambiente em si é não confiável ou desconhecido

A sequência que funciona:

1. escrever um bom briefing na primeira interação
2. verificar que o plano parece razoável
3. mudar para modo auto para execução se a tarefa é bem delimitada

Não uses o modo auto para compensar um briefing fraco. Isso só deixa o modelo avançar mais depressa na direção errada.

9. Elimina o Atrito de Permissões em vez de Clicar Para Passar Por Ele

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

Há dois soluções limpas:

Modo auto para trabalho bem delimitado

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

Boa escolha:

• refatorações longas num repositório familiar
• trabalho de implementação com uma definição clara de "feito"
• investigações onde confias na direção geral

Má escolha:

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

Para a mecânica mais aprofundada, vê Claude Code Auto Mode e os docs oficiais de modos de permissão.

/fewer-permission-prompts para comandos seguros repetidos

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

É um workflow muito melhor para o Opus 4.7 do que qualquer dos extremos:

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

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

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

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

Recaps

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

Os recaps são especialmente úteis quando:

• colocas uma tarefa em segundo plano
• voltas a uma sessão mais tarde no dia
• uma execução longa tocou 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 como sumarização.

Modo de foco

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

O modo de foco é útil quando:

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

Essa é uma mudança de workflow que vale a pena fazer. Modelos mais fortes mudam o gargalo de "consegue fazer o trabalho?" para "quanto do trabalho preciso realmente de acompanhar?"

11. Configura o Esforço Deliberadamente

A thread do Boris também reforçou algo que os docs da Anthropic agora deixam muito mais claro: trata o esforço como um controlo de primeira classe, não como uma configuração oculta.

Regra prática:

• esforço mais baixo para respostas rápidas e menor gasto
• esforço mais alto para engenharia e trabalho de revisão mais difícil
• não assumas que "esforço mais alto" é sempre o melhor workflow

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

Mantém estes padrões:

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

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

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

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

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

Usa a sessão atual quando:

• o próximo passo faz parte da mesma tarefa
• o contexto atual ainda é relevante
• reler os mesmos ficheiros seria 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 marcos naturais, não no meio de debugging frágil
• subagentes para investigação, para que a thread principal se mantenha limpa

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

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

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

Uma das melhores características do Opus 4.7 é que está mais disposto a verificar o seu próprio trabalho. Ajuda-o.

Adiciona 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

Isso é 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 é mais auto-verificador do que versões anteriores. Ainda assim queres que "feito" signifique algo concreto.

Exemplos concretos de um harness de verificação:

• trabalho de backend: um comando de teste, verificação com curl, ou build com tipos
• trabalho de frontend: uma verificação no browser, diff de screenshot, ou lint/build bem sucedido
• refatorações: compile + test + grep para a superfície de API antiga
• docs ou conteúdo: uma lista de verificação de afirmações a validar contra o material fonte

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

14. Usa Orçamentos de Tarefa para Execuções Mais Longas

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

Se executas agentes ou workloads de API, testa orçamentos de tarefa em:

• refatorações mais longas
• trabalhos de pesquisa + implementação
• automação em segundo plano
• loops de revisão e reparação de código

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

• dar ao modelo espaço suficiente para terminar
• manter o orçamento finito
• medir quais classes de trabalho realmente precisam de mais

Isso torna-se mais importante no Opus 4.7 porque o modelo está disposto a gastar mais pensamento com esforço maior em execuções difíceis.

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

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

O teu custo real é afetado por:

• o novo tokenizador
• o maior gasto de raciocínio em níveis de esforço mais altos
• o pipeline de imagens maior
• quantas interações do 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ço menor em trabalhos menores
• faz downsample de imagens que não precisas em fidelidade total
• para de tratar a clarificação repetida do utilizador como gratuita

Alguns parceiros reportaram melhor qualidade com esforço menor 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 a Pena Guardar

Template 1: Implementação de Alto Risco

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 de Documentos Pesada

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 são:

• primeiras interações vagas
• deixar max ligado para trabalho de rotina
• manter o atrito de permissões padrão mesmo depois de saberes quais comandos são seguros
• ignorar os recaps e depois reorientar manualmente dentro de sessões longas
• ver cada linha da transcrição quando o modo de foco tornaria a revisão mais fácil
• assumir que o modelo vai investigar agressivamente sem ser dito para o fazer
• assumir que vai expandir automaticamente para subagentes como workflows mais antigos faziam
• deixar tarefas não relacionadas acumular numa só sessão
• julgar o custo apenas pelo preço de tabela em vez do comportamento real dos 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, launch-day X thread on Opus 4.7 workflow tips, April 16, 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