Prompting preciso é especificação de contexto

20 de junho de 2026 · 10 min de leitura

Resumo

Existe uma checklist conhecida para começar com prompting: definir tarefa, público, tom, papel, contexto, restrições, exemplos e formato de saída. Ela é útil. Mas não basta.

Minha hipótese é que o prompting preciso está se tornando menos uma checklist universal e mais uma escolha dos detalhes que realmente importam para um modelo, uma tarefa, um fluxo de trabalho, um nível de risco e um método de avaliação específicos. Em outras palavras: precisão de prompt não é tamanho. É ajuste.

Este artigo revisa orientações práticas da OpenAI, Anthropic e Microsoft, além de trabalhos acadêmicos sobre taxonomias de prompting, prompt patterns, otimização automática de prompts, tarefas de engenharia de software e context engineering. As fontes apontam na mesma direção: os detalhes úteis em um prompt mudam bastante conforme o contexto. Um prompt para extração estruturada em JSON precisa de elementos diferentes de um prompt para síntese jurídica, geração frontend, tutoria, uso de ferramentas por agentes ou correção de código.

A tese ainda é uma hipótese de trabalho. Mas já é prática.

O problema da checklist de prompts

A maioria das pessoas que usa LLMs há mais de algumas semanas conhece os conselhos básicos.

Diga ao modelo o que você quer. Dê um papel. Defina o público. Especifique o tom. Adicione exemplos. Indique o formato de saída. Talvez inclua restrições.

Isso não está errado. É um bom começo. Mas quando comecei a usar LLMs para me ajudar a escrever prompts mais detalhados, percebi algo um pouco irritante e bem interessante: a lista de detalhes úteis mudava o tempo todo.

Para uma revisão de literatura, os detalhes decisivos eram hierarquia de fontes, estilo de citação, linguagem de incerteza e separação entre evidência e interpretação.

Para uma tarefa frontend, os detalhes decisivos eram comportamento responsivo, design system existente, estados de interação, acessibilidade e assets visuais.

Para um fluxo agentic, os detalhes decisivos eram permissões de ferramentas, limites de aprovação, critérios de parada, etapas de verificação e estado a preservar.

A mesma palavra: "prompt". Um objeto de engenharia bem diferente.

Então o problema não é se um prompt deve conter "mais detalhes". Essa pergunta é ampla demais. A pergunta melhor é:

Quais detalhes são operacionalmente relevantes para esta tarefa?

Eu chamaria de operacionalmente relevante um detalhe cuja inclusão muda a probabilidade de o modelo produzir um resultado aceitável.

Isso soa um pouco formal, mas importa. Um prompt longo ainda pode ser vago. Um prompt curto pode ser preciso. A diferença é se o prompt nomeia as variáveis que realmente orientam o modelo.

Como olhei para as fontes

Esta é uma revisão narrativa, não um benchmark. Busquei fontes que cobrissem cinco ângulos:

O objetivo não era provar que todo prompt precisa ser complexo. Pelo contrário. A afirmação útil é mais estreita: os detalhes certos dependem do trabalho que o prompt precisa fazer.

O que a documentação dos provedores já sugere

A documentação atual da OpenAI sobre prompt engineering e prompt generation mostra os dois lados do tema. Há orientação geral, mas ela rapidamente se torna específica por tipo de saída. O guia de geração de prompts trata tipo de output, schemas, exemplos, ordem entre raciocínio e conclusão, constantes e complexidade da tarefa como variáveis a inspecionar, não como um template fixo [1][2].

A Anthropic é ainda mais explícita sobre começar pelos critérios de sucesso. Sua visão geral de prompt engineering diz que, antes de melhorar um prompt, você deve ter uma definição clara de sucesso, alguma forma de testar esses critérios e uma primeira versão do prompt [3]. Isso é importante. Prompting vira iteração contra um alvo, não frase mágica.

