Anatomia de um prompt técnico
Os seis campos que separam um pedido que gera chute de um que gera hipótese testável — com o mesmo problema escrito das duas formas.
Com o contexto do projeto resolvido, sobra o pedido em si. Um bom pedido técnico não é longo nem educado: é específico sobre seis coisas.
- Escrever pedidos que produzem hipóteses verificáveis em vez de palpites.
- Definir o formato da resposta para acelerar a sua revisão.
- Obrigar o assistente a perguntar quando faltar informação.
Corrige esse erro: TypeError: Cannot read properties of undefined (reading 'total')
Vem uma lista de cinco causas genéricas e um if (obj && obj.total) que esconde o problema em vez de resolver.
Objetivo: descobrir por que o resumo do carrinho quebra para alguns usuários. Ambiente: Node 18, Express 4, TypeScript 5. Comportamento atual: TypeError: Cannot read properties of undefined (reading 'total') em cart.service.ts:48, em ~2% dos requests. Comportamento esperado: carrinho vazio deve devolver total 0, não estourar. Já tentei: reproduzir com carrinho vazio localmente — não reproduz. Restrição: não posso mudar o contrato da resposta da API. Saída: 1) 3 hipóteses ordenadas por probabilidade; 2) para cada uma, o experimento mínimo que a confirma ou elimina; 3) só depois, a correção. Pergunte se faltar informação.
Vem uma fila de verificações — incluindo a hipótese de corrida entre a limpeza de sessão e a leitura, que explica os 2% e a não reprodução local.
A diferença: O segundo pedido não é mais educado nem mais longo por capricho. Ele contém as três informações que mudam tudo: a frequência (2%, não sempre), a tentativa que falhou (não reproduz local) e o formato da resposta (hipóteses antes de correção).
Os seis campos
| Campo | O que responde | O que muda se faltar |
|---|---|---|
| Objetivo | O que precisa ser verdade no final | A resposta otimiza a coisa errada |
| Ambiente | Linguagem, versões, framework | Volta a alucinação de API da aula 1 |
| Atual × esperado | O delta exato entre o que é e o que deveria ser | A resposta descreve o óbvio |
| Evidência | Erro completo, frequência, entrada mínima | Vira adivinhação sobre a causa |
| Restrição | O que não pode mudar | Vem uma reescrita que você não pode usar |
| Formato da saída | Como a resposta deve chegar | Vem texto corrido difícil de revisar |
A frequência merece destaque próprio porque é o campo mais esquecido e o mais informativo. "Sempre" aponta para lógica; "às vezes" aponta para dado, concorrência ou ambiente; "só em produção" aponta para configuração, volume ou fuso. Uma palavra elimina metade do espaço de busca.
Objetivo: [o que precisa ser verdade no final] Ambiente: [linguagem, versões, framework — se não estiver no contexto] Comportamento atual: [o que acontece, com erro completo] Comportamento esperado: [o que deveria acontecer] Frequência: [sempre / ~X% dos casos / só em produção / desde a mudança Y] Já tentei: [o que fiz e o que descobri] Restrições: não alterar [itens]; seguir [padrão] Saída esperada: 1) perguntas, se faltar informação 2) hipóteses ordenadas, cada uma com o experimento que a confirma 3) só depois, a alteração mínima 4) o teste que falha antes e passa depois Marque como PREMISSA tudo que você assumiu sem eu ter dito.
A última linha é a mais útil do template: ela transforma suposição silenciosa em item de lista que você pode conferir.
Quando o pedido termina em "me dá o código", a resposta vem em código — mesmo quando o assistente não tinha informação para decidir. O formato do pedido determina o formato do risco.
Inverter a ordem custa uma mensagem e economiza um ciclo inteiro de revisão: primeiro perguntas e hipóteses, depois código.
Como perceber: Se a primeira resposta já veio com o diff pronto e sem nenhuma pergunta num problema que você mesmo não entendeu ainda, o pedido estava mal formado.
- Pegue no seu histórico um pedido técnico que resultou em resposta ruim.
- Reescreva usando os seis campos, sem mudar o problema.
- Rode os dois em conversas separadas.
- Marque na segunda resposta o que só apareceu por causa de um campo específico.
- A segunda resposta faz pelo menos uma pergunta ou marca ao menos uma premissa.
- Você consegue apontar qual campo produziu qual ganho.
- Seis campos: objetivo, ambiente, atual × esperado, evidência com frequência, restrição e formato da saída.
Comentários e dúvidas
Inscreva-se grátis para comentar, tirar dúvidas, marcar seu progresso e emitir o certificado ao fim do curso.
Inscrever-se grátis com GoogleAinda não há comentários nesta aula.