O que é Prompt Engineering e como criar bons prompts para IA

Por: Angelo Luis Ferreira | 30/10/2026 Acessos: 59

Aprenda como estruturar instruções claras, fornecer contexto, definir objetivos e obter respostas mais úteis e precisas de uma Inteligência Artificial Generativa.

Nos artigos anteriores da série IA na Prática, construímos a base necessária para compreender o que acontece por trás de uma ferramenta de Inteligência Artificial Generativa.

Primeiro, vimos o que são IA Generativa, Modelos de Linguagem e LLMs. Depois, abrimos a “caixa-preta” desses modelos e acompanhamos o caminho percorrido por uma solicitação: o texto é transformado em tokens, convertido em representações numéricas, processado pelas camadas do Transformer e utilizado para gerar novos tokens progressivamente.

Agora chegamos a uma pergunta muito mais prática:

Se a maneira como fornecemos informações ao modelo influencia a resposta, como devemos formular nossas solicitações para obter resultados melhores?

É justamente aqui que entram os prompts.

Sempre que escrevemos uma pergunta, uma instrução ou uma tarefa para uma IA Generativa, estamos fornecendo informações que serão utilizadas pelo modelo durante o processamento.

Compare, por exemplo:

"Fale sobre Arduino."

com:

"Explique o que é Arduino para uma pessoa que nunca estudou eletrônica. Use linguagem simples, dê um exemplo prático e evite termos técnicos sem explicação."

Nos dois casos, estamos falando sobre o mesmo assunto.

Mas a segunda solicitação fornece muito mais informações sobre:

• o objetivo;

• o público;

• o nível da explicação;

• o formato esperado;

• as restrições da resposta.

Consequentemente, o modelo recebe um contexto muito mais claro sobre aquilo que esperamos.

Esse é um dos princípios fundamentais que estudaremos neste artigo:

Quanto menor a ambiguidade da solicitação, maior tende a ser a chance de o modelo produzir uma resposta alinhada ao objetivo do usuário.

Isso não significa que prompts maiores sejam sempre melhores.

Também não significa que exista uma fórmula mágica capaz de garantir respostas perfeitas.

Um bom prompt não é necessariamente longo, sofisticado ou cheio de comandos.

Ele precisa, acima de tudo, fornecer ao modelo informações úteis e suficientemente claras para executar a tarefa.

Muito além de fazer perguntas

Quando começamos a utilizar uma IA Generativa, normalmente interagimos com ela como se estivéssemos utilizando um mecanismo de busca:

"O que é PWM?"

"Como funciona um transistor?"

"O que é Inteligência Artificial?"

Mas um LLM pode receber instruções muito mais completas.

Podemos pedir, por exemplo:

"Explique PWM para um estudante de 14 anos que está começando a aprender Arduino. Utilize uma analogia simples, depois apresente um exemplo com controle de brilho de um LED e finalize com um pequeno resumo."

Agora não estamos apenas fazendo uma pergunta.

Estamos definindo:

Assunto: PWM
Público: estudante iniciante
Contexto: aprendizado de Arduino
Estilo: linguagem simples
Exemplo: controle de LED
Estrutura: explicação + exemplo + resumo

Quanto mais claramente definimos essas condições, menos o modelo precisa inferir aquilo que queremos.

O problema dos prompts vagos

Imagine que alguém solicite:

"Faça um texto sobre inteligência artificial."

A solicitação é válida, mas deixa várias perguntas sem resposta:

• Qual deve ser o tamanho do texto?

• Para quem ele será escrito?

• Qual é o objetivo?

• Deve ser técnico ou introdutório?

• Será utilizado em um blog, trabalho acadêmico ou rede social?

• Deve abordar riscos, história, aplicações ou funcionamento?

• Qual formato deverá ser utilizado?

O modelo precisa preencher essas lacunas utilizando padrões aprendidos durante o treinamento e informações disponíveis no contexto.

Isso pode produzir uma resposta razoável.

Mas talvez não seja a resposta que o usuário realmente precisava.

Agora considere:

"Escreva uma introdução de aproximadamente quatro parágrafos para um artigo destinado a iniciantes sobre Inteligência Artificial Generativa. Explique por que o assunto se tornou importante nos últimos anos, mas não entre ainda em detalhes técnicos sobre LLMs."

O espaço para interpretação ficou muito menor.

O modelo sabe:

• o que produzir;

• para quem produzir;

• aproximadamente quanto escrever;

• qual assunto abordar;

• o que ainda não deve abordar.

É aqui que surge o Prompt Engineering

A prática de estruturar instruções e informações para orientar melhor o comportamento de modelos de IA ficou conhecida como Prompt Engineering.

Em português, encontramos frequentemente expressões como:

Engenharia de Prompt

ou:

Engenharia de Prompts

Apesar do nome aparentemente sofisticado, o princípio fundamental é bastante simples:

comunicar claramente ao modelo aquilo que queremos que ele faça.

Entretanto, quando começamos a desenvolver aplicações mais avançadas, a construção de prompts pode envolver técnicas muito mais elaboradas.

Podemos trabalhar com:

• contexto;

• exemplos;

• formatos estruturados;

• restrições;

• critérios de avaliação;

• instruções em várias etapas;

• documentos;

• dados externos;

• ferramentas.

Portanto, aprender a construir bons prompts não serve apenas para utilizar melhor um chatbot.

Esse conhecimento será importante quando começarmos a desenvolver sistemas utilizando APIs, automações, RAG, ferramentas e agentes de IA.

Prompt Engineering não é decorar frases prontas

É comum encontrar conteúdos prometendo:

"O prompt perfeito para qualquer situação."

ou:

"100 prompts secretos que transformam o ChatGPT."

Esses materiais podem fornecer ideias úteis, mas também podem criar uma compreensão equivocada do assunto.

Não existem palavras mágicas capazes de transformar automaticamente qualquer solicitação em uma resposta perfeita.

O que realmente importa é compreender:

• qual é o objetivo;

• quais informações o modelo precisa;

• qual contexto é relevante;

• qual resultado esperamos;

• quais limites precisam ser respeitados.

Em outras palavras:

Prompt Engineering é muito mais sobre especificar corretamente um problema do que descobrir comandos secretos.

Um modelo mental para começar

Ao longo deste artigo, desenvolveremos uma estrutura que poderá ser reutilizada em praticamente qualquer ferramenta de IA Generativa.

Podemos começar pensando em sete elementos:

OBJETIVO

↓

CONTEXTO

↓

INSTRUÇÕES

↓

PÚBLICO

↓

FORMATO

↓

RESTRIÇÕES

↓

EXEMPLOS

Nem todo prompt precisará conter todos esses elementos.

Uma pergunta simples pode exigir apenas uma linha.

Uma tarefa complexa pode precisar de uma estrutura muito mais detalhada.

O importante será aprender a identificar quais informações realmente ajudam o modelo a compreender a tarefa.

O que aprenderemos neste artigo

Nos próximos tópicos, veremos:

• o que realmente é um prompt;

• o que significa Prompt Engineering;

• a diferença entre prompt e contexto;

• por que solicitações vagas produzem resultados menos previsíveis;

• quais elementos formam um bom prompt;

• como definir objetivo, público, formato e restrições;

• quando fornecer exemplos;

• como utilizar Zero-shot, One-shot e Few-shot;

• como dividir tarefas complexas;

• como refinar uma resposta durante uma conversa;

• quais técnicas realmente ajudam;

• quais práticas são apenas mitos ou exageros.

Também compararemos prompts ruins e melhorados para observar, na prática, como pequenas mudanças na solicitação podem alterar significativamente a qualidade da resposta.

Ao final do artigo, o objetivo não será simplesmente fornecer uma coleção de prompts prontos.

Será permitir que você consiga olhar para qualquer tarefa e pensar:

“Que informações esta IA precisa receber para executar corretamente aquilo que eu quero?”

Essa é a habilidade que realmente torna o uso de Inteligência Artificial Generativa mais eficiente, previsível e útil.

Um prompt é a entrada fornecida a um modelo de Inteligência Artificial para orientar aquilo que ele deve fazer.

Na prática, pode ser uma pergunta, uma instrução, uma descrição, um conjunto de dados ou uma combinação desses elementos.

Por exemplo:

"O que é Arduino?"

é um prompt.

Assim como:

"Explique o que é Arduino para um iniciante, usando linguagem simples e um exemplo prático."

também é um prompt.

Os dois tratam do mesmo assunto, mas fornecem níveis diferentes de informação ao modelo.

Prompt não precisa ser uma pergunta

Um erro comum é pensar que prompt significa apenas "pergunta".

Na verdade, um prompt pode assumir várias formas.

Por exemplo:

Pergunta

"O que é PWM?"

Instrução

"Explique PWM usando uma analogia simples."

Tarefa

"Resuma este texto em cinco tópicos."

Transformação

"Reescreva este parágrafo em linguagem mais formal."

Classificação

"Classifique estas mensagens como positivas, negativas ou neutras."

Geração

"Crie um título para um artigo sobre segurança digital."

Portanto:

Prompt é qualquer entrada utilizada para orientar a resposta ou ação do modelo.

O prompt pode conter vários elementos

Um prompt simples pode ter apenas uma frase.

Mas tarefas mais complexas podem exigir vários componentes.

Considere:

"Você é um professor de eletrônica. Explique PWM para um estudante iniciante de Arduino. Use uma analogia simples, depois mostre um exemplo com controle de brilho de LED e finalize com um resumo em três tópicos."

Esse prompt contém várias informações:

• papel esperado;

• assunto;

• público;

• contexto;

• formato;

• sequência da resposta.

Podemos decompor assim:

Papel

Você é um professor de eletrônica.

Objetivo

Explique PWM.

Público

estudante iniciante de Arduino.

Instrução

Use uma analogia simples.

Exemplo solicitado

controle de brilho de LED.

Formato final

resumo em três tópicos.

Isso mostra que um prompt pode ser muito mais do que uma frase isolada.

Prompt, instrução, mensagem e contexto não são exatamente a mesma coisa

Esses termos são frequentemente usados como sinônimos, mas existe uma diferença importante.

Prompt

É a entrada utilizada para orientar o processamento de um modelo de IA.

Em uma conversa, costumamos chamar de prompt do usuário a solicitação enviada naquele momento.

Pode conter uma ou várias instruções.

Instrução

É uma orientação específica dentro do prompt.

Por exemplo:

"Explique em linguagem simples."

Essa frase é uma instrução.

Mensagem

Em uma interface de chat, cada envio do usuário normalmente aparece como uma mensagem.

Uma mensagem pode conter um prompt completo ou apenas uma continuação da conversa.

Por exemplo:

"Agora dê um exemplo."

Isso é uma nova mensagem, mas depende do contexto anterior para fazer sentido.

Contexto

É o conjunto mais amplo de informações disponíveis ao modelo durante o processamento.

Pode incluir:

• mensagens anteriores;

• instruções do sistema;

• documentos;

• dados externos;

• resultados de ferramentas;

• o prompt atual.

Portanto:

O prompt faz parte do contexto, mas o contexto pode ser maior do que o prompt.

Um exemplo completo

Imagine esta conversa:

Usuário: Estou estudando Arduino e ainda sou iniciante em eletrônica.

Depois:

Usuário: Explique PWM de maneira simples.

O segundo texto é o prompt atual.

Mas o modelo pode utilizar também a informação anterior:

"Estou estudando Arduino e ainda sou iniciante em eletrônica."

Essa informação faz parte do contexto.

Por isso, a resposta pode ser adaptada ao nível do usuário.

Um prompt pode depender do contexto

Considere:

"Explique isso de outra forma."

Sozinha, essa frase é pouco informativa.

Mas dentro de uma conversa, pode funcionar perfeitamente.

O modelo consegue interpretar:

"isso"

porque o assunto já está presente no contexto.

Portanto, um prompt não precisa conter todas as informações em todas as mensagens.

Ele pode utilizar informações que já foram fornecidas anteriormente.

Quanto mais claro o prompt, melhor?

Geralmente, clareza ajuda bastante.

Mas isso não significa que prompts longos sejam sempre melhores.

Compare:

"Explique Arduino."

com:

"Explique Arduino para um iniciante."

A segunda versão já adiciona uma informação útil.

Agora compare com:

"Explique Arduino para um iniciante, em linguagem simples, usando um exemplo prático."

A solicitação ficou mais específica.

Mas se adicionarmos dezenas de instruções desnecessárias, o prompt pode se tornar confuso.

Portanto, o objetivo não é escrever o maior prompt possível.

É fornecer:

as informações necessárias para reduzir ambiguidades e orientar corretamente a tarefa.

Prompt não é comando mágico

Outro ponto importante é que prompts não funcionam como palavras secretas.

Expressões como:

"aja como especialista"

ou:

"pense passo a passo"

podem influenciar a forma da resposta em determinadas situações, mas não transformam automaticamente o modelo em uma fonte infalível.

O que realmente faz diferença é:

• clareza;

• contexto;

• objetivo;

• critérios;

• formato;

• restrições;

• exemplos adequados.

Uma forma simples de pensar

Podemos resumir:

Prompt é aquilo que fornecemos ao modelo para orientar o que queremos que ele faça.

E um bom prompt procura responder, quando necessário, perguntas como:

• O que eu quero?

• Sobre qual assunto?

• Para quem?

• Em qual formato?

• Com quais limites?

• Com base em quais informações?

Nem toda tarefa precisará responder a tudo isso.

Mas quanto mais complexa for a tarefa, mais importante será estruturar a solicitação de forma clara.

O ponto principal

Prompt não é apenas uma pergunta digitada em um chatbot.

Ele é a interface entre:

intenção do usuário

e

processamento do modelo

Se essa intenção for mal especificada, o modelo precisará fazer mais suposições.

Se for bem estruturada, aumentam as chances de obter uma resposta mais alinhada ao objetivo.

No próximo tópico veremos justamente o conceito que surgiu para organizar esse processo:

Depois de entender o que é um prompt, podemos avançar para um conceito mais amplo:

Prompt Engineering é a prática de planejar, estruturar, testar e melhorar prompts para orientar modelos de Inteligência Artificial a produzir resultados mais adequados a um objetivo.

Em português, o termo costuma aparecer como:

Engenharia de Prompt

ou:

Engenharia de Prompts

Apesar do nome, não estamos falando necessariamente de uma engenharia formal no mesmo sentido de áreas tradicionais como Engenharia Civil ou Engenharia Elétrica.

Aqui, a palavra engineering está mais próxima da ideia de projetar uma solução de forma estruturada.

Ou seja:

não é apenas escrever uma pergunta;

é pensar em como formular a tarefa para que o modelo compreenda melhor aquilo que esperamos dele.

O objetivo é reduzir ambiguidades

Considere o prompt:

"Faça um texto sobre Arduino."

O modelo consegue gerar uma resposta.

Mas várias decisões ficaram abertas:

• qual é o público?

• qual é o tamanho?

• qual é o objetivo?

• qual nível técnico deve ser utilizado?

• deve ser um tutorial, introdução ou artigo?

• deve conter exemplos?

• deve explicar eletrônica?

• deve apresentar código?

O modelo precisará preencher essas lacunas por conta própria.

Agora considere:

"Escreva uma introdução para um artigo destinado a iniciantes explicando o que é Arduino, para que ele serve e por que é utilizado em projetos de eletrônica. Use linguagem simples e não apresente código ainda."

Agora a tarefa possui muito menos ambiguidade.

Esse é um dos principais objetivos da Engenharia de Prompt:

fornecer informações suficientes para diminuir interpretações indesejadas e aumentar o alinhamento entre a solicitação e o resultado esperado.

Prompt Engineering não significa controlar totalmente o modelo

Mesmo um prompt extremamente bem escrito não garante uma resposta perfeita.

LLMs utilizam distribuições de probabilidade durante a geração de respostas.

Dependendo das configurações e das condições de execução, uma mesma solicitação pode produzir respostas iguais ou diferentes.

Entretanto, mesmo uma resposta reproduzível pode conter erros. Por isso, a Engenharia de Prompt não elimina a necessidade de verificar os resultados.

Portanto, duas execuções podem apresentar diferenças, e o modelo ainda pode:

• interpretar uma instrução de maneira inesperada;

• omitir alguma informação;

• cometer erros;

• produzir dados incorretos;

• gerar respostas diferentes para o mesmo prompt.

Prompt Engineering aumenta a previsibilidade e o alinhamento, mas não transforma o modelo em um sistema determinístico ou infalível.

Engenharia de Prompt é um processo iterativo

Um bom prompt nem sempre nasce pronto.

Muitas vezes, o processo acontece assim:

Escrever o prompt

↓

Observar a resposta

↓

Identificar problemas

↓

Modificar as instruções

↓

Executar novamente

↓

Comparar os resultados

Esse ciclo pode ser repetido até que a resposta esteja suficientemente próxima do objetivo.

Por isso, Prompt Engineering também envolve:

• testes;

• avaliação;

• comparação;

• refinamento.

Um exemplo de evolução

Imagine que queremos uma explicação sobre resistores.

Primeira tentativa:

"Explique resistores."

A resposta poderá ser genérica.

Podemos melhorar:

"Explique o que é um resistor para um iniciante em eletrônica."

Agora o público está definido.

Podemos avançar:

"Explique o que é um resistor para um iniciante em eletrônica. Mostre sua função em um circuito e use um exemplo com LED."

Agora adicionamos um exemplo prático.

E ainda podemos especificar:

"Explique o que é um resistor para um iniciante em eletrônica. Mostre sua função em um circuito com LED, explique por que ele limita corrente e finalize com um exemplo simples usando 5 V. Evite matemática avançada."

Agora temos:

• objetivo;

• público;

• contexto;

• exemplo;

• limite técnico.

O conteúdo solicitado continua sendo o mesmo.

O que mudou foi a qualidade da especificação da tarefa.

Prompt Engineering também é definir a saída

Muitas vezes pensamos apenas no conteúdo da pergunta.

Mas também podemos dizer ao modelo como queremos receber a resposta.

Por exemplo:

"Compare Arduino Uno e Mega 2560."

Podemos transformar em:

"Compare Arduino Uno e Mega 2560 em uma tabela com as colunas: microcontrolador, pinos digitais, entradas analógicas, memória Flash e aplicação recomendada."

Agora não especificamos apenas o que queremos.

Também definimos como a resposta deve ser organizada.

Isso é extremamente útil em aplicações reais.

Restrições também fazem parte do prompt

Podemos ainda indicar aquilo que o modelo não deve fazer.

Por exemplo:

"Explique o funcionamento de PWM em até cinco parágrafos. Não utilize fórmulas matemáticas e não entre em detalhes sobre registradores do microcontrolador."

Essas restrições ajudam a limitar o espaço de resposta.

Elas podem ser utilizadas para controlar:

• tamanho;

• linguagem;

• escopo;

• nível técnico;

• formato;

• assuntos proibidos;

• fontes permitidas;

• critérios específicos.

Podemos fornecer exemplos

Outra técnica poderosa é mostrar ao modelo exemplos daquilo que esperamos.

Imagine uma tarefa de classificação:

Classifique cada mensagem como DÚVIDA, ELOGIO ou RECLAMAÇÃO.

Podemos fornecer exemplos:

"Como faço para trocar minha senha?" → DÚVIDA
"O atendimento foi excelente." → ELOGIO
"Meu pedido chegou quebrado." → RECLAMAÇÃO

Depois apresentamos uma nova mensagem:

"Não consigo acessar minha conta."

O modelo pode utilizar os exemplos como referência para produzir:

DÚVIDA

Esse tipo de estratégia será estudado mais adiante quando falarmos de Zero-shot, One-shot e Few-shot.

Prompt Engineering não acontece apenas em chatbots

Embora o conceito seja muito associado ao ChatGPT, prompts são utilizados em vários tipos de aplicações baseadas em IA.

Por exemplo:

Geração de imagens

"Crie uma ilustração de uma bancada de eletrônica em estilo técnico, vista superior."

Programação

"Analise este código PHP e identifique apenas erros que possam causar falha em tempo de execução."

Análise de documentos

"Leia este contrato e identifique cláusulas relacionadas a prazo, reajuste e penalidades."

Automação

"Quando receber uma mensagem de suporte, classifique o assunto e gere uma resposta inicial."

Agentes de IA

"Analise a solicitação, determine qual ferramenta deve ser utilizada e execute apenas ações permitidas."

Portanto, Prompt Engineering não está limitado a escrever perguntas em um chatbot.

Ele pode fazer parte da própria arquitetura de um sistema de IA.

Prompts podem ser escritos por pessoas ou por sistemas

Outro ponto importante é que nem todo prompt é digitado diretamente por um usuário.

Em uma aplicação, prompts podem ser montados automaticamente por software.

Por exemplo:

Usuário envia uma pergunta
        ↓
Aplicação recupera informações
        ↓
Sistema monta um contexto
        ↓
Instruções são adicionadas
        ↓
Prompt é enviado ao LLM

O usuário pode enxergar apenas uma pequena parte desse processo.

Por trás da interface, o sistema pode adicionar:

• instruções internas;

• dados de banco de dados;

• documentos;

• histórico da conversa;

• resultados de ferramentas.

Isso será muito importante posteriormente quando estudarmos RAG, APIs e agentes de IA.

Prompt Engineering é mais importante em tarefas complexas

Para perguntas simples, quase nenhuma engenharia pode ser necessária.

Por exemplo:

"Quanto é 2 + 2?"

ou:

"O que significa HTML?"

Não precisamos construir uma estrutura elaborada.

Por outro lado, tarefas como:

• analisar contratos;

• gerar relatórios;

• produzir código;

• resumir documentos;

• classificar dados;

• executar automações;

podem exigir instruções muito mais cuidadosas.

Por isso:

quanto maior a complexidade e o risco da tarefa, maior tende a ser a necessidade de especificar claramente o que esperamos do modelo.

Um bom prompt começa por um problema bem definido

Esse talvez seja um dos princípios mais importantes de todo o artigo.

Muitas vezes o problema não está na IA.

Está na própria solicitação.

Se nós não sabemos exatamente o que queremos, será difícil fornecer ao modelo uma instrução precisa.

Compare:

"Melhore meu site."

com:

"Analise a página inicial deste site e sugira melhorias especificamente para navegação mobile, velocidade percebida e clareza da chamada principal."

Na segunda solicitação, o problema está muito mais bem definido.

Portanto:

antes de escrever um bom prompt, precisamos compreender claramente qual problema queremos resolver.

Não existe um prompt universalmente perfeito

Um prompt pode funcionar muito bem para determinada tarefa e mal para outra.

Também pode produzir resultados diferentes dependendo:

• do modelo utilizado;

• da versão do modelo;

• do contexto;

• das ferramentas disponíveis;

• dos dados fornecidos;

• das configurações de geração.

Por isso, não existe necessariamente um:

"prompt perfeito para qualquer IA."

O que existe é um prompt adequado a determinado objetivo, contexto e modelo.

Uma definição prática

Podemos resumir Prompt Engineering assim:

Prompt Engineering é o processo de transformar uma intenção humana em instruções e contexto suficientemente claros para orientar um modelo de IA na execução de uma tarefa.

Podemos representar:

INTENÇÃO

↓

ESTRUTURAÇÃO DO PROBLEMA

↓

PROMPT

↓

PROCESSAMENTO PELO MODELO

↓

RESPOSTA

↓

AVALIAÇÃO

↓

REFINAMENTO

Esse ciclo é muito mais importante do que simplesmente memorizar comandos.

O ponto principal

Engenharia de Prompt não é descobrir uma combinação secreta de palavras.

É aprender a:

• definir o problema;

• fornecer contexto;

• escrever instruções claras;

• estabelecer critérios;

• definir a saída esperada;

• testar;

• avaliar;

• melhorar.

