Prompts para Gemini: como escrever pedidos que geram respostas melhores

Fala aí, beleza? Prompt ruim quase nunca é limite do modelo, é o pedido que saiu curto e vago demais

E tem número disso: segundo o guia oficial do Google para o Gemini no Workspace, os prompts com maior taxa de sucesso no programa Workspace Labs tinham em média 21 palavras, enquanto a maioria dos usuários escreve menos de nove palavras

Sentiu a distância? 😀

Neste post tu vai ver a estrutura de quatro áreas que o próprio Google recomenda, as camadas que entram POR CIMA dela (exemplos, padronização e corte), o papel do contexto dentro do pedido, e um comparativo linha a linha entre um prompt vago e um prompt bem montado

A diferença aparece na resposta, sem fórmula mágica nenhuma

O que você precisa antes de começar

A lista é curta, mas tem duas fronteiras que pegam muita gente de surpresa quando a ideia é reaproveitar prompt:

• acesso ao Gemini, no app ou na API (é onde tu vai escrever e testar)
• para Gems personalizados: criar, editar e excluir só é possível no app web do Gemini, embora os Gems possam ser usados no web e no mobile
• para instruções permanentes: o recurso de instruções personalizadas (chamado ‘Saved info’ em algumas regiões) exige login com Conta do Google pessoal, e não funciona em conta corporativa, escolar ou supervisionada

E tem uma nota que não é bem de prompt, mas atrapalha a análise: a linha de modelos do Gemini anda rápido, e cada modelo tem um comportamento padrão diferente de verbosidade

Vale saber com qual modelo tu está falando antes de culpar o prompt, beleza?

Formação Recomendada

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

• 474 aulas
• 20 projetos
• 39h 27min

Conhecer formação

Como escrever um prompt para o Gemini passo a passo

O guia oficial do Google para o Gemini no Workspace organiza um bom prompt em quatro áreas: Persona, Tarefa, Contexto e Formato

Se tu já montou um briefing pra alguém do time, é bem parecido: quem está fazendo, o que precisa ser feito, com quais informações e em qual formato entrega

Bora montar do zero?

1. Defina a Persona

Diga de qual cadeira o modelo está respondendo, tipo ‘Você é um gerente de programa do Google Cloud’

O erro comum deste passo é achar que persona é enfeite: sem ela, a resposta sai no registro médio da internet, e não no registro de quem faria aquele trabalho de verdade

2. Escreva a Tarefa como instrução clara e específica

A documentação oficial de estratégias de prompt do Gemini recomenda justamente isso: instrução explícita, sem espaço pra interpretação

O erro comum aqui é o verbo genérico (‘melhore isso’, ‘fale sobre X’), que deixa o modelo escolher o recorte por conta própria

3. Cole o Contexto dentro do próprio prompt

A mesma documentação recomenda incluir a informação de contexto no prompt, pra o modelo entender as restrições da tarefa

É o que muda de figura: em vez de ‘escreva um resumo’, tu entrega o material, o público, o prazo e o que não pode aparecer

O erro comum deste passo é esperar que o modelo adivinhe restrição que só existe na tua cabeça

Quando o contexto é um monte de documento em vez de um parágrafo colado, a lógica de pedido muda um pouco, e eu já destrinchei isso em como escrever prompt para o NotebookLM

4. Declare o Formato de saída

Diga se é email, tabela, lista, e qual o limite, tipo ‘limite a bullet points’

O erro comum é deixar o formato implícito e depois reclamar que veio texto corrido quando tu queria tópicos

Até aqui fecharam as QUATRO áreas do guia do Workspace

O que vem dos passos 5 ao 7 não faz parte dessas quatro: são camadas extras que a documentação do Gemini recomenda por cima da estrutura, e é onde a maioria dos prompts ainda vaza

5. Inclua exemplos (few-shot) com formato idêntico entre si

A documentação do Google recomenda sempre incluir exemplos, principalmente pra mostrar ao modelo o formato de resposta esperado, mantendo o formato consistente entre todos os exemplos

