Contexto, restrições e formato sem instruções conflitantes

Prompts ficam difíceis de manter quando acumulam fatos, preferências e regras sem hierarquia. Nesta aula, você vai transformar esse amontoado em três decisões claras: qual contexto realmente muda a resposta, quais restrições protegem a tarefa e como a saída representa tanto o sucesso quanto a falta de informação. O objetivo não é escrever mais; é retirar ambiguidade sem esconder conflitos.

Pense num formulário de embarque. O destino, o documento e as regras de bagagem afetam a viagem. A cor da mala pode ajudar a reconhecê-la, mas normalmente não decide se o embarque é permitido. Um prompt também recebe informações centrais e decorativas. A analogia termina quando tratamos autoridade: um formulário é validado por sistemas e pessoas responsáveis, enquanto uma instrução ao modelo não cria permissão nem comprova a veracidade do dado.

Contexto bom responde “isso muda o quê?”

Antes de incluir uma informação, ligue-a a uma decisão. Se a tarefa é adaptar uma explicação para crianças, a faixa etária muda vocabulário e exemplos. Se a tarefa é extrair datas de um contrato, dizer que a empresa prefere azul não muda a extração. Esse teste reduz ruído e também facilita atualizar o prompt: quando o público muda, sabemos qual seção revisar.

Contexto pode vir de uma conversa, documento, banco de dados ou resultado de ferramenta. A origem precisa ser conhecida porque conteúdos diferentes exigem confiança diferente. Uma política aprovada não ocupa o mesmo papel que uma mensagem enviada por um usuário. Colocar ambos no mesmo bloco sem rótulo torna difícil explicar qual material fundamentou a resposta.

Use delimitadores consistentes para deixar a fronteira visível:

## Política aprovada
[trecho versionado e com data]

## Mensagem do cliente
[texto recebido, tratado como dado não confiável]

## Tarefa
Compare a solicitação com a política e sinalize informações ausentes.

Delimitar não neutraliza conteúdo malicioso, mas melhora a revisão e permite que outras camadas do sistema apliquem regras de prioridade. Você verá a defesa em profundidade na aula de segurança.

Restrições precisam de motivo e saída possível

Uma restrição útil protege qualidade, segurança, custo ou experiência. “Use somente as categorias entrega, troca, pagamento ou outro” controla um campo. “Não invente número de pedido” protege a integridade do dado. “Escreva pouco” é vago; “limite o motivo a uma frase” é verificável.

Toda proibição precisa de um caminho quando a condição não pode ser cumprida. Se o número do pedido estiver ausente, qual valor deve aparecer? Se as fontes divergirem, a resposta deve escolher uma, apresentar o conflito ou encaminhar para revisão? Sem uma alternativa, o modelo pode preencher o vazio com uma suposição plausível.

Quando o material não informar um valor, escreva "ausente".
Quando duas fontes divergirem, não escolha silenciosamente: liste as duas e
marque "revisão necessária".

Restrições também podem se contradizer. “Inclua todos os detalhes” e “use no máximo cinquenta palavras” talvez não sejam simultaneamente possíveis. “Nunca faça perguntas” entra em conflito com “confirme toda informação ausente”. O responsável pelo fluxo deve decidir o que vence. Numerar prioridades é mais honesto do que esperar que o modelo descubra uma política que o produto ainda não definiu.

Formato é um contrato de uso

Formato não é decoração. Uma lista ajuda leitura rápida; uma tabela facilita comparação; campos estáveis ajudam outro sistema. Defina nomes, opções permitidas e tratamento de ausência. Se a resposta será consumida por código, uma frase no prompt é apenas parte da solução: prefira saída estruturada suportada pelo fornecedor e valide tipos, campos obrigatórios e limites fora do modelo.

Para uma atividade manual, um contrato textual já permite revisar:

categoria: uma opção da lista permitida
evidencia: trecho curto da entrada
pendencia: descrição objetiva | nenhuma

Não peça uma justificativa longa quando uma evidência curta resolve a auditoria. Também não solicite raciocínio interno detalhado como prova de correção. O que interessa é evidência verificável, resultado e critérios observáveis. Uma explicação convincente ainda pode apoiar uma conclusão errada.

No laboratório, leia o prompt de triagem como uma pessoa revisora. Troque uma categoria permitida, remova o comportamento para número ausente e crie de propósito um conflito entre concisão e detalhe. A interface não chama modelo; ela ajuda a enxergar se a especificação continua coerente. Depois restaure a versão e confirme se cada campo pode ser conferido usando somente a mensagem.

O erro comum é esconder regra crítica no meio de exemplos ou de um grande documento. Regras de autorização, segurança e negócio devem morar em controles do sistema e aparecer no prompt somente como orientação complementar. Ao final desta aula, seu prompt deve ter contexto enxuto, prioridades compatíveis e uma forma explícita de dizer “não há dado suficiente”. Essa pequena frase costuma ser mais valiosa do que dezenas de adjetivos pedindo precisão.