É justamente por isso que, antes de estudarmos técnicas mais avançadas, precisamos compreender uma distinção fundamental:

prompt e contexto não são a mesma coisa.

Esse será o assunto do próximo bloco:

Prompt e contexto estão diretamente relacionados, mas não são a mesma coisa.

Essa diferença é importante porque um modelo de IA não responde apenas ao texto que o usuário acabou de digitar.

Ele pode receber um conjunto muito maior de informações.

De forma simples:

Prompt é aquilo que você pede.
Contexto é tudo o que o modelo recebe para processar esse pedido.

O prompt

O prompt é a solicitação atual enviada ao modelo.

Por exemplo:

"Explique PWM de maneira simples."

Esse é o prompt.

Ele contém aquilo que o usuário está pedindo naquele momento.

O contexto

O contexto é mais amplo.

Ele pode incluir:

• o prompt atual;

• mensagens anteriores da conversa;

• instruções internas do sistema;

• documentos;

• dados fornecidos pela aplicação;

• resultados de ferramentas;

• informações recuperadas de bancos de dados;

• outros conteúdos adicionados antes da geração da resposta.

Portanto:

Prompt ⊂ Contexto

Ou, em palavras:

O prompt pode fazer parte do contexto, mas o contexto pode ser muito maior do que o prompt.

Um exemplo simples

Considere esta conversa:

Usuário: Estou começando a estudar Arduino e não conheço eletrônica.

Depois:

Usuário: Explique PWM de maneira simples.

O prompt atual é:

"Explique PWM de maneira simples."

Mas o modelo pode receber também a informação anterior:

"Estou começando a estudar Arduino e não conheço eletrônica."

Essa informação faz parte do contexto.

Por isso, a resposta pode ser adaptada para um iniciante.

O mesmo prompt pode gerar respostas diferentes

Imagine o seguinte prompt:

"Explique porta."

Sozinho, ele é muito ambíguo.

Agora veja três contextos diferentes:

Contexto 1 — Construção civil

Estamos falando sobre elementos de uma casa.

Prompt:

"Explique porta."

Nesse caso, "porta" provavelmente será interpretada como uma estrutura física.

Contexto 2 — Redes de computadores

Estamos estudando protocolos TCP/IP.

Prompt:

"Explique porta."

Aqui, "porta" provavelmente será interpretada como uma porta de comunicação, como 80 ou 443

Estamos estudando entradas e saídas digitais.

Prompt:

"Explique porta."

Agora, o modelo pode interpretar "porta" como uma porta de entrada ou saída do microcontrolador.

O prompt é praticamente o mesmo.

O que mudou foi o contexto.

Contexto reduz ambiguidades

Quanto mais informações relevantes o modelo recebe, menor tende a ser a necessidade de adivinhar aquilo que o usuário realmente quer.

Compare:

"Analise este código."

com:

"Este código foi escrito para Arduino Uno e controla dois LEDs utilizando os pinos 8 e 9. Analise apenas erros que possam impedir a compilação e não altere a lógica do projeto."

No segundo exemplo, o modelo recebeu mais contexto:

• plataforma;

• finalidade;

• pinos utilizados;

• objetivo da análise;

• restrição.

Isso reduz o espaço para interpretações indesejadas.

Contexto não significa simplesmente mais texto

Esse é um ponto importante.

Fornecer mais contexto não significa adicionar qualquer informação ao prompt.

O contexto precisa ser relevante para a tarefa.

Imagine pedir:

"Explique PWM para um iniciante."

e acrescentar:

"Meu carro é azul, gosto de rock e moro perto de uma praça."

Essas informações aumentam o tamanho da entrada, mas não ajudam o modelo a explicar PWM.

Portanto:

Bom contexto não é contexto em excesso. É contexto relevante.

O contexto pode vir de várias fontes

Em uma aplicação moderna de IA, o contexto pode ser montado automaticamente.

Imagine um sistema de atendimento.

O usuário pergunta:

"Onde está meu pedido?"

Antes de enviar essa pergunta ao LLM, a aplicação pode buscar:

• nome do cliente;

• número do pedido;

• status da entrega;

• data prevista;

• transportadora.

O modelo poderá receber algo parecido com:

Cliente: João
Pedido: 45872
Status: em transporte
Previsão: 5 de novembro
Transportadora: ExemploLog

Pergunta do usuário:
Onde está meu pedido?

O usuário digitou apenas:

"Onde está meu pedido?"

Mas o contexto enviado ao modelo é muito maior.

O usuário nem sempre vê todo o contexto

Esse ponto é especialmente importante.

Em muitos sistemas, existem instruções que o usuário não vê.

Por exemplo:

Você é um assistente de suporte.
Responda apenas com base nos dados fornecidos.
Se a informação não estiver disponível, diga que não sabe.

Depois podem ser adicionados:

• histórico da conversa;

• dados do cliente;

• documentos;

• pergunta atual.

Então o fluxo real pode ser:

Instruções do sistema

↓

Dados externos

↓

Histórico

↓

Prompt do usuário

↓

LLM

↓

Resposta

Isso explica por que o comportamento de uma aplicação de IA pode ser muito diferente de simplesmente abrir um chatbot e digitar a mesma pergunta.

Contexto também possui limite

Como vimos no artigo anterior, os modelos trabalham com uma janela de contexto.

Isso significa que existe um limite para a quantidade de informações que podem ser processadas em determinado momento.

Esse limite normalmente é medido em tokens.

Dentro dessa janela podem estar:

• instruções;

• mensagens;

• documentos;

• resultados de ferramentas;

• prompt atual;

• parte da resposta gerada.

Por isso, contextos muito grandes precisam ser administrados.

Mais contexto sempre melhora a resposta?

Não.

Contexto irrelevante, contraditório ou excessivamente grande pode prejudicar o resultado.

Por exemplo, se fornecermos vários documentos com informações conflitantes, o modelo poderá ter dificuldade para determinar qual informação deve priorizar.

Da mesma forma, instruções contraditórias podem gerar respostas menos previsíveis.

Portanto, um bom contexto deve ser:

• relevante;

• claro;

• consistente;

• suficiente;

• organizado.

Prompt e contexto na Engenharia de Prompt

Agora podemos fazer uma distinção importante.

Quando criamos um bom prompt, estamos trabalhando em duas frentes:

1. O que queremos que o modelo faça

Isso aparece nas instruções do prompt.

2. Quais informações ele precisa para fazer bem

Isso faz parte do contexto.

Podemos representar assim:

Objetivo

Explique PWM.

Contexto

O leitor é iniciante em Arduino e ainda não estudou eletrônica.

Instrução

Use linguagem simples e uma analogia.

Formato

Explique em quatro parágrafos e finalize com um exemplo.

Tudo isso pode estar dentro de uma única mensagem.

Mas conceitualmente são elementos diferentes.

Uma analogia simples

Imagine pedir ajuda a um técnico.

Você pode dizer:

"Meu equipamento não funciona."

Isso é a solicitação.

Mas se você acrescentar:

"É um Arduino Uno, alimentado por USB, o LED de energia acende, mas o computador não reconhece a porta serial."

Agora o técnico possui muito mais contexto.

A solicitação continua sendo:

"Ajude-me a descobrir o problema."

Mas as informações adicionais aumentam muito a qualidade da análise.

Com um LLM acontece algo semelhante.

Prompt, contexto e memória também são diferentes

Outra confusão comum envolve memória.

Podemos resumir:

Prompt

solicitação atual.

Contexto

informações disponíveis durante aquele processamento.

Memória

mecanismo que pode armazenar informações para serem recuperadas posteriormente.

Uma memória pode ser usada para adicionar informações novamente ao contexto.

A memória pode armazenar informações para utilização posterior, mas isso não significa que o modelo tenha acesso automático a tudo o que foi armazenado.

Para influenciar uma resposta, essas informações precisam ser disponibilizadas ao modelo durante o processamento, por exemplo, por meio de sua recuperação e inclusão no contexto.

Portanto:

memória não é contexto, mas pode alimentar o contexto.

O ponto principal

A diferença pode ser resumida assim:

Prompt = o que você está pedindo.
Contexto = o que o modelo sabe naquele momento para processar o pedido.

E podemos visualizar:

INSTRUÇÕES DO SISTEMA
        +
HISTÓRICO DA CONVERSA
        +
DOCUMENTOS / DADOS
        +
RESULTADOS DE FERRAMENTAS
        +
PROMPT ATUAL
        ↓
     CONTEXTO
        ↓
       LLM
        ↓
     RESPOSTA

Essa distinção é fundamental para compreender por que a mesma pergunta pode produzir respostas muito diferentes dependendo das informações disponíveis ao modelo.

Um LLM trabalha a partir das informações que recebe.

Isso significa que a qualidade da resposta depende, em grande parte, da qualidade da solicitação, do contexto e das instruções fornecidas ao modelo.

Não porque exista uma fórmula secreta, mas porque:

quanto mais clara for a tarefa, menos o modelo precisará adivinhar o que o usuário realmente deseja.

Prompts vagos deixam muitas decisões abertas

Considere:

"Faça um texto sobre segurança digital."

A solicitação é válida, mas ainda deixa muitas perguntas sem resposta:

• qual é o público?

• qual é o objetivo do texto?

• qual deve ser o tamanho?

• qual nível técnico deve ser utilizado?

• o foco é prevenção, golpes, senhas ou privacidade?

• o texto será usado em blog, escola ou empresa?

• deve haver exemplos?

• deve haver instruções práticas?

O modelo precisará preencher essas lacunas com base nos padrões aprendidos e no contexto disponível.

Isso pode gerar uma resposta correta, mas genérica ou diferente do que o usuário esperava.

Quanto mais específica a intenção, mais direcionada tende a ser a resposta

Agora compare:

"Escreva um artigo introdutório sobre segurança digital para pessoas sem conhecimento técnico. Explique cinco cuidados básicos para evitar golpes online e use exemplos simples do dia a dia."

Aqui o modelo já conhece:

• o tipo de conteúdo;

• o público;

• o nível técnico;

• o tema;

• a quantidade de itens;

• o estilo esperado.

A tarefa ficou mais bem definida.

A qualidade da resposta depende apenas do prompt?

Não.

Embora a clareza das instruções seja importante, a qualidade da resposta também depende de outros fatores, como:

• Capacidade do modelo: diferentes modelos apresentam capacidades e limitações distintas.

• Informações disponíveis: o modelo precisa ter acesso aos dados necessários para executar a tarefa.

• Ferramentas: determinadas atividades exigem consultas externas, execução de código ou acesso a sistemas.

• Complexidade: algumas tarefas exigem verificações que não podem ser substituídas apenas por uma resposta textual.

Por exemplo, um prompt pode solicitar uma revisão completa de um sistema PHP, mas a identificação de todos os problemas não pode ser garantida apenas pela análise textual do código.

Testes de execução, verificação de dependências e análise do ambiente continuam sendo necessários.

📌 Importante

Um bom prompt aumenta as chances de obter resultados adequados, mas não substitui as capacidades necessárias à execução da tarefa nem a verificação das respostas.

O modelo não consegue adivinhar com precisão tudo o que você quer

Quando um prompt é ambíguo, o LLM precisa inferir aquilo que falta.

Por exemplo:

"Melhore este código."

O que significa "melhorar"?

Pode significar:

• corrigir erros;

• aumentar desempenho;

• simplificar;

• melhorar segurança;

• organizar;

• documentar;

• modernizar;

• reduzir consumo de memória.

Sem essa informação, o modelo precisa escolher uma interpretação.

Agora veja:

"Analise este código PHP e corrija apenas problemas que possam causar erros em tempo de execução. Não altere a arquitetura nem os nomes das funções."

A solicitação ficou muito mais precisa.

Clareza reduz interpretações indesejadas

Um bom prompt ajuda a restringir o espaço de possibilidades.

Compare:

"Crie um resumo."

com:

"Resuma este texto em até seis tópicos, mantendo apenas os conceitos essenciais e sem adicionar informações que não estejam no conteúdo original."

Na segunda versão, definimos:

• formato;

• tamanho;

• critério de seleção;

• restrição.

Isso ajuda o modelo a produzir uma resposta mais previsível.

O contexto também influencia a qualidade

A qualidade do prompt não depende apenas da forma como a instrução é escrita.

Ela também depende das informações disponíveis.

Considere:

"Esse código está correto?"

Se o código não for fornecido, o modelo não possui informações suficientes.

Da mesma forma:

"Analise este contrato."

pode ser insuficiente se o contrato não estiver disponível.

Portanto:

um bom prompt não substitui a necessidade de fornecer os dados necessários para executar a tarefa.

Especificidade não significa excesso de detalhes

Existe um equilíbrio importante.

Um prompt muito vago pode deixar decisões demais para o modelo.

Mas um prompt extremamente longo, com dezenas de regras desnecessárias, também pode dificultar a tarefa.

Por exemplo:

"Explique LED para um iniciante."

pode ser suficiente.

Não é necessário escrever várias páginas de instruções para uma tarefa simples.

A pergunta correta é:

Quais informações são realmente necessárias para orientar o modelo?

Bons prompts ajudam a controlar o nível da resposta

Compare:

"Explique transistor."

A resposta pode assumir qualquer nível técnico.

Agora:

"Explique transistor para alguém que conhece tensão, corrente e resistência, mas ainda não estudou semicondutores."

Agora o modelo possui uma referência clara sobre o conhecimento prévio do leitor.

Isso permite ajustar:

• vocabulário;

• profundidade;

• exemplos;

• quantidade de detalhes.

Bons prompts ajudam a controlar o formato

Também podemos definir como queremos receber a informação.

Compare:

"Compare Arduino Uno e Mega."

com:

"Compare Arduino Uno e Mega 2560 em uma tabela contendo microcontrolador, memória Flash, SRAM, quantidade de pinos digitais, entradas analógicas e aplicação recomendada."

A segunda solicitação reduz a necessidade de o modelo decidir como estruturar a resposta.

Bons prompts ajudam a limitar o escopo

Imagine:

"Fale sobre Inteligência Artificial."

Esse assunto é enorme.

Agora:

"Explique apenas a diferença entre IA tradicional e IA Generativa para um leitor iniciante. Não entre ainda em LLMs ou agentes."

O modelo recebe um limite claro.

Isso é especialmente útil em:

• artigos;

• cursos;

• documentação;

• relatórios;

• análises técnicas.

Bons prompts facilitam a verificação

Uma resposta também pode ser mais fácil de avaliar quando o prompt define critérios objetivos.

Por exemplo:

"Analise este código."

é difícil de verificar porque não sabemos exatamente o que deveria ser analisado.

Já:

"Verifique se este código apresenta erros de sintaxe, variáveis não inicializadas ou funções inexistentes. Liste cada problema separadamente."

permite comparar a resposta com critérios específicos.

A qualidade da resposta não depende apenas do prompt

Este ponto é importante.

Um ótimo prompt não garante uma ótima resposta.

O resultado também depende de fatores como:

• capacidade do modelo;

• informações disponíveis no contexto;

• qualidade dos dados fornecidos;

• ferramentas disponíveis;

• configurações de geração;

• complexidade da tarefa.

Portanto:

Prompt Engineering melhora as condições da tarefa, mas não elimina as limitações do modelo.

Um exemplo completo

Considere três versões da mesma solicitação.

Versão 1

"Fale sobre PWM."

Muito aberta.

Versão 2

"Explique PWM para um iniciante em Arduino."

Agora temos público e contexto.

Versão 3

"Explique PWM para um iniciante em Arduino que já conhece entradas e saídas digitais. Use uma analogia simples, explique como ele pode controlar o brilho de um LED e finalize com três pontos principais. Não entre em registradores ou timers."

Agora temos:

• assunto;

• público;

• conhecimento prévio;

• exemplo;

• formato;

• restrição.

A terceira versão oferece ao modelo muito mais informação para produzir uma resposta alinhada ao objetivo.

O ponto principal

A qualidade do prompt influencia a resposta porque define o espaço no qual o modelo trabalhará.

Quanto mais clara for a especificação:

Objetivo

↓

Contexto

↓

Instruções

↓

Critérios

↓

Formato

menor tende a ser a quantidade de decisões que o modelo precisará inferir por conta própria.

Isso não significa escrever prompts enormes.

Significa escrever prompts adequados à complexidade da tarefa.

No próximo bloco, vamos transformar essa ideia em uma estrutura prática:

Até aqui vimos que um bom prompt não precisa ser longo, complicado ou cheio de palavras técnicas.

O mais importante é que ele forneça ao modelo as informações necessárias para executar a tarefa com o mínimo possível de ambiguidade.

Podemos organizar essas informações em alguns elementos principais:

Objetivo + Contexto + Instruções + Público + Formato + Restrições + Exemplos

Nem todo prompt precisa conter todos esses elementos.

Uma pergunta simples pode exigir apenas um ou dois.

Já uma tarefa mais complexa pode se beneficiar de praticamente todos eles.

1. Objetivo

O primeiro elemento é deixar claro:

O que você quer que o modelo faça?

Exemplos:

"Explique o que é PWM."

"Resuma este texto."

"Compare Arduino Uno e Mega 2560."

"Analise este código procurando erros."

O objetivo define a tarefa principal.

Quanto mais claro ele estiver, menor será a necessidade de o modelo inferir aquilo que você deseja.

2. Contexto

Depois, devemos perguntar:

Quais informações o modelo precisa conhecer para executar bem essa tarefa?

Por exemplo:

"Estou começando a estudar Arduino e ainda não conheço eletrônica."

Essa informação ajuda o modelo a ajustar a profundidade da explicação.

Em outra situação:

"Este código roda em PHP 8.3 e utiliza PDO para acessar MySQL."

Agora o contexto técnico ajuda a evitar respostas incompatíveis com o ambiente.

Contexto pode incluir:

• situação;

• problema;

• dados disponíveis;

• tecnologias utilizadas;

• conhecimento prévio;

• documentos;

• informações externas;

• histórico relevante.

3. Instruções

As instruções dizem como a tarefa deve ser executada.

Por exemplo:

"Explique passo a passo."

"Compare os dois códigos."

"Mostre primeiro o problema e depois a correção."

"Não apenas dê a resposta; explique o raciocínio técnico."

Uma tarefa pode conter várias instruções.

O importante é que elas não sejam contraditórias.

4. Público

Quando estamos produzindo conteúdo, explicar para quem a resposta será destinada pode melhorar bastante o resultado.

Compare:

"Explique resistência elétrica."

com:

"Explique resistência elétrica para um estudante de 12 anos."

ou:

"Explique resistência elétrica para um técnico em eletrônica."

O assunto é o mesmo, mas o nível esperado muda completamente.

O público pode determinar:

• vocabulário;

• profundidade;

• exemplos;

• quantidade de detalhes;

• necessidade de explicar conceitos básicos.

5. Formato

Também podemos definir como queremos receber a resposta.

Por exemplo:

"Apresente em uma tabela."

"Responda em cinco tópicos."

"Use títulos e subtítulos."

"Retorne apenas JSON."

"Crie uma lista numerada."

Isso é particularmente importante quando a saída será utilizada por outro sistema.

Em automações, por exemplo, um formato bem definido pode ser mais importante do que o estilo do texto.

6. Restrições

Restrições estabelecem limites.

Podemos indicar:

"Não utilize jQuery."

"Use apenas JavaScript nativo."

"Não ultrapasse cinco parágrafos."

"Não modifique os nomes das funções."

"Utilize apenas as informações presentes no documento."

As restrições ajudam a impedir que o modelo siga caminhos que não interessam ao usuário.

7. Exemplos

Em determinadas tarefas, fornecer exemplos pode ser uma das formas mais eficazes de mostrar aquilo que esperamos.

Considere uma classificação:

Classifique as mensagens como DÚVIDA, ELOGIO ou RECLAMAÇÃO.

Podemos adicionar:

"Como altero minha senha?" → DÚVIDA

"Gostei muito do atendimento." → ELOGIO

"Meu produto chegou quebrado." → RECLAMAÇÃO

Depois:

"Não consigo acessar minha conta."

Agora o modelo possui exemplos concretos do comportamento esperado.

Juntando os elementos

Vamos partir de um prompt muito simples:

"Explique PWM."

Agora podemos estruturá-lo progressivamente.

Objetivo

Explique o que é PWM.

Contexto

Estou começando a estudar Arduino.

Público

A explicação será para alguém sem conhecimento avançado de eletrônica.

Instruções

Comece pelo conceito e depois mostre uma aplicação prática.

Formato

Use pequenos parágrafos e finalize com um resumo de três tópicos.

Restrição

Não explique timers ou registradores neste momento.

Exemplo

Utilize controle de brilho de um LED como exemplo.

O prompt completo poderia ser:

"Explique o que é PWM para um iniciante que está começando a estudar Arduino e ainda não possui conhecimento avançado de eletrônica. Comece explicando o conceito de forma simples, depois mostre como ele pode ser utilizado para controlar o brilho de um LED. Use pequenos parágrafos e finalize com um resumo de três tópicos. Não entre ainda em timers ou registradores."

Perceba que não adicionamos palavras mágicas.

Nós apenas especificamos melhor a tarefa.

Uma estrutura reutilizável

Podemos transformar esses elementos em um modelo simples:

OBJETIVO
O que eu quero que a IA faça?

CONTEXTO
Que informações ela precisa conhecer?

INSTRUÇÕES
Como a tarefa deve ser executada?

PÚBLICO
Para quem a resposta será produzida?

FORMATO
Como quero receber o resultado?

RESTRIÇÕES
Quais limites precisam ser respeitados?

EXEMPLOS
Existe algum exemplo que mostre o resultado esperado?

Esse modelo não deve ser utilizado como uma regra rígida.

Ele funciona como um checklist mental.

Antes de enviar uma solicitação, podemos perguntar:

Falta alguma informação importante para o modelo executar esta tarefa?

Nem todos os elementos são obrigatórios

Considere:

"Traduza 'Good morning' para português."

Não precisamos informar:

• público;

• contexto detalhado;

• formato complexo;

• exemplos;

• várias restrições.

A tarefa já é suficientemente clara.

Agora considere:

"Analise meu sistema."

Nesse caso, provavelmente faltam várias informações:

• qual sistema?

• qual tecnologia?

• qual problema?

• o que deve ser analisado?

• qual resultado esperamos?

Portanto:

a complexidade do prompt deve acompanhar a complexidade da tarefa.

Ordem também ajuda

Em prompts maiores, organizar as informações de maneira lógica pode melhorar a clareza.

Uma estrutura bastante útil é:

Contexto

↓

Objetivo

↓

Instruções

↓

Restrições

↓

Formato esperado

Por exemplo:

"Tenho uma aplicação PHP 8.3 que utiliza PDO e MySQL. Analise o código abaixo procurando possíveis falhas de segurança relacionadas ao banco de dados. Explique cada problema encontrado e apresente uma correção. Não altere a arquitetura da aplicação. Organize a resposta em: problema, risco e solução."

Esse prompt é fácil de compreender porque cada parte possui uma função clara.

Para tarefas complexas, use separadores

Quando o prompt possui muitas informações, podemos utilizar títulos ou delimitadores.

Por exemplo:

CONTEXTO:
Aplicação PHP 8.3 utilizando PDO e MySQL.

OBJETIVO:
Encontrar vulnerabilidades relacionadas ao banco de dados.

RESTRIÇÕES:
Não alterar a arquitetura do projeto.

FORMATO:
Para cada problema, mostrar:
- problema
- risco
- correção

CÓDIGO:
[cole o código aqui]

Esse tipo de organização torna o prompt mais legível tanto para quem escreve quanto para quem precisará mantê-lo posteriormente.

É especialmente útil em:

• APIs;

• automações;

• agentes;

• prompts reutilizáveis;

• sistemas empresariais.

O melhor prompt não é necessariamente o mais completo

