A frase que parte tudo

O que é e porque importa

A frase que parte tudo é aquela atirada para o ar: «arranja o login», «põe a página mais rápida», «acrescenta os pagamentos». O Claude Code leva-a a sério e faz alguma coisa. O problema é que decide ele o que quer dizer «arranjado», em que pode mexer e quando terminou.

Não é um defeito da IA. É que não te lê o pensamento. O próprio guia da Anthropic sobre prompts diz isto de forma simples: trata-o como um colega brilhante mas acabado de chegar, que não conhece as tuas regras nem o teu projeto. Quanto mais preciso fores sobre o que queres, melhor é o resultado.

Por isso, antes de cada pedido, preencho um modelo de três linhas: o que tem de acontecer, o que não pode mudar, como o verificamos. Demoro pouco. Poupa-me a pior parte, que é descobrir no fim que ele reescreveu uma coisa que funcionava. A mesma IA, com um pedido claro, dá-te um resultado diferente. Não é magia: é ser claro com alguém que não te lê o pensamento.

O modelo de três linhas

Aqui está. Copia-o e preenche os parênteses retos. Uma linha por parte chega.

O que tem de acontecer: [o resultado que queres ver, por palavras tuas]
O que não pode mudar: [ficheiros, páginas ou funções em que não deve mexer]
Como o verificamos: [como sabes que funciona: um teste, um clique, um dado que tem de aparecer]

O que tem de acontecer

O resultado que queres ver, não a forma de lá chegar. Escreve-o por palavras tuas, como o dirias em voz alta. «Quando carrego em Guardar, a nota aparece na lista» funciona melhor do que «resolve o bug de guardar», porque diz o que deve ver quem usa a app. Se sabes onde acontece, que página, que botão, escreve-o: assim o Claude não tem de adivinhar.

O que não pode mudar

Os limites: ficheiros, páginas ou funções que têm de ficar como estão. Para resolver uma coisa, às vezes o Claude «melhora» outras ao lado que ninguém lhe pediu. Se lhe disseres onde não deve mexer, ele tem um limite claro. É a linha que quase todos saltam, e volto a ela mais abaixo.

Como o verificamos

Como sabes que funciona: um teste, um clique, um dado que tem de aparecer. Esta linha serve-te a ti e serve ao Claude. Se ele tiver uma verificação que consegue fazer sozinho, tipo um teste que passa ou falha, pode experimentar, ler o resultado e corrigir-se antes de te dizer que terminou. Sem isso, o único sinal é que o trabalho «parece feito», e a verificação fica contigo.

Dois exemplos para copiar

Exemplo 1: um botão que não guarda

O que tem de acontecer: quando carrego no botão Guardar na página Notas, tem de criar uma linha na tabela das notas na base de dados.
O que não pode mudar: não mexas no login e não mudes o design da página.
Como o verificamos: diz-me exatamente como o testo, passo a passo, e se conseguires escreve um teste que o verifique.

Repara na terceira linha. Não precisas de saber escrever um teste: peço ao Claude que me diga como o experimentar e, se conseguir, que o escreva ele. Não tens de saber como se verifica. Só tens de exigir que haja uma forma.

Exemplo 2: uma página lenta

O que tem de acontecer: a página de preços tem de abrir em menos de dois segundos, também no telemóvel.
O que não pode mudar: os preços, os textos e o pagamento ficam idênticos.
Como o verificamos: mede o tempo de carregamento antes e depois, e mostra-me os dois números.

Aqui a verificação é um número antes e outro depois. Se o Claude te disser «agora está mais rápido» sem os dois números, não sabes se é verdade. E a linha do meio protege o que não queres ver mudar por engano enquanto ele otimiza: preços, textos, pagamento.

Três conselhos para o usar no Claude Code

1. Se não sabes como o verificar, para

Se não sabes responder a «como o verificamos», ainda não sabes o que queres. Acontece, e é melhor dares por isso antes do que depois. Em vez de pôr o trabalho a andar, pede ajuda para perceber:

Ajuda-me a perceber como verificar isto, não escrevas código.

Para os trabalhos maiores uso o modo de plano do Claude Code (plan mode). O Claude lê os ficheiros e propõe-te um plano, mas não altera nada até o aprovares. Entras nele carregando em Shift+Tab até aparecer «plan mode on» em baixo, ou escrevendo /plan antes da mensagem. É aí que colo o modelo e pergunto:

Lê o modelo abaixo e propõe-me um plano. Diz-me em que ficheiros pensas mexer, confirma que não mexes nos que excluí e explica-me como vamos fazer a verificação da última linha.

[cola aqui o modelo preenchido]

Para uma alteração pequena não precisas do plano: se a descreves numa frase, tipo corrigir uma gralha num texto, pede-a diretamente.

2. Não saltes a linha do meio

«O que não pode mudar» é a parte que todos saltam, e é a que te salva o login, os pagamentos e os dados reais. Aquilo em que nunca deve mexer, escrevo-o também no CLAUDE.md, o ficheiro na pasta do projeto que o Claude Code lê no início de cada sessão. Por exemplo, esta linha:

Não alteres o login, os pagamentos nem os dados dos utilizadores sem me perguntares antes.

Atenção, porém: o CLAUDE.md é uma instrução, não um cadeado. O Claude trata-o como contexto, não como um bloqueio. Por isso, quando o pedido passa perto dessas partes, volto a escrevê-las no modelo.

3. No fim, pede o relatório

Quando terminar, pergunta sempre:

Diz-me o que mudaste e em que não mexeste.

Depois compara a resposta com o modelo. Se mexeu em alguma coisa da linha do meio, ou se falta a verificação da terceira linha, vês logo. Nesse caso não avanço e peço:

Mostra-me a prova da última linha do modelo: o teste com o resultado, ou os passos exatos para eu o experimentar.

Os erros mais comuns

• Descrever o código em vez do resultado, tipo «muda essa função»: escreve o que deve ver quem usa a app e deixa o como ao Claude.
• Deixar vazio «o que não pode mudar» porque parece óbvio: escreve pelo menos login, pagamentos e dados reais quando o trabalho passa perto.
• Uma verificação vaga como «vê se funciona»: pede uma coisa que se veja ou se meça, ou seja, um teste que passa, um clique, um número.
• Meter três pedidos no mesmo modelo: um modelo, uma só coisa, e as outras pedes depois, uma de cada vez.
• Confiar no «feito» sem relatório: pergunta o que mudou e em que não mexeu, e compara com o modelo.

Checklist

• Escrevi o resultado por palavras minhas
• Escrevi em que não deve mexer
• Sei como vou verificar que funciona
• O modelo pede uma só coisa
• Para um trabalho grande pedi primeiro um plano
• No fim perguntei o que mudou e o que não mudou

Perguntas frequentes