Como escrever prompts melhores

Prompt é especificação, não encantamento

Prompt é tudo o que orienta um modelo durante uma interação: instruções, perguntas, exemplos, documentos, histórico, dados, imagens e regras de formato. Em produtos com API, também podem existir mensagens de sistema, ferramentas e configurações invisíveis ao usuário. A resposta depende do conjunto, não apenas da última frase digitada.

Modelos generativos calculam continuações plausíveis a partir do contexto. Eles não adivinham com segurança objetivos que ficaram apenas na cabeça de quem escreveu. Quanto mais uma tarefa admite interpretações — resumir para quem, comparar por qual critério, escrever em qual formato — maior a necessidade de explicitar decisões.

Um prompt melhor não precisa ser longo. Precisa conter a informação que muda a resposta. Para uma pergunta factual simples, uma linha pode bastar; para elaborar uma proposta comercial, analisar um contrato ou alterar um sistema, a especificação precisa ser proporcional ao risco e à complexidade.

Defina a tarefa antes de escrever a instrução

Converta pedidos vagos em uma entrega observável. “Fale sobre vendas” pode significar explicar conceitos, diagnosticar uma queda, criar um roteiro ou projetar receita. Especifique o verbo, o objeto, o usuário da resposta e a decisão que será apoiada. Se você não consegue descrever o que fará com a saída, a tarefa ainda não está madura.

Separe tarefas compostas. Pesquisar, avaliar evidências, decidir uma tese, redigir e revisar exigem operações diferentes. Um único comando pode funcionar, mas dificulta descobrir onde ocorreu um erro. Em trabalhos importantes, produza artefatos intermediários: plano, lista de fontes, rascunho, crítica e versão final.

Defina também o que está fora do escopo. Um assistente que deve classificar chamados não precisa oferecer aconselhamento jurídico; um resumo executivo não deve introduzir recomendações não presentes no documento. Limites claros reduzem deriva e facilitam a revisão.

1. Escreva em uma frase a decisão ou entrega desejada.
2. Liste o público, o conhecimento prévio e o contexto indispensável.
3. Determine quais fontes e dados podem ser usados.
4. Defina formato, extensão, tom e nível de detalhe.
5. Crie critérios verificáveis para aprovar ou rejeitar a resposta.

Dê contexto suficiente e organize a entrada

Contexto útil inclui definições internas, versão do produto, período analisado, localização, público, exemplos anteriores e critérios da organização. Contexto excessivo pode esconder a instrução, aumentar custo e trazer conflitos. Selecione trechos relevantes e explique a função de cada anexo em vez de despejar arquivos sem orientação.

Delimite documentos com títulos, aspas triplas, marcadores ou blocos nomeados. Diga explicitamente “use apenas o conteúdo entre INÍCIO DA FONTE e FIM DA FONTE”. Essa separação ajuda o modelo e o revisor a distinguir instrução de dado. Ainda assim, um documento externo pode conter instruções maliciosas; em sistemas com ferramentas, separação visual não substitui proteção contra prompt injection.

Quando houver lacunas, autorize o modelo a perguntar antes de responder. Uma regra como “se faltar público, prazo ou fonte, faça até três perguntas objetivas” é mais confiável do que exigir uma conclusão com dados incompletos.

Especifique formato, limites e critérios de qualidade

Formato não é decoração; ele determina se a saída pode ser usada. Peça títulos, campos, ordem, unidade, idioma, comprimento aproximado ou esquema quando isso fizer diferença. Para integração automática, prefira recursos nativos de saída estruturada ou validação de schema quando disponíveis, porque pedir “JSON válido” apenas em linguagem natural não oferece garantia absoluta.

Restrições devem ser operacionais. “Seja preciso” é abstrato; “não inclua afirmação factual sem indicar a fonte fornecida” é testável. “Seja breve” varia entre pessoas; “até 180 palavras em cinco tópicos” reduz ambiguidade. Não acumule regras contraditórias como “seja exaustivo” e “responda em duas linhas”.

Inclua uma política de incerteza: distinguir fato da fonte, inferência e informação ausente; não criar referência; declarar quando não houver evidência. Isso não elimina alucinações, mas torna a revisão mais eficiente.

Use papéis, exemplos e etapas com propósito

Atribuir um papel pode orientar vocabulário e perspectiva, mas não concede credenciais reais. “Atue como editor técnico” ajuda a definir foco; não transforma o modelo em profissional habilitado. Prefira descrever a competência e a ação: “revise clareza, consistência terminológica e afirmações sem evidência”.

Exemplos são valiosos quando a fronteira entre certo e errado é difícil de explicar. Mostre entradas e saídas aprovadas, incluindo casos limítrofes. Um exemplo ruim pode ser copiado com grande fidelidade, portanto revise rótulos, números e formatação. Não use apenas exemplos fáceis ou de uma única classe.