Existe uma tentação de transformar qualquer prompt em um formulário gigantesco.

Isso também pode ser um erro.

O objetivo não é preencher obrigatoriamente sete campos.

O objetivo é identificar:

quais informações realmente influenciam o resultado desta tarefa?

Se uma informação não ajuda o modelo a produzir uma resposta melhor, talvez ela nem precise estar ali.

Um modelo mental simples

Podemos guardar esta estrutura:

O QUE?
→ Objetivo

EM QUAL SITUAÇÃO?
→ Contexto

COMO?
→ Instruções

PARA QUEM?
→ Público

EM QUAL FORMATO?
→ Formato

COM QUAIS LIMITES?
→ Restrições

TEM UM MODELO DO QUE ESPERO?
→ Exemplos

Essa estrutura será nosso ponto de referência ao longo dos próximos tópicos.

A partir de agora, vamos analisar cada elemento com mais profundidade.

Começaremos pelo mais importante:

Um dos erros mais comuns ao escrever prompts é começar pela forma da resposta antes de definir com precisão o que realmente queremos que a IA faça.

Antes de pensar em formato, tamanho, tom ou exemplos, vale responder a uma pergunta simples:

Qual é o resultado que eu quero obter?

Esse é o objetivo do prompt.

Um objetivo claro reduz interpretações

Compare:

"Fale sobre Arduino."

com:

"Explique o que é Arduino."

ou:

"Compare Arduino Uno e Mega 2560."

ou ainda:

"Analise este código Arduino e identifique erros de compilação."

Todos os exemplos tratam de Arduino, mas cada um possui um objetivo diferente.

No primeiro caso, o pedido é amplo.

Nos demais, a tarefa está muito mais clara:

• explicar;

• comparar;

• analisar.

O verbo utilizado no prompt já ajuda a definir o tipo de tarefa esperado.

Use verbos que expressem a ação desejada

Uma boa prática é iniciar a solicitação com um verbo que represente claramente o que você espera.

Por exemplo:

• explique;

• resuma;

• compare;

• classifique;

• analise;

• revise;

• traduza;

• organize;

• converta;

• extraia;

• liste;

• gere;

• identifique;

• avalie;

• reescreva.

Compare:

"Arduino Uno e Mega."

com:

"Compare Arduino Uno e Mega 2560."

A segunda versão informa imediatamente ao modelo o que deve ser feito.

Um prompt pode ter mais de um objetivo

Isso é possível, mas precisa ser feito com cuidado.

Considere:

"Analise este código, corrija os erros, explique as correções, melhore a performance, adicione comentários e reescreva a documentação."

O modelo consegue tentar executar todas essas tarefas, mas o prompt já contém vários objetivos diferentes.

Em situações assim, pode ser melhor organizar:

OBJETIVO PRINCIPAL:
Corrigir erros que impeçam a execução do código.

DEPOIS:
1. Explique cada correção.
2. Sugira melhorias de performance.
3. Adicione comentários apenas onde forem necessários.

Essa estrutura cria uma ordem de prioridade.

Defina o resultado, não apenas o assunto

Existe uma diferença importante entre dizer sobre o que queremos falar e o que queremos produzir.

Por exemplo:

"Segurança digital."

define apenas um assunto.

Já:

"Crie uma lista com cinco cuidados básicos de segurança digital para usuários iniciantes."

define um resultado.

Da mesma forma:

"PHP."

é apenas um tema.

Enquanto:

"Explique a diferença entre include e require em PHP, com um exemplo de cada."

define uma tarefa concreta.

Objetivos vagos geram resultados vagos

Considere:

"Melhore este texto."

O que significa melhorar?

Pode significar:

• corrigir gramática;

• reduzir o tamanho;

• deixar mais formal;

• tornar mais persuasivo;

• melhorar SEO;

• adaptar para iniciantes;

• remover repetições.

Agora compare:

"Revise este texto para melhorar clareza e fluidez, preservando o significado e o nível técnico."

O objetivo está muito mais definido.

Objetivo principal e critérios secundários

Em prompts mais complexos, pode ser útil separar:

Objetivo principal

aquilo que precisa necessariamente ser realizado.

Critérios secundários

características desejáveis da resposta.

Por exemplo:

OBJETIVO PRINCIPAL:
Identificar vulnerabilidades de SQL Injection neste código PHP.

CRITÉRIOS:
- Explique por que cada trecho é vulnerável.
- Apresente uma correção utilizando PDO.
- Preserve a lógica existente.

Isso ajuda o modelo a compreender o que deve receber prioridade.

Não misture tarefas incompatíveis sem necessidade

Imagine:

"Resuma este texto detalhadamente em duas linhas."

Existe uma tensão entre:

detalhadamente

e:

duas linhas.

Outro exemplo:

"Explique tecnicamente, mas sem utilizar nenhum termo técnico."

Essas instruções podem entrar em conflito.

Quanto mais claras e coerentes forem as metas, melhor.

Objetivos mensuráveis ajudam

Quando possível, critérios concretos facilitam a execução e também a avaliação da resposta.

Compare:

"Faça um resumo curto."

com:

"Resuma o texto em até cinco tópicos."

Ou:

"Crie algumas opções de título."

com:

"Crie cinco opções de título com até 60 caracteres."

A segunda forma é mais verificável.

Um exemplo prático

Prompt inicial:

"Ajude com meu artigo sobre Arduino."

O problema é que não sabemos qual ajuda é necessária.

Podemos melhorar:

"Revise a introdução deste artigo sobre Arduino para verificar clareza e adequação a leitores iniciantes."

Agora existe um objetivo definido:

revisar a introdução

e dois critérios:

clareza
adequação ao público iniciante

Podemos ainda acrescentar:

"Não reescreva o texto ainda. Primeiro liste os problemas encontrados."

Agora o comportamento esperado ficou ainda mais preciso.

Quando o objetivo ainda não está claro

Às vezes o próprio usuário ainda não sabe exatamente qual solução deseja.

Nesse caso, o prompt pode solicitar ajuda para definir o problema.

Por exemplo:

"Tenho um site sobre eletrônica com queda de tráfego orgânico. Antes de sugerir soluções, liste quais informações você precisa analisar para identificar as possíveis causas."

Nesse caso, o objetivo não é ainda resolver o problema.

O objetivo é:

definir quais dados serão necessários para investigá-lo.

Isso também é uma tarefa válida e bem especificada.

Uma pergunta útil antes de enviar o prompt

Antes de enviar uma solicitação mais importante, pergunte:

Se outra pessoa lesse este pedido, ela saberia exatamente o que precisa entregar?

Se a resposta for não, provavelmente o objetivo ainda pode ser melhor definido.

Uma estrutura simples

Podemos utilizar:

AÇÃO:
O que a IA deve fazer?

OBJETO:
Sobre o que ela deve fazer isso?

RESULTADO:
O que eu espero receber?

Por exemplo:

AÇÃO:
Compare

OBJETO:
Arduino Uno e Mega 2560

RESULTADO:
Uma comparação técnica para ajudar um iniciante a escolher a placa mais adequada

Isso poderia virar:

"Compare Arduino Uno e Mega 2560 destacando as diferenças técnicas mais importantes para ajudar um iniciante a escolher qual placa utilizar."

O ponto principal

Um bom prompt começa com um objetivo claro.

Antes de adicionar exemplos, restrições ou formatos, devemos saber:

O que exatamente queremos que o modelo faça?

Podemos resumir:

Assunto

Arduino

não é necessariamente um objetivo.

Objetivo

Comparar Arduino Uno e Mega 2560

já define uma tarefa.

Objetivo mais específico

Comparar Arduino Uno e Mega 2560 para ajudar um iniciante a escolher entre as duas placas

define não apenas a tarefa, mas também a finalidade.

Quanto melhor definirmos o resultado desejado, menos decisões desnecessárias deixaremos para o modelo.

No próximo bloco, vamos aprofundar o segundo elemento fundamental de um bom prompt:

Depois de definir claramente o objetivo, o próximo passo é fornecer ao modelo as informações de que ele precisa para executar bem a tarefa.

Essas informações formam o contexto do prompt.

Aqui precisamos fazer uma distinção importante.

No artigo anterior, Como um LLM funciona por dentro?, vimos que contexto, em sentido amplo, é todo o conjunto de informações disponíveis ao modelo durante o processamento, incluindo mensagens anteriores, instruções do sistema, documentos, dados externos, resultados de ferramentas e o próprio prompt atual.

Neste tópico, porém, vamos utilizar a expressão contexto do prompt para nos referirmos especificamente às informações que você fornece na solicitação para situar melhor a tarefa.

Em outras palavras:

Contexto geral do modelo = tudo o que está disponível ao LLM naquele processamento.

Contexto do prompt = informações adicionadas ao prompt para ajudar o modelo a compreender a situação e executar a tarefa.

O contexto do prompt é, portanto, uma parte possível do contexto geral.

Podemos visualizar assim:

Contexto Geral do Modelo

• instruções do sistema;

• histórico da conversa;

• documentos e dados externos;

• resultados de ferramentas;

• memória recuperada, quando houver;

• contexto fornecido no prompt;

• prompt atual.

O contexto do prompt explica a situação

Considere o prompt:

"Corrija este código."

A tarefa está clara apenas em parte.

Ainda faltam informações importantes:

• em qual linguagem ele foi escrito?

• qual versão está sendo usada?

• qual comportamento é esperado?

• qual erro está acontecendo?

• o código pode ser reestruturado?

• existem limitações técnicas?

Agora compare:

"Este código foi escrito em PHP 8.3 e utiliza PDO com MySQL. Ele deveria cadastrar usuários, mas está gerando erro ao executar o INSERT. Corrija apenas o problema que impede a gravação e preserve a estrutura atual."

Nesse caso, informações como:

PHP 8.3
PDO
MySQL
erro no INSERT

formam o contexto fornecido no prompt.

Em termos simples:

Contexto é aquilo que ajuda o modelo a compreender a situação na qual a tarefa está inserida.

Sem contexto suficiente, o modelo precisa fazer mais suposições.

Contexto não é apenas histórico da conversa

Muitas pessoas associam contexto apenas às mensagens anteriores de um chat.

Mas ele pode incluir qualquer informação relevante para a tarefa.

Por exemplo:

• ambiente técnico;

• versão de software;

• objetivo do projeto;

• público-alvo;

• limitações;

• dados de entrada;

• documentos;

• regras de negócio;

• estado atual de um sistema;

• informações anteriores da conversa.

Contexto relevante melhora a precisão

Considere:

"Qual placa devo usar?"

Sozinho, o prompt é amplo demais.

Agora:

"Quero montar um projeto com Wi-Fi, Bluetooth e leitura de três sensores analógicos. O projeto será alimentado por USB e programado pela IDE do Arduino. Qual placa você recomenda?"

Agora o modelo sabe:

• quais recursos são necessários;

• como o projeto será alimentado;

• qual ambiente de programação será utilizado.

A recomendação tende a ser muito mais útil.

Contexto demais também pode atrapalhar

Adicionar informação não significa automaticamente melhorar o prompt.

Se o usuário acrescentar dados irrelevantes, o texto pode ficar confuso.

Por exemplo:

"Quero escolher uma placa para um projeto com Wi-Fi. Meu gabinete é preto, comprei a protoboard no ano passado, gosto de rock e estou usando uma mesa de madeira."

Essas informações não ajudam na decisão.

Portanto:

Bom contexto é contexto relevante, não contexto em excesso.

O contexto deve responder ao que realmente importa

Uma boa forma de selecionar contexto é perguntar:

Que informação mudaria a resposta?

Se uma informação pode alterar a análise, ela provavelmente é relevante.

Por exemplo, ao pedir ajuda com código, podem importar:

• linguagem;

• versão;

• framework;

• banco de dados;

• mensagem de erro;

• comportamento esperado.

Ao pedir ajuda com um texto, podem importar:

• público;

• finalidade;

• canal de publicação;

• tamanho desejado;

• nível técnico.

Dados concretos são melhores que descrições vagas

Compare:

"Meu código não funciona."

com:

"Ao executar este código PHP 8.3, recebo o erro Undefined variable $pdo na linha 42."

A segunda versão oferece um dado concreto.

Da mesma forma:

"Meu site está lento."

é menos útil do que:

"A página inicial leva cerca de 6 segundos para carregar no mobile e possui três imagens acima de 2 MB."

Quanto mais objetiva for a informação, melhor o modelo consegue trabalhar.

Contexto técnico evita respostas incompatíveis

Em programação, informar o ambiente pode evitar sugestões inadequadas.

Por exemplo:

"Estou usando PHP 8.3, MySQL e PDO."

Isso ajuda a evitar respostas baseadas em:

• funções obsoletas;

• bibliotecas incompatíveis;

• versões antigas da linguagem.

O mesmo vale para eletrônica:

"Estou usando Arduino Uno com alimentação de 5 V."

Essa informação pode ser essencial para recomendar componentes ou circuitos.

Contexto também pode limitar o escopo

Considere:

"Analise este contrato."

Agora:

"Analise apenas as cláusulas relacionadas a prazo, reajuste e penalidades. Não faça uma análise jurídica completa."

Além de orientar a tarefa, o contexto também ajuda a definir o que está fora do escopo.

Organize o contexto quando ele for grande

Em tarefas simples, uma frase pode bastar.

Mas em prompts maiores, vale organizar as informações.

Por exemplo:

CONTEXTO:
Aplicação PHP 8.3 com MySQL e PDO.

PROBLEMA:
O cadastro de usuários não grava os dados.

ERRO:
SQLSTATE[23000]: Integrity constraint violation

COMPORTAMENTO ESPERADO:
Salvar o usuário e retornar o ID criado.

Esse formato ajuda tanto o modelo quanto quem estiver revisando o prompt posteriormente.

Contexto pode vir de documentos

Nem sempre precisamos escrever todas as informações manualmente.

Podemos fornecer:

• arquivos;

• contratos;

• planilhas;

• códigos;

• relatórios;

• artigos;

• imagens;

• manuais.

Nesse caso, o próprio conteúdo fornecido passa a fazer parte do contexto disponível ao modelo.

Por exemplo:

"Com base exclusivamente no documento anexado, identifique os prazos de entrega e as penalidades por atraso."

Agora a fonte relevante está explicitamente definida.

Contexto pode vir de sistemas externos

Em aplicações mais avançadas, o contexto pode ser montado automaticamente.

Por exemplo:

Usuário pergunta

"Qual é o status do meu pedido?"

A aplicação pode buscar:

• número do pedido;

• data da compra;

• transportadora;

• localização atual;

• previsão de entrega.

Depois, essas informações são enviadas ao LLM.

Assim, o modelo recebe um contexto que o usuário não precisou digitar manualmente.

Esse tipo de arquitetura será importante quando estudarmos:

• APIs;

• RAG;

• ferramentas;

• agentes de IA.

Contexto e atualização de informações

Outro ponto importante é que o contexto pode trazer informações mais recentes do que aquelas aprendidas no treinamento.

Por exemplo, um modelo pode não conhecer uma mudança ocorrida depois do treinamento.

Mas, se a aplicação fornecer dados atualizados no contexto, ele poderá utilizá-los na resposta.

Podemos pensar assim:

Conhecimento aprendido no treinamento + Informação atual adicionada ao contexto = Resposta

Isso é uma das razões pelas quais contexto externo é tão importante em aplicações reais.

Contexto não garante verdade

Mesmo com bons dados, o modelo ainda pode interpretar alguma informação de forma incorreta.

Por isso:

fornecer contexto melhora as condições da tarefa, mas não elimina a necessidade de verificar respostas importantes.

Quanto contexto devo fornecer?

Não existe uma quantidade fixa.

Uma boa regra é:

forneça o mínimo necessário para que a tarefa fique clara e corretamente delimitada.

Se faltar informação essencial, o modelo precisará inferir.

Se houver informação demais, o prompt pode ficar desnecessariamente complexo.

Um exemplo completo

Prompt pouco contextualizado:

"Qual sensor devo usar?"

Prompt melhor:

"Estou desenvolvendo um projeto com Arduino Uno para medir temperatura ambiente entre 10 °C e 40 °C. Não preciso de alta precisão e quero utilizar um componente disponível no Tinkercad. Qual sensor seria adequado?"

Agora temos:

• placa utilizada;

• grandeza medida;

• faixa esperada;

• nível de precisão;

• ambiente de simulação.

A recomendação pode ser muito mais direcionada.

O ponto principal

Definir o objetivo responde:

O que quero que a IA faça?

Fornecer contexto responde:

O que ela precisa saber para fazer isso corretamente?

Podemos resumir:

OBJETIVO: tarefa

CONTEXTO: informações necessárias para executar a tarefa

Os dois trabalham juntos.

• Um objetivo claro sem contexto suficiente pode gerar uma resposta genérica.

• Muito contexto sem um objetivo claro pode gerar uma resposta dispersa.

• O melhor resultado tende a surgir quando ambos estão bem definidos.

No próximo bloco veremos outro elemento que pode influenciar bastante o comportamento da resposta:

Em alguns prompts, pode ser útil indicar qual papel, especialidade ou perspectiva o modelo deve adotar ao responder.

Por exemplo:

"Explique este conceito como um professor de eletrônica para iniciantes."

ou:

"Analise este texto sob a perspectiva de um revisor técnico."

Essa estratégia ajuda o modelo a ajustar aspectos como:

• vocabulário;

• profundidade;

• foco;

• critérios de análise;

• estilo da resposta.

Mas é importante usar esse recurso corretamente.

Definir um papel pode orientar a resposta, mas não transforma o modelo automaticamente em um especialista real.

O papel funciona como uma orientação

Considere:

"Explique o que é corrente elétrica."

A resposta pode ser genérica.

Agora:

"Explique o que é corrente elétrica como um professor de eletrônica ensinando um aluno iniciante."

A segunda versão acrescenta uma perspectiva.

O modelo tende a adaptar:

• linguagem;

• exemplos;

• nível técnico;

• forma de explicação.

O conteúdo continua sendo sobre corrente elétrica, mas o modo de apresentar a informação muda.

Papel e objetivo são coisas diferentes

Esse ponto é importante.

O objetivo responde:

O que a IA deve fazer?

O papel responde:

A partir de qual perspectiva ela deve executar essa tarefa?

Por exemplo:

Objetivo

Analise este código PHP.

Papel

Faça a análise como um revisor técnico preocupado com segurança.

Juntos:

"Analise este código PHP como um revisor técnico, com foco em possíveis vulnerabilidades de segurança."

O papel não substitui o objetivo.

Ele apenas ajuda a direcioná-lo.

Quando definir um papel realmente ajuda

A definição de papel costuma ser útil quando a tarefa depende de uma perspectiva específica.

Por exemplo:

Professor

"Explique PWM como um professor de eletrônica para iniciantes."

Revisor

"Revise este artigo como um editor técnico."

Analista

"Analise estes dados como um analista de desempenho."

Desenvolvedor

"Revise este código como um desenvolvedor PHP experiente, com foco em legibilidade e segurança."

Especialista em UX

"Analise esta página sob a perspectiva de usabilidade mobile."

Nesses casos, o papel ajuda a definir quais aspectos devem receber mais atenção.

Papel não substitui critérios claros

Considere:

"Aja como um especialista em PHP e melhore este código."

Ainda é um prompt bastante aberto.

Melhor seria:

"Analise este código PHP 8.3 sob a perspectiva de um desenvolvedor experiente. Identifique problemas de segurança, legibilidade e tratamento de erros. Não altere a arquitetura da aplicação."

Agora o papel foi acompanhado por critérios objetivos.

Isso é muito mais útil.

Quanto mais importante for a tarefa, menos devemos depender apenas do rótulo do papel e mais devemos definir critérios concretos.

"Aja como especialista" não cria conhecimento novo

Esse é um ponto que merece destaque.

Escrever:

"Aja como o maior especialista do mundo em eletrônica."

não adiciona conhecimento ao modelo.

Também não garante:

• respostas corretas;

• experiência prática;

• atualização das informações;

• ausência de alucinações.

O modelo continua limitado por:

• seu treinamento;

• o contexto disponível;

• suas ferramentas;

• sua capacidade de processamento.

Portanto:

o papel orienta o comportamento da resposta; ele não aumenta magicamente o conhecimento do modelo.

Evite papéis exagerados e desnecessários

Prompts como:

"Você é o maior gênio da programação da história, vencedor de todos os prêmios..."

geralmente adicionam pouco valor real.

Uma formulação mais objetiva costuma ser melhor:

"Analise o código como um desenvolvedor PHP experiente, com foco em segurança e compatibilidade com PHP 8.3."

A segunda versão informa ao modelo aquilo que realmente importa.

Perspectiva pode ser mais útil que profissão

Nem sempre precisamos atribuir uma profissão.

Às vezes, basta definir a perspectiva da análise.

Por exemplo:

"Analise este texto do ponto de vista de um leitor iniciante."

"Avalie esta página com foco em acessibilidade."

"Revise esta documentação pensando em quem nunca utilizou a ferramenta."

"Analise esta proposta considerando riscos técnicos e custos de manutenção."

Nesses casos, estamos direcionando o ângulo da resposta.

Isso frequentemente é mais útil do que simplesmente escrever:

"Você é um especialista."

Diferentes perspectivas podem gerar análises diferentes

Considere um mesmo sistema web.

Podemos pedir:

"Analise este sistema do ponto de vista de segurança."

A resposta poderá enfatizar:

• autenticação;

• permissões;

• SQL Injection;

• exposição de dados.

Agora:

"Analise este sistema do ponto de vista de experiência do usuário."

A análise poderá priorizar:

• navegação;

• clareza;

• feedback visual;

• facilidade de uso.

Ou:

"Analise este sistema pensando em manutenção futura."

O foco poderá mudar para:

• arquitetura;

• organização do código;

• dependências;

• documentação.

O objeto é o mesmo.

A perspectiva é que muda.

Podemos combinar perspectivas?

Sim, mas com cuidado.

Por exemplo:

"Analise este projeto considerando segurança, desempenho e facilidade de manutenção."

Isso pode funcionar bem.

Mas adicionar muitas perspectivas pode tornar a tarefa ampla demais.

Em vez de:

"Analise como programador, designer, especialista em segurança, SEO, marketing e acessibilidade."

pode ser melhor dividir a tarefa em etapas.

Papel também pode definir o estilo de comunicação

Imagine:

"Explique o que é um transistor."

Agora:

"Explique como um professor conversando com um estudante do ensino médio."

Isso pode influenciar:

• nível de formalidade;

• quantidade de termos técnicos;

• uso de analogias;

• ritmo da explicação.

Por isso, o papel pode ser especialmente útil em tarefas educacionais.

Um exemplo completo

Prompt simples:

"Explique interrupções no Arduino."

Com papel:

"Explique interrupções no Arduino como um professor de eletrônica para iniciantes."

Melhor estruturado:

"Explique interrupções no Arduino como um professor de eletrônica ensinando um aluno que já conhece digitalRead() e digitalWrite(), mas nunca utilizou interrupções. Comece pelo conceito, mostre uma situação prática e evite registradores neste momento."

Agora temos:

• papel;

• público;

• conhecimento prévio;

• objetivo;

• estrutura;

• restrição.

A definição do papel faz parte do prompt, mas trabalha em conjunto com os outros elementos.

Papel pode ser usado em tarefas criativas

Em produção de conteúdo, podemos orientar a perspectiva:

"Escreva como um jornalista de tecnologia."

"Explique como um instrutor de curso técnico."

"Revise como um editor de conteúdo para web."

Mas, novamente, é melhor complementar com características objetivas.

Por exemplo:

"Escreva em estilo jornalístico, com linguagem objetiva, parágrafos curtos e sem tom promocional."

Essa formulação descreve diretamente o comportamento desejado.

Quando não precisamos definir um papel

Nem toda solicitação precisa conter:

