# Quatro prompts para contrariar a bajulação no Claude Code > Factos, precedentes, um plano e uma autoavaliação: um ciclo de quatro passos no Plan Mode para tarefas complexas e erros pouco claros. Source: https://ailoot.ai/blog/pt-pt/claude-code-sycophancy-prompts/ Canonical: https://ailoot.ai/blog/pt-pt/claude-code-sycophancy-prompts/ Language: pt-PT Publisher: Ailoot (https://ailoot.ai/) Translation: guide-123 Revision: sha256-bcadcb17f87393919d2cf8ef149450a49a5fcca16d20889bc40eacc1b4427ef0
Principais conclusões O Claude Code está configurado por predefinição para concordar. Isso é conveniente numa conversa e perigoso ao programar: o modelo produz rapidamente uma solução plausível que espalha um módulo de autenticação por 14 ficheiros. Um ciclo de prompts de 4 passos no Plan Mode bloqueia este reflexo: leva o modelo a estabelecer primeiro os factos, depois a encontrar precedentes, a seguir a elaborar um plano com riscos e, por fim, a verificar o próprio plano.
A [documentação da Ailoot](https://ailoot.ai/docs/) descreve a ligação de modelos e a utilização da API.
## O que é a bajulação da IA no Claude Code?
Principais conclusões A bajulação da IA não é um erro, mas uma característica arquitetural do Claude e de outros grandes modelos de linguagem. Numa análise de um milhão de conversas com o Claude, a Anthropic concluiu que, em conversas sobre relações, o modelo se adapta ao utilizador um quarto das vezes e, em temas espirituais, um terço das vezes. A percentagem é menor na programação, mas o mecanismo é o mesmo: o modelo quer responder rapidamente com algo que pareça plausível e tenta agradar.
A psicologia tem há muito um termo para isto: bajulação. Um bajulador diz aquilo que quer ouvir apenas para manter a conversa em andamento. Com a chegada dos grandes modelos de linguagem, a palavra passou para a investigação em IA e, numa análise oficial, a Anthropic reconheceu abertamente que o modelo sacrifica regularmente a precisão em favor da concordância rápida. Na programação, é assim que acontece. Escreve ao Claude Code: «Corrige este erro em authMiddleware; os magic links deixaram de funcionar.» O bajulador não faz perguntas para esclarecer. Não pede registos. Não pergunta que versão da biblioteca está a utilizar. Oferece imediatamente uma solução porque foi treinado para ajudar rapidamente. E a solução vai parecer correta: imports, tratamento de erros, comentários. Mas será uma solução para o problema de outra pessoa, inventada a partir do contexto que o Claude reuniu com fragmentos. A causa não é o Claude. A causa é a forma como o pedido está formulado. Quando pergunta «Como é que corrijo isto?», já partiu do princípio de que é possível corrigir. O bajulador adota esse enquadramento e produz uma «correção», mesmo que o verdadeiro problema esteja na arquitetura, na versão da biblioteca ou no facto de o sintoma descrito ser apenas a consequência de um erro de raiz completamente diferente. Um teste simples para detetar um pedido que incentiva a bajulação: se não consigo responder à pergunta «O que está exatamente avariado?» em três frases, não estou preparado para resolver o problema. Preciso de um diagnóstico. A correção vem depois. É exatamente aí que começa o ciclo de 4 passos. ## Um caso prático: 8 commits revertidos numa hora
Principais conclusões Pedi ao Claude Code que corrigisse a autenticação por magic link. O modelo fez três perguntas para esclarecer, produziu um plano que abrangia 14 ficheiros e aprovei-o. Dezoito minutos depois, o magic link não funcionava, o token de atualização estava avariado e tinha aparecido um erro 500 nos pagamentos. Reverti 8 commits com `git reset --hard origin/main`. O verdadeiro problema estava numa linha.
Um caso concreto de abril de 2026. Estava a trabalhar na autenticação por magic link em `src/lib/auth/`. O sintoma: os tokens eram validados, mas a sessão não era guardada. O utilizador clica na ligação do e-mail, chega ao site e, cinco segundos depois, é enviado de volta para /login. Abri o Claude Code e escrevi: «A sessão não é guardada depois do magic link; procura em src/lib/auth/ e corrige o problema.» O Claude fez três perguntas para esclarecer e, de seguida, produziu imediatamente um plano. Disse: «Vou atualizar o handler do callback, reescrever o serializador JWT, acrescentar a gravação explícita no Redis e corrigir uma condição de corrida no middleware.» Parecia plausível. Aprovei o plano. Dezoito minutos depois, tinha um diff em 14 ficheiros. O magic link continuava sem funcionar. Mas agora o token de atualização também não funcionava, o início de sessão com palavra-passe estava avariado e havia um erro 500 estranho na rota de pagamentos. Os testes estavam a falhar. Comecei a reverter as alterações. Reverti 8 commits com `git reset --hard origin/main`. Uma hora de trabalho foi pelo cano abaixo. Se quiser perceber como reverter corretamente sem perder nada útil, expliquei-o em separado no [guia para reverter alterações no Claude Code](https://ailoot.ai/blog/pt-pt/claude-code-undo-changes/). Sentei-me e investiguei devidamente. Abri `src/lib/auth/magic-link.ts:42`, li o ficheiro, abri os registos e verifiquei o Redis. Vinte minutos depois, descobri o problema. Estava numa linha: faltava o atributo `SameSite=lax` no cabeçalho `set-cookie`, e o Safari rejeitava o cookie ao redirecionar do domínio do e-mail para o site. Sem JWT, sem Redis, sem middleware. Uma linha. Quando pedi ao Claude que corrigisse o problema, ele nem sequer consultou os registos do navegador. Não tinha contexto sobre o Safari. Construiu uma hipótese a partir do padrão «a sessão não é guardada = problema de serialização», porque essa é a resposta mais comum nos dados de treino. O bajulador produziu uma solução estatisticamente plausível, mas sem qualquer relação com a minha tarefa. Anotei a lição como regra: nunca pergunte «Como é que corrijo isto?». Pergunte sempre «Estabelece os factos». Só faltava formalizar isto como um ciclo de trabalho. ## De onde vem a bajulação: Opus 4.8 no lançamento e maio de 2026
Principais conclusões A bajulação é um padrão de comportamento documentado que exige adaptar os prompts de trabalho.
Em abril, a Anthropic analisou separadamente, numa análise técnica pós-incidente, como um erro de cache no Claude Code levou o modelo a «esquecer» o seu raciocínio entre interações.
Este erro situava-se na interseção entre a gestão de contexto do Claude Code, a API da Anthropic e o extended thinking.
— Anthropic Engineering, https://www.anthropic.com/engineering/april-23-postmortem
Quando um modelo se esquece da sua cadeia de raciocínio, torna-se mais fácil «adivinhar» uma resposta com base num padrão — por outras palavras, tornar-se ainda mais bajulador. O que fazer perante o lançamento do 4.8. Não escolha um modelo «mais fácil». Não volte ao 4.7. Adapte os seus prompts aos factos: o modelo está mais inclinado a concordar, por isso insista mais em «estabelecer os factos». Se ainda não percebeu exatamente o que está a mudar no Opus 4.8, comparei-o em detalhe na [análise do Opus 4.8 no Claude Code](https://ailoot.ai/blog/pt-pt/opus-4-8-claude-code-features/). ## Quando são necessários os 4 passos — e quando são uma perda de tempo
Principais conclusões O ciclo de 4 passos é artilharia pesada. Passar 15 minutos a estabelecer factos, procurar precedentes e verificar o trabalho só para corrigir um erro tipográfico num README não faz sentido. O ciclo é necessário precisamente quando o custo de um erro é superior ao custo de 15 minutos de planeamento. O teste simples abaixo divide as tarefas em três níveis. Uma regra simples para classificar tarefas: antes de começar, pergunte a si próprio se consegue enumerar 3–5 ficheiros que serão definitivamente afetados e dizer o que vai mudar em cada um.
| Resposta | O que fazer | |----|----| | Sim, consigo enumerar os ficheiros e as alterações | Faça-o diretamente, sem Plan Mode | | Não, tenho dúvidas sobre os ficheiros, mas sei o que alterar | Use o Plan Mode sem o ciclo de 4 passos | | Tenho dúvidas tanto sobre os ficheiros como sobre a abordagem | O ciclo de 4 passos é obrigatório | | O sintoma é pouco claro e não pode ser reproduzido localmente | O ciclo de 4 passos mais um passo zero com um exemplo mínimo reproduzível | Exemplos concretos. Corrigir o texto de um e-mail de boas-vindas: faça-o diretamente. Acrescentar um novo botão CTA a um site: Plan Mode sem o ciclo. Migrar um projeto de MySQL para Postgres: o ciclo de 4 passos é obrigatório. Um erro 500 estranho em produção que não pode ser reproduzido localmente: o ciclo de 4 passos com um passo «zero» adicional: «vamos primeiro criar um exemplo mínimo reproduzível». Um erro comum ao usar o ciclo é aplicá-lo a tarefas triviais. Isso reduz a velocidade e faz com que as pessoas rapidamente desistam da metodologia. O ciclo é necessário precisamente quando o custo de um erro é superior ao custo de 15 minutos de planeamento. Antes de implementar o ciclo, tenha em conta que os quatro prompts funcionam **numa única sessão de Plan Mode**. Se ainda não utilizou este modo, leia primeiro o [guia do Plan Mode no Claude Code](https://ailoot.ai/blog/pt-pt/claude-code-plan-mode/) e depois volte. ## Passo 1. Proíba soluções — faça o Claude estabelecer os factos
Principais conclusões O primeiro impulso do bajulador de IA é «aqui está a solução». O passo 1 bloqueia-o explicitamente. O prompt dá ao Claude quatro campos para preencher: o que observo, como reproduzir, o que sei e o que não sei. O último campo é o mais valioso: é aí que começa a surgir uma lista de perguntas para si, em vez de um diff apressado.
O passo mais importante. É aqui que se bloqueia o primeiro impulso — «aqui está a solução». O prompt: ``` Dei de caras com o seguinte: [sintoma]. A tua tarefa agora é estabelecer os factos. São proibidas quaisquer soluções, ideias ou sugestões. Apenas: - o que observo (a formulação exata do sintoma) - passos para reproduzir (um cenário mínimo) - que dados estão disponíveis (registos, versões, ambiente) - que dados faltam (o que é preciso recolher) Condição de paragem obrigatória: não sugiras soluções; apenas regista o diagnóstico. Se quiseres sugerir algo, formula antes uma pergunta para mim. ``` O que faz. Com uma proibição explícita de apresentar soluções, o Claude não pode atalhar. Tem de preencher quatro campos: o que vejo, como reproduzir, o que sei e o que não sei. O último campo é o mais valioso. Muitas vezes, acaba por ser: «Não sei a versão da biblioteca, o que está nos registos nem se o sintoma ocorre em produção.» Esse é o ponto de partida para o passo seguinte. A armadilha do passo 1. Se o sintoma estiver formulado de forma demasiado vaga («a autenticação não funciona»), o Claude continuará a fazer suposições. A solução está no próprio prompt: descreva o sintoma exato numa frase e apresente um cenário mínimo de três passos. Se não conseguir fazê-lo, isso significa que ainda não percebe exatamente o que está avariado e, de qualquer forma, a resposta do Claude será inútil. ## Passo 2. Precedentes da Internet em vez de alucinações tiradas da memória
Principais conclusões O segundo impulso do bajulador de IA é «inventar uma solução com base em conhecimentos gerais». O passo 2 envia o Claude para o mundo à procura de abordagens verificáveis. Pelo menos três precedentes, cada um com uma ligação ativa, vantagens e desvantagens. Se o Claude citar os seus «próprios conhecimentos» sem uma ligação, rejeite-os imediatamente.
Este passo bloqueia o segundo impulso: «inventar uma solução de memória». O prompt: ``` Agora que o diagnóstico está estabelecido, procura na Internet precedentes para resolver problemas semelhantes. Pelo menos 3 abordagens diferentes. Para cada uma: - uma ligação para a fonte primária (issue, artigo, documentação) - uma breve descrição da abordagem - vantagens e desvantagens para a nossa situação - armadilhas conhecidas São proibidas ligações baseadas nos teus próprios conhecimentos sem confirmação através de uma ligação. Se não conseguires encontrar um precedente, diz isso explicitamente. ``` O efeito na prática. O Claude vai ao mundo e traz abordagens verificáveis. Surgem ligações para issues no GitHub e documentação. Se o Claude não conseguir encontrar precedentes, é um sinal de que a tarefa é invulgar ou de que o sintoma está formulado incorretamente. Volte ao passo 1. Quando isto falha. O Claude pode citar uma ligação inexistente. Trata-se de uma alucinação do género «aqui está a issue número 4291 no repositório X», quando, na realidade, a issue 4291 é sobre outra coisa. Resolva isto com uma regra explícita no CLAUDE.md: «abre sempre a ligação com WebFetch antes de a citar». Consulte o [guia para configurar corretamente o CLAUDE.md](https://ailoot.ai/blog/pt-pt/claude-md-template/) para obter mais detalhes. ## Passo 3. Um plano detalhado em `plans/` com riscos previstos
Principais conclusões O terceiro prompt transforma o melhor precedente num artefacto: um ficheiro `plans/YYYY-MM-DD-fix-X.md`. O plano inclui ficheiros e linhas específicos, testes, riscos previstos com dois ou três passos de antecedência e um plano de reversão. O ficheiro dura mais do que a conversa: pode abri-lo duas semanas depois e voltar a utilizar a abordagem três meses mais tarde.
Agora, o Plan Mode está a funcionar como previsto. O prompt: ``` Escolhe a melhor opção do passo 2 e escreve um plano pormenorizado no ficheiro plans/YYYY-MM-DD-fix-[name].md: - que ficheiros específicos vamos alterar (caminhos completos e números de linha) - o que vamos acrescentar e o que vamos remover - que testes vamos escrever e quais dos existentes têm de passar - riscos com dois a três passos de antecedência (o que pode deixar de funcionar para os utilizadores) - um plano de reversão caso algo corra mal Transforma cada passo numa caixa de verificação [ ]. O ficheiro tem de caber num ecrã. Se o plano tiver mais de 200 linhas, divide-o em fases. ``` O resultado. O plano passa a ser um artefacto, em vez de uma nota temporária no chat. Pode lê-lo duas semanas depois, entregá-lo a outro agente ou usá-lo como condição para o comando `/goal`. Um ficheiro de plano dura mais do que a conversa no Claude Code. A parte fundamental são os riscos previstos com dois ou três passos de antecedência. Isto bloqueia outro padrão de bajulação: um plano otimista sem efeitos secundários. Quando pede explicitamente ao Claude que enumere os riscos, ele encontra coisas que teria ignorado silenciosamente num plano normal. ## Passo 4. Faça uma autoavaliação do plano — detete pressupostos bajuladores
Principais conclusões O filtro final. O Claude relê o próprio plano e assinala os pontos que inventou: bibliotecas que não estão em package.json, variáveis que nunca especificou e passos descritos de forma vaga. Na amostra do autor, de cerca de 50 ciclos, dois ou três itens do plano são revistos especificamente no passo 4.
O filtro final. O prompt: ``` Agora faz uma autoavaliação obrigatória. Relê o teu plano com honestidade. Há pontos que inventaste e que não confirmaste através de: - código que leste; - documentação que citaste no passo 2; - um precedente do passo 2? Se houver, assinala-os explicitamente, revê-os ou elimina-os. Verifica também: - se menciona bibliotecas que ainda não estão instaladas em package.json; - se menciona variáveis de ambiente que não especifiquei; - se o plano tem passos descritos em termos gerais em vez de pormenorizados. ``` O que faz. O Claude tem de voltar a verificar o seu próprio raciocínio. Na amostra do autor, de cerca de 50 ciclos, pelo menos dois ou três itens do plano são revistos especificamente no passo 4. São pontos por onde o bajulador tentou passar no passo 3 e que o passo 4 deteta. Depois dos quatro passos, o plano está pronto para ser aprovado. Pode avançar para a implementação sem se preocupar: «E se tiver de reverter 8 commits?» ## Porquê exatamente 4 passos, e não 2 ou 7?
Principais conclusões O ciclo baseia-se na metodologia canónica Explore-Plan-Implement-Commit da Anthropic. Das quatro fases da Anthropic, desenvolvo a Plan em quatro micro-passos para combater a bajulação. Cada passo bloqueia a sua própria classe de erros: se saltar qualquer um, terá um tipo de falha previsível.
Eis o raciocínio, seguindo o método que a Anthropic usa para orientar o Claude na sua documentação oficial.
Se deixar o Claude avançar diretamente para o código, pode obter uma solução para o problema errado. Use o Plan Mode para separar a exploração da execução.
— Claude Code Docs, https://code.claude.com/docs/en/best-practices
A documentação recomenda um fluxo de trabalho em quatro fases: Explore, Plan, Implement, Commit. O meu ciclo de 4 passos é uma especialização da fase Plan para combater a bajulação. Das quatro fases da Anthropic, desenvolvo uma em quatro micro-passos: proibir soluções, procurar precedentes, escrever o plano e fazer uma autoavaliação. Trata-se de um plano detalhado que é depois transmitido às fases Implement e Commit. Eis o que corre mal se saltar qualquer um dos quatro passos: | Passo ignorado | O que obtém | |----|----| | Passo 1 (factos) | Uma solução para o problema de outra pessoa: o Claude adivinhou o sintoma com base num padrão e seguiu na direção errada | | Passo 2 (precedentes) | Uma solução inventada a partir de «conhecimentos gerais»: funciona no caso de referência e falha na realidade | | Passo 3 (plano) | Implementação sem análise de riscos: os testes falham, o token de atualização deixa de funcionar e os utilizadores dão-lhe conta do problema | | Passo 4 (autoavaliação) | Um plano com dois ou três pressupostos sem fundamento: uma biblioteca que não existe, uma variável que não foi especificada | A tabela deixa-o claro: cada passo bloqueia a sua própria classe de erros. Precisa dos quatro porque cada um deteta uma categoria diferente. Se a tarefa parecer suficientemente pequena para dois passos, então é mesmo pequena — e não precisa de usar o Plan Mode. ## Como se relacionam `plans/`, o comando `/goal` e os passos seguintes
Principais conclusões Os 4 passos não existem isoladamente. Funcionam dentro de um sistema composto pelo Plan Mode, pela pasta `plans/` no repositório e pelo comando `/goal`. O Plan Mode fornece o modo. A pasta `plans/` garante a durabilidade. `/goal` fornece a automatização. Sem qualquer uma destas três camadas, o ciclo perde metade do seu valor.
O ciclo funciona num sistema que inclui: 1. Plan Mode ativado (duplo Shift+Tab no Claude Code). 2. Uma pasta `plans/` no repositório para guardar os planos. 3. Opcionalmente, o comando `/goal` para implementar planos longos de forma autónoma. Mais especificamente, sobre a pasta `plans/`. Depois do passo 3, obtém um ficheiro `plans/2026-05-27-fix-magic-link.md` com fases e caixas de verificação. É um artefacto. Abra-o uma semana depois e lembrar-se-á do motivo por que escolheu aquela abordagem. Daqui a três meses, encontrará uma tarefa semelhante e reutilizá-la-á. Daqui a seis meses, mostrá-la-á a um colega e poupar-lhe-á duas semanas de integração. A pasta `plans/` faz parte do conceito de [«segundo cérebro» no Claude Code](https://ailoot.ai/blog/pt-pt/claude-code-second-brain/). Mais especificamente, sobre `/goal`. Depois de concluir os quatro passos e aprovar o plano, sai do Plan Mode e introduz: ``` /goal executar todas as fases de plans/2026-05-27-fix-magic-link.md, todos os testes em test/auth passam ou parar após 30 turnos ``` Numa sessão local do Claude Code, mantenha o terminal em execução, o computador acordado e a rede disponível. Não feche o portátil sem ter configurado explicitamente uma forma suportada de o manter acordado. Ao regressar, examine o histórico: pode indicar conclusão, limite de turnos, pedido de permissão ou erro. Um objetivo não garante progresso enquanto a máquina dorme. Sem o ciclo de 4 passos, o `/goal` desperdiça tokens em iterações inúteis. Com o ciclo de 4 passos, o `/goal` leva um plano concluído até aos testes passarem. O que fazer a seguir. Se está a começar a utilizar o Claude Code, experimente o ciclo na próxima tarefa não trivial. Não um erro tipográfico. Algo que envolva 3+ ficheiros ou um comportamento que não compreenda totalmente. Pegue nos prompts acima, copie-os e preencha os seus próprios detalhes. Vai notar como muda a taxa de reversões. Se já utiliza o Plan Mode, acrescente uma pasta `plans/` ao seu repositório. Defina consigo próprio um formato para os nomes dos ficheiros: `YYYY-MM-DD-feature-name.md`. Dentro de um mês terá 20–30 ficheiros; dentro de seis meses, mais de uma centena. É assim que se constrói o segundo cérebro do projeto: um histórico vivo de decisões. Se quiser aprofundar a gestão do contexto antes do prompt, abordei a [engenharia de contexto no Claude Code](https://ailoot.ai/blog/pt-pt/context-engineering/) como disciplina autónoma. Se já tem o Plan Mode e `plans/`, experimente `/goal` numa tarefa autónoma. Escolha uma tarefa que normalmente faria à mão em 30–40 minutos. Execute-a pelos 4 passos, guarde o plano, inicie `/goal` e mantenha o terminal local e o computador acordados. Para trabalhar com esse computador desligado, configure primeiro um percurso remoto ou na nuvem e confirme que a tarefa está efetivamente em execução aí.
### Fontes - [Anthropic Engineering - Best practices for Claude Code](https://code.claude.com/docs/en/best-practices) - [Anthropic Engineering - April 23 postmortem about quality reports](https://www.anthropic.com/engineering/april-23-postmortem) - [Anthropic Docs - Reduce hallucinations](https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-hallucinations) - [Anthropic Docs - Permission Modes (Plan Mode)](https://code.claude.com/docs/en/permission-modes) - [Anthropic Docs - /goal command](https://code.claude.com/docs/en/goal)
Pode continuar a trabalhar com IA na [Ailoot](https://ailoot.ai/).
## Perguntas frequentes ### Um /goal local continua a trabalhar se eu fechar o portátil? Só se a máquina permanecer acordada e o processo de terminal continuar; a suspensão normal pode parar o trabalho local. Mantenha computador e rede disponíveis ou verifique que iniciou efetivamente a tarefa num ambiente remoto ou na nuvem separado. ### Quando compensa o esforço do ciclo de quatro prompts? Use-o quando o sintoma, os ficheiros afetados ou a abordagem forem pouco claros e uma alteração errada for cara. Comece por um sintoma reproduzível e pela evidência em falta, procure fontes, escreva o plano e verifique os pressupostos; um simples erro de escrita costuma dispensar o ciclo. ## Ailoot · A empresa e a sua carteira de projetos A Ailoot assenta numa experiência operacional consolidada, numa ampla base de clientes, num serviço estável e no acompanhamento contínuo dos KPI. A empresa e a sua carteira de projetos: milhões de clientes; vendas mensais na ordem dos milhares de milhões. A Ailoot aplica essa experiência operacional ao acesso por API a funcionalidades de IA nos produtos dos clientes, agentes, aplicações e automatizações.