E tem um detalhe fino: os exemplos precisam vir acompanhados de instrução clara, senão o modelo capta padrões que tu não pediu

O erro comum deste passo é misturar exemplos com estruturas diferentes e esperar consistência na saída

Essa régua, aliás, não é exclusividade do Google: ela vale igual pra quem está montando prompts para o Grok

6. Padronize a estrutura e defina termos ambíguos

A documentação do Gemini 3 recomenda manter estrutura uniforme no prompt (por exemplo, tags XML padronizadas) e definir explicitamente os termos ambíguos

Se tu escreve ‘resumo executivo’, diga o que isso significa pra ti: quantos blocos, pra quem, com qual nível de detalhe

O erro comum é usar jargão interno da empresa como se fosse vocabulário universal

7. Enxugue no fim

O guia de desenvolvedor do Gemini 3 afirma que o modelo responde melhor a instruções diretas e concisas, e que pode ‘superanalisar’ técnicas de engenharia de prompt verbosas herdadas de modelos antigos

O mesmo guia diz que, por padrão, o modelo é menos verboso e entrega respostas diretas, então resposta mais conversacional precisa ser pedida explicitamente

O erro comum deste passo é empilhar camada de técnica velha achando que quanto maior o prompt, melhor a resposta

Juntando tudo, o pedido fica mais ou menos assim:

<persona>
Você é um gerente de programa do Google Cloud
</persona>

<tarefa>
Escreva um resumo executivo por email para a liderança de produto
com base nos documentos abaixo
</tarefa>

<contexto>
O leitor não acompanhou o projeto de perto
O email será lido no celular, antes de uma reunião
(cole aqui os documentos ou os pontos do projeto)
</contexto>

<formato>
Limite a bullet points
Um bullet por decisão tomada, na ordem em que aconteceram
</formato>

<exemplo>
- Decisão: (o que foi decidido). Impacto: (efeito prático)
</exemplo>

Repare que não tem prompt secreto ali, só as quatro áreas preenchidas com informação que só tu tinha, mais as camadas de exemplo e padronização por cima 🙂

Antes e depois: o mesmo pedido, vago e bem montado

Usando o exemplo do guia oficial (gerente de programa do Google Cloud escrevendo um resumo executivo por email, limitado a bullet points), dá pra ver elemento por elemento o que cada linha adicionada passa a especificar

As quatro primeiras linhas são as quatro áreas do guia, e as duas últimas são as camadas extras da documentação do Gemini:

O ganho não é mágico: é que a versão da direita tirou da resposta todas as escolhas que o modelo estava fazendo sozinho

Erros comuns em prompts do Gemini e como corrigir

Resposta genérica, cara de post de internet

Sintoma: veio um texto correto e inútil, que serviria pra qualquer empresa

Causa: falta de contexto no prompt

Correção: a documentação recomenda incluir a informação contextual dentro do próprio prompt, então cole material, público e restrição no lugar de descrever de longe

O formato sai errado toda vez

Sintoma: tu queria bullet points e recebeu três parágrafos

Causa: formato de saída não declarado

Correção: escreva o formato como instrução, tipo ‘limite a bullet points’, e não deixe o modelo adivinhar a estrutura da saída

O modelo copia um padrão que você não pediu

Sintoma: a resposta imita um detalhe estranho do teu exemplo, tipo o tamanho da frase ou a ordem dos campos

Causa: exemplos sem instrução clara, ou exemplos com formatos diferentes entre si

Correção: mantenha o formato idêntico entre todos os exemplos e sempre acompanhe os exemplos de uma instrução explícita

Resposta curta demais

Sintoma: tu esperava explicação e veio um resumo seco

Causa: no Gemini 3, o padrão é resposta direta e menos verbosa

Correção: peça a verbosidade extra de forma explícita no prompt, dizendo que quer tom conversacional ou explicação passo a passo