"Você é..."

Por exemplo:

"Converta 2500 milímetros para metros."

não precisa de nenhum papel.

Da mesma forma:

"Liste os meses do ano."

ou:

"Traduza esta frase para inglês."

Adicionar um papel não necessariamente melhora tarefas simples e objetivas.

Uma regra prática

Antes de incluir um papel, pergunte:

Essa perspectiva muda a forma como a tarefa deve ser executada?

Se sim, pode ser útil.

Se não, provavelmente é desnecessário.

O ponto principal

Definir o papel ou perspectiva da IA pode ajudar a orientar:

• foco;

• nível técnico;

• estilo;

• critérios;

• profundidade.

Mas o papel deve ser tratado como uma orientação de comportamento, e não como uma forma de conceder capacidades que o modelo não possui.

Podemos resumir:

OBJETIVO: O que fazer?

CONTEXTO: O que precisa saber?

PAPEL / PERSPECTIVA: Sob qual ponto de vista executar?

No próximo bloco veremos outro elemento que influencia diretamente a forma da resposta:

Uma mesma explicação pode ser excelente para uma pessoa e inadequada para outra.

Isso acontece porque leitores diferentes possuem:

• conhecimentos prévios diferentes;

• vocabulários diferentes;

• objetivos diferentes;

• níveis técnicos diferentes.

Por isso, informar para quem a resposta será produzida pode melhorar bastante a qualidade do resultado.

O mesmo assunto pode exigir explicações muito diferentes dependendo do público.

O público influencia a linguagem

Compare estas duas solicitações:

"Explique o que é corrente elétrica."

e:

"Explique o que é corrente elétrica para uma criança de 10 anos."

Na segunda versão, o modelo tende a usar:

• frases mais simples;

• menos termos técnicos;

• analogias;

• exemplos do cotidiano.

Agora imagine:

"Explique corrente elétrica para um técnico em eletrônica."

Nesse caso, a resposta pode utilizar termos como:

• fluxo de cargas;

• diferença de potencial;

• resistência;

• ampères;

• circuitos.

O tema é o mesmo.

O que muda é o nível de profundidade e linguagem.

Público e nível não são exatamente a mesma coisa

Esses dois elementos estão relacionados, mas não são idênticos.

Público

responde: Para quem estou produzindo esta resposta?

Nível

responde: Quanto essa pessoa já sabe sobre o assunto?

Por exemplo:

"Explique PWM para estudantes de Arduino."

Define o público. Mas ainda não sabemos o nível.

Podemos melhorar:

"Explique PWM para estudantes iniciantes em Arduino que já conhecem digitalWrite(), mas ainda não estudaram timers."

Agora temos:

• público;

• conhecimento prévio;

• limite técnico.

Informe o conhecimento prévio

Essa é uma das formas mais eficazes de ajustar a resposta.

Considere:

"Explique classes em PHP."

Agora:

"Explique classes em PHP para alguém que já conhece funções, arrays e variáveis, mas ainda não estudou orientação a objetos."

Essa informação ajuda o modelo a decidir:

• o que pode assumir como conhecido;

• o que precisa explicar;

• quais exemplos serão adequados.

Isso evita dois problemas comuns:

1. explicar conceitos básicos demais;

2. avançar rápido demais.

O mesmo conceito em níveis diferentes

Veja como um mesmo assunto pode ser explicado em diferentes níveis.

Para uma criança

"Um sensor de temperatura é como um termômetro eletrônico. Ele percebe se algo está quente ou frio e envia essa informação para um circuito."

Para um iniciante em eletrônica

"Um sensor de temperatura é um componente que transforma a temperatura medida em um sinal elétrico que pode ser lido por um circuito ou microcontrolador."

Para um estudante técnico

"Um sensor de temperatura converte uma variação térmica em uma grandeza elétrica mensurável, como tensão, resistência ou dado digital."

Para um profissional

"A escolha do sensor depende de fatores como faixa de operação, precisão, resolução, tempo de resposta, interface e condições ambientais."

Nenhuma dessas explicações é necessariamente melhor que as outras.

Elas são adequadas a públicos diferentes.

O nível de detalhe também deve ser definido

Mesmo para o mesmo público, podemos querer profundidades diferentes.

Por exemplo:

"Explique superficialmente o que é um transistor."

ou:

"Explique transistor em nível intermediário, incluindo regiões de operação e uso como chave."

ou:

"Explique transistor em nível técnico, incluindo polarização e curvas características."

Isso ajuda a controlar a quantidade de informação.

Evite classificações vagas quando puder

Termos como:

"iniciante"

"intermediário"

"avançado"

são úteis, mas podem ser subjetivos.

Quando possível, complemente com informações concretas.

Por exemplo:

"Explique para um iniciante que já conhece tensão, corrente e resistência, mas nunca estudou semicondutores."

Isso é mais preciso do que apenas:

"Explique para iniciante."

O público influencia os exemplos

Considere um artigo sobre banco de dados.

Para um estudante iniciante, um exemplo adequado pode ser:

tabela de alunos e notas.

Para um desenvolvedor web, pode ser:

usuários, pedidos e produtos.

Para um analista de dados, pode ser:

consultas e agregações.

Os exemplos funcionam melhor quando estão próximos da realidade do público.

O público influencia o vocabulário

Um bom prompt pode solicitar explicitamente:

"Evite termos técnicos sem explicação."

ou:

"Utilize terminologia técnica da área."

ou:

"Explique cada termo na primeira vez em que aparecer."

Essas instruções ajudam a adaptar a resposta.

O público influencia o formato

Também podemos combinar público e formato.

Por exemplo:

"Explique o conceito para uma criança de 12 anos utilizando três exemplos simples."

ou:

"Explique para um estudante técnico usando uma tabela comparativa."

ou:

"Prepare uma explicação executiva para gestores em até cinco tópicos."

Nesse caso, não estamos mudando apenas a linguagem, mas também a estrutura.

Público técnico não significa resposta difícil

Outro cuidado importante:

usar linguagem técnica não significa escrever de forma complicada.

Mesmo para especialistas, clareza continua sendo importante.

Compare:

"Utilize terminologia técnica adequada."

com:

"Escreva da forma mais complicada possível."

São coisas completamente diferentes.

Uma resposta profissional pode ser:

• precisa;

• técnica;

• objetiva;

• clara.

Definir o público ajuda em produção de conteúdo

Esse elemento é especialmente importante quando utilizamos IA para criar:

• artigos;

• cursos;

• apostilas;

• e-books;

• documentação;

• treinamentos;

• posts;

• apresentações.

Por exemplo:

"Escreva um artigo sobre ESP32."

é muito aberto.

Agora:

"Escreva uma introdução sobre ESP32 para estudantes e hobistas que já utilizaram Arduino Uno, mas nunca trabalharam com Wi-Fi ou Bluetooth."

O modelo recebe uma referência clara de onde começar.

Um exemplo completo

Prompt inicial:

"Explique APIs."

Melhor:

"Explique o que é uma API para um programador iniciante."

Mais preciso:

"Explique o que é uma API para um programador iniciante que conhece PHP e JavaScript, mas nunca integrou dois sistemas. Use um exemplo simples de uma aplicação consultando dados de outro serviço."

Agora sabemos:

• público;

• conhecimento prévio;

• tecnologias familiares;

• experiência;

• tipo de exemplo desejado.

Papel e público não são a mesma coisa

Também é importante não confundir os dois.

Considere:

"Explique como um professor de eletrônica para uma criança de 12 anos."

Aqui temos:

Papel

professor de eletrônica.

Público

criança de 12 anos.

O papel orienta a perspectiva de quem responde.

O público orienta para quem a resposta está sendo produzida.

Os dois podem trabalhar juntos.

Nem toda tarefa possui um público externo

Em alguns prompts, o resultado será utilizado pelo próprio usuário.

Por exemplo:

"Analise este log e identifique o erro."

Nesse caso, talvez não seja necessário especificar um público.

Mas ainda pode ser útil informar o nível técnico:

"Explique o problema considerando que conheço PHP, mas não tenho experiência com configuração de servidores."

Isso ajuda a adaptar a explicação.

Uma regra prática

Antes de criar uma resposta destinada a alguém, pergunte:

Quem vai consumir essa informação e o que essa pessoa já sabe?

Se essas duas respostas alterarem significativamente a maneira de explicar o assunto, vale incluí-las no prompt.

O ponto principal

Definir público e nível ajuda o modelo a decidir:

• por onde começar;

• quais termos utilizar;

• o que explicar;

• o que pode assumir como conhecido;

• quais exemplos escolher;

• qual profundidade adotar.

Podemos resumir:

PÚBLICO

Para quem?

NÍVEL

Quanto essa pessoa já sabe?

PROFUNDIDADE

Até onde devo avançar?

Esses três elementos trabalham juntos para tornar a resposta mais adequada.

No próximo bloco veremos outro aspecto fundamental:

Não basta dizer ao modelo o que queremos.

Em muitas tarefas, também é importante dizer como queremos receber a resposta.

Essa definição é o formato da saída.

Por exemplo, podemos pedir que o resultado seja apresentado como:

• texto corrido;

• lista;

• tabela;

• checklist;

• passo a passo;

• JSON;

• código;

• tópicos;

• resumo;

• estrutura com títulos e subtítulos.

Definir o formato ajuda a tornar a resposta mais previsível, organizada e adequada ao uso final.

O mesmo conteúdo pode ser apresentado de maneiras diferentes

Considere o prompt:

"Compare Arduino Uno e Mega 2560."

O modelo pode responder em vários formatos.

• Pode escrever um texto corrido.

• Pode criar uma lista.

• Pode fazer uma tabela.

• Pode resumir apenas as diferenças mais importantes.

Se o formato não for definido, o modelo escolherá uma estrutura por conta própria.

Agora veja:

"Compare Arduino Uno e Mega 2560 em uma tabela com as colunas: microcontrolador, memória Flash, SRAM, pinos digitais, entradas analógicas e aplicação recomendada."

A tarefa ficou muito mais específica.

Formato pode melhorar a leitura

Para conteúdos longos, definir estrutura pode tornar a resposta muito mais fácil de consumir.

Compare:

"Explique como funciona um transistor."

com:

"Explique como funciona um transistor usando os seguintes tópicos: definição, princípio de funcionamento, terminais, aplicações e exemplo prático."

Na segunda versão, o leitor sabe exatamente como a resposta será organizada.

Isso é especialmente útil em:

• artigos;

• apostilas;

• documentação;

• relatórios;

• guias;

• conteúdos educacionais.

Listas são úteis quando queremos objetividade

Por exemplo:

"Liste cinco vantagens do ESP32."

ou:

"Apresente os principais riscos em tópicos."

ou:

"Crie um checklist para revisar este código antes da publicação."

Listas funcionam bem quando queremos:

• itens independentes;

• leitura rápida;

• priorização;

• consulta posterior.

Tabelas ajudam em comparações

Quando o objetivo é comparar características, tabelas podem ser melhores que texto corrido.

Por exemplo:

"Compare ESP8266, ESP32 e Arduino Uno R4 WiFi em uma tabela."

Podemos ainda definir as colunas:

"Use as colunas: conectividade, Bluetooth, tensão lógica, entradas analógicas, desempenho e aplicação recomendada."

Isso reduz ambiguidades e facilita a comparação visual.

Passo a passo ajuda em procedimentos

Quando queremos executar uma tarefa, podemos pedir:

"Explique passo a passo como configurar uma conexão PDO com MySQL."

ou:

"Mostre o procedimento em etapas numeradas."

Esse formato é adequado para:

• instalação;

• configuração;

• montagem;

• depuração;

• processos;

• tutoriais.

Podemos definir uma estrutura de resposta

Em tarefas mais complexas, podemos dizer exatamente quais seções queremos.

Por exemplo:

Organize a resposta em:

  1. Problema encontrado
  2. Causa provável
  3. Correção
  4. Exemplo de código
  5. Observações

Isso é muito útil porque transforma a resposta em um padrão reutilizável.

O formato pode ser usado para automação

Em sistemas de software, o formato da saída pode ser ainda mais importante.

Imagine que um programa precise receber a resposta do modelo e processá-la automaticamente.

Nesse caso, podemos pedir:

Retorne apenas JSON no seguinte formato:

{
    "status": "",
    "categoria": "",
    "prioridade": "",
    "resumo": ""
}

Assim, a saída pode ser utilizada por outro sistema.

Formatos estruturados exigem instruções claras

Se o resultado será consumido por software, é importante evitar respostas adicionais desnecessárias.

Por exemplo:

"Retorne apenas o JSON. Não inclua explicações antes ou depois."

Isso reduz o risco de o modelo gerar:

Claro! Aqui está o JSON solicitado:

antes da estrutura esperada.

Definir formato não garante validade perfeita

Mesmo quando pedimos JSON, XML ou outra estrutura, o modelo ainda pode cometer erros.

Por exemplo:

• aspas ausentes;

• vírgulas incorretas;

• campos inesperados;

• texto adicional.

Por isso, aplicações reais devem validar a saída antes de utilizá-la.

Formato solicitado não substitui validação.

Podemos definir tamanho

O formato também pode incluir limites.

Por exemplo:

"Responda em até cinco tópicos."

"Escreva no máximo 300 palavras."

"Use três parágrafos."

"Crie um resumo de até 500 caracteres."

Isso ajuda a controlar a extensão.

Mas devemos evitar limites excessivamente rígidos quando não forem necessários.

Podemos definir tom e estilo

Embora tom e formato não sejam exatamente a mesma coisa, eles podem ser definidos juntos.

Por exemplo:

"Escreva em linguagem técnica e objetiva."

"Use um tom didático e acessível."

"Evite linguagem promocional."

"Escreva em estilo formal."

Essas orientações ajudam a adaptar a resposta ao uso final.

Formato pode incluir exemplos

Também podemos dizer:

"Explique o conceito e depois apresente um exemplo."

ou:

"Para cada item, mostre um exemplo prático."

ou:

"Após cada definição, adicione um pequeno exemplo."

Nesse caso, estamos definindo uma estrutura repetível.

Um exemplo completo

Prompt genérico:

"Analise este código."

Melhor:

"Analise este código PHP e organize a resposta em três partes: problema, impacto e correção."

Mais específico:

Analise este código PHP.

Para cada problema encontrado, apresente:

1. Problema
2. Motivo
3. Risco
4. Correção
5. Código corrigido

Não reescreva partes que já estejam corretas.

Agora o formato da saída está claramente definido.

Formato visual e formato técnico

Podemos pensar em dois tipos principais.

Formato visual

Serve para facilitar leitura humana.

Exemplos:

• tabela;

• lista;

• títulos;

• tópicos;

• passo a passo.

Formato técnico

Serve para integração com sistemas.

Exemplos:

• JSON;

• XML;

• CSV;

• estrutura de campos;

• código.

Essa distinção é importante porque o formato ideal depende de quem consumirá a resposta:

pessoa ou software.

Um formato pode facilitar a comparação

Imagine pedir:

"Compare três sensores de temperatura."

Se o modelo responder em texto corrido, talvez seja difícil comparar.

Agora:

"Compare os sensores em uma tabela com faixa de temperatura, precisão, interface e aplicação recomendada."

A estrutura facilita a decisão.

Não peça formato sem necessidade

Assim como os outros elementos do prompt, o formato deve ser utilizado quando acrescenta valor.

Para uma pergunta simples:

"Quanto é 10 × 5?"

não precisamos solicitar:

"Responda em tabela com quatro colunas."

O formato deve acompanhar a complexidade da tarefa.

O formato precisa ser compatível com o objetivo

Considere:

"Explique profundamente a arquitetura Transformer em duas frases."

Talvez seja possível gerar algo, mas existe uma incompatibilidade entre:

profundidade

e:

duas frases.

Da mesma forma:

"Compare dez produtos detalhadamente em três linhas."

O formato pode limitar demais a tarefa.

Portanto:

o formato deve ajudar o objetivo, não competir com ele.

Um modelo simples

Podemos perguntar:

QUEM VAI CONSUMIR A RESPOSTA?

Pessoa
→ texto, tabela, lista, passo a passo...

Software
→ JSON, XML, CSV, estrutura fixa...

QUAL É O OBJETIVO?

Explicar
→ texto estruturado

Comparar
→ tabela

Executar
→ passo a passo

Verificar
→ checklist

Integrar
→ formato estruturado

O ponto principal

Definir o formato da saída ajuda a responder:

Como eu quero receber o resultado?

Podemos resumir:

OBJETIVO

O que deve ser feito?

FORMATO

Como o resultado deve ser entregue?

Um bom formato pode tornar a resposta:

• mais clara;

• mais útil;

• mais fácil de verificar;

• mais fácil de reutilizar;

• mais simples de integrar a outros sistemas.

No próximo bloco veremos como estabelecer limites para aquilo que o modelo deve ou não fazer:

Além de dizer ao modelo o que fazer, também pode ser necessário definir limites e condições de qualidade.

Esses dois elementos são parecidos, mas não são exatamente a mesma coisa.

Restrições dizem o que o modelo não deve fazer ou quais limites precisa respeitar.

Critérios dizem quais condições o resultado deve cumprir para ser considerado adequado.

Essa diferença é importante.

O que são restrições?

Restrições delimitam o espaço da resposta.

Por exemplo:

"Não utilize jQuery."

"Não altere os nomes das funções."

"Não ultrapasse cinco parágrafos."

"Não use informações externas ao documento."

"Não entre em detalhes sobre registradores."

Essas instruções ajudam a impedir caminhos indesejados.

Restrições podem ser técnicas

Em programação:

"Use apenas JavaScript nativo."

"Mantenha compatibilidade com PHP 8.3."

"Não altere a estrutura do banco de dados."

"Não utilize bibliotecas externas."

Em eletrônica:

"Utilize apenas componentes disponíveis no Tinkercad."

"Considere alimentação de 5 V."

"Não utilize módulos externos."

Essas informações podem ser decisivas para a utilidade da resposta.

Restrições podem limitar escopo

Considere:

"Explique Inteligência Artificial."

Agora:

"Explique apenas IA Generativa e não entre ainda em agentes, RAG ou automações."

A restrição impede que o modelo amplie demais o assunto.

Restrições podem limitar tamanho

Por exemplo:

"Responda em até 200 palavras."

"Use no máximo cinco tópicos."

"Crie uma introdução de três parágrafos."

Esses limites são úteis quando existe uma necessidade editorial ou técnica.

Mas não devem ser usados apenas por estética.

Um limite muito pequeno pode prejudicar uma tarefa complexa.

O que são critérios?

Critérios definem características que o resultado deve apresentar.

Por exemplo:

"A resposta deve ser compreensível para iniciantes."

"O código deve permanecer compatível com PHP 8.3."

"A comparação deve considerar custo, desempenho e conectividade."

"A análise deve citar a cláusula correspondente."

Diferentemente da restrição, o critério não necessariamente proíbe algo.

Ele estabelece um requisito de qualidade ou adequação.

Restrição e critério podem trabalhar juntos

Considere:

OBJETIVO:
Corrigir este código PHP.

RESTRIÇÕES:
- Não alterar a arquitetura.
- Não renomear métodos.
- Não adicionar bibliotecas externas.

CRITÉRIOS:
- O código deve continuar compatível com PHP 8.3.
- A solução deve utilizar PDO.
- Cada alteração deve ser explicada.

Agora o modelo sabe:

• o que deve preservar;

• o que não pode fazer;

• quais condições a solução precisa atender.

Critérios tornam a resposta mais verificável

Considere:

"Melhore este artigo."

É difícil saber se a tarefa foi cumprida.

Agora:

"Revise este artigo considerando clareza, ausência de repetições, adequação ao público iniciante e coerência entre os tópicos."

Agora existem critérios que podem ser avaliados.

Critérios ajudam em comparações

Por exemplo:

"Qual placa é melhor?"

Essa pergunta é vaga porque "melhor" depende dos critérios.

Podemos definir:

"Compare ESP32 e Arduino Uno R4 WiFi considerando conectividade, desempenho, quantidade de GPIOs, facilidade para iniciantes e custo-benefício."

Agora a comparação possui parâmetros objetivos.

Critérios ajudam a reduzir subjetividade

Termos como:

• melhor;

• moderno;

• profissional;

• fácil;

• eficiente;

podem significar coisas diferentes.

Sempre que possível, vale transformar essas palavras em critérios concretos.

Em vez de:

"Faça um código melhor."

podemos pedir:

"Melhore o código reduzindo duplicação, aumentando legibilidade e preservando o comportamento atual."

Cuidado com instruções contraditórias

Quanto mais restrições adicionamos, maior o risco de criar conflitos.

Por exemplo:

"Explique detalhadamente em apenas duas frases."

ou:

"Não altere nada no código, mas reestruture completamente a aplicação."

Essas instruções são incompatíveis.

Por isso, revise o prompt procurando contradições.

Priorize quando houver muitos requisitos

Em tarefas complexas, pode ser útil indicar prioridades.

Por exemplo:

PRIORIDADE 1:
Preservar o comportamento atual.

PRIORIDADE 2:
Corrigir vulnerabilidades.

PRIORIDADE 3:
Melhorar legibilidade quando isso não afetar as prioridades anteriores.

Isso ajuda o modelo quando dois critérios entram em tensão.

Uma estrutura prática

Podemos pensar:

O QUE NÃO PODE ACONTECER?
→ Restrições

O QUE PRECISA SER ATENDIDO?
→ Critérios

Por exemplo:

RESTRIÇÕES:
- não alterar o banco de dados
- não adicionar dependências

CRITÉRIOS:
- eliminar o erro
- manter compatibilidade
- explicar a solução

O ponto principal

Restrições e critérios aumentam a precisão do prompt porque deixam claro:

• o que deve ser evitado;

• o que precisa ser preservado;

• quais condições devem ser atendidas;

• como o resultado será avaliado.

Podemos resumir:

RESTRIÇÃO

limite que precisa ser respeitado.

CRITÉRIO

condição que o resultado deve atender.

No entanto, há situações em que apenas descrever regras ainda não é suficiente.

Às vezes, a forma mais clara de mostrar ao modelo aquilo que esperamos é simplesmente apresentar um exempl

Em algumas tarefas, fornecer exemplos pode ser mais eficiente do que escrever várias linhas de explicação.

Isso acontece porque um exemplo mostra concretamente:

qual padrão esperamos que o modelo siga.

Por exemplo:

"Classifique cada mensagem como DÚVIDA, ELOGIO ou RECLAMAÇÃO."

A instrução já é compreensível.

Mas podemos torná-la ainda mais clara:

"Como altero minha senha?" → DÚVIDA
"Gostei muito do atendimento." → ELOGIO
"Meu produto chegou quebrado." → RECLAMAÇÃO

Depois apresentamos:

"Não consigo acessar minha conta."

Agora o modelo possui referências concretas do comportamento esperado.

Exemplos ajudam a mostrar o padrão

Considere uma tarefa de reescrita:

"Reescreva os títulos no mesmo estilo."

Mas qual estilo?

Podemos fornecer:

Original: "Como instalar o Arduino IDE"
Resultado esperado: "Arduino IDE: Como instalar e configurar passo a passo"

Agora existe um padrão observável.

Exemplos podem definir o formato

Considere:

"Retorne o resultado em JSON."

Podemos acrescentar

{
    "categoria": "erro",
    "prioridade": "alta",
    "resumo": "Falha na conexão com o banco de dados"
}

Esse exemplo mostra:

• nomes dos campos;

• estrutura;

• tipo de conteúdo esperado.

Exemplos podem definir o tom

Imagine:

"Escreva títulos profissionais e objetivos."

Ainda existe certa subjetividade.

Podemos fornecer:

"Como funciona PWM no Arduino: conceitos e aplicações práticas"

como exemplo de estilo desejado.

