🧩 As peças de um prompt
No módulo anterior você descobriu que existe um bilhete invisível. Agora vamos abrir esse bilhete e ver as peças por dentro. Um bom system prompt não é um textão solto — é um kit de peças encaixáveis: identidade, tom, ferramentas, segurança e prioridade. Você vai aprender o que cada peça faz e como elas se encaixam, tudo com exemplos reais de prompts de verdade.
Conteúdo detalhado
Identidade: quem a IA é
A primeira peça — e a mais importante — é a identidade. Quase todo system prompt do mundo começa com duas palavrinhas: "You are..." ("Você é..."). Em uma frase, a IA já sabe quem é, para quem trabalha e o que veio fazer. É a âncora: tudo que vem depois no bilhete se apoia nela.
🪪 A ideia em uma frase
A identidade é o crachá da IA. Sem ela, a IA "deriva": muda de personagem no meio da conversa, inventa poderes que não tem. Por isso vem no topo e em poucas linhas — é âncora, não biografia.
✓ Identidade forte (no topo)
- ✓Fica no personagem certo a conversa toda
- ✓Sabe o que é e o que veio fazer
- ✓Curta e clara — âncora, não biografia
✗ Identidade fraca ou enterrada
- ✗"Vira" outro personagem no meio do papo
- ✗Inventa ferramentas que não existem
- ✗Backstory inútil enterra o que importa
You are an AI coding assistant, powered by {model_name}.
You operate in Cursor.
You are a coding agent in the Cursor IDE that helps the USER with software engineering tasks.
Três linhas, três informações: quem é ("coding assistant"), com o quê ({model_name}) e onde está ("in Cursor"). A IA não decora qual modelo roda — a Cursor preenche o espacinho {model_name} na hora.
O que é
A peça que declara, logo na abertura, quem a IA é (produto + função), para quem trabalha e os limites do que ela sabe. É a única peça que aparece em todos os prompts reais, sem exceção.
Por que aprender
Porque é a peça que mais "segura" a IA no personagem certo. Quando uma IA "esquece quem é" no meio do papo, ou inventa que pode fazer coisas que não pode, quase sempre o problema é uma identidade fraca ou enterrada lá no fundo do bilhete.
Tom: como a IA fala
A segunda peça é o tom — o jeito de falar: formal ou descontraído, com emoji ou sem, prolixo ou direto. A identidade diz quem ela é; o tom diz como ela se expressa. É a diferença entre um atendente de banco e um amigo te explicando algo no bar: mesma língua, "tons" completamente diferentes.
<tone_and_style>
- Only use emojis if the user explicitly requests it. Avoid using emojis in all communication unless asked.
- Do not use a colon before tool calls. ...text like "Let me read the file:" ... should just be "Let me read the file." with a period.
</tone_and_style>
Repare como o tom desce ao detalhe: nada de emoji sem pedido, e até a regra de não usar dois-pontos antes de uma ação. Tom não é só "seja simpático" — são escolhas concretas de escrita.
O que é
A peça que define o jeito de falar: nível de formalidade, uso de emoji, tamanho das respostas, formatação. É o que dá a "voz" da IA — e o que mais muda a sensação de conversar com ela.
Por que aprender
Porque é a peça que você mais sente. "Por que essa IA fala tão robótico?" "Por que aquela enche de emoji?" Está tudo no bloco de tom. Saber que ele existe te mostra que o "jeitão" da IA é uma escolha — e uma escolha que dá pra mudar.
Tom anda junto com honestidade
Muitos prompts juntam, no mesmo bloco, "como falar" e "como ser honesto" — por exemplo, não fingir certeza que não tem, não inventar fatos. Faz sentido: as duas coisas são sobre o jeito de se comunicar com você. Tom não é só estilo; é também a postura de dizer a verdade do jeito certo.
Ferramentas: o que a IA faz
Algumas IAs só conversam. Outras fazem coisas: leem arquivos, buscam na web, rodam comandos. Essas ações são as ferramentas. Mas dar uma ferramenta não basta — a IA precisa saber quando e como usar cada uma. Essa peça é o "manual de uso" das ferramentas.
1. Liste o que existe
A IA precisa saber quais ferramentas tem na mão. Sem a lista, ela ignora um recurso útil ou inventa um que não existe — como uma caixa de ferramentas sem etiqueta.
2. Diga quando usar cada uma
Cada ferramenta vem com a condição de uso. A Cursor manda usar a ferramenta certa pra cada coisa — e não usar comandos de terminal pra ler ou editar arquivos quando existe uma ferramenta dedicada.
3. Defina a ordem (pré-requisitos)
Às vezes uma ação só vem depois de outra. "Ler antes de editar" é o clássico: a IA precisa ler o arquivo ao menos uma vez antes de mudá-lo — senão edita no escuro.
1. Don't refer to tool names when speaking to the USER. Instead, just say what the tool is doing in natural language.
2. Use specialized tools instead of terminal commands when possible... don't use cat/head/tail to read files, don't use sed/awk to edit files...
// em <making_code_changes>:
1. You MUST use the Read tool at least once before editing.
Três contratos numa tacada: não citar o nome da ferramenta pro usuário, usar a ferramenta certa (não o terminal pra tudo), e ler antes de editar. Cada ferramenta com seu "quando" e "como".
O que é
A peça que declara as ações da IA (ler, buscar, editar, rodar) e as regras de uso de cada uma: quando chamar, em que ordem, e o que evitar. Existe sobretudo nas IAs que "fazem", como assistentes de código.
Por que aprender
Porque é a diferença entre uma IA que fala sobre uma tarefa e uma que executa a tarefa. E é aqui que moram os erros mais chatos: a IA que edita um arquivo sem ler antes, ou que usa a ferramenta errada. Boas regras de ferramenta evitam isso.
Segurança: o que a IA não faz
Tão importante quanto dizer o que a IA deve fazer é dizer o que ela não deve. Essa é a peça da segurança: as barreiras de proteção. Algumas evitam danos sérios (não ajudar com algo ilegal); outras evitam estragos pequenos mas irritantes (criar arquivo à toa). Toda IA confiável tem esse bloco de "freios".
NEVER create files unless they're absolutely necessary for achieving your goal. ALWAYS prefer editing an existing file to creating a new one.
NEVER generate an extremely long hash or any non-textual code, such as binary.
Veja o par NEVER ... ALWAYS ...: a IA é proibida de criar arquivos sem necessidade e orientada a preferir editar. É uma barreira que evita bagunça no projeto — proteção, não censura.
✓ COM bloco de segurança
- ✓Recusa pedidos perigosos com educação
- ✓Não cria arquivos/bagunça sem necessidade
- ✓Não inventa fatos com falsa certeza
- ✓Sabe onde ficam os limites — e respeita
✗ SEM bloco de segurança
- ✗Topa qualquer pedido, inclusive nocivos
- ✗Faz alterações destrutivas sem pensar
- ✗Afirma com convicção coisas que não sabe
- ✗Não tem freio — e você descobre tarde
O que é
A peça das barreiras de proteção: o que a IA recusa, o que ela nunca faz, e como ela age na dúvida. Vai do grave (não ajudar com crime) ao prático (não criar arquivo à toa). É o "freio" do bilhete.
Por que aprender
Porque é o que torna a IA confiável. "Por que ela se recusou a fazer isso?" Quase sempre a resposta mora aqui. E porque mostra uma verdade importante: uma IA sem freios não é "mais livre" — é só imprevisível e arriscada.
Prioridade: quem manda na hora do conflito
E se duas instruções se chocarem? O bloco de segurança diz "não faça X", mas o usuário pede X. Quem ganha? É pra isso que existe a peça da prioridade: ela define a ordem de comando — quem vence quando há briga. Sem ela, a IA fica perdida no conflito.
🪜 A escada de comando (exemplo do Grok)
- ① Política central (topo). As regras de segurança mais importantes vêm em primeiro lugar — "estas têm a mais alta precedência". Nada passa por cima delas.
- ② Mensagem do sistema. Em seguida vem o resto do system prompt: identidade, tom, ferramentas. Manda em quase tudo — menos onde colide com a política do topo.
- ③ Mensagem do usuário (você). Seus pedidos vêm depois. A IA te atende com prazer — desde que não bata nas duas camadas de cima.
<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.
</policy>
Em duas frases, três níveis: política > sistema > usuário. A própria peça anuncia que está no topo da escada — por isso fica no comecinho do prompt.
Pense numa empresa
A lei (política) está acima de todo mundo. As regras da empresa (sistema) valem no dia a dia. E o pedido de um cliente (você) é atendido — desde que não quebre nem a lei nem as regras da casa. A IA segue exatamente essa escada.
Como as peças se encaixam: o compartimento XML
Você já viu as cinco peças. Falta a pergunta final: como elas ficam organizadas dentro do bilhete? Imagina jogar identidade, tom, ferramentas, segurança e prioridade tudo num textão só, sem separação. Vira um caos impossível de manter. A solução que os profissionais usam é o compartimento XML — gavetas nomeadas, uma pra cada peça.
🗂️ Gavetas com etiqueta
Cada peça vai dentro de uma "gaveta" com nome — uma tag de abertura e uma de fechamento, tipo <tone_and_style> ... </tone_and_style>. Olha o SVG lá em cima: as peças soltas (esquerda) entram cada uma na sua gaveta e formam o prompt inteiro (direita).
As gavetas ficam lado a lado (sem uma dentro da outra). Assim, pra mudar o tom você abre só a gaveta do tom — o resto fica intacto. É o que deixa um prompt gigante ainda fácil de mexer.
<tone_and_style>
- Only use emojis if the user explicitly requests it...
</tone_and_style>
<tool_calling>
You have tools at your disposal to solve the coding task...
</tool_calling>
<making_code_changes>
1. You MUST use the Read tool at least once before editing...
</making_code_changes>
Três gavetas, três assuntos: tom, ferramentas e mudanças de código. Cada uma com seu nome e seu conteúdo, uma do lado da outra. Pra trocar a regra de tom, mexe-se só na primeira gaveta — as outras nem percebem.
O nome da gaveta ajuda você (e a IA)
A tag <making_code_changes> já diz, só no nome, do que aquele bloco trata. Isso ajuda a IA a separar assuntos — e ajuda quem escreve a achar, comparar versões e remover uma peça inteira sem reler tudo. Gaveta sem etiqueta é gaveta que ninguém acha. O nome é parte da instrução.
📝 Nem sempre é XML
Prompts curtos (umas poucas linhas) não precisam de gavetas — viraria cerimônia. E alguns assistentes de código usam títulos em Markdown (tipo # Seção) no lugar das tags XML, cumprindo o mesmo papel: separar assuntos com clareza. A ideia que importa é a compartimentação, não a tag em si.
📝 Resumo do Módulo
- ✓Um prompt é um kit de peças encaixáveis, não um textão solto
- ✓Identidade ("You are...") diz quem a IA é — é a âncora no topo
- ✓Tom diz como ela fala — formal, emoji, tamanho (anda junto com honestidade)
- ✓Ferramentas dizem o que ela faz — e quando/como (ex.: ler antes de editar)
- ✓Segurança diz o que ela não faz, e prioridade diz quem manda no conflito
- ✓As peças se encaixam em gavetas nomeadas (compartimento XML), lado a lado
➡️ Próximo Módulo
1.3 — 🏗️ Padrões estruturais. Agora que você conhece as peças, vamos ver os moldes que se repetem em todos os prompts de verdade: o bloco de identidade, a declaração de capacidades, o compartimento XML e a regra por exemplo. As formas que se repetem porque funcionam.