As boas práticas da Anthropic separam várias situações: exemplos, estrutura XML, papéis, contexto longo, formato de saída, uso de ferramentas, thinking, sistemas agentic, frontend, migração entre versões de modelos e mais [4]. Isso parece menos "a fórmula única" e mais "cada fluxo expõe controles diferentes".

A documentação da Microsoft Azure OpenAI acrescenta um aviso útil: construir prompts é mais arte do que ciência, e modelos diferentes se comportam de maneiras diferentes [5]. Eu não usaria isso como desculpa para prompts descuidados. Usaria como razão para testá-los.

A literatura deixa o espaço de design visível

O apoio acadêmico mais forte vem da própria amplitude do campo.

The Prompt Report cataloga 58 técnicas de prompting para LLMs e 40 técnicas para outras modalidades [6]. Isso não é uma lista para iniciantes. É sinal de que "prompting" cobre problemas muito diferentes.

O catálogo de prompt patterns de White et al. é útil por outro motivo [7]. Ele trata prompts como padrões de software: soluções reutilizáveis para problemas recorrentes em um contexto particular. Essa última parte é essencial. Um padrão é reutilizável, mas não é livre de contexto.

Automatic Prompt Engineer vai além. Zhou et al. tratam instruções como candidatas que podem ser geradas, pontuadas e selecionadas conforme o desempenho na tarefa [8]. É um modelo mental diferente de "escrever um bom prompt". A qualidade depende da tarefa, da função de pontuação e do espaço de busca.

O estudo de Shin et al. sobre engenharia de software também se encaixa. Ele compara prompting básico, in-context learning e prompting específico da tarefa para geração, resumo e tradução de código. Prompt engineering não supera fine-tuning em todos os cenários, e prompting conversacional melhora quando humanos adicionam contexto, feedback e instruções específicas [9].

Isso bate com a experiência prática. Você descobre o que falta no prompt observando onde o modelo falha.

Os detalhes mudam com a tarefa

A versão prática do argumento é esta:

Uma checklist genérica diria: "inclua contexto". Certo. Mas em um repositório de código, contexto pode significar arquitetura local e comando de teste. Em uma síntese jurídica, pode significar jurisdição e data da norma. Em uma extração, pode significar schema e regras para campos ausentes.

A palavra é a mesma. O conjunto de detalhes não é.

Precisão não é verbosidade

É aqui que muitas conversas sobre prompting saem do eixo.

As pessoas ouvem "seja preciso" e traduzem como "adicione mais instruções". Às vezes funciona. Muitas vezes só cria um prompt mais longo, com mais lugares onde instruções podem entrar em conflito.

A definição melhor é:

Prompting preciso é a seleção de contexto, restrições, exemplos e critérios de avaliação relevantes para a tarefa que afetam materialmente o comportamento do modelo.

Isso separa precisão de tamanho.

Um prompt que diz "escreva em tom profissional para um público geral" não é preciso se o problema real é fidelidade de citações. Um prompt que diz "extraia claims em JSON com claim, source_quote, confidence e needs_verification; use null quando a fonte não disser nada" pode ser preciso mesmo sendo curto.

Um soa polido. O outro muda o comportamento.

Context engineering como moldura maior

A literatura recente de context engineering formula o mesmo ponto em escala maior. Mei et al. descrevem context engineering como a otimização do pacote de informações dado a um LLM, incluindo retrieval, processamento de contexto, memória, ferramentas, RAG, raciocínio com ferramentas e sistemas multiagente [10].

O termo pode ficar vago se virar moda. Mas a ideia central é útil: o prompt visível do usuário é só uma parte da janela de contexto.

Em uma aplicação séria com LLM, o modelo também pode receber:

• instruções de sistema
• instruções de developer
• documentos recuperados
• memória
• definições de ferramentas
• regras de policy
• preferências do usuário
• exemplos
• schemas
• saídas anteriores
• rubricas de avaliação