O modelo passa a ter uma referência concreta.

Bons exemplos precisam ser representativos

Um exemplo ruim pode orientar o modelo na direção errada.

Se queremos respostas curtas, mas fornecemos exemplos longos, criamos uma inconsistência.

Se queremos classificação objetiva, mas os exemplos são ambíguos, o modelo poderá reproduzir essa ambiguidade.

Portanto:

o exemplo também faz parte da instrução.

Não precisamos fornecer muitos exemplos

Em algumas tarefas, um único exemplo já ajuda.

Em outras, dois ou três podem mostrar melhor o padrão.

Adicionar dezenas de exemplos nem sempre traz benefícios proporcionais e pode aumentar muito o contexto.

A quantidade ideal depende da complexidade da tarefa.

Um exemplo completo

Considere:

"Transforme os dados abaixo em um resumo curto."

Podemos melhorar:

Transforme cada registro em uma frase curta.

Exemplo:

Entrada:
Produto: Arduino Uno
Status: indisponível
Previsão: 15/11

Saída:
Arduino Uno está indisponível, com previsão de reposição em 15/11.

Agora processe:
[novos dados]

O modelo recebe não apenas uma explicação, mas também um padrão.

Exemplos não precisam ser idênticos à tarefa real

Eles servem para demonstrar a estrutura.

Por exemplo, se queremos classificar chamados de suporte, podemos fornecer três exemplos diferentes dos dados reais.

O importante é que representem corretamente as categorias e regras esperadas.

Cuidado para não ensinar um padrão errado

Imagine que você queira respostas factuais com fontes verificáveis.

Se os exemplos apresentarem referências inventadas, o modelo pode reproduzir esse padrão.

Da mesma forma, exemplos de código com práticas ruins podem induzir resultados ruins.

Portanto:

exemplos devem representar o comportamento que realmente queremos reproduzir.

Exemplos e regras podem trabalhar juntos

Não precisamos escolher entre instrução e exemplo.

Podemos combinar:

REGRA:
Classifique cada mensagem como DÚVIDA, ELOGIO ou RECLAMAÇÃO.

EXEMPLOS:
"Como faço para trocar minha senha?" → DÚVIDA
"Excelente atendimento!" → ELOGIO
"O produto veio quebrado." → RECLAMAÇÃO

MENSAGEM:
"Não recebi meu pedido."

Isso reduz ainda mais a ambiguidade.

Exemplos podem mostrar também o que não queremos

Em alguns casos, podemos mostrar:

Exemplo adequado

e

Exemplo inadequado

Por exemplo:

ADEQUADO:
"O Arduino Uno possui 14 pinos digitais."

INADEQUADO:
"O incrível e revolucionário Arduino Uno possui fantásticos 14 pinos digitais!"

Agora fica claro que desejamos linguagem objetiva, sem exageros promocionais.

Exemplos e aprendizado dentro do contexto

É importante entender que, quando fornecemos exemplos em um prompt, normalmente não estamos treinando permanentemente os parâmetros do modelo.

Estamos oferecendo um padrão dentro do contexto atual para orientar a resposta.

Essa distinção conecta diretamente este tópico ao que aprendemos nos artigos anteriores:

usar exemplos no prompt não é o mesmo que treinar o LLM.

O modelo utiliza esses exemplos como parte das informações disponíveis naquele processamento.

Do exemplo às técnicas de prompting

A quantidade de exemplos fornecidos dá origem a alguns termos comuns em Prompt Engineering:

• Zero-shot — nenhum exemplo;

• One-shot — um exemplo;

• Few-shot — alguns exemplos.

Estudaremos essas estratégias em um tópico específico mais adiante.

Uma regra prática

Pergunte:

Seria mais fácil mostrar ao modelo um exemplo do resultado do que explicar tudo em palavras?

Se a resposta for sim, provavelmente vale incluir um exemplo.

Isso é especialmente útil em:

• classificação;

• transformação de dados;

• padronização;

• geração estruturada;

• estilos de escrita;

• extração de informações;

• automações.

O ponto principal

Exemplos ajudam a transformar uma instrução abstrata em um padrão concreto.

Podemos resumir:

INSTRUÇÃO

explica o que fazer.

EXEMPLO

mostra como deve ficar.

Quando os dois são utilizados corretamente, o modelo recebe uma referência muito mais clara sobre aquilo que esperamos.

Com isso, já conhecemos os principais componentes que podemos utilizar na construção de um prompt.

O próximo passo é entender como organizá-los de acordo com a complexidade da tarefa:

Nem toda tarefa exige um prompt longo ou dividido em várias partes.

Para solicitações simples, uma frase direta pode ser suficiente.

Por exemplo:

"Explique o que é um resistor."

Esse prompt já contém um objetivo claro.

Mas, conforme a tarefa fica mais complexa, pode ser útil organizar melhor as informações.

É nesse ponto que entram os prompts estruturados.

O que é um prompt simples?

Um prompt simples geralmente possui uma instrução direta e poucas informações adicionais.

Por exemplo:

"Resuma este texto em cinco tópicos."

ou:

"Traduza esta frase para inglês."

ou:

"Compare Arduino Uno e Mega 2560."

Essas tarefas são relativamente claras.

O modelo precisa fazer poucas inferências sobre o resultado esperado.

Quando um prompt simples é suficiente?

Prompts simples funcionam bem quando:

• a tarefa é objetiva;

• o contexto já está claro;

• não existem muitas restrições;

• o formato da resposta é simples;

• o risco de interpretação incorreta é baixo.

Por exemplo:

"Explique o que significa HTML."

Não há necessidade de criar uma estrutura extensa para isso.

O que é um prompt estruturado?

Um prompt estruturado organiza a solicitação em blocos ou seções.

Por exemplo:

CONTEXTO:
Estou criando um artigo para iniciantes em Arduino.

OBJETIVO:
Explicar o que é PWM.

PÚBLICO:
Leitores que já conhecem entradas e saídas digitais.

INSTRUÇÕES:
Comece pelo conceito e depois mostre uma aplicação prática.

RESTRIÇÕES:
Não explique registradores ou timers.

FORMATO:
Use pequenos parágrafos e finalize com três pontos principais.

O conteúdo poderia ser escrito em um único parágrafo.

Mas a estrutura deixa cada parte da tarefa mais evidente.

Estrutura não torna o prompt automaticamente melhor

Esse ponto é importante.

Considere:

OBJETIVO:
Calcule 10 × 5.

FORMATO:
Número inteiro.

RESTRIÇÕES:
Não utilize explicações adicionais.

PÚBLICO:
Adultos.

Tecnicamente funciona.

Mas seria muito mais simples escrever:

"Quanto é 10 × 5?"

Portanto:

Prompt estruturado não significa prompt superior. Significa apenas uma forma de organizar tarefas que precisam de mais informações.

A complexidade do prompt deve acompanhar a tarefa

Podemos pensar assim:

Tarefa simples

↓

Prompt simples

---

Tarefa intermediária

↓

Prompt com algumas informações adicionais

---

Tarefa complexa

↓

Prompt estruturado

Por exemplo:

Tarefa simples

"Explique o que é PHP."

Tarefa intermediária

"Explique o que é PHP para um iniciante em programação web e dê um exemplo simples."

Tarefa complexa

CONTEXTO:
O leitor conhece HTML e CSS, mas ainda não estudou programação de servidor.

OBJETIVO:
Introduzir PHP.

PÚBLICO:
Programadores iniciantes.

INSTRUÇÕES:
Explique o papel do PHP em uma aplicação web e mostre como ele se relaciona com HTML.

FORMATO:
Introdução curta + exemplo de código + explicação do código.

RESTRIÇÕES:
Não entre ainda em orientação a objetos ou frameworks.

O assunto é o mesmo.

A estrutura cresce porque a tarefa se torna mais específica.

Prompts estruturados ajudam em tarefas reutilizáveis

Imagine que uma empresa utilize IA para analisar chamados de suporte.

Em vez de criar uma instrução diferente toda vez, pode utilizar um padrão:

TAREFA:
Classifique o chamado.

CATEGORIAS:
- DÚVIDA
- PROBLEMA TÉCNICO
- FINANCEIRO
- CANCELAMENTO

FORMATO DA SAÍDA:
Categoria:
Prioridade:
Resumo:

CHAMADO:
[texto do cliente]

Esse prompt pode ser reutilizado inúmeras vezes.

Apenas o conteúdo de:

CHAMADO

é alterado.

Isso torna o processo mais consistente.

Prompts estruturados facilitam manutenção

Em aplicações reais, prompts podem crescer bastante.

Imagine um prompt com:

• regras;

• exemplos;

• documentos;

• formato de saída;

• restrições;

• critérios.

Se tudo estiver escrito em um único parágrafo, qualquer alteração se torna mais difícil.

Separar em blocos facilita:

• leitura;

• manutenção;

• testes;

• versionamento;

• identificação de problemas.

Isso é especialmente importante quando prompts fazem parte de software.

Use títulos claros

Os títulos não precisam seguir um padrão específico.

Podemos utilizar:

OBJETIVO:

CONTEXTO:

REGRAS:

DADOS:

FORMATO DE SAÍDA:

O importante é que a organização seja consistente e compreensível.

Delimitadores também ajudam

Quando inserimos textos grandes, códigos ou documentos, podemos utilizar delimitadores para separar claramente cada parte.

Por exemplo

Analise o código abaixo.

--- CÓDIGO ---

<?php
...
?>

--- FIM DO CÓDIGO ---

Identifique erros que possam impedir sua execução.

Ou

DOCUMENTO:
"""
conteúdo do documento
"""

A função do delimitador é deixar claro:

onde começam e terminam os dados que devem ser analisados.

Separar instruções de dados é uma boa prática

Considere:

Resuma o texto abaixo em cinco tópicos.

TEXTO:
[conteúdo]

Isso é melhor organizado do que misturar instruções e conteúdo sem qualquer separação.

Em prompts maiores, podemos pensar:

INSTRUÇÕES

↓

DADOS

↓

RESULTADO ESPERADO

Essa separação será particularmente importante em aplicações com documentos e dados externos.

Um exemplo: evolução do mesmo prompt

Considere a tarefa:

revisar um código PHP.

Prompt simples

"Revise este código PHP."

Prompt enriquecido

"Revise este código PHP 8.3 procurando erros de segurança e problemas de legibilidade."

Prompt estruturado

CONTEXTO:
Aplicação PHP 8.3 utilizando PDO e MySQL.

OBJETIVO:
Revisar o código abaixo.

VERIFIQUE:
- vulnerabilidades de segurança
- tratamento de erros
- duplicação de código
- legibilidade

RESTRIÇÕES:
- não alterar a arquitetura
- não renomear métodos
- não adicionar bibliotecas

FORMATO:
Para cada problema, informe:
1. trecho
2. problema
3. risco
4. correção

CÓDIGO:
[cole aqui]

Perceba que o prompt estruturado não contém necessariamente ideias diferentes.

Ele apenas organiza melhor as informações.

Prompts estruturados podem virar templates

Quando uma estrutura funciona bem para uma tarefa recorrente, podemos transformá-la em um template.

Por exemplo:

CONTEXTO:
[descreva a situação]

OBJETIVO:
[descreva o resultado desejado]

DADOS:
[adicione as informações]

RESTRIÇÕES:
[defina os limites]

FORMATO:
[defina a saída]

Depois basta preencher os campos.

Essa abordagem pode ser útil para:

• produção de conteúdo;

• revisão de código;

• atendimento;

• relatórios;

• análise de documentos;

• automações.

Não transforme templates em formulários rígidos

Embora templates sejam úteis, não devemos transformar todo prompt em uma burocracia.

Se determinada informação não é necessária, simplesmente não a inclua.

Por exemplo, em uma tarefa que não possui um público específico, não há razão para criar:

PÚBLICO:
N/A

O template deve servir à tarefa, e não o contrário.

Conversas permitem construir o prompt aos poucos

Em uma interface de chat, também não precisamos necessariamente colocar tudo em uma única mensagem.

Podemos começar:

"Quero criar um artigo sobre Arduino."

Depois informar:

"O público será iniciante."

Depois:

"Quero uma abordagem prática."

Depois:

"Agora escreva apenas a introdução."

Essas mensagens anteriores passam a integrar o contexto disponível na conversa.

Isso significa que um prompt complexo pode ser construído interativamente.

Em APIs, a organização se torna ainda mais importante

Em aplicações programáticas, não existe necessariamente um usuário ajustando a solicitação durante a conversa.

O software precisa fornecer instruções de maneira consistente.

Por isso, prompts estruturados são especialmente úteis em:

• APIs;

• automações;

• pipelines;

• agentes;

• sistemas empresariais.

Nesses casos, estrutura e previsibilidade deixam de ser apenas questões de organização e passam a fazer parte da própria arquitetura da aplicação.

Uma regra prática

Antes de estruturar um prompt, pergunte:

Essa estrutura torna a tarefa mais clara ou apenas torna o prompt maior?

Se ajuda a separar:

• objetivo;

• contexto;

• dados;

• regras;

• formato;

provavelmente vale a pena.

Se não acrescenta clareza, um prompt simples pode ser melhor.

O ponto principal

Prompts simples e estruturados não são categorias concorrentes.

São diferentes níveis de organização.

Podemos resumir:

PROMPT SIMPLES

adequado para tarefas claras e diretas.

PROMPT ESTRUTURADO

adequado para tarefas com vários requisitos, dados, restrições ou formatos.

A regra mais importante continua sendo:

use apenas a complexidade necessária para deixar a tarefa clara.

Agora que sabemos como organizar prompts, podemos avançar para uma técnica muito utilizada quando queremos ensinar um padrão ao modelo por meio de exemplos:

Quando fornecemos exemplos dentro de um prompt, estamos ajudando o modelo a identificar o padrão esperado para a tarefa.

A quantidade de exemplos fornecidos dá origem a três estratégias muito conhecidas em Prompt Engineering:

• Zero-shot — nenhum exemplo;

• One-shot — um exemplo;

• Few-shot — alguns exemplos.

Essas técnicas não alteram permanentemente os parâmetros do modelo.

Elas funcionam dentro do contexto atual, usando exemplos para orientar a resposta.

Zero-shot

No Zero-shot, fornecemos apenas a instrução, sem nenhum exemplo.

Por exemplo:

Classifique a mensagem abaixo como DÚVIDA, ELOGIO ou RECLAMAÇÃO.

Mensagem: "Meu pedido ainda não chegou."

O modelo precisa compreender a tarefa apenas pela instrução.

A resposta esperada poderia ser:

RECLAMAÇÃO

Podemos representar:

Instrução

↓

Nova entrada

↓

Resposta

Quando Zero-shot funciona bem?

Ele costuma funcionar bem quando:

• a tarefa é simples;

• as categorias são claras;

• o modelo já conhece o tipo de tarefa;

• não existe um formato muito específico.

Por exemplo:

Traduza esta frase para inglês.

ou:

Resuma este texto em três tópicos.

ou:

Classifique o sentimento como positivo, negativo ou neutro.

Nesses casos, exemplos podem ser desnecessários.

One-shot

No One-shot, fornecemos um exemplo antes da nova entrada.

Por exemplo:

Classifique cada mensagem como DÚVIDA, ELOGIO ou RECLAMAÇÃO.

Exemplo:

"Como faço para alterar minha senha?" → DÚVIDA

Agora classifique:

"Meu pedido ainda não chegou."

O modelo recebe uma demonstração do formato esperado.

Podemos representar:

Instrução

↓

1 exemplo

↓

Nova entrada

↓

Resposta

O que o exemplo acrescenta?

O exemplo pode mostrar:

• formato da resposta;

• tipo de classificação;

• nível de detalhe;

• estilo;

• padrão esperado.

Isso reduz a necessidade de o modelo inferir essas características sozinho.

Few-shot

No Few-shot, fornecemos alguns exemplos.

Por exemplo:

Classifique cada mensagem como DÚVIDA, ELOGIO ou RECLAMAÇÃO.

Exemplos:

"Como faço para alterar minha senha?" → DÚVIDA

"O atendimento foi excelente." → ELOGIO

"Meu produto chegou quebrado." → RECLAMAÇÃO

Agora classifique:

"Meu pedido ainda não chegou."

Aqui, o modelo já observou exemplos das três categorias.

Podemos representar:

Instrução

↓

Exemplo 1

↓

Exemplo 2

↓

Exemplo 3

↓

Nova entrada

↓

Resposta

Comparando as três estratégias

Podemos resumir:

Ou:

Zero-shot

"Faça isto."

One-shot

"Faça isto. Aqui está um exemplo."

Few-shot

"Faça isto. Aqui estão alguns exemplos."

Few-shot não significa treinamento

Esse ponto é muito importante.

Quando fornecemos exemplos no prompt, normalmente não estamos treinando permanentemente o modelo.

Os exemplos entram no contexto e são utilizados apenas para orientar aquela execução.

Portanto:

Few-shot prompting

exemplos fornecidos no contexto.

Treinamento / fine-tuning

ajuste dos parâmetros internos do modelo.

São processos diferentes.

Exemplos podem ensinar padrões de saída

Few-shot é particularmente útil quando queremos padronizar respostas.

Por exemplo:

Entrada:
Produto indisponível

Saída:
STATUS: indisponível
AÇÃO: informar previsão de reposição

Segundo exemplo:

Entrada:
Pagamento recusado

Saída:
STATUS: pagamento recusado
AÇÃO: solicitar outro método de pagamento

Depois:

Entrada:
Pedido enviado

O modelo pode inferir que queremos uma resposta semelhante

STATUS: pedido enviado
AÇÃO: informar código de rastreamento

Os exemplos mostram o padrão melhor do que uma descrição longa poderia fazer.

Few-shot também pode ajudar na escrita

Imagine que você queira títulos seguindo um estilo específico.

Podemos fornecer:

"Arduino Uno: Guia Completo para Iniciantes"

"ESP32: Recursos, Aplicações e Primeiros Passos"

"Sensores no Arduino: Como Funcionam e Como Utilizá-los"

Depois pedir:

Crie um título nesse mesmo estilo para um artigo sobre PWM.

Os exemplos ajudam o modelo a identificar:

• tamanho aproximado;

• estrutura;

• tom;

• uso de dois blocos no título.

Exemplos ruins geram padrões ruins

Se fornecermos exemplos inconsistentes, o modelo poderá reproduzir essa inconsistência.

Imagine:

"Atendimento excelente!" → ELOGIO

"Produto quebrado." → DÚVIDA

O segundo exemplo está incorreto.

Esse erro passa a fazer parte do contexto utilizado pelo modelo.

Por isso:

a qualidade dos exemplos é tão importante quanto a qualidade das instruções.

Quantos exemplos devo fornecer?

Não existe um número universal.

Depende da tarefa.

Um exemplo pode ser suficiente quando:

• o padrão é simples;

• queremos apenas mostrar o formato.

Alguns exemplos podem ser melhores quando:

• existem várias categorias;

• há exceções;

• o estilo precisa ficar mais claro;

• a tarefa é ambígua.

Mas adicionar muitos exemplos aumenta o tamanho do contexto e nem sempre melhora proporcionalmente o resultado.

Escolha exemplos representativos

Se a tarefa possui três categorias, é útil mostrar exemplos das três.

Se possui casos comuns e exceções, talvez valha mostrar ambos.

Por exemplo:

NORMAL:
"Gostaria de saber o prazo de entrega." → DÚVIDA

CASO ESPECIAL:
"Quero cancelar porque meu pedido atrasou." → CANCELAMENTO

Isso ajuda o modelo a perceber que alguns casos exigem tratamento diferente.

Zero-shot pode ser melhor do que Few-shot

Mais exemplos não significam automaticamente melhor resultado.

Se a tarefa já estiver muito clara, adicionar exemplos pode apenas:

• aumentar o prompt;

• consumir mais contexto;

• introduzir padrões desnecessários.

Por exemplo:

"Traduza 'Good morning' para português."

não precisa de três exemplos de tradução antes.

Portanto:

Use exemplos quando eles realmente reduzirem ambiguidades ou demonstrarem um padrão importante.

Um mesmo problema nas três abordagens

Vamos comparar diretamente.

Zero-shot

Classifique a mensagem como DÚVIDA, ELOGIO ou RECLAMAÇÃO:

"Não consigo acessar minha conta."

One-shot

Classifique a mensagem como DÚVIDA, ELOGIO ou RECLAMAÇÃO.

Exemplo:

"Como altero minha senha?" → DÚVIDA

Agora:

"Não consigo acessar minha conta."

Few-shot

Classifique a mensagem como DÚVIDA, ELOGIO ou RECLAMAÇÃO.

Exemplos:

"Como altero minha senha?" → DÚVIDA

"Excelente atendimento." → ELOGIO

"Meu produto chegou quebrado." → RECLAMAÇÃO

Agora:

"Não consigo acessar minha conta."

A tarefa é a mesma.

O que muda é a quantidade de referências fornecidas ao modelo.

O ponto principal

Podemos resumir:

Zero-shot → instrução sem exemplo.

One-shot → instrução com um exemplo.

Few-shot → instrução com alguns exemplos.

Essas estratégias são úteis porque permitem orientar o comportamento do modelo sem modificar seus parâmetros.

Os exemplos são adicionados ao contexto e utilizados como referência para a tarefa atual.

No próximo bloco, avançaremos para outra estratégia importante para tarefas mais complexas:

Nem toda tarefa deve ser resolvida de uma só vez.

Quando um pedido envolve várias decisões, análises ou entregas diferentes, dividir o trabalho em etapas pode melhorar a clareza e facilitar a avaliação de cada resultado.

Em vez de pedir:

"Analise este sistema, identifique problemas, proponha melhorias, reescreva o código e crie a documentação."

podemos dividir:

1. analisar o sistema;

2. identificar os principais problemas;

3. priorizar as correções;

4. propor soluções;

5. implementar as alterações;

6. revisar o resultado.

Essa abordagem reduz a complexidade de cada passo.

Por que dividir a tarefa?

Quando colocamos muitas exigências em um único prompt, o modelo precisa lidar simultaneamente com:

• vários objetivos;

• diferentes critérios;

• dependências entre etapas;

• grande quantidade de contexto;

• múltiplos formatos de saída.

Isso pode aumentar a chance de:

• alguma instrução ser ignorada;

• etapas serem executadas fora de ordem;

• detalhes importantes serem omitidos;

• a resposta ficar superficial.

Dividir a tarefa ajuda a manter o foco.

Uma estrutura útil: analisar → planejar → executar → revisar

Para tarefas complexas, uma sequência bastante prática é:

ANALISAR

↓

PLANEJAR

↓

EXECUTAR

↓

REVISAR

Por exemplo:

Etapa 1 — Analisar

"Analise este código PHP e liste os problemas encontrados. Não faça alterações ainda."

Etapa 2 — Planejar

"Com base nos problemas identificados, proponha uma ordem de correção e explique as prioridades."

Etapa 3 — Executar

"Agora aplique apenas as correções de prioridade alta, preservando a arquitetura atual."

Etapa 4 — Revisar

"Revise o código alterado e verifique se as correções introduziram algum efeito colateral."

Cada etapa possui um objetivo claro.

Separar análise de execução pode ser muito útil

Em muitos casos, vale impedir que o modelo altere algo antes de compreender o problema.

Por exemplo:

"Primeiro identifique os problemas. Não reescreva o texto ainda."

Isso permite verificar se o diagnóstico está correto antes de avançar.

Depois:

"Agora reescreva apenas os trechos que precisam de correção."

Essa abordagem é especialmente útil em:

• código;

• contratos;

• documentos;

• relatórios;

• textos longos;

• planejamento de projetos.

Dividir também ajuda o usuário a controlar o processo

Se pedirmos tudo de uma vez, recebemos um resultado completo, mas com pouca oportunidade de intervenção no meio do caminho.

