Prompt engineering para engenharia civil

Analogia: instruções a um engenheiro do escritório

Imagine que você encarrega um trabalho a um engenheiro do escritório.

Versão ruim: «Melhora o estudo do pórtico.» Sem escopo, sem entregáveis, sem unidades, sem dizer qual arquivo abrir nem o que não inventar. O que volta pode ser brilhante… ou uma coisa que você não pediu. E se não fixou critérios, não tem forma limpa de recusar.

Versão clara: «Revise o pórtico do nível 3 no arquivo X. Unidades em kN e m. Liste hipóteses, cargas e avisos. Não invente resultados de motor: se faltarem, peça. Entregue em seções: hipóteses, fatos, pendências. Se o modelo não abrir, pare e avise.»

Isso não é feitiço. É uma ordem de serviço. Prompt engineering, em linguagem de escritório, é exatamente isso: desenhar as instruções que você dá ao assistente — aqui, a um «engenheiro» dentro da empresa digital — para que o trabalho seja verificável, não só persuasivo.

Instruções ruins (sem clareza, sem escopo, sem entregáveis) produzem trabalho que você não queria. Boas instruções não garantem mágica; garantem que você pode auditar, recusar e repetir.

Esta nota faz parte da série sobre o harness de IA para engenharia civil. Leia junto com o system prompt (onde vivem as políticas) e o papel do LLM (por que duas rodadas podem diferir).

Você escreveu «melhor» e colou no relatório

Você pede uma memória de cálculo «mais clara». O chat responde com um texto limpo. Você cola no relatório. Meia hora depois, por curiosidade, roda o mesmo pedido de novo. O tom mudou. Uma hipótese se moveu. Um número aparece com outra redação — ou diretamente outro valor.

Você escreveu «melhor» e tratou como procedimento. Não era.

A crença que convém quebrar: prompt engineering é um curso de truques, ou pedir que «pense passo a passo» até soar profissional. No escritório AEC, prompt engineering é outra coisa: desenhar instruções verificáveis — como as que você daria a qualquer pessoa da equipe — e testá-las antes de tocarem um entregável.

O que é prompt engineering (sem o curso)

Na prática, prompt engineering é escrever instruções para que o modelo gere de forma mais consistente o que você pediu. Não garante identidade bit a bit entre rodadas. O output — a saída — é não determinístico por padrão: pode variar mesmo que o pedido seja o mesmo. Isso se desenvolve na peça sobre o papel do LLM.

Um bom prompt de escritório costuma incluir:

• Papel delimitado (o que é e o que não é).
• Delimitadores claros (o que é dado, o que é pedido, o que é exemplo).
• Contexto mínimo necessário (não o projeto inteiro «por precaução»).
• Formato de saída (seções, unidades, o que marcar como hipótese).
• Exemplos do correto e do incorreto quando o risco justifica.
• Critérios de recusa: quando deve dizer «não consigo» em vez de inventar.

Isso não é feitiço. É um procedimento incompleto até você versionar e rodar mais de uma vez.

Ordens vagas versus ordens claras

Ilustração — demo de mesa, não caso de cliente.

Pedido A: «Escreve melhor esta memória.»

Pedido B: o mesmo encargo com papel, delimitadores, lista de checagem (hipóteses, cargas, unidades, avisos) e a regra «não invente resultados de motor; se faltarem, peça».

Você roda B duas vezes. A segunda não coincide de todo com a primeira. Isso não é falha do seu prompt: é a natureza do modelo. Por isso um prompt que funcionou uma vez não é procedimento de escritório.

Se a segunda rodada muda um número que você achava «fechado», não cole. Peça evidência de motor ou trate o texto como rascunho de redação, não como cálculo.

A diferença entre A e B não é «mais tokens mágicos». É a mesma diferença entre um e-mail vago e uma ordem de serviço que um chefe consegue revisar.

User prompt versus políticas do system

As políticas persistentes — o system prompt / instructions / rules — dizem como o assistente deve se comportar sempre: papel, unidades, proibições, quando parar. Isso é o nível empresa.

O user prompt — o pedido — diz qual trabalho precisa ser feito agora: o pórtico de hoje, o trecho a reescrever, os anexos.

Prompt engineering não substitui essas políticas. Usa. Se você mistura tudo numa só mensagem, está desenhando uma ordem de serviço que se dilui sozinha. Se separa políticas (system) e pedido (user), está desenhando como num escritório: o manual da qualidade não se reescreve em cada tarefa; a ordem do dia, sim.

Harness sem prompts claros é uma oficina com mãos e sem contrato. Prompts claros sem harness são contratos que ninguém executa nem verifica.

Checklist prático de escritório

Em instructions / system (persistente)

O que não deveria mudar em cada pórtico: papel, unidades, proibições, formato-base, quando parar. Ver system prompt.

No pedido (user)

O entregável de hoje, os dados, o trecho a reescrever, os anexos. Escopo explícito. Entregável explícito.

Antes de colar no relatório

1. Guarde o prompt com versão (data + mudança).
2. Rode pelo menos duas vezes com o mesmo input.
3. Anote o que mudou: tom, estrutura, hipóteses, números.
4. Defina quais diferenças são aceitáveis e quais param o fluxo.
5. Se houver número crítico, exija tool/motor ou recuse a colagem.
6. Marque hipóteses frente a fatos na saída.
7. Se não puder dizer qual arquivo ou motor respalda um número, não assine.

Ajudas de reprodutibilidade em algumas APIs (seeds, snapshots) podem reduzir variedade; não transformam o chat em ETABS. São ajudas de software, não substituto de solver.

Ação imediata (menos de 15 minutos)

Pegue um prompt que você já use no escritório.

1. Acrescente papel.
2. Separe dados e pedido com delimitadores.
3. Acrescente um exemplo curto de saída aceitável.
4. Rode duas vezes.
5. Marque o que mudou.
6. Não cole no relatório ainda.

Se não sobreviveu a duas rodadas com diferenças aceitáveis, não é procedimento: é rascunho.

Relação com as peças vizinhas

• O system prompt responde onde vivem as regras persistentes.
• O papel do LLM responde por que duas rodadas podem diferir mesmo com o pedido idêntico.
• O harness responde quem executa, verifica e pede assinatura.

Conclusão

Você escreveu «melhor» e colou no relatório. Essa é a cena que este artigo quer cortar.

Um prompt que funcionou uma vez não é procedimento. Prompt engineering na engenharia civil é desenhar instruções verificáveis — como as que você daria a um engenheiro do escritório —, versioná-las e testá-las, sabendo que o modelo não é determinístico e que o número sério sai de um motor, não de uma frase sortuda. Não são truques. São ordens de serviço.

Fontes

• OpenAI — Prompt engineering (guia oficial: instruções, estrutura e boas práticas).

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.

Versione prompts como encomendas. Se o resultado muda sem mudar os dados, não trate como cálculo reproduzido.