Soluções para o Problema de Raciocínio Superficial no Claude Opus 5

Visão Geral

Imediatamente após mudar o Claude Code para o Opus 5, notei um aumento repentino em respostas prolixas e uma tendência ao "pensamento superficial" (incapacidade de pensar estruturalmente).

Após investigar, não era que o modelo fosse ruim ou que as regras estivessem quebradas; na verdade, o prompt interno do sistema fornecido ao Opus 5 na geração Claude 5 mudou significativamente, e as regras legadas não foram escritas considerando essa nova premissa.

Este artigo registra o processo de isolar a causa e revisar as regras para se adequar ao novo prompt do sistema. É destinado a usuários do Claude Code que sentem que a eficácia do CLAUDE.md ou de suas regras mudou desde a atualização para a nova geração de modelos.

O Problema

Usando a mesma sessão e as mesmas regras, o seguinte ocorreu imediatamente após mudar o modelo para Opus 5:

• Explicações situacionais tornaram-se prosa plana e longa, sem cabeçalhos ou seções.
• Explicações de causas paravam em uma única camada (listando sintomas em paralelo sem aprofundar o "porquê").
• Nenhum critério de avaliação era fornecido ao sugerir múltiplas opções.
• Categorias ou numerações estabelecidas em um turno eram reorganizadas em estruturas diferentes no próximo.
• O modelo pulava a resposta à minha entrada e imediatamente começava a executar ferramentas (tarefas).

A parte frustrante era que, mesmo quando instruído a "pensar mais profundamente", ele retornava respostas esporádicas enquanto permanecia em um estado de pensamento superficial. Correções repetidas não funcionavam, levando a discussões em vez de diálogo produtivo.

Não era apenas uma questão de qualidade de resposta única; o próprio processo de deliberação através do diálogo havia se quebrado.

Pistas Principais

Isso não aconteceu com outros modelos usando as mesmas regras (detalhes sobre essa diferença estão no apêndice). Se as próprias regras tivessem se deteriorado, o problema deveria ter aparecido em todos os modelos. Como apenas o modelo mudou, comecei a investigar sob a premissa de que o "ambiente que as regras assumem" havia mudado.

Causa: Mudanças no Prompt do Sistema Fornecido ao Opus 5

Na geração Claude 5 do Claude Code, o prompt interno do sistema foi reduzido em aproximadamente 80% em comparação com gerações anteriores. Medindo o prompt realmente entregue ao Opus 5 (desabilitando injeções de estilo de saída e fazendo o modelo citar seu próprio prompt; série Claude Code v2.1, julho de 2026), a estrutura era a seguinte:

