Analogia de escritório: políticas da empresa
Pense em como trabalha um escritório sério.
Quando entra um engenheiro novo, você não cola o manual da qualidade no rodapé de cada e-mail. As políticas vivem no nível da empresa: como se nomeiam os arquivos, quais unidades se usam, o que não se inventa se faltar um dado, quando é preciso escalar para o sênior, o que pode sair como rascunho e o que exige assinatura. Essas políticas são persistentes. Estão aí mesmo que o pedido de hoje seja um pórtico e o de amanhã seja um quantitativo.
O system prompt — ou as instructions / rules do cliente — é exatamente isso: políticas de como os problemas devem ser resolvidos com aquele assistente. Definem o papel, os limites e o jeito de trabalhar. Não são o trabalho do dia. São o quadro.
Se cada manhã você precisa reescrever as políticas no corpo do e-mail porque «senão o júnior esquece», você não tem políticas de empresa: tem um lembrete frágil. A mesma coisa acontece quando cola as regras junto do pórtico em cada chat.
Esta nota faz parte da série sobre o harness de IA para engenharia civil. Aqui está H-01 Instruções e políticas. Complementa, não substitui, o prompt engineering nem o papel do LLM.
O que é (de verdade) o system prompt
O system prompt — ou as instructions persistentes do cliente — é o conjunto de regras de maior prioridade que orientam o comportamento do modelo durante a sessão ou a tarefa: seu papel, escopo, unidades, ferramentas disponíveis e situações em que deve pedir ajuda ou parar.
Não é o pedido do pórtico. Não é o arquivo. Não é a tool — a ação encaixada num programa. Não é a assinatura.
Na indústria se fala de system prompts de produtos (por exemplo o que a Anthropic documenta sobre instruções de sistema) e da distinção entre instructions e input (como nos guias da OpenAI): o persistente frente ao pedido concreto. No Cursor aparecem como rules. No Claude Desktop, como instruções do projeto. O nome muda; a tensão de escritório é a mesma.
Colar regras em cada mensagem versus políticas no nível da empresa
Ilustração de escritório — demo de mesa, não caso de cliente.
Versão A. Você cola as regras junto do pórtico em cada mensagem. Na terceira pergunta o histórico cresceu, o modelo compactou contexto e as suas regras ficaram misturadas com números, hipóteses e piadas da conversa. O chat «esqueceu» o que nunca esteve fixado no nível de políticas.
Versão B. As mesmas oito linhas vivem como instruções persistentes do cliente — como políticas de empresa. O pedido do pórtico entra limpo. As regras continuam aí mesmo que você mude a pergunta. Não porque o modelo virou engenheiro: porque o harness as reinjeta.
Essa é a diferença que importa em AEC. Não é mágica. É onde mora o contrato.
O que vai aí, o que não vai
Vai no system / instructions (políticas)
- Papel concreto: «assistente de revisão estrutural no escritório; você não emite verificação assinada».
- Unidades e convenções: kN, m, graus, critério de arredondamento.
- O que é proibido inventar: IDs, cargas, resultados de motor, cláusulas normativas.
- Quando deve parar e perguntar: falta de arquivo, ambiguidade de versão, tool caída.
- Quais tools existem e para quê (se o harness as expõe).
Vai no pedido (user)
- O pórtico de hoje, o nível, o arquivo, a pergunta concreta.
- Dados do projeto que mudam em cada tarefa.
- O entregável de que você precisa agora.
Vai numa tool / motor
- Abrir o modelo, ler parâmetros, rodar OpenSees ou CalculiX, validar esquemas.
- Qualquer número que pretenda ser resultado de engenharia.
Se você mete o cálculo no system prompt, está pedindo poesia de uniforme. Se mete as regras só no user, está apostando que a conversa não as dilua.
Peça do harness: H-01 — instruções e políticas
Em o que é um harness de IA, o arnês se descreve como o quadro com que o modelo trabalha: ferramentas, instruções, checagens e a sua assinatura. O system prompt é uma peça desse quadro — H-01: instruções / políticas. Não é a oficina inteira.
Três limites que evitam o autoengano:
- Um system prompt não executa. Pode dizer «use a tool do Revit», mas sem uma tomada real (por exemplo MCP ou outra mão) não abre nada.
- Um system prompt não é memória de projeto. Não lembra o RFI da semana passada a menos que o harness o carregue.
- Um system prompt não assina. «Aja como engenheiro sênior» não transfere registro nem responsabilidade.
Por isso a frase do harness continua sendo a bússola: o modelo raciocina e propõe; o harness conecta, executa, verifica e limita; o profissional decide e assina. O system prompt ajuda o raciocínio a respeitar políticas. Não substitui tools, motores nem assinatura.
Conclusão
Você colou as regras e na terceira já não as tinha. Essa cena não é meme: é o sintoma de confundir uma mensagem com políticas de empresa.
O chat não vira engenheiro por um parágrafo. O system prompt é a instrução persistente do harness: papel, limites e jeito de trabalhar. Escreva, audite e tire do pedido. O cálculo e a assinatura continuam sendo outra coisa.
Se quiser o quadro completo ao redor do modelo, leia o que é um harness de IA. Para o pedido do dia, siga com prompt engineering. Para por que duas rodadas podem diferir, o papel do LLM.
Fontes
- Anthropic — documentação sobre system prompts (instruções de sistema versus entrada do usuário; consulte a documentação oficial da plataforma).
- OpenAI — Prompt engineering: distinção entre instructions e input (consulte o guia oficial de prompt engineering).
Avaliação e limitações
Trate as notas abaixo como contexto de avaliação, não como um cálculo ou uma verificação comprovados.
Revise o system prompt junto com tools e aprovações. O texto de política é H-01; não é o sistema completo.