Anatomia de um Prompt

Objetivos

• Criar prompts previsíveis — mesma entrada, mesma estrutura de saída
• Tratar prompt como interface entre seu sistema e o LLM

Prompt não é "texto bonito" — é contrato

Quando você integra LLM em produto, o prompt deixa de ser curiosidade e vira interface de API. Assim como uma rota REST tem schema de entrada e saída, o prompt define o que o modelo deve fazer, como deve falar e em que formato deve responder.

Prompt vago gera resposta vaga — e bug de produto. O cliente não vê "o modelo alucinou"; vê "seu sistema não funciona".

Os quatro blocos

[CONTEXTO]     Quem é você, quem é o usuário, situação atual
[OBJETIVO]     O que deve ser feito — verbo claro
[RESTRIÇÕES]   O que NÃO fazer, limites, tom, idioma
[FORMATO]      Como entregar — markdown, JSON, lista, tamanho

Pense nesses blocos como receita de bolo: falta o forno (formato) ou a quantidade de açúcar (restrições), o resultado muda completamente.

Exemplo fraco

"Fale sobre pedidos"

Resposta típica: ensaio genérico sobre e-commerce, sem relação com sua loja, sem passos práticos, sem limite de tamanho.

Exemplo forte

Contexto: Você é assistente da Loja Nova Era. O usuário está logado.
Objetivo: Explicar como rastrear um pedido pelo número.
Restrições: Máximo 4 frases. Português BR. Não invente URLs.
Formato: Passo numerado 1–3.

Resposta típica: três passos objetivos, tom alinhado, sem inventar link de rastreio.

Diálogo de revisão de prompt:

QA: "O bot respondeu um artigo de 800 palavras sobre logística."
Dev: "O system prompt só diz 'ajude com pedidos'."
QA: "Coloca limite de frases e formato numerado."
Dev: "Agora sim — prompt é spec, não desejo."

System vs User prompt

System — regras estáveis (carregue uma vez por sessão):

Você é o assistente oficial da API Docs Co.
Responda só sobre REST e OAuth2.
Se a pergunta for off-topic, diga: "Só posso ajudar com nossa documentação."
Respostas em português, tom técnico mas acessível.

User — pedido específico da vez:

Como renovo um access token com refresh token?

Separar permite versionar system prompt no Git (prompts/support-v2.txt) sem misturar com input do usuário. Quando qualidade cair após deploy, você faz diff no prompt — como faria com qualquer código.

Formato de saída explícito

Para integração com código, peça JSON:

Responda APENAS com JSON válido, sem markdown:
{"intent": "...", "confidence": 0.0-1.0}

Valide com JSON.parse + schema (Zod, ajv). Se inválido: retry com "Corrija o JSON".

Por que isso importa:

Sem formato explícito, o modelo responde: "A intenção parece ser FAQ, com alta confiança..."
Seu parser quebra. Com JSON obrigatório, você automatiza o próximo passo do pipeline.

Anti-padrões

Template mínimo (copie e adapte)

## Contexto

{empresa, produto, dados conhecidos}

## Objetivo

{ação específica}

## Restrições

- Idioma: pt-BR
- Máximo: {N} palavras
- Não inventar: {dados sensíveis}

## Formato

{lista | JSON | parágrafo}

Resumo

• Prompt = contrato: contexto + objetivo + restrições + formato
• System = regras fixas; User = pedido variável
• Saída estruturada (JSON) habilita automação downstream
• Prompt vago → resposta vaga → bug de produto

Na próxima aula você verá padrões (zero-shot, few-shot) para ensinar o modelo pelo exemplo — sem trocar de LLM e sem fine-tuning.