Quando trabalhamos por etapas, podemos:

• corrigir uma interpretação;

• mudar uma prioridade;

• fornecer novos dados;

• alterar o escopo;

• aprovar uma etapa antes de seguir.

Isso transforma a interação em um processo mais controlado.

Tarefas dependentes devem respeitar a ordem

Algumas atividades só fazem sentido depois que outras forem concluídas.

Por exemplo:

não faz sentido escrever uma solução antes de entender corretamente o problema.

Da mesma forma:

não faz sentido resumir conclusões antes de analisar os dados.

Por isso, em tarefas dependentes, vale explicitar a sequência.

Exemplo:

ETAPA 1:
Leia o documento e identifique os principais riscos.

ETAPA 2:
Agrupe os riscos por categoria.

ETAPA 3:
Classifique cada risco por impacto e probabilidade.

ETAPA 4:
Sugira ações para os riscos mais críticos.

Podemos pedir uma etapa de cada vez

Em uma conversa, não precisamos enviar todas as etapas no mesmo prompt.

Podemos dizer:

"Primeiro, faça apenas a análise."

Depois:

"Agora vamos para a priorização."

Depois:

"Agora proponha as soluções."

Essa abordagem é útil quando queremos revisar cada parte antes de continuar.

Ou podemos definir todas as etapas no mesmo prompt

Também é possível:

Execute a tarefa em quatro etapas:

1. Analise os dados.
2. Identifique os três principais problemas.
3. Sugira soluções.
4. Finalize com uma recomendação.

Separe claramente cada etapa na resposta.

Isso funciona quando:

• a sequência é simples;

• não precisamos aprovar cada etapa;

• o resultado pode ser produzido de uma só vez.

Quando dividir em mensagens e quando dividir dentro do prompt?

Uma regra prática:

Divida em mensagens diferentes quando:

• uma etapa depende da aprovação da anterior;

• você quer revisar o resultado antes de continuar;

• o problema é complexo;

• novos dados podem surgir.

Divida dentro do mesmo prompt quando:

• as etapas são simples;

• a sequência já está clara;

• não há necessidade de intervenção intermediária.

Dividir tarefas não significa pedir raciocínio interno

Existe aqui uma distinção importante.

Podemos pedir que o modelo organize a tarefa em etapas observáveis, como:

"Primeiro identifique os erros, depois proponha correções."

Isso é diferente de pedir acesso ao funcionamento interno ou ao raciocínio privado do modelo.

O que queremos é uma estrutura de trabalho verificável, não uma exposição do processo interno completo.

Um exemplo com produção de conteúdo

Imagine:

"Crie um artigo completo sobre segurança digital."

Podemos dividir:

Etapa 1

Defina público, objetivo e estrutura.

Etapa 2

Crie o índice.

Etapa 3

Desenvolva a introdução.

Etapa 4

Desenvolva cada tópico separadamente.

Etapa 5

Revise coerência, repetição e SEO.

Isso costuma produzir um trabalho mais controlado do que gerar tudo de uma vez.

Um exemplo com programação

Pedido muito amplo:

"Corrija e melhore meu sistema PHP."

Melhor:

Etapa 1

Identifique erros que possam impedir a execução.

Etapa 2

Analise problemas de segurança.

Etapa 3

Verifique duplicações e problemas de organização.

Etapa 4

Proponha melhorias.

Etapa 5

Implemente apenas as alterações aprovadas.

Cada tipo de problema é tratado separadamente.

Um exemplo com tomada de decisão

Imagine:

"Qual dessas três ferramentas devo escolher?"

Podemos dividir:

1. definir os critérios;

2. comparar as opções;

3. identificar vantagens e desvantagens;

4. considerar restrições;

5. recomendar.

Por exemplo

Primeiro defina os critérios relevantes para a escolha.

Depois compare as três opções segundo esses critérios.

Por fim, apresente uma recomendação e explique em quais situações outra opção seria melhor.

Isso produz uma análise mais estruturada.

Dividir demais também pode ser desnecessário

Assim como prompts estruturados, etapas demais podem criar burocracia.

Não precisamos transformar:

"Traduza esta frase."

em:

1. identificar idioma;

2. analisar sintaxe;

3. traduzir;

4. revisar tradução;

5. apresentar resultado.

Para uma tarefa simples, isso seria exagero.

Portanto:

divida a tarefa apenas quando a decomposição realmente melhorar clareza, controle ou qualidade.

Uma regra prática

Pergunte:

Esta tarefa possui várias decisões ou entregas que podem ser verificadas separadamente?

Se sim, provavelmente vale dividir.

Também podemos perguntar:

Um erro na primeira parte comprometeria todo o restante?

Se sim, é ainda mais útil validar a primeira etapa antes de continuar.

O ponto principal

Dividir tarefas complexas em etapas ajuda a:

• reduzir ambiguidades;

• organizar prioridades;

• controlar o processo;

• verificar resultados intermediários;

• corrigir problemas antes que se propaguem.

Podemos resumir:

Tarefa simples

execute diretamente.

Tarefa complexa

decomponha em partes menores.

Uma estrutura bastante útil é:

ANALISAR → PLANEJAR → EXECUTAR → REVISAR

Mas mesmo depois de receber uma resposta, o trabalho nem sempre termina.

Uma das grandes vantagens de uma interface conversacional é justamente poder continuar a interação e melhorar o resultado progressivamente.

Uma das vantagens mais importantes de uma interface conversacional é que o primeiro prompt não precisa resolver tudo.

Podemos utilizar a própria conversa para ajustar progressivamente o resultado.

Em vez de tentar escrever um prompt perfeito logo na primeira mensagem, podemos trabalhar de forma iterativa:

Solicitação inicial

↓

Resposta

↓

Avaliação

↓

Ajuste

↓

Nova resposta

Esse processo é chamado, de forma prática, de refinamento iterativo.

A primeira resposta pode ser apenas um ponto de partida

Considere:

"Explique o que é PWM para um iniciante."

A resposta pode estar correta, mas talvez:

• esteja longa demais;

• esteja técnica demais;

• não tenha exemplos;

• não esteja adequada ao público.

Nesse caso, não precisamos começar do zero.

Podemos simplesmente continuar:

"Agora deixe a explicação mais simples."

ou:

"Inclua um exemplo com controle de brilho de LED."

ou:

"Resuma em três parágrafos."

O modelo utiliza a conversa anterior como parte do contexto.

Podemos refinar conteúdo, formato e profundidade

Alguns tipos comuns de refinamento são:

Aprofundar

"Explique com mais detalhes a parte sobre frequência."

Simplificar

"Reescreva para alguém que nunca estudou eletrônica."

Resumir

"Reduza para cinco tópicos."

Mudar formato

"Transforme a explicação em uma tabela."

Adicionar exemplo

"Agora inclua um exemplo prático com Arduino."

Corrigir foco

"Não fale sobre timers ainda. Mantenha o foco apenas no conceito de PWM."

Refinar é diferente de repetir o prompt

Se a resposta ficou quase adequada, normalmente é melhor corrigir apenas aquilo que precisa mudar.

Por exemplo:

"Gostei da estrutura, mas o segundo tópico ficou técnico demais. Reescreva apenas essa parte para iniciantes."

Esse tipo de refinamento preserva o que já funcionou.

Podemos estabelecer critérios progressivamente

Às vezes percebemos uma necessidade somente depois de ver a primeira resposta.

Exemplo:

"Compare ESP32 e Arduino Uno R4 WiFi."

Depois:

"Agora acrescente consumo de energia."

Depois:

"Inclua custo-benefício."

Depois:

"Reorganize a tabela colocando conectividade primeiro."

A resposta vai sendo construída em etapas.

A conversa também serve para corrigir interpretações

Se o modelo entendeu errado:

"Não era isso. Estou falando de PWM aplicado ao controle de brilho de LED, não ao controle de motores."

Essa correção adiciona nova informação ao contexto.

O próximo resultado tende a ficar mais alinhado.

Refinamento funciona melhor com instruções específicas

Compare:

"Melhore."

com:

"Mantenha o conteúdo, mas reduza repetições e deixe os exemplos mais objetivos."

A segunda instrução informa claramente o que deve mudar.

Use o histórico a seu favor

Quando o assunto já está bem definido na conversa, não precisamos repetir tudo.

Por exemplo:

"Agora transforme o exemplo anterior em PHP."

ou:

"Mantenha a mesma estrutura, mas adapte para ESP32."

O contexto anterior ajuda a interpretar essas referências.

Mas cuidado com conversas muito longas

Conforme a conversa cresce, aumenta também a quantidade de contexto que pode precisar ser administrada.

Além disso, instruções antigas podem entrar em conflito com instruções novas.

Por isso, em trabalhos muito longos, pode ser útil reafirmar periodicamente:

• objetivo atual;

• restrições principais;

• formato desejado.

Por exemplo:

"Para esta próxima etapa, mantenha apenas estas regras: linguagem para iniciantes, exemplos com Arduino Uno e sem registradores."

Isso ajuda a recentrar a tarefa.

Refinar não significa aceitar tudo

Outro ponto importante:

refinar uma resposta não significa apenas pedir mudanças estéticas.

Também devemos avaliar se ela está:

• correta;

• completa;

• coerente;

• atualizada;

• adequada ao objetivo.

Podemos perguntar:

"Revise sua resposta procurando possíveis erros técnicos."

ou:

"Indique quais afirmações precisam ser verificadas em fonte oficial."

Isso torna o processo mais crítico.

O ponto principal

Uma boa interação com IA é frequentemente iterativa.

Podemos pensar:

PERGUNTAR

↓

AVALIAR

↓

CORRIGIR

↓

APROFUNDAR

↓

FORMATAR

↓

REVISAR

Nem todo resultado precisa sair perfeito na primeira tentativa.

Em muitas tarefas, a melhor estratégia é construir a resposta progressivamente.

Depois de aprender sobre objetivo, contexto, público, formato, restrições e exemplos, pode surgir uma conclusão aparentemente lógica:

"Então quanto maior o prompt, melhor será a resposta."

Mas isso não é necessariamente verdade.

Um prompt longo pode ser excelente quando contém informações relevantes.

Também pode ser ruim quando contém:

• repetições;

• regras desnecessárias;

• informações irrelevantes;

• instruções contraditórias;

• detalhes que não influenciam a tarefa.

Qualidade do prompt não é medida pelo número de palavras.

Mais informação não significa mais clareza

Considere:

"Explique o que é um resistor para um iniciante."

Essa solicitação já é suficiente para muitas situações.

Não há necessidade de acrescentar várias páginas de regras se elas não alterarem o resultado desejado.

Prompts longos podem esconder a instrução principal

Imagine um prompt com muitos parágrafos antes da tarefa principal.

Se o objetivo estiver perdido no meio de dezenas de informações, a solicitação fica menos clara.

Por isso, em prompts grandes, vale destacar:

OBJETIVO PRINCIPAL:
[...]

CONTEXTO:
[...]

RESTRIÇÕES:
[...]

FORMATO:
[...]

A organização passa a ser tão importante quanto o conteúdo.

Repetição não necessariamente reforça a instrução

Escrever:

"Não altere o código."

e depois:

"Lembre-se de não alterar o código."

e depois:

"É muito importante não modificar o código."

pode apenas aumentar o prompt sem acrescentar informação.

Uma instrução objetiva costuma ser suficiente:

"Não altere o código; apenas identifique os problemas."

Informações irrelevantes consomem contexto

Se uma informação não ajuda a resolver a tarefa, talvez não deva estar no prompt.

Por exemplo:

"Tenho 42 anos, gosto de rock e trabalho de manhã. Explique a diferença entre GET e POST."

Esses dados não alteram a explicação técnica.

Portanto, apenas aumentam o contexto sem benefício real.

Prompts muito longos podem conter conflitos

Quanto mais regras adicionamos, maior a chance de criar contradições.

Por exemplo:

"Seja extremamente detalhado."

e depois:

"Responda em duas linhas."

Ou:

"Não altere nenhuma palavra."

e depois:

"Reescreva completamente o texto."

Esses conflitos reduzem a previsibilidade.

Contexto excessivo também pode diluir o foco

Se fornecermos muitos documentos, mensagens e instruções irrelevantes, o modelo precisa lidar com um volume maior de informação.

O problema não é apenas tamanho.

É relevância.

Por isso:

bom contexto é contexto suficiente e relevante.

Um prompt curto pode ser excelente

Por exemplo:

"Compare ESP32 e Arduino Uno R4 WiFi em uma tabela com conectividade, desempenho, GPIOs, tensão lógica e aplicação recomendada."

Esse prompt é relativamente curto, mas contém:

• objetivo;

• objetos da comparação;

• formato;

• critérios.

Não há necessidade de torná-lo muito maior.

Um prompt longo pode ser necessário

Por outro lado, uma tarefa como:

analisar um contrato extenso;

revisar um sistema;

gerar dados estruturados;

seguir várias regras empresariais;

pode exigir bastante contexto e instruções.

Nesse caso, o tamanho não é um problema por si só.

O importante é que cada parte tenha uma função.

Uma regra prática

Pergunte:

Se eu remover esta informação, a resposta provavelmente mudará de forma relevante?

Se não, talvez ela seja dispensável.

Também podemos perguntar:

Esta instrução já foi dita de forma clara antes?

Se sim, talvez não precise ser repetida.

Prefira densidade de informação

Um bom prompt costuma ter uma boa relação entre:

quantidade de texto

e

quantidade de informação útil.

Por exemplo:

CONTEXTO:
Aplicação PHP 8.3 com PDO e MySQL.

OBJETIVO:
Identificar erros que impeçam o INSERT.

RESTRIÇÃO:
Não alterar a arquitetura.

FORMATO:
Liste problema, causa e correção.

É curto, mas informativo.

O ponto principal

Um prompt melhor não é necessariamente maior.

É mais claro, relevante e consistente.

Podemos resumir:

PROMPT LONGO + INFORMAÇÃO ÚTIL

pode ser excelente.

PROMPT LONGO + REPETIÇÃO E RUÍDO

pode ser pior.

PROMPT CURTO + OBJETIVO CLARO

pode ser suficiente.

A pergunta correta não é:

"Meu prompt está grande o bastante?"

Mas:

"Ele contém tudo o que realmente importa para a tarefa?"

Um dos maiores mitos sobre Prompt Engineering é a ideia de que existem frases especiais capazes de liberar respostas muito melhores automaticamente.

Na internet, encontramos recomendações como:

"Use esta frase secreta para melhorar qualquer resposta."

"Comece sempre com 'aja como especialista'."

"Diga ao modelo que ele tem 20 anos de experiência."

"Use este prompt mestre para qualquer tarefa."

Essas técnicas podem ocasionalmente influenciar o comportamento da resposta, mas não existe uma combinação universal de palavras capaz de eliminar as limitações de um LLM.

Prompt Engineering é especificação de tarefa, não feitiço.

"Aja como especialista" não cria especialização

Considere:

"Aja como o melhor especialista em eletrônica do mundo."

Essa frase não adiciona automaticamente:

• novos conhecimentos;

• experiência prática;

• acesso a informações atuais;

• garantia de precisão.

Uma instrução mais útil seria:

"Analise o circuito com foco em tensão, corrente máxima, dissipação de potência e limites dos componentes."

Aqui estamos fornecendo critérios concretos.

Autoridade fictícia não garante qualidade

Outro padrão comum:

"Você possui 30 anos de experiência em PHP."

Isso pode influenciar o estilo, mas não transforma o modelo em alguém que realmente trabalhou três décadas com PHP.

É melhor indicar aquilo que desejamos:

"Faça uma revisão técnica com foco em segurança, compatibilidade com PHP 8.3 e boas práticas de PDO."

Agora a expectativa é verificável.

Prompts universais devem ser tratados com cautela

Templates podem ser úteis.

Mas um prompt criado para:

• escrever artigos;

não necessariamente é adequado para:

• revisar código;

• analisar documentos;

• extrair dados;

• classificar mensagens.

Tarefas diferentes possuem necessidades diferentes.

Por isso:

um bom prompt é adequado ao problema, não universal.

Algumas expressões podem ajudar, mas por uma razão concreta

Por exemplo:

"Explique passo a passo."

pode ser útil porque solicita uma estrutura sequencial.

"Responda em tabela."

ajuda porque define formato.

"Use apenas o documento fornecido."

ajuda porque estabelece uma restrição de fonte.

Essas expressões funcionam não porque sejam mágicas, mas porque transmitem instruções concretas.

Cuidado com prompts excessivamente teatrais

Compare:

"Você é um gênio mundial da programação, premiado internacionalmente e incapaz de cometer erros."

com:

"Revise o código abaixo procurando erros de sintaxe, vulnerabilidades de SQL Injection e incompatibilidades com PHP 8.3."

A segunda versão fornece informações muito mais úteis para a tarefa.

Nenhum prompt elimina alucinações

Mesmo um prompt excelente pode produzir:

• erros factuais;

• referências inexistentes;

• interpretações incorretas;

• código com problemas;

• conclusões inadequadas.

Por isso, Prompt Engineering deve ser combinado com:

• verificação;

• boas fontes;

• ferramentas;

• validação;

• revisão humana quando necessário.

O modelo também importa

O mesmo prompt pode produzir resultados diferentes em modelos distintos.

Isso acontece porque eles podem variar em:

• capacidade;

• treinamento;

• tamanho;

• arquitetura;

• contexto disponível;

• ferramentas;

• configurações.

Portanto, não existe garantia de que um prompt que funciona muito bem em um modelo terá exatamente o mesmo efeito em outro.

A tarefa deve orientar o prompt

Em vez de perguntar:

"Qual é o prompt secreto para fazer isso?"

é mais produtivo perguntar:

"Que informações o modelo precisa para realizar essa tarefa corretamente?"

Esse raciocínio leva naturalmente aos elementos que estudamos:

Objetivo

Contexto

Instruções

Público

Formato

Restrições

Exemplos

Prompt Engineering é comunicação estruturada

Podemos pensar em Prompt Engineering como uma forma de transformar:

intenção humana

em:

especificação compreensível para o modelo.

Assim:

O QUE EU QUERO?
        ↓
O QUE O MODELO PRECISA SABER?
        ↓
COMO A TAREFA DEVE SER EXECUTADA?
        ↓
QUAIS LIMITES DEVEM SER RESPEITADOS?
        ↓
COMO O RESULTADO DEVE SER ENTREGUE?
        ↓
PROMPT

Essa estrutura é muito mais útil do que memorizar dezenas de frases prontas.

O ponto principal

Não existe uma fórmula verbal capaz de transformar automaticamente qualquer prompt em um resultado perfeito.

Um bom prompt funciona porque:

• define o objetivo;

• reduz ambiguidades;

• fornece contexto relevante;

• estabelece critérios;

• orienta formato;

• apresenta exemplos quando necessário.

Portanto:

A melhor técnica de Prompt Engineering continua sendo definir com clareza aquilo que queremos que o modelo faça e fornecer as informações necessárias para que ele faça isso bem.

Com esses princípios estabelecidos, podemos avançar para uma parte mais prática do artigo:

Depois de entender objetivo, contexto, público, formato, restrições, exemplos e estrutura, podemos reunir algumas técnicas simples que ajudam a melhorar prompts no dia a dia.

A ideia aqui não é criar fórmulas rígidas, mas desenvolver hábitos que tornem as solicitações mais claras e úteis.

1. Comece pelo objetivo principal

Evite começar com informações secundárias antes de dizer o que você realmente quer.

Em vez de:

"Estou trabalhando em um projeto há alguns dias, já tentei algumas coisas e estou com algumas dúvidas sobre PHP..."

prefira:

"Analise este código PHP e identifique o erro que impede o cadastro do usuário."

Depois, acrescente o contexto necessário.

A regra é simples:

primeiro deixe claro o que deve ser feito.

2. Acrescente apenas o contexto que muda a resposta

Compare:

"Qual placa devo usar?"

com:

"Preciso de Wi-Fi, Bluetooth e pelo menos três entradas analógicas. Qual placa seria mais adequada?"

A segunda versão fornece contexto relevante.

Evite acrescentar informações que não influenciam a decisão.

3. Defina para quem a resposta será produzida

Isso é especialmente útil em conteúdo educacional.

Em vez de:

"Explique transistores."

use:

"Explique transistores para um estudante iniciante que já conhece tensão, corrente e resistência."

Isso ajuda a calibrar o nível técnico.

4. Diga como deseja receber a resposta

Se o formato importa, informe.

Por exemplo:

"Compare as opções em uma tabela."

"Responda em cinco tópicos."

"Mostre primeiro o problema e depois a correção."

"Retorne apenas JSON."

Isso reduz decisões desnecessárias por parte do modelo.

5. Transforme palavras vagas em critérios concretos

Evite:

"Deixe este código melhor."

Prefira:

"Melhore este código reduzindo duplicação, aumentando legibilidade e preservando o comportamento atual."

Da mesma forma:

"Faça um artigo profissional."

é menos preciso que:

"Escreva em linguagem objetiva, com parágrafos curtos, exemplos práticos e sem tom promocional."

6. Informe o que não deve ser feito

Restrições podem evitar resultados indesejados.

Por exemplo:

"Não altere os nomes das funções."

"Não use bibliotecas externas."

"Não inclua informações que não estejam no documento."

"Não entre ainda em detalhes sobre registradores."

Isso ajuda a manter o escopo.

7. Use exemplos quando o padrão for difícil de explicar

Se você quer uma saída específica, muitas vezes é mais fácil mostrar.

Por exemplo:

Entrada: "Excelente atendimento!"
Saída: ELOGIO

Entrada: "Meu produto chegou quebrado."
Saída: RECLAMAÇÃO

Depois:

Entrada: "Não consigo acessar minha conta."

O modelo passa a ter uma referência concreta.

8. Separe instruções de dados

Quando o prompt contém código, documentos ou grandes blocos de informação, organize.

Por exemplo:

OBJETIVO:
Encontrar erros de execução.

CONTEXTO:
PHP 8.3 com PDO e MySQL.

CÓDIGO:
[cole o código aqui]

FORMATO:
Liste problema, causa e correção.

Isso ajuda a distinguir claramente:

• instruções;

• contexto;

• dados;

• saída esperada.

9. Divida tarefas complexas

Em vez de:

"Analise, corrija, documente e otimize este sistema."

podemos usar:

"Primeiro analise os problemas. Não altere nada ainda."

Depois:

"Agora priorize os problemas encontrados."

Depois:

"Aplique apenas as correções de maior prioridade."

Essa estratégia facilita o controle da tarefa.

10. Use uma etapa de revisão

Depois de obter uma resposta importante, podemos solicitar:

"Revise a resposta procurando possíveis inconsistências."

ou:

"Verifique se todos os critérios do prompt foram atendidos."

ou:

"Liste quais partes ainda precisam de confirmação em fonte oficial."

Essa etapa não garante ausência de erros, mas pode ajudar a identificar problemas.

11. Peça fontes quando a verificabilidade for importante

Para informações técnicas, jurídicas, científicas ou atuais, podemos definir:

"Baseie a resposta em fontes oficiais e indique quais afirmações precisam ser verificadas."

Mas é importante lembrar:

pedir uma fonte não garante que a referência gerada exista ou esteja correta.

Quando a informação for importante, a fonte deve ser conferida.

12. Diga ao modelo quando admitir incerteza

Uma instrução útil pode ser:

"Se não houver informação suficiente, informe isso em vez de assumir."

ou:

"Quando não tiver certeza, diferencie claramente fato, hipótese e recomendação."

Isso pode ajudar a tornar a resposta mais transparente.

Ainda assim, não elimina totalmente erros ou alucinações.

13. Evite instruções contraditórias

Antes de enviar um prompt longo, procure conflitos como:

"Seja detalhado."

e:

