Soluções para o Problema de Pensamento 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 com muito texto em prosa e uma tendência a "pensamento superficial" (incapacidade de pensar de forma estrutural).

Ao investigar, não era que o modelo fosse ruim ou que as regras estivessem quebradas; na verdade, o prompt de sistema interno fornecido ao Opus 5 na geração do 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 de 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 o Opus 5:

• Explicações situacionais se tornaram prosa longa e plana, sem cabeçalhos ou seções.
• Explicações de causas paravam em uma única camada (listando sintomas em paralelo sem aprofundar no "porquê").
• Nenhum critério de avaliação era fornecido ao sugerir múltiplas opções.
• Categorias ou numerações estabelecidas em uma rodada eram reorganizadas em estruturas diferentes na próxima.
• O modelo ignorava minha entrada e pulava direto para execução de 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 suposição de que o "ambiente que as regras assumem" havia mudado.

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

Na geração Claude 5 do Claude Code, o prompt de sistema interno foi reduzido em aproximadamente 80% em comparação com gerações anteriores. Ao medir 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 de abertura.
2. Especificações do Harness (# Harness) — Explicações do ambiente de execução, como a saída ser 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 restringir ou expandir o escopo solicitado sem permissão.
5. Etiqueta de Correção (# Corrections) — Manter 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-ler os sintomas através dessas duas características faz tudo se encaixar. 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 no 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 vácuo é 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 "divida 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 de sistema com muito estilo. Embora 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 de Sistema do 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 Instruções para 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 pode encontrar 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 de sistema.

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

Primeiro, cruzei todas as regras com o novo prompt de 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 completamente ausentes do prompt, como regras de estilo, a instrução funciona para "preencher o vácuo" 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 faz". Proibições ajudam a detectar violações, mas não transmitem o que fazer em vez disso. Quando uma proibição conflita 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 texto do corpo."

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

1. A regra é autocontida? (Escopo, exemplos e critérios em um só lugar)
2. O gatilho é um fato observável?
3. Ela contradiz o prompt de sistema interno?
4. Ela descreve 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 etapas primeiro)
8. A conformidade pode ser determinada após o fato?

Reduzi os marcadores de ênfase (IMPORTANTE) apenas para portões de segurança e 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 solicitação (a cada rodada). A diferença está em "quando o conteúdo é finalizado" e "onde ele é colocado no prompt = quão perto está da ação sendo executada."

Surpreendentemente, output style — que a documentação diz "substitui o prompt de sistema" — foi entregue como um anexo em cada rodada, de acordo com os 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, o problema de Processo — ignorar respostas para começar o trabalho — não parou via output style. Finalmente parei este 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 texto do corpo 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 foi corrigido com output style sozinho, mas parou após introduzir injeção por fala (atualmente observando efeitos de longo prazo).

Resumo

• Uma atualização de modelo também é uma atualização de prompt de 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 de contradições.
• 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 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 de 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, elas funcionam como definições para preencher o vácuo.

1# Formato de Relatório e Decomposição
2
3Esta instrução tem precedência sobre as seguintes descrições no prompt de 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"O 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 pensamentos primeiro, depois estruture no final. Não coloque um modelo primeiro e o preencha.
17- Ao explicar causas, rastreie o "porquê" pelo menos duas camadas de profundidade a partir do evento observado e descreva ao 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 seu raciocínio primeiro, seguidos 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 rodadas subsequentes enquanto continuar a mesma tarefa. Se alterá-los, escreva primeiro o que foi alterado.
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 rodada com um relatório no texto do corpo, e pare para esperar uma resposta em rodadas onde uma pergunta é feita.
24- Apenas o texto do corpo no final de uma rodada é exibido neste ambiente. Coloque todas as informações a serem transmitidas no final da rodada.
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 o 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 regras antigas.
• Fable 5 foi uma surpresa. Assumi que tinha o mesmo prompt já que é da mesma geração, mas medições mostraram que ao Fable 5 é fornecido 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, output style 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." Porque o prompt em si 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. Foi dado um prompt com zero regras de estilo de escrita, expondo tendências brutas de saída.
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 antigo e detalhado e não foram moldadas para preencher este novo vácuo.