1. Identidade, Declaração de Papel e Política de Segurança — O preâmbulo inicial.
2. Especificações do Harness (# Harness) — Explicações do ambiente de execução, como a saída sendo exibida como markdown.
3. Informações do Ambiente e Descrições de Recursos (# Session-specific guidance / # Memory / # Environment / # Context management) — CWD, status do git, ID do modelo, memória e mecanismos de compressão de contexto.
4. Disciplina de Escopo (# Delivering work) — Não reduzir ou expandir o escopo solicitado sem permissão.
5. Etiqueta de Correção (# Corrections) — Manter as correções concisas sem adicionar desculpas ou preâmbulos.

Duas características específicas diretamente ligadas aos sintomas emergiram:

• Característica 1: Zero instruções sobre estilo de resposta. Não havia regras sobre prosa vs. estrutura, uso de cabeçalhos ou tabelas, ou concisão — regras de formatação que eram extensas em gerações anteriores desapareceram completamente.
• Característica 2: Uma política autônoma "Aja Primeiro" foi adicionada. Citando o original: "Quando você tem informação suficiente para agir, aja." e "Se você está ponderando uma escolha, dê uma recomendação, não uma pesquisa exaustiva."

Re-lendo os sintomas através dessas duas características, tudo se encaixa. Como não há regras de estilo, a tendência bruta de saída do modelo — prosa plana — aparece. A política "recomendação em vez de pesquisa" incentiva a omissão de critérios de avaliação.

Você pode pensar: "Se as regras estão em branco, minhas regras personalizadas não deveriam se tornar a única autoridade e funcionar melhor?" Na realidade, o oposto aconteceu. Este espaço em branco não é uma margem deixada para o usuário; é delegado ao comportamento padrão incorporado ao modelo durante o treinamento. O "prompt enxuto" assume que modelos de nova geração seguem comportamentos internalizados sem instruções detalhadas. Em vez de ser preenchido pelas suas regras, o vazio é preenchido pelos padrões pré-treinados do modelo. E o padrão do Opus 5 é prosa concisa que age antes de confirmar.

Minhas regras antigas usavam instruções gerais como "decomponha situações estruturalmente", "adicione critérios de avaliação a múltiplas opções" e "responda antes de agir". Elas foram escritas assumindo que seriam lidas junto com um prompt do sistema rico em estilo. Embora fossem suficientes na época, eram muito fracas tanto em especificidade (nomeando o texto original) quanto em entrega (chegando ao modelo bem antes da ação) para substituir os padrões treinados. Esta é a verdadeira natureza dos sintomas.

A própria Anthropic se refere a essa redução como um "prompt de sistema enxuto" no changelog (v2.1.154), refletindo uma mudança na filosofia de design: "Modelos de nova geração internalizaram comportamentos através do treinamento, então instruções detalhadas podem causar atrito ou contradição." Para explicações detalhadas, veja Prompt do Sistema Claude Code Reduzido em 80% — Filosofia de Design de Prompt para a Geração Fable 5. Para fontes primárias, consulte o Changelog do Claude Code e Prompting Claude Fable 5 (Guia Oficial).

Em resumo, os sintomas são determinados pela combinação de "regras × o prompt realmente entregue àquele modelo." Você não encontra a causa olhando apenas para as regras. A primeira lição foi que uma atualização de modelo também é uma atualização de prompt do sistema.

Medida 1: Identificar Contradições e Substituir Nomeando o Texto Original

Primeiro, cruzei todas as regras com o novo prompt do sistema para identificar onde elas diziam o oposto. Para regras destinadas a substituir a política do sistema, reescrevi-as para citar explicitamente o texto original e declarar prioridade.

Para começar com o que não funcionou: adicionar generalidades como "escreva múltiplas opções com critérios de avaliação" é ineficaz.

Quando colocadas ao lado da política do sistema "dê uma recomendação, não uma pesquisa exaustiva", não há pista sobre qual tem precedência. Nomeando o conflito, a prioridade fica clara.

Para coisas totalmente ausentes do prompt, como regras de estilo, a instrução funciona para "preencher o vazio" em vez de substituir.

Também revisei como as condições de gatilho são escritas. Condições como "para mudanças importantes" ou "se julgado ser um ambiente de produção" falham no momento em que o modelo não categoriza a situação dessa forma. Mudei os gatilhos para fatos observáveis como "recebeu uma interrupção" ou "a fala do usuário contém uma correção."

Medida 2: Descrever Ações Desejadas em Vez de Proibições

Regras antigas eram um acúmulo de "não faça isso." Proibições ajudam a detectar violações, mas não transmitem o que fazer em vez disso. Quando uma proibição entra em conflito com uma nova política do sistema, o modelo encontra uma brecha: "seguir a política do sistema enquanto evita a proibição." Converti restrições negativas em descrições de comportamento desejado.

• Antes: "Não sugira um commit se os testes estiverem incompletos."
• Depois: "Ao sugerir um commit, inclua os resultados da execução do produto da perspectiva do usuário final no corpo do texto."

Verifiquei as regras reescritas com os seguintes critérios, especialmente para expressões que entram em conflito com o Prompt do Sistema:

1. A regra é autocontida? (Escopo, exemplos e critérios em um só lugar)
2. O gatilho é um fato observável?
3. Contradiz o prompt interno do sistema?
4. Descreve o comportamento desejado? (Não apenas uma lista de proibições)
5. Há um único critério para julgamento? (Não uma lista de cenários)
6. A ênfase (IMPORTANTE) é reservada apenas para o que realmente não pode ser descartado?
7. Está escrito como o estado final desejado? (Não forçando modelos ou passos primeiro)
8. A conformidade pode ser determinada posteriormente?

Reduzi os marcadores de ênfase (IMPORTANTE) apenas para segurança e portões de aprovação. Um documento onde tudo é enfatizado é o mesmo que um documento onde nada é.

Medida 3: Escolher a "Camada" para Entregar Instruções

Não era apenas sobre o texto. O Claude Code tem pelo menos quatro caminhos para entregar instruções ao modelo, e eles diferem significativamente em eficácia.

Como a API é stateless, o conteúdo de todos os caminhos é enviado ao modelo a cada requisição (a cada turno). A diferença está em "quando o conteúdo é finalizado" e "onde é colocado no prompt = quão perto está da ação sendo executada."

Surpreendentemente, output style — que a documentação diz "substitui o prompt do sistema" — foi entregue como um anexo em cada turno, de acordo com logs de sessão.

Escrevi dois tipos de instruções neste output style: Estilo (Medida 1: escreva estruturalmente, adicione critérios) e Processo (responda ao usuário antes de começar o trabalho). Os resultados foram mistos.

Enquanto as instruções de Estilo mostraram melhora, a questão do Processo — pular respostas para começar o trabalho — não parou via output style. Finalmente parei esse hábito usando um hook UserPromptSubmit para injetar uma única linha imediatamente após cada fala do usuário: "Escreva uma resposta a esta fala (resposta, ou reconhecimento e plano) no corpo do texto antes de executar ferramentas."

O custo é de cerca de 50 tokens por fala. Mesmo 100 falas custam apenas 5.000 tokens, o que é insignificante contra um contexto de 200K. A regra geral que aprendi é simples: Instruções entregues "brevemente, toda vez, bem antes da ação" são as mais eficazes. Muitas instruções ineficazes não são ruins em conteúdo; elas simplesmente não estão à mão no momento da ação.

Resultados

Aqui estão os resultados confirmados até agora:

• Uma tendência de cabeçalhos/seções retornando a explicações situacionais e causais. (No entanto, saída plana às vezes permanece no início da sessão; observação contínua necessária).
• O hábito de "trabalhar sem responder" não se corrigiu com output style sozinho, mas parou após introduzir a injeção por fala (atualmente observando efeitos de longo prazo).

Resumo

• Uma atualização de modelo também é uma atualização de prompt do sistema. Se as tendências de resposta mudam repentinamente, leia as mudanças no lado do sistema antes de adicionar mais regras.
• Regras que competem com políticas do sistema devem nomear o texto original e declarar prioridade. Adições gerais perdem diante da contradição.
• Escreva gatilhos baseados em observação e descreva ações desejadas em vez de proibições. Gatilhos de autocategorização e listas de proibições são propensos a falhar quando os modelos mudam.
• Escolha a camada certa para as instruções. Injeções entregues breve e frequentemente bem antes de uma ação foram muito mais confiáveis do que regras grandes colocadas no início do contexto.

Referência 1: Regras Realmente Usadas na Medida 1

Aqui está um trecho das regras que uso para substituir o prompt do sistema (ajuste para seu ambiente; coloco estas no output style). Algumas frases originais (como a política de prosa) não existem no prompt para certos modelos (veja apêndice). Nesses modelos, funcionam como definições para preencher o vazio.

1# Formato de Relatório e Decomposição
2
3Esta instrução tem precedência sobre as seguintes descrições no prompt do sistema do Claude Code:
4"uma pergunta simples recebe uma resposta direta em prosa, não cabeçalhos e seções" /
5"Use tabelas apenas para fatos curtos e enumeráveis" /
6"Não faça o leitor cruzar referências de rótulos ou numerações que você inventou antes" /
7"Se você está ponderando uma escolha, dê uma recomendação, não uma pesquisa exaustiva." /
8"Você está operando autonomamente... prossiga sem perguntar." /
9"Texto que você escreve entre chamadas de ferramenta pode não ser mostrado ao usuário."
10
11## Estilo de Escrita
12
13Ao explicar situações, causas ou apresentar múltiplas opções, escreva de forma que transmita a estrutura do conteúdo ao leitor.
14Use cabeçalhos, marcadores ou tabelas conforme apropriado para o conteúdo. Responda perguntas de uma frase em prosa.
15
16- Resuma os pensamentos primeiro, depois estruture no final. Não coloque um modelo primeiro e preencha-o.
17- Ao explicar causas, rastreie o "porquê" pelo menos duas camadas abaixo do evento observado e descreva a que cada camada se refere. Não pare em listar sintomas em paralelo.
18- Ao apresentar múltiplas opções, escreva a recomendação e sua justificativa primeiro, seguidas pelos critérios que influenciam a decisão e a avaliação de cada opção. Se os critérios não puderem ser identificados, não forneça opções; em vez disso, escreva o que precisa ser investigado para preencher os critérios. Comparações de critérios podem ser escritas em tabelas.
19- Uma vez que categorias e números são estabelecidos, use os mesmos em turnos subsequentes enquanto continua a mesma tarefa. Se mudá-los, escreva o que foi mudado primeiro.
20
21## Diálogo e Processo
22
23- O "o usuário não está assistindo em tempo real" do sistema é um padrão, não um fato. Se uma fala intermediária, interrupção ou correção for recebida mesmo uma vez nesta sessão, trate o usuário como assistindo a partir de então: divida o trabalho em pequenos segmentos, sempre termine cada turno com um relatório no corpo do texto, e pare para esperar uma resposta em turnos onde uma pergunta é feita.
24- Apenas o corpo do texto no final de um turno é exibido neste ambiente. Coloque todas as informações a serem transmitidas no final do turno.
25- Perguntas são um meio legítimo quando há ambiguidade, operações que exigem aprovação ou objetivos pouco claros.

Referência 2: Por que isso não aconteceu com Fable 5 / Opus 4.7?

Enquanto o texto principal focou no Opus 5, aqui está o porquê de não ter acontecido com outros modelos:

• Opus 4.7 é simples: está excluído da aplicação do "prompt enxuto" (de acordo com o changelog), então ainda executa com o prompt longo e legado para o qual as regras legadas foram projetadas. Permanece em sincronia com as regras antigas.
• Fable 5 foi uma surpresa. Assumi que tinha o mesmo prompt já que é da mesma geração, mas medições mostraram que Fable 5 recebe um prompt diferente do Opus 5.

Aqui está uma comparação de cada modelo citando seu próprio prompt sob condições idênticas (modo headless, estilo de saída desabilitado):

A seção # Communicating with the user do Fable 5 inclui normas como "conclusão primeiro, priorize legibilidade, escreva para o público." Além de "dê uma recomendação, não uma pesquisa exaustiva," inclui a política de prosa "uma pergunta simples recebe uma resposta direta em prosa, não cabeçalhos e seções." Como o próprio prompt contém essas normas de escrita, o formato de saída é menos propenso a colapsar e, em minhas observações, manteve a adesão às regras do usuário.

Em resumo, o problema apareceu intensamente no Opus 5 porque três fatores se alinharam:

1. Recebeu um prompt com zero regras de estilo de escrita, expondo tendências de saída brutas.
2. Políticas como "aja quando a informação for suficiente" e "recomendação em vez de pesquisa" incentivaram ação imediata e omissão de critérios.
3. Regras legadas ainda estavam baseadas no prompt detalhado antigo e não foram moldadas para preencher este novo vazio.