"Responda em duas linhas."

Ou:

"Não altere o texto."

e:

"Reescreva completamente."

Se duas instruções entram em conflito, o resultado fica menos previsível.

14. Defina prioridades

Quando vários requisitos são importantes, podemos explicitar a ordem.

Por exemplo:

PRIORIDADE 1:
Preservar o comportamento atual.

PRIORIDADE 2:
Corrigir falhas de segurança.

PRIORIDADE 3:
Melhorar a legibilidade.

Isso ajuda o modelo quando dois objetivos entram em tensão.

15. Use delimitadores em prompts grandes

Para separar documentos, códigos ou dados:

--- INÍCIO DO TEXTO ---

[conteúdo]

--- FIM DO TEXTO ---

ou:

CÓDIGO:
"""
[conteúdo]
"""

A função é simplesmente deixar claras as fronteiras entre instrução e conteúdo.

16. Informe o que deve ser preservado

Em tarefas de edição, isso é muito útil.

Por exemplo:

"Corrija a gramática, mas preserve o estilo do autor."

"Refatore o código sem alterar a interface pública."

"Resuma o documento preservando datas, valores e nomes próprios."

Isso reduz alterações indesejadas.

17. Use perguntas de controle quando necessário

Em tarefas complexas, podemos pedir que o modelo identifique lacunas antes de executar.

Por exemplo:

"Antes de sugerir uma arquitetura, liste as informações que ainda faltam para tomar a decisão."

ou:

"Informe quais dados são necessários para comparar corretamente essas opções."

Isso é útil quando uma resposta precipitada seria pior do que reconhecer falta de informação.

18. Refine apenas o que precisa mudar

Se a resposta ficou boa em quase tudo, não é necessário reiniciar.

Por exemplo:

"Mantenha a estrutura e os exemplos. Apenas reduza a introdução pela metade."

ou:

"Não altere o restante. Corrija somente a seção sobre segurança."

Isso preserva o que já funcionou.

19. Compare versões quando a escolha for subjetiva

Para títulos, textos, estratégias ou abordagens, pode ser útil pedir alternativas.

Por exemplo:

"Crie três versões: uma direta, uma didática e uma mais técnica."

Depois podemos escolher ou combinar elementos.

20. Avalie o prompt pela resposta obtida

Prompt Engineering é um processo iterativo.

Se o modelo respondeu errado ou de forma inadequada, pergunte:

• o objetivo estava claro?

• faltou contexto?

• havia alguma ambiguidade?

• o formato estava definido?

• existiam instruções conflitantes?

• faltou um exemplo?

• a tarefa era grande demais para um único passo?

A resposta também serve como diagnóstico do próprio prompt.

Antes e depois

Veja um exemplo simples.

Antes

"Veja meu código."

Depois

"Analise este código PHP 8.3 com PDO e MySQL. Identifique apenas erros que possam impedir sua execução. Não altere a arquitetura. Para cada problema, mostre o trecho, explique a causa e apresente a correção."

O segundo prompt deixa claro:

• ambiente;

• objetivo;

• escopo;

• restrição;

• formato.

Um checklist rápido

Antes de enviar uma tarefa mais complexa, podemos verificar:

[ ] O objetivo está claro?

[ ] Forneci o contexto necessário?

[ ] Informei o público, se isso for relevante?

[ ] Defini o formato esperado?

[ ] Existem restrições importantes?

[ ] Há critérios claros de qualidade?

[ ] Um exemplo ajudaria?

[ ] Existem instruções contraditórias?

[ ] A tarefa deveria ser dividida em etapas?

[ ] O resultado precisará ser verificado?

Não precisamos preencher todos os itens em toda solicitação.

O checklist serve para identificar o que realmente importa.

Uma fórmula prática

Podemos resumir boa parte do artigo em:

Seja claro sobre o que quer, forneça apenas o contexto relevante, estabeleça critérios verificáveis e organize a tarefa de acordo com sua complexidade.

Ou, visualmente:

OBJETIVO

↓

CONTEXTO

↓

INSTRUÇÕES

↓

CRITÉRIOS

↓

FORMATO

↓

RESTRIÇÕES

↓

EXEMPLOS

↓

AVALIAÇÃO

O ponto principal

Melhorar prompts não significa adicionar palavras sofisticadas.

Significa reduzir ambiguidades e tornar mais explícito aquilo que o usuário espera do modelo.

As técnicas que vimos funcionam porque ajudam a responder perguntas concretas:

O que deve ser feito?

Com quais informações?

Para quem?

Sob quais condições?

Em qual formato?

Como saberemos se o resultado ficou bom?

No próximo bloco colocaremos tudo isso em prática comparando solicitações reais:

Depois de estudar todos os principais elementos de um bom prompt, chegou a hora de comparar exemplos práticos.

A ideia aqui não é dizer que existe apenas uma forma correta de escrever um prompt.

O objetivo é mostrar como pequenas mudanças podem:

• reduzir ambiguidades;

• acrescentar contexto útil;

• definir critérios;

• orientar o formato;

• limitar o escopo;

• tornar o resultado mais verificável.

Exemplo 1 — Produção de conteúdo

❌ Prompt fraco:

"Escreva sobre Arduino."

O problema é que o modelo não sabe:

• para quem escrever;

• qual nível técnico utilizar;

• qual objetivo do texto;

• qual tamanho;

• qual foco.

✅ Prompt melhorado:

"Escreva uma introdução para um artigo destinado a iniciantes explicando o que é Arduino, para que ele serve e por que é utilizado em projetos de eletrônica. Use linguagem simples, evite termos técnicos sem explicação e não apresente código ainda."

O que melhorou?

Foram definidos:

• público;

• objetivo;

• conteúdo;

• nível;

• restrição.

Exemplo 2 — Programação

❌ Prompt fraco:

"Corrija meu código."

Faltam informações importantes.

✅ Prompt melhorado:

"Analise este código PHP 8.3 com PDO e MySQL. Identifique apenas erros que possam impedir a execução ou a gravação dos dados. Não altere a arquitetura nem renomeie métodos. Para cada problema, mostre a causa e a correção."

O que melhorou?

Agora temos:

• linguagem e versão;

• tecnologias utilizadas;

• escopo;

• restrições;

• formato da resposta.

Exemplo 3 — Eletrônica

❌ Prompt fraco:

"Qual sensor devo usar?"

Não sabemos para qual aplicação.

✅ Prompt melhorado:

"Estou criando um projeto com Arduino Uno para medir temperatura ambiente entre 10 °C e 40 °C. Não preciso de alta precisão e quero simular o circuito no Tinkercad. Qual sensor é mais adequado e por quê?"

O que melhorou?

O contexto passou a incluir:

• placa;

• grandeza;

• faixa de medição;

• precisão;

• ambiente de simulação.

Exemplo 4 — Comparação

❌ Prompt fraco:

"Qual é melhor, ESP32 ou Arduino?"

A palavra:

"melhor"

é subjetiva.

✅ Prompt melhorado:

"Compare ESP32 DevKit e Arduino Uno R4 WiFi considerando Wi-Fi, Bluetooth, desempenho, tensão lógica, quantidade de GPIOs, facilidade para iniciantes e custo-benefício. Apresente o resultado em tabela e finalize indicando em quais situações cada placa é mais adequada."

O que melhorou?

Foram definidos:

• modelos;

• critérios;

• formato;

• finalidade da comparação.

Exemplo 5 — Revisão de texto

❌ Prompt fraco:

"Melhore este texto."

O modelo precisa decidir sozinho o que significa "melhorar".

✅ Prompt melhorado:

"Revise este texto para melhorar clareza, fluidez e organização. Preserve o significado original e o nível técnico. Remova repetições, mas não reduza informações importantes."

O que melhorou?

Agora existem critérios claros:

• clareza;

• fluidez;

• organização;

• preservação;

• redução de repetições.

Exemplo 6 — Análise de documento

❌ Prompt fraco:

"Analise este contrato."

É amplo demais.

✅ Prompt melhorado:

"Analise este contrato exclusivamente quanto a prazo, reajuste, penalidades e hipóteses de rescisão. Para cada item encontrado, cite a cláusula correspondente. Se algum desses temas não estiver presente no documento, informe explicitamente."

O que melhorou?

Foram definidos:

• escopo;

• critérios;

• formato;

• comportamento quando a informação não existir.

Exemplo 7 — Resumo

❌ Prompt fraco:

"Resuma esse texto."

Pode gerar um resumo muito longo ou superficial.

✅ Prompt melhorado:

"Resuma este texto em até seis tópicos, preservando apenas as ideias centrais. Não acrescente informações externas ao conteúdo original."

O que melhorou?

Foram definidos:

• tamanho;

• critério de seleção;

• restrição.

Exemplo 8 — Pesquisa

❌ Prompt fraco:

"Pesquise sobre inteligência artificial."

A tarefa é ampla demais.

✅ Prompt melhorado:

"Faça um levantamento introdutório sobre os principais usos de IA Generativa em pequenas empresas. Organize por área de aplicação, indique benefícios e riscos e diferencie claramente informações consolidadas de tendências ainda incertas."

O que melhorou?

Foram definidos:

• tema;

• recorte;

• organização;

• critérios de análise;

• tratamento da incerteza.

Exemplo 9 — Automação

❌ Prompt fraco:

"Responda mensagens de clientes."

Faltam regras.

✅ Prompt melhorado:

OBJETIVO:
Classificar mensagens de suporte e gerar uma resposta inicial.

CATEGORIAS:
- dúvida
- problema técnico
- financeiro
- cancelamento

REGRAS:
- não inventar informações
- não prometer prazos não fornecidos
- encaminhar casos de cancelamento para atendimento humano

FORMATO:
Categoria:
Prioridade:
Resposta:

O que melhorou?

O prompt passou a funcionar como uma pequena especificação de sistema.

O padrão por trás das melhorias

Observe que os prompts melhorados não são necessariamente muito maiores.

Eles apenas respondem melhor a perguntas como:

• O que deve ser feito?

• Em qual contexto?

• Para quem?

• Com quais critérios?

• Em qual formato?

• Com quais limites?

Podemos resumir:

Prompt fraco

deixa decisões demais abertas.

Prompt melhorado

reduz ambiguidades e torna o resultado esperado mais explícito.

Escrever um bom prompt é apenas metade do trabalho.

Depois de receber a resposta, precisamos avaliar:

Ela realmente resolveu o problema?

Uma resposta pode parecer excelente e ainda assim:

• estar incompleta;

• fugir do objetivo;

• conter erros;

• ignorar critérios;

• utilizar informações inventadas;

• apresentar formato inadequado.

Por isso, Prompt Engineering também envolve avaliar o resultado.

1. A resposta cumpriu o objetivo?

Volte ao pedido inicial.

Se o objetivo era:

comparar duas placas;

a resposta realmente comparou?

Se era:

identificar erros;

ela encontrou os problemas?

Se era:

produzir um resumo;

ela resumiu ou apenas reescreveu?

A primeira pergunta deve ser:

O resultado corresponde ao que foi solicitado?

2. Todas as instruções foram atendidas?

Imagine que o prompt dizia:

"Use uma tabela e finalize com uma recomendação."

Verifique:

• a tabela foi criada?

• a recomendação foi apresentada?

Se o prompt tinha cinco requisitos e apenas três foram atendidos, a resposta ainda precisa ser refinada.

3. O conteúdo está correto?

Essa talvez seja a avaliação mais importante.

Pergunte:

• os fatos estão corretos?

• as datas conferem?

• os valores fazem sentido?

• o código realmente funciona?

• as referências existem?

• as interpretações estão corretas?

Em assuntos importantes, a resposta deve ser confrontada com fontes confiáveis.

4. A resposta adicionou informações que não deveria?

Se o prompt dizia:

"Use apenas o documento fornecido."

e a IA acrescentou informações externas, a resposta não respeitou a restrição.

Da mesma forma, se pedimos:

"Não altere a arquitetura."

e o modelo reestruturou todo o código, existe um problema de aderência.

5. O nível está adequado ao público?

Uma resposta tecnicamente correta pode ser inadequada.

Por exemplo, uma explicação para iniciantes pode conter:

• termos avançados;

• fórmulas desnecessárias;

• conceitos não explicados.

Ou uma resposta para especialistas pode ser superficial demais.

Pergunte:

Essa resposta é adequada para quem vai utilizá-la?

6. O formato ficou adequado?

Se o objetivo era comparar, uma tabela pode ser melhor que vários parágrafos.

Se o resultado será processado por software, um JSON inválido é um problema, mesmo que o conteúdo esteja correto.

Portanto, verifique:

• estrutura;

• campos;

• organização;

• tamanho;

• legibilidade.

7. A resposta é completa sem ser excessiva?

Uma boa resposta deve conter informação suficiente.

Mas isso não significa incluir tudo que o modelo sabe.

Pergunte:

O conteúdo essencial está presente?

e também:

Existe informação que não contribui para o objetivo?

8. Existem afirmações sem sustentação?

Fique atento a frases muito específicas, principalmente envolvendo:

• pesquisas;

• estatísticas;

• leis;

• decisões judiciais;

• documentação;

• versões de software;

• preços;

• notícias.

Se a afirmação for importante, verifique a fonte.

9. A resposta demonstra incerteza quando necessário?

Nem toda pergunta possui uma resposta absoluta.

Compare:

❌

"Essa é definitivamente a melhor tecnologia."

com:

✅

"Para os critérios informados, esta opção parece mais adequada, mas a escolha pode mudar se consumo de energia for prioridade."

Uma resposta de qualidade reconhece limites quando eles realmente existem.

10. A resposta é consistente internamente?

Às vezes o modelo afirma algo no início e contradiz mais adiante.

Por isso, em respostas longas, vale verificar:

• números;

• recomendações;

• nomes;

• conclusões;

• critérios.

Um checklist de avaliação

Podemos utilizar:

[ ] O objetivo foi cumprido?

[ ] Todas as instruções foram atendidas?

[ ] As restrições foram respeitadas?

[ ] As informações estão corretas?

[ ] O nível está adequado ao público?

[ ] O formato ficou correto?

[ ] O conteúdo é suficientemente completo?

[ ] Existem informações irrelevantes?

[ ] Há afirmações que precisam ser verificadas?

[ ] Existem contradições?

Avaliar também ajuda a melhorar o prompt

Se a resposta ficou ruim, nem sempre significa que o modelo é incapaz de realizar a tarefa.

Talvez o prompt tenha deixado algo importante em aberto.

Por exemplo:

Problema

resposta longa demais.

Possível melhoria

estabelecer limite ou formato.

Problema

resposta genérica.

Possível melhoria

fornecer mais contexto ou critérios.

Problema

linguagem técnica demais.

Possível melhoria

definir público e conhecimento prévio.

Problema

modelo alterou partes que deveriam ser preservadas.

Possível melhoria

adicionar uma restrição explícita.

Assim, podemos utilizar o resultado como um diagnóstico.

O ciclo completo de Prompt Engineering

Agora conseguimos visualizar o processo inteiro:

DEFINIR O OBJETIVO

↓

CRIAR O PROMPT

↓

EXECUTAR

↓

AVALIAR A RESPOSTA

↓

IDENTIFICAR PROBLEMAS

↓

REFINAR O PROMPT

↓

EXECUTAR NOVAMENTE

Esse ciclo pode continuar até que o resultado esteja suficientemente adequado à tarefa.

Não busque perfeição desnecessária

Nem toda resposta precisa passar por várias revisões.

Para uma pergunta simples, uma resposta suficientemente correta pode resolver o problema.

Já tarefas de maior impacto podem exigir:

• revisão;

• validação;

• fontes;

• testes;

• análise humana.

O nível de verificação deve acompanhar o risco da tarefa.

O ponto principal

Um bom prompt não é avaliado apenas pela forma como foi escrito.

Ele deve ser avaliado principalmente pelo resultado que produz.

A pergunta final é:

A resposta é correta, útil, adequada ao objetivo e verificável quando necessário?

Se não for, podemos melhorar:

• o prompt;

• o contexto;

• os critérios;

• a tarefa;

• ou até escolher outra ferramenta ou modelo.

No próximo bloco veremos uma limitação fundamental que nenhuma técnica de Prompt Engineering consegue eliminar completamente:

Ao longo deste artigo, vimos várias técnicas capazes de melhorar a comunicação com um modelo de Inteligência Artificial.

Aprendemos a:

• definir objetivos;

• fornecer contexto relevante;

• indicar público e nível;

• estabelecer formatos;

• utilizar restrições e critérios;

• fornecer exemplos;

• dividir tarefas complexas;

• avaliar e refinar respostas.

Tudo isso pode melhorar bastante a qualidade do resultado.

Mas existe um limite importante:

Nenhum prompt, por melhor que seja, elimina completamente os erros de um LLM.

Um bom prompt melhora as condições da tarefa

Quando estruturamos bem uma solicitação, reduzimos ambiguidades.

Por exemplo:

"Analise este código."

é menos preciso que:

"Analise este código PHP 8.3 e identifique apenas erros que possam impedir sua execução. Não altere a arquitetura."

A segunda versão oferece melhores condições para o modelo realizar a tarefa.

Mas ainda não garante que:

• todos os erros serão encontrados;

• nenhuma sugestão estará incorreta;

• o código corrigido funcionará perfeitamente;

• nenhuma informação será inventada.

Prompt Engineering melhora o processo, mas não transforma o modelo em um sistema infalível.

O modelo continua sendo probabilístico

Como vimos no artigo anterior, LLMs geram respostas por meio de cálculos probabilísticos.

O modelo processa o contexto e estima quais tokens são mais adequados para continuar a sequência.

Isso significa que uma resposta pode ser:

• coerente;

• bem escrita;

• tecnicamente convincente;

e ainda assim conter erros.

Por isso:

boa formulação não é garantia de verdade.

Um prompt não cria conhecimento que o modelo não possui

Considere:

"Responda como o maior especialista do mundo sobre este assunto."

Essa instrução não fornece automaticamente novas informações ao modelo.

Se o conhecimento necessário não estiver adequadamente representado em:

• seus parâmetros;

• documentos fornecidos;

• ferramentas disponíveis;

• dados externos;

o modelo ainda poderá responder de forma incorreta ou incompleta.

Um prompt não atualiza automaticamente informações

Imagine perguntar:

"Qual é a versão mais recente desta biblioteca?"

Se o sistema não possuir acesso a informações atuais, um prompt melhor não resolverá esse problema sozinho.

Podemos escrever:

"Forneça apenas informações atualizadas."

Mas isso não cria acesso a dados recentes.

Para determinadas tarefas, será necessário utilizar:

• pesquisa na web;

• APIs;

• bancos de dados;

• documentação oficial;

• outras ferramentas externas.

O modelo pode interpretar instruções incorretamente

Mesmo prompts claros podem ser interpretados de maneira diferente da esperada.

Isso pode ocorrer quando:

• existem ambiguidades;

• as instruções são numerosas;

• há conflitos entre regras;

• o contexto é muito extenso;

• a tarefa exige muitas decisões.

Por isso, a avaliação do resultado continua sendo necessária.

Exemplos também podem induzir erros

Few-shot prompting pode melhorar uma tarefa.

Mas, se os exemplos estiverem errados, o modelo pode aprender o padrão errado dentro daquele contexto.

Por exemplo:

"Excelente atendimento." → RECLAMAÇÃO

Se fornecermos essa classificação como exemplo, estaremos orientando o modelo de maneira inadequada.

Portanto:

bons exemplos ajudam; exemplos ruins também ensinam.

Formato correto não significa conteúdo correto

Um modelo pode produzir um JSON perfeitamente estruturado

{
    "status": "correto",
    "resultado": "42"
}

e, ainda assim, o valor estar errado.

Da mesma forma, uma tabela pode estar bem organizada e conter informações incorretas.

Isso mostra que devemos avaliar separadamente:

forma

e

conteúdo.

O modelo pode inventar informações

LLMs podem produzir informações plausíveis que não correspondem à realidade.

Isso pode incluir:

• referências bibliográficas;

• números;

• datas;

• nomes;

• artigos de lei;

• funções inexistentes;

• métodos de bibliotecas;

• especificações técnicas.

Esse fenômeno é frequentemente chamado de alucinação.

Um prompt pode reduzir o risco, por exemplo:

"Se não encontrar essa informação no documento, diga que ela não está disponível."

Mas ainda não existe garantia absoluta de que o modelo sempre obedecerá.

Pedir referências não garante referências verdadeiras

Considere:

"Forneça três artigos científicos que comprovem isso."

O modelo pode gerar referências aparentemente perfeitas, mas inexistentes.

Por isso, referências devem ser verificadas.

Em tarefas importantes, prefira:

fontes recuperadas diretamente por ferramentas;

ou:

documentação oficial fornecida no contexto.

A resposta pode estar correta, mas inadequada à decisão

Existe outro tipo de limitação.

Uma resposta pode conter informações corretas, mas não considerar todos os fatores necessários para uma decisão.

Por exemplo:

"Qual placa é melhor?"

O modelo pode recomendar ESP32 com base em desempenho.

Mas talvez o projeto tenha uma exigência não informada:

alimentação de 5 V;

ou:

compatibilidade com determinado shield.

Isso reforça um princípio já estudado:

a qualidade da resposta também depende da qualidade das informações disponíveis.

Algumas tarefas exigem ferramentas, não apenas linguagem

Um LLM é excelente para processar e gerar linguagem.

Mas determinadas tarefas são melhor resolvidas com ferramentas especializadas.

Por exemplo:

Cálculos → calculadora ou ambiente de execução.

Dados atuais → API ou pesquisa.

Banco de dados → consulta real ao banco.

Execução de código → interpretador ou compilador.

Informações de sistema → ferramentas de diagnóstico.

Um sistema de IA pode combinar o LLM com essas ferramentas.

Isso aumenta bastante suas capacidades.

Quanto maior o risco, maior deve ser a verificação

Nem toda resposta exige o mesmo nível de cuidado.

Por exemplo:

sugestão de título para um artigo

possui baixo risco.

Já:

orientação jurídica;

diagnóstico médico;

decisão financeira;

alteração crítica de código;

cálculo de engenharia;

exigem muito mais verificação.

Podemos pensar:

Baixo impacto → revisão simples.

Médio impacto → conferir informações relevantes.

Alto impacto → validar em fontes confiáveis e, quando necessário, com profissional ou sistema especializado.

Prompt Engineering não substitui pensamento crítico

Talvez essa seja a principal limitação a compreender.

A IA pode:

• ajudar;

• acelerar;

• organizar;

• sugerir;

• analisar;

• gerar alternativas.

Mas o usuário continua responsável por avaliar se o resultado:

• faz sentido;

• está correto;

• atende ao objetivo;

• deve ser utilizado.

Prompt Engineering melhora a comunicação com a IA, mas não elimina a necessidade de julgamento humano.

Uma regra prática

Podemos resumir:

Quanto mais importante for a consequência de uma resposta, menos devemos depender exclusivamente do texto gerado pelo modelo.

Use a IA como ferramenta.

Não confunda fluência com certeza.

Ao longo deste artigo, vimos que escrever bons prompts é muito mais do que aprender frases prontas ou copiar comandos encontrados na internet.

Prompt Engineering é, essencialmente, uma forma de transformar uma intenção em uma especificação clara para um modelo de Inteligência Artificial.

Começamos entendendo que um prompt pode ser:

• uma pergunta;

• uma instrução;

• uma tarefa;

• um conjunto de dados;

• uma combinação de vários elementos.

Depois vimos que prompt e contexto não são exatamente a mesma coisa.

O prompt representa aquilo que solicitamos.

O contexto pode incluir muito mais:

• informações anteriores;

• documentos;

• dados externos;

• instruções;

• ferramentas;

• histórico da conversa.

Os principais elementos de um bom prompt

