As quatro restrições que fazem cada prompt abaixo funcionar
Antes dos prompts, as regras que todos eles compartilham. Adicionar isso a qualquer prompt de código melhora mais a saída do que trocar de modelo.
Informe sua versão. Os dados de treinamento tendem a favorecer a versão principal sobre a qual mais se escreveu, que muitas vezes não é a que você está usando. Estamos na versão [versão] do [framework], [linguagem] [versão] evita a maioria das respostas desatualizadas.
Restrinja o diff. Peça uma correção e frequentemente você recebe uma refatoração. Mude o mínimo possível, preserve a estrutura e a nomenclatura existentes, e liste cada linha alterada com um motivo de uma linha é a frase mais útil deste documento.
Peça hipóteses antes de soluções. Um modelo perguntado o que está errado te dá um chute apresentado como conclusão. Um modelo perguntado por causas ranqueadas e verificações baratas te dá um plano de debugging.
Exija o modo de falha. O que isso poderia quebrar, e isso corrige a causa ou o sintoma? pega a classe mais cara de assistência de IA, que é uma mudança que faz o sintoma sumir enquanto o defeito permanece.
Debugging
1. Hipóteses ranqueadas
Aqui está o erro, o código relevante e o que eu já descartei. Ainda não me dê uma correção. Liste as quatro causas mais prováveis, ranqueadas por probabilidade, e para cada uma a verificação mais barata que confirmaria ou eliminaria essa hipótese. Erro: [colar]. Código: [colar]. Já descartado: [lista]. Stack: [linguagem, framework, versões].
2. O bug intermitente
Isso falha de forma intermitente, aproximadamente [frequência], sob [condições]. Enumere as categorias de falha intermitente que poderiam produzir esse sintoma específico: timing, ordenação, esgotamento de recursos, uma dependência externa, estado vazando entre execuções, fuso horário ou relógio, cache. Para cada uma, diga o que no código sustenta ou contradiz essa hipótese, e exatamente o que eu deveria registrar em log para distingui-las. Código: [colar].
3. Funciona localmente
Isso funciona localmente e falha em [ambiente]. Liste todas as categorias de diferença de ambiente que poderiam causar esse sintoma específico: configuração, variáveis de ambiente, versões, sistema de arquivos e sensibilidade a maiúsculas e minúsculas, fuso horário e localidade, rede e DNS, permissões, limites de recursos, e diferenças de build ou empacotamento. Ranqueie por probabilidade dado o sintoma, e me dê o comando de diagnóstico para cada uma.
4. Explique a correção antes de eu aplicá-la
Explique por que essa correção funciona, o que ela não corrige, e o que ela poderia quebrar. Se a causa real está em outro lugar e isso é um remendo no sintoma, diga isso diretamente.
Code review
5. Revisar um diff
Revise este diff como um revisor exigente. Categorias em ordem de prioridade: bugs de corretude, problemas de segurança, modos de falha não tratados, condições de corrida, depois estilo. Para cada achado, dê a severidade, a linha específica, e por que isso importa nesta base de código, e não em geral. Não comente sobre formatação. Se o diff estiver correto, diga isso em vez de inventar achados. Convenções: [descrever]. Diff: [colar].
6. A passada de segurança
Revise este código especificamente por problemas de segurança: injeção, falhas de autenticação e autorização, desserialização insegura, segredos no código ou em logs, entrada não validada chegando a uma operação sensível, e risco de dependências. Para cada um, dê o caminho de ataque de forma concreta, em vez de apenas nomear a categoria. Declare claramente o que você não consegue avaliar sem ver [deployment, camada de autenticação, sensibilidade dos dados].
7. A auditoria de modo de falha
Para cada chamada externa neste código, declare o que acontece quando ela está lenta, quando falha, quando retorna dados inesperados, e quando tem sucesso parcial. Quais dessas situações estão atualmente sem tratamento, e quais seriam silenciosas?
Esse último prompt encontra mais problemas reais de produção do que uma revisão geral, porque questiona os caminhos para os quais ninguém escreveu um teste.
Refatoração e arquitetura
8. O plano de refatoração
Proponha um plano sequenciado para refatorar [descrição]. Restrições: a API pública de [x] não pode mudar, fazemos deploy contínuo então cada etapa precisa ser entregável de forma independente, e os testes precisam passar após cada etapa. Para cada etapa, dê a mudança, o risco, como verificá-la, e como reverter. Ordene por risco, do menor para o maior. Ainda não escreva o código.
9. Defenda o outro lado
Estou escolhendo [abordagem A] em vez de [abordagem B] para [contexto e restrições]. Faça o caso mais forte possível para B. O que precisaria ser verdade sobre nossas restrições para B estar correta, e algo disso é verdade aqui? Não conclua que ambas são válidas.
10. Entenda o que você herdou
Aqui estão os principais arquivos de origem. Produza: os pontos de entrada, o fluxo de dados da requisição até a resposta, o estado que é compartilhado e onde é mutado, dependências externas e o que acontece quando cada uma está indisponível, e as três áreas mais propensas a conter bugs com base na complexidade e no acoplamento. Declare explicitamente o que você não consegue determinar a partir do que forneci.
Essa última instrução importa. Modelos vão descrever o comportamento de um arquivo que você não colou, inferido a partir do nome dele. Forçar uma lista explícita de incertezas mostra o que você precisa ir ler.
Testes
11. Os testes que você não teria escrito
Escreva casos de teste para esta função, focando em entradas que eu provavelmente não considerei: limites, vazio e nulo, unicode, valores muito grandes, chamadas concorrentes, e qualquer suposição implícita na implementação. Para cada teste, declare a suposição que ele está verificando. Função: [colar].
12. Teste a suíte de testes
Aqui está uma função e seus testes existentes. Que comportamento não está coberto? Especificamente: caminhos de erro, valores limite, interações entre parâmetros, e qualquer coisa que a implementação faça que nenhum teste verifique. Não reescreva os testes existentes.
O segundo é o prompt de maior valor e é raramente usado. Percentuais de cobertura dizem quais linhas foram executadas, não quais comportamentos estão de fato garantidos, e a lacuna entre essas duas coisas é onde vivem as regressões.
O padrão de segunda opinião
O hábito de maior alavancagem em todo este pacote, e o único que exige mais de um modelo.
Obtenha uma resposta de um modelo. Depois troque e passe adiante:
Outro engenheiro propôs esta solução para este problema. Encontre o que está errado com ela: corretude em casos extremos, concorrência, tratamento de erros, desempenho em [escala], ou uma abordagem mais simples que foi ignorada. Se for genuinamente sólida, diga isso claramente em vez de inventar objeções. Problema: [colar]. Solução proposta: [colar].
Dois resultados possíveis, e ambos são úteis. Ou o segundo modelo encontra uma falha real, o que você agora sabe antes de fazer o merge, ou ele concorda mesmo sendo pressionado a discordar, o que é uma confirmação significativa. Iterar com o mesmo modelo não te dá nenhum dos dois, porque um modelo revisando sua própria saída, na maioria das vezes, concorda consigo mesmo.
Use isso nas decisões caras de errar: uma mudança de schema, uma correção de concorrência, qualquer coisa que envolva autenticação ou dinheiro. Não em trabalho rotineiro. Veja comparar modelos lado a lado, trocar de modelo no meio da conversa, e escrever e depurar código com múltiplos modelos para o fluxo de trabalho completo em um só lugar.
O que observar
APIs inventadas. Nomes de métodos, parâmetros e chaves de configuração apresentados com confiança, mas que não existem, especialmente para bibliotecas que mudaram recentemente. A assinatura vai parecer correta. Verifique a documentação real antes de construir sobre qualquer coisa não familiar.
Nenhum sinal de confiança. Uma correção certa e uma sutilmente errada chegam com a mesma certeza aparente. O tom não diz nada.
Aumento de escopo silencioso. É exatamente para isso que existe a segunda restrição.
Teatro de segurança. Nomear classes de vulnerabilidade no seu código é uma primeira passada útil. Não é uma auditoria, e o modelo não conhece seu modelo de ameaça, seu deployment, nem a sensibilidade dos seus dados.
Mantenha os prompts que você usa semanalmente em algum lugar de onde você possa colar, e coloque restrições permanentes nas instruções de um projeto para que se apliquem automaticamente a todo chat naquele projeto.
- Informe sua linguagem, framework e versão em todo prompt de código
- Adicione a frase de restrição de diff a qualquer prompt que produza código
- Peça hipóteses ranqueadas e verificações baratas antes de pedir uma correção
- Sempre pergunte o que uma correção poderia quebrar e se ela trata o sintoma
- Rode o padrão de segunda opinião em qualquer coisa cara de errar
- Pergunte o que a suíte de testes existente não cobre, não só por mais testes
- Verifique APIs não familiares contra a documentação real
- Mantenha os prompts que você usa semanalmente onde possa colá-los
Perguntas frequentes
Esses prompts funcionam só com o Claude?
Não. Eles são escritos para o estilo de raciocínio cuidadoso e contexto longo em que o Claude se destaca, e funcionam diretamente com GPT e Gemini também. Na verdade, vários deles são mais úteis usados entre modelos diferentes: o prompt de segunda opinião exige dois, e o prompt "defenda o outro lado" é mais útil quando o modelo que argumenta não fez a escolha original.
Qual modelo devo usar para qual prompt?
Como ponto de partida: Claude para raciocínio sutil, arquitetura não familiar, e explicar por que algo se comporta de determinada forma; GPT para implementação rápida em terreno já bem conhecido e saída estruturada rígida; um modelo de contexto grande quando a pergunta abrange mais código do que cabe confortavelmente em um prompt normal. Depois substitua isso por uma semana das suas próprias comparações, já que a resposta certa depende mais da sua stack do que de qualquer benchmark.
Isso substitui uma ferramenta de codificação agêntica?
Não, eles resolvem problemas diferentes. Um agente vive no seu repositório e edita arquivos. Esses prompts são para a camada de raciocínio: entender um erro, revisar um diff, planejar uma refatoração, argumentar sobre uma abordagem. A maioria dos desenvolvedores usa os dois, e a escolha do modelo importa mais aqui porque você está avaliando o raciocínio, e não o diff resultante.
Como eu impeço que ele reescreva código que eu não pedi?
Adicione isso ao prompt: mude o mínimo possível, preserve a estrutura e a nomenclatura existentes, e liste cada linha alterada com um motivo de uma linha. Refatoração não solicitada é o principal motivo pelo qual sugestões de IA se tornam impossíveis de revisar, e restringir o diff é a diferença entre uma mudança que você consegue raciocinar sobre e uma que você precisa reler do zero.
Posso colar código proprietário?
O Whizi não treina com base nas suas conversas e a política de dados de cada provedor pode ser revisada antes de você ativar aquele modelo, mas a política da sua empresa é a restrição que vale, e ela varia muito. Onde houver restrições, reproduzir o problema como um exemplo mínimo que preserva a estrutura e remove a lógica de negócio costuma ser tanto permitido quanto um prompt melhor, já que remove o detalhe que estava competindo pela atenção.