Para tarefas complexas, peça um plano curto ou divida o fluxo em turnos. Você pode solicitar perguntas de esclarecimento, depois um esboço, depois a execução e por fim uma verificação contra a rubrica. O ganho vem da decomposição e do feedback, não de pedir que o modelo revele raciocínio privado detalhado.

• Papel: útil para audiência, domínio e perspectiva; dispensável em pedidos simples.
• Exemplos: úteis para classificação, estilo, extração e formatos específicos.
• Etapas: úteis quando há dependências, decisões intermediárias ou risco elevado.
• Ferramentas: necessárias quando a tarefa exige fatos atuais, cálculo, código ou ações externas.

Converse, critique e refine

A primeira resposta é uma amostra, não a conclusão do processo. Indique o que funcionou e o que falhou com exemplos concretos: “o segundo parágrafo repete a introdução; preserve os dados, elimine a repetição e reduza 20%”. Feedback específico é mais informativo que “melhore”.

Peça alternativas quando o espaço de solução for criativo e comparação quando houver decisão. Para uma revisão, forneça uma rubrica e solicite que cada problema seja ligado a um trecho. Depois aplique apenas mudanças aprovadas, preservando fatos e voz.

Em conversas longas, instruções antigas podem perder relevância ou entrar em conflito. Recapitule a versão atual do objetivo e das regras, ou inicie uma nova sessão com o prompt consolidado. Não dependa de memória implícita para requisitos críticos.

Teste prompts como parte de um sistema

Um prompt aprovado em um exemplo pode falhar em entradas longas, vazias, ambíguas, adversariais ou diferentes do padrão. Monte um conjunto de testes com casos normais, difíceis, limites e recusas esperadas. Defina métricas antes de comparar versões: exatidão de campos, aderência ao formato, cobertura, taxa de invenção, tempo, custo e necessidade de edição.

Altere uma variável por vez quando possível. Registre modelo, versão, parâmetros, prompt, anexos, data e resultado. Modelos e produtos mudam; por isso, a mesma instrução precisa ser reavaliada após migrações ou atualizações significativas.

Avaliação humana é indispensável para qualidade subjetiva, mas use uma rubrica consistente e, em equipes, mais de um avaliador em amostras. Em produção, monitore casos reais e permita correção. Um prompt é código de comportamento: merece versionamento, revisão e testes de regressão.

Erros comuns e como corrigir

Pedidos vagos geram respostas genéricas; excesso de regras gera conflito; contexto irrelevante dilui o foco; exemplos enviesados distorcem a saída; exigência de certeza incentiva invenção. Corrija o problema observado, não apenas acrescente texto ao prompt. Às vezes a solução é selecionar outro modelo, recuperar uma fonte, usar uma calculadora, validar com código ou redesenhar a tarefa.

Evite fórmulas universais vendidas como garantia. Siglas ajudam a lembrar elementos, mas não substituem avaliação. Também não confunda fluência com correção: uma resposta elegante pode estar errada, desatualizada ou baseada em uma premissa falsa.

Não automatize uma decisão de alto impacto apenas porque o prompt parece robusto. Controle de acesso, validação de entrada e saída, logs, limites de ferramentas, revisão humana e plano de incidente pertencem ao sistema ao redor do modelo.

• Se a resposta é genérica, acrescente público, decisão, evidência e critério.
• Se o formato varia, forneça schema, exemplo e validação externa.
• Se inventa fatos, limite fontes, peça citações verificáveis e permita “não encontrado”.
• Se omite casos, divida a tarefa e use uma checklist de cobertura.
• Se custa ou demora demais, remova contexto irrelevante e avalie modelo e arquitetura.

Checklist de um prompt profissional

Antes de usar a saída, verifique se objetivo, fonte, formato e critérios estão explícitos; se os dados são autorizados; se há instrução para lacunas; e se o responsável pela revisão está definido. Para prompts recorrentes, mantenha um cabeçalho com finalidade, proprietário, versão, data, modelo testado e conjunto de avaliação.

A melhor prática é preservar a autoria da decisão. A IA pode propor, organizar, transformar e criticar; uma pessoa ou processo autorizado deve conferir fatos, direitos, impacto e adequação antes da publicação ou da ação.

1. Objetivo e público estão claros.
2. Dados e fontes estão delimitados e autorizados.
3. Tarefa e ordem das etapas não se contradizem.
4. Formato e extensão são verificáveis.
5. Critérios de qualidade e tratamento da incerteza estão escritos.
6. Casos de teste incluem erros, limites e tentativas de desvio.
7. A saída será revisada por alguém responsável antes do uso.