Ao longo do artigo construímos uma estrutura prática:

OBJETIVO

↓

CONTEXTO

↓

INSTRUÇÕES

↓

PÚBLICO

↓

FORMATO

↓

RESTRIÇÕES

↓

EXEMPLOS

Nem todo prompt precisa conter todos esses elementos.

Uma tarefa simples pode precisar apenas de:

objetivo + instrução.

Uma tarefa complexa pode exigir:

contexto + critérios + formato + exemplos + restrições.

O ponto central é:

usar apenas as informações necessárias para tornar a tarefa clara.

Clareza vale mais que tamanho

Também vimos que prompts maiores não são necessariamente melhores.

Um prompt eficiente não é aquele que possui mais palavras.

É aquele que contém:

• informação relevante;

• instruções consistentes;

• critérios verificáveis;

• pouco ruído.

Por isso:

clareza é mais importante que comprimento.

Prompt Engineering é um processo

Outro aprendizado importante é que não precisamos acertar tudo na primeira tentativa.

Podemos trabalhar iterativamente:

Definir

↓

Executar

↓

Avaliar

↓

Refinar

↓

Executar novamente

Essa interação permite melhorar progressivamente o resultado.

Exemplos ajudam a ensinar padrões

Vimos também como exemplos podem orientar o comportamento do modelo.

A partir daí conhecemos:

Zero-shot

nenhum exemplo.

One-shot

um exemplo.

Few-shot

alguns exemplos.

Essas técnicas utilizam informações fornecidas no contexto e não devem ser confundidas com treinamento permanente do modelo.

Tarefas complexas podem ser divididas

Quando uma solicitação envolve muitas etapas, podemos decompor:

ANALISAR

↓

PLANEJAR

↓

EXECUTAR

↓

REVISAR

Isso aumenta o controle sobre o processo e facilita a correção de problemas antes que eles se propaguem.

Formato, critérios e restrições tornam o resultado mais previsível

Também aprendemos que podemos indicar:

como a resposta deve ser apresentada;

quais requisitos precisam ser atendidos;

quais limites devem ser respeitados.

Isso torna o prompt mais próximo de uma especificação.

Esse princípio será particularmente importante quando começarmos a utilizar IA em:

• automações;

• APIs;

• RAG;

• agentes;

• sistemas empresariais.

Não existem palavras mágicas

Um dos pontos mais importantes deste artigo foi desfazer a ideia de que Prompt Engineering depende de frases secretas.

Escrever:

"Você é o maior especialista do mundo..."

não transforma automaticamente o modelo em uma fonte infalível.

O que realmente melhora a tarefa é algo muito mais concreto:

dizer claramente o que queremos e fornecer as informações necessárias para executar aquilo que queremos.

E um bom prompt ainda pode produzir uma resposta errada

Por fim, vimos que Prompt Engineering possui limites.

Mesmo uma solicitação excelente pode resultar em:

• erros;

• interpretações inadequadas;

• informações desatualizadas;

• alucinações;

• omissões.

Portanto:

um bom prompt aumenta a chance de uma boa resposta, mas não garante uma resposta correta.

Avaliação e verificação continuam sendo fundamentais.

Um modelo mental para levar deste artigo

Se você precisar lembrar apenas de uma pergunta antes de enviar um prompt, use esta:

“O que esta IA precisa saber para executar corretamente aquilo que eu quero?”

A partir dela, outras perguntas surgem naturalmente:

O que quero que ela faça?

Qual contexto é necessário?

Para quem é a resposta?

Como quero receber o resultado?

Quais limites devem ser respeitados?

Existe algum exemplo útil?

Como vou avaliar se o resultado ficou bom?

Esse raciocínio é muito mais valioso do que memorizar prompts prontos.

Do prompt para sistemas mais avançados

Até aqui, aprendemos a conversar melhor com um modelo.

Mas um LLM pode fazer muito mais quando deixa de apenas responder textos e passa a interagir com:

• ferramentas;

• dados;

• sistemas;

• APIs;

• aplicações externas.

É justamente essa evolução que começará a nos levar aos próximos conceitos da série IA na Prática.

A partir daqui, não estaremos apenas perguntando:

"Como escrever uma boa instrução?"

Começaremos a perguntar:

"Como fazer uma IA utilizar informações, ferramentas e ações para resolver tarefas de forma mais autônoma?"

Até aqui, nossa interação com a Inteligência Artificial aconteceu principalmente por meio de uma lógica simples:

Usuário

↓

Prompt

↓

LLM

↓

Resposta

Aprendemos como melhorar essa comunicação utilizando:

• objetivos claros;

• contexto relevante;

• instruções;

• público;

• formatos;

• restrições;

• critérios;

• exemplos.

Mas existe uma evolução importante.

E se, em vez de apenas responder uma pergunta, a IA pudesse:

• consultar uma ferramenta;

• pesquisar uma informação;

• analisar o resultado;

• decidir qual deve ser o próximo passo;

• executar uma ação;

• verificar o resultado;

• continuar trabalhando até concluir uma tarefa?

Nesse caso, começamos a sair do modelo de um simples chatbot e entramos no universo dos Agentes de IA.

De forma bastante simplificada:

LLM tradicional em uma conversa

recebe informações → gera uma resposta.

Sistema com comportamento agêntico

recebe um objetivo → avalia a situação → utiliza recursos disponíveis → executa etapas → observa resultados → continua até atingir determinado objetivo.

Isso não significa que a IA tenha vontade própria ou consciência.

As decisões continuam ocorrendo dentro das regras, ferramentas, permissões e objetivos definidos pelo sistema.

O prompt continua sendo importante

Tudo o que aprendemos neste artigo continuará sendo utilizado.

Um agente também precisa receber:

• objetivos;

• contexto;

• regras;

• limites;

• critérios;

• instruções.

Mas agora surge um elemento novo:

a possibilidade de utilizar ferramentas e executar ações.

Por exemplo, um sistema poderia receber:

"Verifique meus compromissos de amanhã e prepare um resumo."

Para realizar essa tarefa, não basta apenas gerar texto.

O sistema precisaria:

1. compreender o objetivo;

2. acessar um calendário;

3. consultar os eventos;

4. interpretar os dados;

5. organizar as informações;

6. produzir o resumo.

Essa combinação entre modelo + instruções + ferramentas + processo de decisão abre uma nova etapa da nossa série.

No próximo artigo, veremos:

Artigo 4 — O que são Agentes de IA e como eles funcionam

Vamos entender:

• o que diferencia um agente de um chatbot;

• como um agente recebe objetivos;

• como ele escolhe ações;

• como utiliza ferramentas;

• como observa resultados;

• como memória e contexto participam do processo;

• quais são suas limitações;

• e por que agentes estão se tornando uma das principais aplicações práticas dos LLMs.

Neste artigo aprendemos que Prompt Engineering não é decorar frases prontas ou descobrir comandos secretos.

Seu objetivo é transformar uma intenção humana em instruções suficientemente claras para orientar um modelo de Inteligência Artificial.

Visão geral

Podemos resumir todo o processo assim:

INTENÇÃO DO USUÁRIO
        ↓
DEFINIÇÃO DO OBJETIVO
        ↓
CONTEXTO NECESSÁRIO
        ↓
INSTRUÇÕES
        ↓
PÚBLICO / NÍVEL
        ↓
FORMATO
        ↓
RESTRIÇÕES E CRITÉRIOS
        ↓
EXEMPLOS, SE NECESSÁRIO
        ↓
PROMPT
        ↓
LLM
        ↓
RESPOSTA
        ↓
AVALIAÇÃO
        ↓
REFINAMENTO

Os principais conceitos

Prompt e contexto não são iguais

Uma das distinções mais importantes deste artigo é:

Prompt

aquilo que você solicita ao modelo.

Contexto geral

todas as informações disponíveis ao modelo naquele processamento.

Portanto:

o prompt faz parte do contexto, mas o contexto pode ser muito maior do que o prompt.

A estrutura-base de um bom prompt

Podemos utilizar como referência:

OBJETIVO
O que quero que a IA faça?

CONTEXTO
O que ela precisa saber?

INSTRUÇÕES
Como deve executar?

PÚBLICO
Para quem é a resposta?

FORMATO
Como quero receber o resultado?

RESTRIÇÕES
Quais limites precisa respeitar?

EXEMPLOS
Existe um padrão que devo mostrar?

Nem todos os elementos são obrigatórios.

Tarefa simples não exige prompt complexo

Por exemplo:

"Traduza 'Good morning' para português."

já é suficientemente claro.

Não precisamos transformá-lo em um prompt enorme.

A complexidade da solicitação deve acompanhar a complexidade da tarefa.

Prompts estruturados

Para tarefas maiores, podemos organizar:

CONTEXTO:
[...]

OBJETIVO:
[...]

INSTRUÇÕES:
[...]

RESTRIÇÕES:
[...]

FORMATO:
[...]

DADOS:
[...]

Essa estrutura facilita leitura, manutenção e reutilização.

Zero-shot, One-shot e Few-shot

Podemos lembrar assim:

ZERO-SHOT
Instrução
↓
Resposta

ONE-SHOT
Instrução + 1 exemplo
↓
Resposta

FEW-SHOT
Instrução + alguns exemplos
↓
Resposta

Esses exemplos são utilizados no contexto atual e não significam que o modelo esteja sendo permanentemente treinado.

Tarefas complexas podem ser divididas

Uma estrutura útil é:

ANALISAR
   ↓
PLANEJAR
   ↓
EXECUTAR
   ↓
REVISAR

Essa abordagem permite controlar melhor o processo e corrigir problemas antes que eles afetem etapas posteriores.

Prompt Engineering é iterativo

O processo não termina quando enviamos o prompt:

CRIAR
  ↓
EXECUTAR
  ↓
AVALIAR
  ↓
REFINAR
  ↓
EXECUTAR NOVAMENTE

A própria resposta ajuda a identificar o que precisa ser melhorado.

E existem limites

Mesmo um excelente prompt não garante:

• resposta correta;

• ausência de alucinações;

• informações atualizadas;

• referências verdadeiras;

• código sem erros.

Portanto:

Prompt Engineering melhora as condições da tarefa, mas não elimina as limitações do modelo.

A melhor síntese deste capítulo talvez seja:

Um bom prompt não é aquele que possui mais palavras, mas aquele que fornece as informações certas para a tarefa certa.

1. O que é um prompt?

É a entrada fornecida ao modelo para orientar o que ele deve fazer.

Pode ser uma pergunta, instrução, tarefa, descrição, conjunto de dados ou combinação desses elementos.

2. Prompt é a mesma coisa que pergunta?

Não.

Uma pergunta pode ser um prompt, mas prompts também podem conter:

• instruções;

• dados;

• exemplos;

• regras;

• formatos;

• restrições.

3. O que é Prompt Engineering?

É a prática de estruturar, testar e melhorar prompts para orientar modelos de IA na execução de tarefas.

4. Prompt e contexto são a mesma coisa?

Não.

O prompt é a solicitação enviada ao modelo.

O contexto geral é todo o conjunto de informações disponível durante o processamento, podendo incluir o prompt, histórico, documentos, instruções do sistema, dados externos e resultados de ferramentas.

5. Quanto mais longo o prompt, melhor?

Não.

Um prompt deve conter as informações relevantes para a tarefa.

Texto desnecessário, repetitivo ou contraditório pode reduzir a clareza.

6. Todo prompt precisa ter contexto, público, formato e exemplos?

Não.

Esses elementos são ferramentas.

Utilize apenas aqueles que realmente ajudam a especificar a tarefa.

7. "Aja como especialista" melhora sempre a resposta?

Não.

Definir uma perspectiva pode ajudar a orientar foco e linguagem, mas não cria conhecimento novo nem garante precisão.

8. O que são restrições em um prompt?

São limites que precisam ser respeitados.

Por exemplo:

"Não altere a arquitetura."

"Não utilize bibliotecas externas."

9. O que são critérios?

São condições que a resposta deve atender.

Por exemplo:

"A solução deve permanecer compatível com PHP 8.3."

10. Para que servem exemplos?

Eles mostram concretamente ao modelo o padrão esperado.

São especialmente úteis em classificação, transformação, padronização e geração estruturada.

11. O que significa Zero-shot?

Executar uma tarefa sem fornecer exemplos.

12. O que significa One-shot?

Fornecer um exemplo da tarefa antes da nova entrada.

13. O que significa Few-shot?

Fornecer alguns exemplos para demonstrar o padrão esperado.

14. Few-shot é treinamento do modelo?

Não.

Os exemplos são normalmente utilizados dentro do contexto atual e não modificam permanentemente os parâmetros do LLM.

15. É melhor pedir tudo em um único prompt?

Depende.

Tarefas simples podem ser resolvidas diretamente.

Tarefas complexas frequentemente se beneficiam de divisão em etapas.

16. Posso melhorar a resposta depois que ela já foi gerada?

Sim.

Podemos continuar a conversa solicitando:

• correções;

• simplificações;

• exemplos;

• mudanças de formato;

• aprofundamentos;

• revisões.

17. Existe um prompt perfeito?

Não existe um prompt universalmente perfeito.

A qualidade depende da tarefa, do contexto, do modelo, das informações disponíveis e do resultado esperado.

18. Existem palavras mágicas para melhorar qualquer prompt?

Não.

Expressões específicas podem ajudar quando transmitem instruções úteis, mas não existe uma combinação secreta capaz de garantir respostas perfeitas.

19. Um bom prompt elimina alucinações?

Não.

Ele pode reduzir ambiguidades e melhorar o resultado, mas o modelo ainda pode gerar informações incorretas.

20. Como sei se meu prompt está bom?

Observe o resultado.

Pergunte:

• o objetivo foi atendido?

• as instruções foram seguidas?

• o formato está correto?

• existem erros?

• faltaram informações?

Prompt Engineering é um processo de criação, avaliação e refinamento.

21. Conversar com o ChatGPT de forma mais humana, como se fosse um amigo, pode prejudicar as respostas?

Em geral, não.

Você pode conversar com o ChatGPT de maneira natural, informal e até afetiva sem prejudicar automaticamente a qualidade das respostas.

Expressões como:

"Por favor"

"Obrigado"

"Meu amigo, me ajude com isso"

não tornam o modelo menos capaz.

O que realmente influencia a qualidade da resposta é principalmente a clareza da solicitação, o contexto fornecido, os critérios e as restrições da tarefa.

Por exemplo:

"Amigo, você pode analisar este código PHP 8.3 e identificar apenas erros que impeçam sua execução?"

continua sendo um prompt claro.

Você pode ser informal, educado e natural — desde que continue deixando claro o que deseja que a IA faça.

Exercício 1 — Conceito

Explique com suas palavras o que é um prompt.

Exercício 2 — Prompt e contexto

Explique a diferença entre:

prompt

e

contexto geral do modelo.

Exercício 3 — Objetivo

Qual dos prompts possui objetivo mais claro?

A) "Arduino."

B) "Fale de Arduino."

C) "Compare Arduino Uno e Mega 2560 destacando as diferenças para projetos com muitos pinos."

Explique sua escolha.

Exercício 4 — Contexto

Melhore:

"Qual placa devo usar?"

adicionando pelo menos três informações de contexto relevantes.

Exercício 5 — Público

Crie duas versões de um prompt pedindo uma explicação sobre corrente elétrica:

• uma para uma criança;

• outra para um estudante técnico.

Exercício 6 — Papel

Explique a diferença entre:

"Explique PWM."

e:

"Explique PWM como um professor de eletrônica para um iniciante."

Exercício 7 — Formato

Transforme:

"Compare ESP32 e Arduino Uno R4 WiFi."

em um prompt solicitando uma tabela com pelo menos cinco critérios.

Exercício 8 — Restrição e critério

Classifique cada frase como RESTRIÇÃO ou CRITÉRIO:

"Não utilize bibliotecas externas."

"O código deve permanecer compatível com PHP 8.3."

"Não altere o banco de dados."

"A resposta deve explicar cada alteração."

Exercício 9 — Exemplos

Crie um pequeno prompt de classificação utilizando três categorias e forneça um exemplo para cada uma.

Exercício 10 — Zero-shot, One-shot e Few-shot

Explique a diferença entre as três estratégias.

Exercício 11 — Prompt estruturado

Transforme:

"Revise meu código PHP."

em um prompt estruturado contendo:

• contexto;

• objetivo;

• restrições;

• formato da resposta.

Exercício 12 — Divisão de tarefas

Divida a tarefa:

"Analise, corrija e documente este sistema."

em pelo menos três etapas.

Exercício 13 — Refinamento

Imagine que a IA produziu uma explicação correta, porém técnica demais.

Escreva uma mensagem de refinamento adequada.

Exercício 14 — Identifique o problema

Analise:

"Explique detalhadamente como funciona o Transformer em apenas uma frase."

Existe algum conflito na solicitação? Explique.

Exercício 15 — Melhore o prompt

Reescreva:

"Faça meu texto melhor."

de modo que o modelo saiba exatamente o que deve melhorar.

Exercício 16 — Avaliação

Liste cinco perguntas que você utilizaria para avaliar se uma resposta da IA ficou boa.

Exercício 17 — Verdadeiro ou falso

Indique V ou F:

( ) Quanto maior o prompt, melhor será sempre a resposta.

( ) Exemplos podem ajudar o modelo a identificar um padrão.

( ) Few-shot modifica permanentemente os parâmetros do modelo.

( ) Restrições ajudam a limitar a tarefa.

( ) Prompt e contexto são exatamente a mesma coisa.

( ) Um prompt estruturado pode ser útil em tarefas complexas.

( ) Um bom prompt elimina totalmente as alucinações.

( ) A resposta deve ser avaliada depois de gerada.

📌 Respostas: as respostas comentadas destes exercícios serão reunidas no Caderno de Revisão da série IA na Prática, junto com fichas, mapas conceituais e materiais de consulta rápida.

Agora vamos juntar os principais conceitos deste artigo.

Imagine que você precisa utilizar uma IA para revisar um artigo técnico sobre Arduino destinado a leitores iniciantes.

O artigo já está escrito.

Seu objetivo é pedir que a IA:

• identifique trechos difíceis;

• encontre repetições;

• preserve as informações técnicas;

• não invente novos dados;

• mantenha o estilo do autor;

• sugira melhorias;

• não reescreva o artigo ainda.

Sua tarefa

Crie um prompt estruturado contendo, quando aplicável:

OBJETIVO

CONTEXTO

PAPEL / PERSPECTIVA

PÚBLICO

INSTRUÇÕES

CRITÉRIOS

RESTRIÇÕES

FORMATO DA RESPOSTA

Depois, explique por que cada elemento foi utilizado.

Desafio extra

Depois de criar seu prompt:

1. identifique quais partes são realmente indispensáveis;

2. remova qualquer informação desnecessária;

3. verifique se existem instruções contraditórias;

4. imagine uma possível resposta inadequada;

5. acrescente uma instrução que reduza o risco desse problema.

Por fim, responda:

Seu prompt ficou melhor porque ficou maior ou porque ficou mais claro?

A resposta esperada deve partir dos princípios estudados neste artigo.

📌 O gabarito comentado deste desafio também será incluído no Caderno de Revisão da série

1. Achar que prompt significa apenas pergunta

❌ Errado:

Prompt é simplesmente uma pergunta feita à IA.

✅ Certo:

Um prompt pode conter perguntas, instruções, dados, exemplos, regras, formatos e restrições.

2. Confundir prompt com contexto

❌ Errado:

Prompt e contexto são exatamente a mesma coisa.

✅ Certo:

O prompt é uma entrada fornecida ao modelo. O contexto geral pode incluir o prompt e diversas outras informações disponíveis durante o processamento.

3. Achar que o maior prompt é sempre o melhor

❌ Errado:

Quanto mais texto eu escrever, melhor será a resposta.

✅ Certo:

O importante é fornecer informações relevantes, claras e consistentes.

4. Usar contexto irrelevante

❌ Errado:

Quanto mais informações pessoais ou detalhes eu adicionar, melhor.

✅ Certo:

Inclua informações que realmente possam alterar ou melhorar a resposta.

5. Usar "aja como especialista" como solução para tudo

❌ Errado:

Basta dizer que a IA é especialista para garantir uma resposta correta.

✅ Certo:

Definir uma perspectiva pode orientar a resposta, mas não cria conhecimento nem garante precisão.

6. Usar objetivos vagos

❌ Errado:

"Melhore isso."

✅ Certo:

Defina o que significa melhorar: clareza, gramática, segurança, desempenho, organização ou outro critério.

7. Não definir o público quando ele influencia a resposta

❌ Errado:

Uma única explicação serve igualmente para qualquer pessoa.

✅ Certo:

Conhecimento prévio e público podem mudar linguagem, profundidade e exemplos.

8. Confundir restrição com critério

❌ Errado:

Restrição e critério significam exatamente a mesma coisa.

✅ Certo:

Restrição estabelece limites; critério define condições que o resultado deve atender.

9. Fornecer exemplos incorretos

❌ Errado:

Qualquer exemplo ajuda.

✅ Certo:

Exemplos ruins podem orientar o modelo para um padrão errado.

10. Achar que Few-shot significa treinar o LLM

❌ Errado:

Ao fornecer exemplos no prompt, estou alterando permanentemente o modelo.

✅ Certo:

Os exemplos normalmente são utilizados dentro do contexto atual, sem alterar permanentemente os parâmetros.

11. Transformar toda tarefa em um prompt gigantesco

❌ Errado:

Todo prompt profissional precisa ter contexto, papel, critérios, exemplos e várias seções.

✅ Certo:

Utilize apenas a complexidade necessária para a tarefa.

12. Não dividir tarefas muito complexas

❌ Errado:

Quanto mais coisas eu pedir em uma única mensagem, mais eficiente será.

✅ Certo:

Tarefas complexas podem ser mais controláveis quando divididas em etapas.

13. Reiniciar tudo quando apenas uma parte ficou ruim

❌ Errado:

Se uma seção não ficou boa, preciso fazer todo o pedido novamente.

✅ Certo:

Podemos utilizar refinamento para alterar somente aquilo que precisa ser corrigido.

14. Achar que formato correto significa conteúdo correto

❌ Errado:

Se o JSON está válido ou a tabela ficou bonita, a informação está correta.

✅ Certo:

Estrutura e veracidade precisam ser avaliadas separadamente.

15. Achar que pedir fontes garante fontes verdadeiras

❌ Errado:

Se eu pedir referências, todas serão necessariamente reais.

✅ Certo:

Referências importantes precisam ser verificadas em fontes confiáveis.

16. Criar instruções contraditórias

❌ Errado:

"Explique profundamente em apenas uma frase."

✅ Certo:

Objetivo, profundidade e formato devem ser compatíveis entre si.

17. Achar que Prompt Engineering elimina alucinações

❌ Errado:

Um prompt perfeito impede a IA de errar.

✅ Certo:

Bons prompts reduzem ambiguidades, mas não eliminam as limitações do LLM.

18. Não avaliar a resposta

❌ Errado:

Se a IA respondeu, a tarefa terminou.

✅ Certo:

Devemos verificar se objetivo, critérios, restrições, formato e precisão foram atendidos.

19. Procurar palavras mágicas

❌ Errado:

Existe uma frase secreta capaz de melhorar qualquer resposta.

✅ Certo:

Prompt Engineering funciona principalmente por meio de clareza, contexto relevante, critérios e boa especificação da tarefa.

20. Confundir fluência com qualidade

❌ Errado:

Uma resposta muito bem escrita deve estar correta.

✅ Certo:

Uma resposta pode ser fluente e convincente e ainda conter erros.

Com isso, concluímos o Artigo 3 da série IA na Prática.

O principal aprendizado pode ser resumido em uma única ideia:

Um bom prompt não tenta impressionar a IA. Ele descreve com clareza o problema que queremos que ela resolva.