O resultado piorou depois que você encheu o prompt de técnica

Sintoma: o prompt cresceu, a resposta ficou pior

Causa: o guia de desenvolvedor do Gemini 3 diz que o modelo pode superanalisar técnicas de engenharia de prompt verbosas, herdadas de modelos antigos

Correção: corte camada por camada até sobrar instrução precisa e concisa

Na API, loop ou degradação depois de baixar a temperatura

Sintoma: saída repetitiva ou pior em tarefa de raciocínio e matemática

Causa: para os modelos Gemini 3 na API, o Google recomenda manter a temperatura no padrão 1.0, e reduzir esse valor pode causar loops ou degradação

Correção: deixe a temperatura em 1.0 e busque determinismo por instrução de sistema explícita, não por ajuste de parâmetro

Como prevenir tudo isso de uma vez? Antes de mandar, releia o prompt caçando as quatro áreas e, depois, as camadas extras: se alguma estiver faltando, tu já sabe qual reclamação vai aparecer na resposta 😛

Quando vale transformar o prompt em Gem ou instrução salva

Tem um ponto em que reescrever o mesmo prompt toda semana vira desperdício

Se a tarefa se repete com a MESMA persona e o mesmo formato (relatório semanal, resposta padrão de suporte, revisão de texto no teu estilo), esse prompt merece virar um Gem personalizado

No app Gemini, os Gems são criados em gemini.google.com clicando em ‘Explore Gems’ e depois em ‘New Gem’, informando nome e instruções, com possibilidade de anexar arquivos como contexto

E tem um atalho simpático ali: depois de escrever algumas palavras de instrução, existe a opção ‘Use Gemini to re-write instructions’, em que o próprio Gemini reescreve e expande o que tu digitou

Já quando a preferência vale pra TODA conversa (sempre um resumo curto no início, sempre bullet points), o lugar dela é o recurso de instruções salvas, que fica guardado até tu apagar

Lembrando a fronteira, pra não te ferrar no meio do caminho: criação, edição e exclusão de Gem só no app web, uso no web e no mobile

O que aprendi escrevendo prompts no dia a dia

Aqui é honestidade total: essa parte não é sobre o Gemini especificamente, é sobre qualidade de instrução e prompt reaproveitável, que é o que vale pra qualquer modelo

No vídeo eu mostro um pedido escrito com a frequência dentro dele: eu queria a rotina rodando todos os dias às 10 da manhã, em vez de descrever a tarefa solta e torcer

No mesmo pedido eu encadeei os passos em ordem: verificar se houve alteração no projeto, criar o commit semântico sobre essa alteração e enviar pro GitHub

E, o detalhe que eu mais gosto, eu defini o critério de qualidade da saída e não só a ação: o commit precisa declarar bem o que foi feito, a ponto de qualquer pessoa, mesmo sem ser técnica, conseguir ler e entender

A motivação foi bem prosaica: esquecimento

Se o envio pro repositório depender só de eu lembrar, ele às vezes não acontece 😅

Desde então eu separo por tipo de pedido: o que é rotina perpétua eu deixo agendado, e o que é ação repetitiva de curto prazo, ligada ao desenvolvimento de um projeto ou a uma exceção específica, eu peço no chat

Se tu tem esse tipo de rotina, recomendo escrever o pedido nesse formato: frequência, passos encadeados e critério de qualidade explícito

Pra ver isso na prática, este vídeo do canal mostra os prompts sendo escritos assim, com frequência, passos em ordem e critério de qualidade dentro do próprio pedido:

Próximo passo

Pega o último prompt vago que tu usou, aquele de uma linha

Reescreve ele nas quatro áreas (Persona, Tarefa, Contexto e Formato), adiciona um exemplo do formato que tu quer e compara as duas respostas lado a lado

O antes e depois costuma ser bem escancarado 😀

E se aquela tarefa se repete toda semana, não digita de novo: salva como Gem e segue a vida

Até o próximo post!