Tejune Kang quer ser cuidadoso. Este post não é sobre explorar material vazado ou fazer jailbreak de sistemas. Ele não tem interesse em nenhum dos dois, e você também não deveria ter se está tocando uma empresa de verdade. O que interessa a ele é o que a estrutura de um system prompt de produção profundamente pensado ensina sobre dar instruções a agentes de IA que funcionam no mundo real — sob pressão, em escala, com usuários de verdade tentando quebrar as coisas.
A Anthropic na verdade publicou boa parte do material relevante — veja as release notes oficiais dos system prompts — e Simon Willison tem sido o melhor cronista público de como esses prompts são estruturados e o que eles revelam. Os prompts vazados valem não porque expõem segredos. Valem porque mostram, em escala séria de produção, como um time que realmente sabe o que está fazendo escreve instruções para um modelo poderoso. E quase nada no jeito como eles escrevem instruções se parece com o que a maioria dos fundadores e operadores faz ao instruir um agente.
Lição um: a estrutura é a instrução
A primeira coisa que te atinge lendo qualquer prompt de produção sério é a quantidade de andaime estrutural. Seções com cabeçalhos. Regras numeradas. Definições explícitas de papel. Tags tipo XML para diferentes categorias de instrução. Isso não é estilo. Isso é a instrução.
Quando você joga um paredão de texto no modelo, o modelo tem que inferir o que as partes do seu prompt significam e como se relacionam. Quando você dá ao modelo estrutura explícita — "esta seção é sobre segurança, esta seção é sobre uso de ferramentas, esta seção é sobre quando recusar" — você já fez metade do trabalho de prompt engineering só ao escrever os cabeçalhos.
A maioria dos fundadores que Tejune conhece escreve prompts que parecem e-mail. Uma saudação, um parágrafo, um pedido, uma assinatura. Isso funciona para um estagiário inteligente que conhece sua empresa. Não funciona para um modelo operando sob condições adversariais em escala.
Lição dois: regras vencem exemplos. Exemplos vencem abstrações.
Um prompt sério de produção usa uma camada muito específica. Regras duras no topo ("nunca faça X"). Exemplos concretos no meio. Princípios abstratos na base como fallback. Os prompts vazados do Claude Code seguem esse padrão quase perfeitamente.
O que a maioria dos prompts escritos por operadores faz é o contrário. Começam com abstrações vagas — "seja útil e preciso" — e nunca dão uma regra dura ou um exemplo concreto. O modelo faz o melhor dele, mas não tem âncora. Então o comportamento dele deriva de formas que você não consegue prever, reproduzir nem depurar.
A conclusão dele depois de ler com atenção. Toda instrução que ele dá a um agente deveria incluir ao menos um exemplo concreto do que é um output certo. Se ele não consegue escrever esse exemplo, é porque não entende o que quer bem o suficiente para pedir — e o agente definitivamente não vai.
Se você não consegue mostrar ao agente um bom exemplo do que quer, o agente não consegue construir um para você. O exemplo é a spec.
Lição três: comportamento de recusa é problema de design, não de segurança
Uma parte enorme do prompt é sobre quando e como o modelo deve se recusar a fazer algo. Não só "coisas ilegais". Uma taxonomia inteira de quando recusar, quando empurrar de volta, quando fazer perguntas de esclarecimento, quando seguir em frente. Essa taxonomia é engenhada, não assumida.
Se você está construindo um produto de agente para sua empresa, o comportamento de "recusar" não é detalhe. É a parte de maior alavancagem do seu prompt. Porque toda vez que o agente diz "vou fazer o meu melhor" quando deveria ter dito "preciso de mais informação" — ou diz "não posso ajudar com isso" quando deveria ter tentado — você está queimando a confiança do usuário e treinando-o a driblar seu agente. Faça o que você diz, diga o que você faz vale para agentes também. Se o agente não consegue traçar uma linha clara do que vai e do que não vai fazer, ele vai dizer sim para coisas que não deveria e não para coisas que deveria.
Desenhe sua taxonomia de recusa antes de desenhar o happy path. É a jogada adulta.
Lição quatro: instruções de uso de ferramentas merecem mais palavras do que instruções de tarefa
No prompt, as instruções sobre como e quando usar ferramentas são significativamente mais longas do que as instruções sobre quais tarefas executar. Isso não é acaso. Uso de ferramentas é onde os agentes falham no mundo real. Chamar a ferramenta errada. Chamar a certa com os argumentos errados. Chamar ferramentas na ordem errada. Chamar uma ferramenta quando deveriam ter feito uma pergunta de esclarecimento antes.
Se o agente da sua empresa tem acesso a qualquer ferramenta — um banco de dados, uma API, um sistema de arquivos, um índice de busca — você deveria gastar pelo menos 60% do tempo de prompt engineering nas instruções de uso de ferramentas. Não na personalidade. Não no tom. Na mecânica de quando usar cada ferramenta e como verificar que ela fez o que disse que faria.
Lição cinco: o prompt é uma política, não uma conversa
A mudança mais importante de pensamento que ler um prompt de produção de verdade deu a Tejune. O system prompt não é uma mensagem. É uma política. É a constituição escrita sob a qual o agente opera. Deveria ser escrito como um documento jurídico — preciso, inequívoco, com prioridade explícita entre regras conflitantes, com linguagem específica sobre casos de borda.
A maioria dos prompts escritos por fundadores é conversacional. Parece uma mensagem de Slack para uma pessoa recém-contratada. O agente resultante se comporta como alguém recém-contratado que recebeu um onboarding de cinco minutos. Entusiasmado. Quase sempre útil. Ocasionalmente desastroso. Inconsistente de um dia para o outro.
Reescreva o system prompt do seu agente como se um advogado fosse ler. Não porque você quer que o agente soe como advogado, mas porque a precisão necessária para escrever desse jeito é justamente o que o seu agente precisa para se comportar de forma consistente quando mil usuários estiverem martelando ele ao mesmo tempo.
O que ele fez depois de ler
Três mudanças práticas que ele fez no jeito de escrever prompts para as próprias ferramentas:
- Agora ele começa todo novo prompt de agente com um outline estrutural — papel, regras duras, instruções de uso de ferramentas, exemplos, taxonomia de recusa, casos de borda — antes de escrever uma única frase de conteúdo.
- Se obriga a escrever pelo menos três exemplos concretos para cada instrução principal. Se não consegue, a instrução ainda não está bem definida. Esse é um sinal para ele, não uma derrota.
- Trata o prompt como política versionada. Toda mudança ganha mensagem de commit. Toda mudança é testada contra o mesmo conjunto de cenários. Sem edições no estilo cowboy à 1 da manhã.
Você não precisa ler nenhum prompt vazado para adotar esses hábitos. Mas se um dia colocar as mãos num prompt de produção sério — leia uma vez, com cuidado, de mente aberta. Vai te ensinar mais sobre como instruir um agente de IA do que qualquer post sobre prompt engineering, inclusive este.
Aqui vai o desafio. Abra o system prompt que está alimentando o seu agente mais importante agora. Leia como se você fosse um advogado auditando um contrato. A cada frase, pergunte: essa regra é concreta, tem exemplo, a ordem de prioridade sobrevive a uma contradição? Se sua resposta é não para qualquer um dos três, reescreva esta semana. A diferença entre um agente que funciona e um que te envergonha numa terça à tarde está quase sempre no prompt, não no modelo.
Para saber como ele conecta tudo isso ao dia a dia operacional, veja IA dentro da cabine do operador.