Como escrever prompts melhores para IA: o contexto que falta e torna as sugestões de IA realmente úteis

Prompts melhores para IA não são necessariamente mais longos. Eles contêm o contexto de que um assistente precisa para tomar a decisão certa, em vez de apenas produzir uma alteração plausível. No trabalho de engenharia, isso normalmente significa indicar o escopo, o pressuposto, o resultado desejado, as restrições e o motivo de a alteração ser importante.

Essa é a diferença entre uma resposta que compila e uma alteração que ajuda o produto.

Um assistente pode escrever código válido a partir de uma instrução curta, mas uma instrução curta muitas vezes esconde a decisão de produto. “Remova a barra lateral no celular” diz ao assistente o que alterar. Não diz se o comportamento no desktop deve permanecer intacto, por que o comportamento atual prejudica as pessoas ou como avaliar o sucesso.

Quando esse contexto falta, o assistente precisa adivinhar. Ele pode fazer uma alteração tecnicamente organizada que remove um fluxo útil no desktop, modifica um layout não relacionado ou resolve um sintoma em vez do problema.

Use um prompt como um briefing de engenharia conciso, não como um comando.

Comece com estas seis informações:

1. Escopo: Qual tela, arquivo, fluxo ou comportamento está no escopo?
2. Problema: O que é difícil, quebrado, lento ou confuso para alguém que usa o produto?
3. Pressuposto: O que você acha que está causando o problema?
4. Resultado desejado: O que deve ser verdade quando o trabalho estiver concluído?
5. Restrições: O que deve permanecer inalterado e quais abordagens estão fora de questão?
6. Pedido de evidências: Peça ao assistente que questione o pressuposto e explique o que ele verificaria primeiro.

Você não precisa de todos os itens para uma pergunta de uma linha. Precisa deles quando o assistente puder tomar uma decisão de produto ou arquitetura em seu nome.

Aqui está um prompt fraco:

Torne a navegação em dispositivos móveis mais consistente e remova a barra lateral.

Ele dá uma ação, mas não define um limite para a decisão. O assistente poderia remover a barra lateral em todos os lugares, pois não sabe que os usuários de desktop dependem dela.

Aqui está um prompt melhor:

Problema: A barra lateral do desktop é difícil de usar em dispositivos móveis porque
ocupa espaço horizontal demais e compete com o conteúdo das lições.

Pressuposto: Um padrão de navegação específico para dispositivos móveis facilitaria a
troca de lições sem alterar o fluxo de trabalho no desktop.

Resultado: Em telas pequenas, os alunos podem trocar de lição e voltar ao exercício
atual sem perder o contexto. Os usuários de desktop mantêm a barra lateral e o fluxo
de trabalho por teclado existentes.

Restrições: Não remova a barra lateral do desktop. Preserve o comportamento de rota,
os rótulos de acessibilidade e o estado de progresso existentes. Evite adicionar uma
segunda fonte de verdade para a lição selecionada.

Antes de implementar, investigue a responsabilidade atual da navegação e questione o
pressuposto se uma alteração menor de layout resolver o problema.

O prompt melhor dá espaço para o assistente investigar, mas torna explícitos os limites importantes: dispositivos móveis são o escopo, o comportamento no desktop está protegido e um único responsável pelo estado não é negociável.

Uma solicitação de posicionamento pode ter o mesmo problema:

Mova o botão de tópicos para a barra lateral e faça com que ele se ajuste.

Essa instrução trata o layout existente como decoração. Ela não explica por que a troca de tópicos pertence a outro lugar nem como as pessoas devem encontrá-la depois da mudança.

Em vez disso, tente isto:

Problema: O seletor de tópicos na barra de navegação compete com a navegação global,
mas as pessoas o usam enquanto comparam lições dentro do curso atual.

Resultado desejado: Posicione a troca de tópicos ao lado da navegação do curso para
que sua finalidade fique clara e ela continue fácil de alcançar ao navegar por uma lição.

Restrições: Mantenha inalteradas as ações da barra de navegação global, preserve o
tópico selecionado durante a navegação e não faça da barra lateral a única forma de
trocar de tópico em telas estreitas.

Primeiro, investigue o modelo atual de rota e estado. Explique se a barra lateral é o
destino certo antes de alterar o layout.

A mudança central não é “mais detalhes”. É uma definição melhor de sucesso.

A IA é mais útil quando pode apontar uma premissa ruim antes de escrever um patch. Adicione uma pergunta direta:

Que evidência refutaria este pressuposto e qual mudança menor deveríamos
considerar primeiro?

Para um bug, peça etapas de reprodução e hipóteses concorrentes. Para uma refatoração, pergunte qual comportamento pode regredir. Para uma alteração de arquitetura, pergunte qual responsável, limite ou contrato existente seria duplicado.

Isso muda o trabalho de “produza código agora” para “tome uma decisão defensável e então implemente”.

Use este modelo quando uma tarefa precisar de contexto de produto e técnico:

Tarefa: [Descreva a alteração em uma frase.]

Problema: [Quem é afetado e o que está dando errado?]
Escopo: [Arquivos, telas, fluxo de trabalho ou subsistema no escopo.]
Pressuposto: [O que você acredita estar causando o problema ou qual solução pode ajudar.]
Resultado desejado: [Resultado observável para o usuário e o sistema.]
Restrições: [Comportamento a preservar, compatibilidade, desempenho, acessibilidade,
segurança, implantação e itens fora do escopo.]
Contexto relevante: [Arquitetura, fluxo de dados, alterações recentes, logs ou exemplos.]
Critérios de aceitação: [Como sabemos que o trabalho está concluído.]
Validação: [Testes, verificações manuais ou medições a executar.]

Antes de alterar o código, investigue a área relevante. Questione o pressuposto se as
evidências sugerirem uma solução mais segura ou menor.

O modelo também facilita a revisão: um colega pode ver o resultado pretendido e decidir se a implementação proposta o atende.

O contexto relevante é seletivo. Inclua um teste que falha, uma mensagem de erro, o limite atual do componente, o payload de uma solicitação, ou uma breve jornada do usuário. Não cole milhares de linhas não relacionadas esperando que o assistente encontre a parte importante.

Para um fluxo de programação focado, consulte como criar prompts para programação com o ChatGPT. Para padrões reutilizáveis em trabalho de implementação, depuração e revisão, leia engenharia de prompts para desenvolvedores.

Use um guia específico para a ferramenta quando o contexto do repositório mudar o prompt: prompts para Cursor AI, práticas recomendadas para prompts do GitHub Copilot ou como obter melhores resultados com o Claude Code.

Use um guia específico para a tarefa quando precisar de uma redação pronta para adaptar: exemplos de engenharia de prompts para engenheiros de software, modelos de prompt para refatorar código ou modelos de prompt para depurar problemas de produção.

Use um guia de decisão quando o risco for de processo, não de sintaxe: erros de assistentes de programação com IA e como evitá-los e como desenvolvedores experientes usam IA de forma diferente.

Os mesmos hábitos que tornam os prompts de IA úteis tornam tickets, pull requests e notas de incidentes mais claros: explique o problema, defina o resultado, preserve comportamentos importantes e valide o resultado.

Quando uma tarefa envolve um comando de shell ou saída de terminal, torne o comportamento concreto antes de pedir a um assistente que o altere. Pratique fluxos de trabalho de linha de comando no navegador para reconhecer a entrada, a saída e o modo de falha que você quer que a implementação trate.