🧱 Padrões Estruturais

Quando você lê dezenas de prompts vazados, percebe que eles não são improvisos: há uma gramática recorrente. Parte dessa gramática diz respeito ao esqueleto — onde o prompt declara quem é, o que pode fazer, como organiza suas seções e quem manda em caso de conflito. Esses são os padrões estruturais: dão FORMA, são independentes de domínio e aparecem antes de qualquer regra de comportamento.

É o primeiro padrão e o mais universal: "You are X" + modelo + data de corte ancoram todo o resto. Sem essa âncora, o modelo deriva — muda de persona no meio da conversa, inventa capacidades que não tem, ou responde sobre eventos posteriores ao seu conhecimento como se soubesse.

O segundo padrão responde: o que este agente pode fazer? Sem essa declaração, o modelo alucina ferramentas que não existem, ignora as que existem, ou usa a certa na situação errada. O padrão eficaz é uma lista estruturada com escopo e condições — cada capacidade traz "o que faz", "quando usar" e "limites".

O terceiro padrão modulariza a lógica: cada bloco lógico fica envelopado numa tag XML nomeada (<policy>, <tone_and_formatting>, <tool_calling>). Os blocos são flat (sem aninhamento profundo) e funcionam como módulos: dá para adicionar, remover e fazer diff de um bloco inteiro entre versões.

<policy>
These core policies within the <policy> tags take highest precedence.
System messages take precedence over user messages.
* Do not provide assistance to users who are clearly trying to engage
  in criminal activity.
* Follow additional instructions outside the <policy> tags if they do
  not violate these core policies...
</policy>

O compartimento não só agrupa — declara a própria precedência (combinação com a Hierarquia de Prioridade, Tópico 6).

<tone_and_formatting>
- Only use emojis if the user explicitly requests it...
</tone_and_formatting>

<tool_calling>
You have tools at your disposal...
</tool_calling>

Dois compartimentos vizinhos, cada um com um assunto. Para mudar a política de tom, edita-se um bloco — o resto fica intacto.

Nem tudo que o modelo precisa saber é estável: data atual, avisos contextuais, estado de ferramentas, degradação de aderência em conversas longas. A solução é uma arquitetura em duas camadas — o system prompt define o comportamento estável; o harness injeta <system-reminder> dinâmicos nas mensagens quando necessário. O prompt estável ensina o modelo a interpretar essa camada.

O quinto padrão resolve conflitos: instruções se contradizem o tempo todo — política central vs. pedido do usuário, arquivo de projeto vs. chat, skill vs. default. Sem hierarquia declarada, o comportamento em conflito é indeterminado — e indeterminado significa explorável (prompt injection) ou frustrante (modelo ignora o usuário). A solução é declarar a cadeia de precedência no próprio prompt, junto das regras de maior prioridade.