---
title: A anatomia de um prompt: as partes que realmente importam
description: Aprenda os componentes essenciais de prompts de IA eficazes e como estruturá-los para obter resultados melhores. Um desmonte prático do que funciona.
date: February 5, 2026
author: Robert Soares
category: prompt-engineering
---

A maioria dos prompts falha porque deixa a IA adivinhar.

Não porque sejam curtos demais. Mas porque não deixam claro o que você realmente quer. E quando a IA precisa adivinhar, ela vai para uma resposta genérica.

Como um [comentário no Hacker News](https://news.ycombinator.com/item?id=41395921) colocou: "prompt engineering is probably very close to good management and communication principles." Esse enquadramento ajuda. Você não está programando. Você está se comunicando com algo que não tem como fazer perguntas de acompanhamento.

Então, como é um prompt completo? Existe uma estrutura por trás dos bons.

## Os blocos de construção

A [documentação do Learn Prompting](https://learnprompting.org/docs/basics/prompt_structure) identifica cinco componentes que aparecem em prompts eficazes. O [Prompt Engineering Guide](https://www.promptingguide.ai/introduction/elements) usa termos um pouco diferentes, mas chega a categorias parecidas: instrução, contexto, dados de entrada e indicador de saída.

A maioria dos bons prompts usa três ou quatro desses. Perguntas simples precisam de um.

### A diretriz (instrução)

É a tarefa em si. O que você quer, de fato?

"Escreva um e-mail de acompanhamento para um potencial cliente que não respondeu há duas semanas."

Isso é uma diretriz. Clara e específica. Compare com "Me ajude com este e-mail". A segunda versão força a IA a adivinhar sua intenção, seu público, seu objetivo.

Diretrizes vagas geram respostas vagas. Esta parte não tem mistério.

### Contexto (informações de base)

Tudo o que a IA precisa para entender a sua situação.

Sem contexto, você ganha suposições genéricas. Com contexto, você ganha respostas sob medida. A diferença pode ser grande.

Digamos que você precise de um roteiro de apresentação. "Crie um roteiro de apresentação sobre IA" não dá nada para o modelo trabalhar. Quem é o público? Qual o ângulo? Quão técnico?

Agora adicione contexto: "Vou apresentar para nossa diretoria na semana que vem. Eles aprovaram nosso piloto de IA no trimestre passado e querem uma atualização de progresso de 6 meses. Eles se importam com ROI e cronograma, não com detalhes técnicos."

De repente a IA sabe que deve enfatizar resultados de negócio, evitar jargão e estruturar para executivos. Contexto responde às perguntas que o modelo faria se pudesse.

Um [usuário no Hacker News](https://news.ycombinator.com/item?id=39733697) sugeriu uma estrutura que captura isso bem: "[Context] + [Supplemental Information] + [Intent / Use of result] + [Format you would like the result in]"

### O papel (perfil)

Este ponto é controverso. Alguns juram por ele. Outros acham que não acrescenta nada.

A ideia: atribuir um papel diz à IA que perspectiva e que tipo de experiência trazer. "Atue como um CFO explicando os números do 4º trimestre ao conselho" molda as respostas de um jeito diferente do que fazer a mesma pergunta do zero.

Uma [pesquisa compilada pela K2View](https://www.k2view.com/blog/prompt-engineering-techniques/) sugere que o prompting por papel envolve "explicitly assign[ing] the LLM a role, profession, or perspective to shape how it reasons and responds." A recomendação deles: escolha papéis realistas, relevantes para a tarefa, e mantenha a definição concisa.

Mas aqui vai a parte honesta: isso nem sempre importa. Em tarefas diretas, papéis não adicionam nada mensurável. Em tarefas em que experiência e perspectiva realmente moldam o resultado, parece ajudar. A evidência é mista o suficiente para que conselhos definitivos em qualquer direção pareçam prematuros.

### Formato de saída

Como a resposta deve parecer? Marcadores, lista numerada, tabela, parágrafo, JSON?

O [guia de engenharia de prompts da IBM](https://www.ibm.com/think/prompt-engineering) enfatiza entradas e saídas estruturadas para dar mais confiabilidade. Quando você especifica o formato, você reduz a ambiguidade sobre como é um resultado "pronto".

"Me dê 10 ideias de temas para blog em uma lista numerada. Para cada uma, inclua o tema e uma descrição de uma frase sobre o ângulo."

Isso evita o parágrafo longo quando você queria uma lista. Especificar formato elimina muito vai-e-volta.

Vale saber: instruções de formato nem sempre colam. Um comentarista no [Hacker News](https://news.ycombinator.com/item?id=38657029) relatou uma solução criativa: "YOUR RESPONSE MUST BE FEWER THAN 100 CHARACTERS OR YOU WILL DIE. Yes, threats work. Yes, all-caps works." Absurdo, mas aparentemente eficaz para impor restrições.

A mesma thread trouxe outra abordagem: "The examples are also too _polite_ and conversational: you can give more strict commands and in my experience it works better." Parece haver algo aí: ser direto em vez de diplomático.

### Exemplos (demonstrações)

Às vezes, mostrar é melhor do que explicar.

Isso é especialmente útil quando o formato ou o estilo são difíceis de descrever, mas fáceis de reconhecer. Em vez de explicar a voz da sua marca, mostre uma amostra. Em vez de descrever o formato do seu e-mail, inclua um.

"Escreva uma descrição de produto com a voz da nossa marca" é vago. Adicione um exemplo:

> "A Horizon Backpack não é só armazenamento. É seu escritório móvel, sua bolsa de academia e sua escapada de fim de semana, tudo em um. Cabe um laptop de 15 polegadas, três dias de roupa e ainda sobra espaço para lanches. Porque prioridades."

Agora escreva uma descrição parecida para a garrafa d'água. O exemplo comunica ritmo, humor, estrutura de frases. Mais do que parágrafos de explicação conseguiriam.

Segundo um [comentário no Hacker News](https://news.ycombinator.com/item?id=44186161), existem na prática só três técnicas centrais de engenharia de prompts: "In Context Learning" (fornecer exemplos), "Chain of Thought" (pedir para pensar passo a passo) e "Structured Output" (especificar um formato como JSON). A maioria das outras estratégias se reduz a comunicar requisitos com clareza.

## A ordem importa?

Talvez. Modelos de linguagem processam texto de forma sequencial, prevendo o que vem em seguida com base no que veio antes. Isso significa que a última coisa no seu prompt costuma ter mais peso.

O [Learn Prompting recomenda](https://learnprompting.org/docs/basics/prompt_structure) colocar a diretriz mais para o fim, depois de contexto e exemplos. A IA foca na instrução em vez de continuar a informação contextual.

Uma sequência lógica:
1. Exemplos (se você usar) - define o padrão
2. Contexto - dá o pano de fundo
3. Papel - estabelece a perspectiva
4. Diretriz - a tarefa central
5. Formato - como você quer a saída

Dito isso, não é rígido. Muitos prompts funcionam bem em ordens diferentes. O princípio: garantir que sua diretriz esteja clara e em destaque, não enterrada.

## O que você pode pular

Nem todo prompt precisa das cinco partes.

Pule exemplos quando a tarefa for direta ou quando você não se importa com um estilo específico. Pule papel quando a tarefa não exige uma perspectiva especializada. Pule contexto extenso quando a tarefa for autocontida.

Perguntas simples pedem prompts simples. "Qual é a capital da França?" não precisa de toda essa maquinaria. A complexidade do seu prompt deve combinar com a complexidade da sua tarefa.

Também existe um argumento para começar pelo mínimo. Como um [comentário no Hacker News](https://news.ycombinator.com/item?id=41395921) observou: "sometimes the less specific you are, the better the result...if you specify too much they tend to hyperfixate on things." Nem sempre fica claro onde está a linha.

## O custo

Mais nem sempre é melhor. Cada palavra custa tokens.

Uma [análise do Aakash Gupta](https://www.news.aakashg.com/p/prompt-engineering) encontrou diferenças grandes de custo entre abordagens verbosas e estruturadas. Em uma comparação, uma estrutura de prompt mais simples custava cerca de $706 por dia para 100.000 chamadas de API, enquanto uma abordagem mais detalhada custava $3.000 por dia. Isso é uma redução de 76% de custo por uma qualidade que pode ser equivalente.

A mesma análise observa que prompts mais curtos e estruturados também entregam menos variância nas respostas e menor latência. Prompt longo não vira automaticamente resposta melhor.

## Construindo um prompt

Vamos passar por um exemplo.

**Comece só com a diretriz:**

> Escreva um e-mail de vendas sobre nosso novo software de gestão de projetos.

Isso vai produzir algo genérico, mas utilizável.

**Adicione contexto:**

> Vamos lançar o TaskFlow, uma ferramenta de gestão de projetos para agências de marketing. O cliente-alvo são donos de agência gerenciando equipes de 10 a 50 pessoas. Eles estão frustrados com ferramentas feitas para empresas de software.
>
> Escreva um e-mail de vendas sobre o TaskFlow.

Agora a IA entende produto e público.

**Adicione papel:**

> Você é um profissional de marketing B2B SaaS com experiência vendendo para agências.

O papel traz experiência relevante.

**Adicione formato:**

> Mantenha abaixo de 200 palavras. Inclua uma chamada para ação clara para marcar uma demonstração.

Agora existe uma estrutura para a saída.

**Adicione exemplo (opcional):**

> Aqui vai um e-mail de vendas que performou bem para nós:
>
> "Assunto: Sua ferramenta de gestão de projetos não foi feita para você
>
> Tocar uma agência de marketing significa equilibrar campanhas, clientes e caos criativo. A maioria das ferramentas de gestão foi desenhada para entregar código, não para entregar campanhas.
>
> O TaskFlow é diferente. Feito por gente de agência para gente de agência. Sem jargão de desenvolvedor. Sem recursos que você nunca vai usar. Só acompanhamento claro de projetos que combina com a forma como equipes criativas realmente trabalham.
>
> [Demo link] - Veja em ação (15 minutos, sem pitch)."
>
> Escreva um e-mail semelhante para a nossa campanha de inscrições no webinar. Mesmo tom, mesmo tamanho.

Cada componente adiciona especificidade. A versão final deixa menos ao acaso.

## Quando o resultado sai errado

Quando o resultado não for o que você queria, pergunte qual componente falhou.

Resposta genérica demais? Adicione contexto. Tom errado? Ajuste ou adicione um papel. Formato saiu fora? Seja explícito. Estilo não bate? Adicione um exemplo. A resposta está confusa? Sua diretriz talvez esteja pouco clara.

Esse diagnóstico é melhor do que começar do zero. Identifique a parte fraca, conserte aquele ponto específico, tente de novo.

## Técnicas relacionadas

Entender a anatomia de um prompt é conhecimento de base. Explica por que alguns pedidos funcionam e outros não.

Técnicas mais avançadas constroem em cima dessa estrutura. [Prompting com cadeia de pensamento](/posts/chain-of-thought-prompting) usa o componente de diretriz de outra forma, pedindo que a IA raciocine passo a passo. [Prompting com poucos exemplos](/posts/zero-shot-vs-few-shot-prompting) foca em exemplos, mostrando como lidar com situações novas por demonstração.

Se a estrutura de prompts vai importar tanto conforme os modelos melhorarem ainda não está claro. A virada para "engenharia de contexto" sugere que o jogo está mudando. A [IBM observa](https://www.ibm.com/think/prompt-engineering) que um prompting eficaz vai além de pedidos simples: envolve entender a intenção do usuário, o histórico da conversa e o comportamento do modelo.

Uma [thread no Hacker News](https://news.ycombinator.com/item?id=37130531) sugeriu que "sensitivity to the exact phrasing of the prompt is a deficiency in current approaches to LLMs and many are trying to fix that issue." Talvez modelos futuros entendam o que você quer a partir de pedidos vagos. Ou talvez a habilidade subjacente — conseguir explicar algo com clareza — continue útil, independentemente do que você estiver explicando para quem.