Visto assim, a checklist antiga fica pequena. O trabalho não é apenas formular bem o pedido. É montar o ambiente de informação no qual o modelo consegue realizar a tarefa.

Um pequeno modelo para prompting preciso

As fontes sugerem um modelo de trabalho simples. Eu ainda não chamaria de teoria. Mais como um andaime prático.

Isso também explica por que LLMs ajudam a escrever prompts. Quando peço a um LLM para melhorar um prompt, ele frequentemente traz categorias que eu tinha esquecido: casos-limite, rubricas, política de fontes, exemplos negativos, modos de falha, permissões de ferramentas.

Mas essas sugestões não estão automaticamente certas. São detalhes candidatos. Precisam ser testados.

O que isso significa na prática

Se você mantém uma biblioteca de prompts, não salve apenas o prompt final. Salve tipo de tarefa, modelo, critérios de sucesso, falhas conhecidas e o motivo pelo qual certos detalhes foram incluídos.

Se você pede a um LLM para melhorar um prompt, não peça apenas "um prompt melhor". Peça que ele identifique quais categorias de detalhe provavelmente afetam o resultado.

Se um prompt falha, não o torne mais longo imediatamente. Pergunte que tipo de contexto estava faltando.

Alguns prompts precisam de exemplos. Alguns de schema. Alguns de hierarquia de fontes. Alguns de política de ferramentas. Alguns de uma definição de sucesso mais forte. Alguns precisam de menos instrução, porque o modelo está preso demais às suas restrições.

Essa é a parte um pouco desconfortável: bom prompting não é uma habilidade só. É uma família de pequenas habilidades diagnósticas.

Limitações

Este artigo é especulativo no bom sentido: parte de uma observação prática e verifica se a literatura aponta na mesma direção. Ela aponta, mas isso não é um experimento controlado.

O próximo passo útil seria operacionalizar "detalhes" e testá-los por famílias de tarefas. Uma política de citação melhora uma revisão de literatura mais do que uma orientação de tom? Detalhe de schema importa mais do que exemplos em extração? Quais detalhes se transferem entre famílias de modelos?

Seria um bom benchmark. Também seria bagunçado, porque prompts reais combinam muitos detalhes que interagem.

Conclusão

A literatura sustenta a hipótese: prompting está saindo do conselho universal por checklist e indo em direção à especificação contextual.

A checklist inicial continua útil. Tarefa, público, tom, exemplos e formato são bons defaults. Mas o prompting avançado começa quando paramos de perguntar "do que todo prompt precisa?" e passamos a perguntar "o que o modelo precisa saber, restringir, usar, evitar e provar para esta tarefa?"

Essa é a mudança.

Prompting preciso não é adicionar detalhes em todo lugar. É encontrar os detalhes que mudam o resultado.

Referências

[1] OpenAI, Prompt engineering, OpenAI API documentation.

[2] OpenAI, Prompt generation, OpenAI API documentation.

[3] Anthropic, Prompt engineering overview, Claude API documentation.

[4] Anthropic, Prompting best practices, Claude API documentation.

[5] Microsoft, Prompt engineering techniques, Microsoft Learn.

[6] S. Schulhoff et al., The Prompt Report: A Systematic Survey of Prompting Techniques, arXiv:2406.06608, 2024.

[7] J. White et al., A Prompt Pattern Catalog to Enhance Prompt Engineering with ChatGPT, arXiv:2302.11382, 2023.

[8] Y. Zhou et al., Large Language Models Are Human-Level Prompt Engineers, arXiv:2211.01910, 2022.

[9] J. Shin et al., Prompt Engineering or Fine Tuning: An Empirical Assessment of Large Language Models in Automated Software Engineering Tasks, arXiv:2310.10508, 2023.

[10] L. Mei et al., A Survey of Context Engineering for Large Language Models, arXiv:2507.13334, 2025.