Como criar prompts para programação com o ChatGPT

Crie prompts para programação com o ChatGPT descrevendo a decisão de engenharia, não apenas o código que você quer receber. Dê a ele o código relevante ou o contexto do repositório, o comportamento a preservar, um resultado concreto e uma forma de verificar o resultado.

“Escreva uma função que faça X” pode bastar para um pequeno utilitário. Não basta quando uma alteração afeta o comportamento do usuário, um contrato compartilhado ou um sistema de produção.

Antes de pedir código, informe quatro pontos:

• O que existe agora: o componente, a função, a API ou a falha relevantes.
• O que deve mudar: um resultado visível para o usuário ou para o sistema.
• O que não deve mudar: compatibilidade, desempenho, acessibilidade, contratos ou APIs públicas.
• Como verificar: testes, etapas de reprodução, verificações de tipos ou critérios de aceitação manuais.

Se você usa um espaço de trabalho persistente do ChatGPT, mantenha as notas de arquitetura, os requisitos e os arquivos relevantes juntos. Os Projetos do ChatGPT podem organizar conversas, arquivos de referência e instruções específicas do projeto; verifique seu plano atual e os controles do espaço de trabalho antes de enviar material de código-fonte.

Evite isto:

Crie um componente de envio de arquivos.

Isso não define responsabilidade, tratamento de erros, limites de arquivos, acessibilidade nem o contrato da interface ao redor.

Use uma solicitação com limites claros:

Temos uma página de configurações em React que já é responsável pelo envio do
formulário e pelas mensagens de erro. Adicione um componente de envio de arquivos
ao formulário existente.

Resultado: Um usuário pode selecionar um PNG ou JPEG de até 5 MB, ver o nome do
arquivo selecionado, removê-lo antes do envio e receber a mensagem de erro
localizada existente para arquivos inválidos.

Restrições: Não adicione uma nova biblioteca de estado, não crie um endpoint de
envio e mantenha o manipulador de envio atual como o único responsável pelo estado
do formulário.

Retorne o menor conjunto de arquivos alterados, explique cada alteração e inclua
testes para tipo inválido, limite de tamanho, remoção e seleção bem-sucedida.

A solicitação torna o componente menor porque descarta arquitetura desnecessária.

Para depuração, peça uma hipótese e um caminho de reprodução antes de pedir um patch:

Sintoma: O botão Salvar permanece desativado depois que uma nova tentativa da chamada à API é bem-sucedida.

Comportamento esperado: O botão fica disponível após a nova tentativa bem-sucedida.
Comportamento observado: Os dados da resposta aparecem, mas o botão continua desativado.

Contexto relevante: O botão depende de isPending e form.isDirty. Isso começou
depois que novas tentativas foram adicionadas ao hook de mutação.

Primeiro, liste as transições de estado mais prováveis e as evidências necessárias
para confirmar cada uma. Depois, proponha a menor correção e o teste de regressão.

Isso é mais seguro do que “corrija o botão desativado”, pois pede ao ChatGPT que diferencie um bug de estado obsoleto de um problema de validação ou renderização da interface.

Solicitações de refatoração precisam de uma cláusula de preservação mais forte:

Refatore a lista de cartões de preços para remover a lógica duplicada de renderização de planos.

Preserve: propriedades públicas, nomes de eventos de analytics, destinos de checkout,
comportamento de teclado, estados de carregamento e o layout móvel existente.

Escopo: Limite as alterações ao recurso de preços e aos testes diretamente relacionados.
Não introduza uma abstração de sistema de design a menos que o componente primitivo
existente não consiga expressar o comportamento compartilhado.

Critérios de aceitação: Testes de snapshot ou interação cobrem cada estado do plano, e
os links renderizados e as cargas úteis dos eventos permanecem inalterados.

Antes de editar, identifique a duplicação e qualquer comportamento oculto que os dois
cartões implementam de forma diferente.

A expressão “preserve o comportamento” não basta sozinha. Nomeie o comportamento que importa.

Não peça “testes para este componente” sem um contrato. Nomeie os cenários:

Escreva testes para o formulário de redefinição de senha usando a pilha de testes existente.

Cubra:
1. um e-mail inválido mostra a mensagem de validação localizada;
2. o envio envia o e-mail normalizado uma vez;
3. um erro de rede mantém o valor inserido e mostra o estado de erro existente;
4. uma resposta bem-sucedida anuncia a confirmação sem revelar se uma conta existe.

Não simule detalhes de implementação. Prefira funções e rótulos acessíveis.

Isso informa ao assistente o que o usuário precisa conseguir fazer e qual comportamento de privacidade não pode regredir.

Um prompt de explicação deve pedir uma trilha de evidências, não um resumo:

Explique como o estado de autenticação chega à tela de cobrança neste repositório.

Rastreie o caminho do provedor à proteção de rota e à chamada de checkout. Nomeie os
arquivos e símbolos exportados envolvidos. Separe o comportamento confirmado dos
pressupostos e liste o que você investigaria em seguida se alguma parte não estiver clara.

Esse formato facilita identificar uma dependência ausente ou uma conexão inventada.

O ChatGPT é mais confiável quando você fornece o contexto mais restrito que responde à pergunta:

• um teste que falha e o código que ele exercita;
• o componente e o hook que é responsável pelo estado;
• um exemplo de solicitação/resposta com valores confidenciais removidos;
• as convenções do projeto que restringem a alteração;
• uma lista curta de arquivos que estão intencionalmente fora do escopo.

Não envie segredos, tokens de acesso de produção, dados de clientes ou logs privados que você não tem permissão para compartilhar. Substitua esses valores por versões ocultadas de modo realista e mantenha o comportamento que você precisa analisar.

Para conhecer a estrutura geral por trás desses prompts, leia como escrever prompts melhores para IA. Para um conjunto de padrões de implementação e revisão baseados em funções, continue com engenharia de prompts para desenvolvedores. Use exemplos de engenharia de prompts para engenheiros de software quando quiser ver uma solicitação trabalhada de antes e depois, e use os modelos de prompt para depurar problemas de produção antes de investigar um problema ativo.

Código gerado é uma proposta. Execute os testes relevantes, inspecione o diff e teste você mesmo o caminho afetado. Quando o trabalho envolve saída de comando, erros ou scripts de shell, reproduzir o fluxo de trabalho faz parte da validação — não é um extra opcional. Use a área de prática de linha de comando no navegador para desenvolver esse hábito com entradas e feedback reais de comandos.