Prompting no Gemini Omni: a sintaxe de tags que o Google documenta e ninguém cita
A maior parte dos conselhos de prompting para o Omni publicados esta semana é inventada.
O "framework de cinco elementos da documentação oficial do Google" que meia dúzia de guias cita não está em nenhuma página do Google que conseguimos encontrar, e os guias que o citam não concordam sobre se são cinco elementos ou seis. A alegação de que colocar diálogo entre aspas coloca o modelo num modo de lip-sync também não está em documento nenhum do Google — aspas aparecem nos exemplos do Google apenas para texto renderizado na tela.
O que o Google de fato documenta é mais útil e quase ninguém escreveu sobre: uma sintaxe de tags que permite a um único prompt endereçar imagens e clipes específicos pelo nome. É daí que este guia parte.
Duas observações sobre o que vem a seguir
Tudo que está citado aqui vem das próprias páginas do Google — a seção de guia de prompt da documentação da API do Gemini Omni e o guia de prompting compartilhado que cobre Omni e Veo juntos. Onde o Google se cala, dizemos isso em vez de preencher a lacuna com algo que soe autoritativo.
Os clipes abaixo foram gerados com o Veo 3.1 Fast na nossa própria API, não com o Omni. O Gemini Omni 1.1 Flash ainda não está na E2X, e não vamos ilustrar um guia com imagens de um modelo fingindo que vieram de outro. As técnicas que eles demonstram — vocabulário de câmera, a instrução de plano único, direção de som — vêm do guia de prompt que o Google publica para os dois modelos, então elas transferem. A sintaxe de tags da próxima seção não: essa parte é exclusiva do Omni, e a mostramos como sintaxe, não como resultado.
A sintaxe de tags
O Omni aceita tags inline que apontam para entradas específicas. É a parte da documentação com menos cobertura de terceiros e com mais a ganhar na leitura.
Para frames:
<FIRST_FRAME> a woman is walking
<LAST_FRAME> marca o frame em que se deve aterrissar, e o Google é explícito que ele "deve ser usado com" <FIRST_FRAME>. Quando um prompt fica complicado a ponto de a posição virar ambígua, existe uma forma de declaração explícita:
[# Sources <FIRST_FRAME>@Image1 <LAST_FRAME>@Image2]
Aponte as duas tags para a mesma imagem e você obtém um loop. O Google documenta isso diretamente — o clipe volta para onde começou:
[# Sources <FIRST_FRAME>@Image1 <LAST_FRAME>@Image1]
Para referências, as tags são numeradas e começam em zero:
in the style of <IMAGE_REF_0> a woman <IMAGE_REF_1> is walking
Essa única linha puxa estilo de uma imagem e sujeito de outra. O equivalente em vídeo é <VIDEO_REF_0>, também indexado a partir de zero, com um limite rígido: "Referências de vídeo suportam no máximo 3 clipes, de até 3 segundos cada", e qualquer áudio num clipe de referência é ignorado.
O modo de falha aqui é o modelo tratar uma referência como frame de abertura literal. A correção do Google é uma instrução acrescentada ao prompt:
Use the given image(s) as references for video generation.
The images should not be used as literal initial frames.
Um limite que vale conhecer antes de projetar em cima dele: "Referenciar ou raciocinar através de múltiplos vídeos não é suportado." Múltiplas referências de imagem são tranquilas — o próprio exemplo do Google usa seis delas — mas o prompting com múltiplos vídeos degrada.
O Omni corta seu clipe em vários planos, a menos que você impeça
Essa é a linha mais surpreendente da documentação, e ela explica um bocado de resultado confuso:
"Por padrão o Omni Flash vai tentar criar um vídeo com alguns planos diferentes. Ele vai tentar construir uma narrativa interessante com base no prompt. Se você precisa que o vídeo de saída contenha uma cena única, precisa pedir isso no prompt"
Peça oito segundos de uma pessoa atravessando uma porta e você pode receber três cortes disso. O modelo não está te interpretando errado. Ele está fazendo o padrão dele.
A correção é uma oração, e o Google dá três formulações: "Em uma cena única e ininterrupta", "Em um plano único e contínuo" ou "Sem cortes de cena".
Aqui está essa instrução fazendo seu trabalho, com um movimento de câmera documentado e uma linha de som anexada:
In a single continuous shot, no scene cuts. Slow dolly in on a battered
enamel coffee pot sitting on a cast-iron stove in a dim cabin kitchen.
Steam rises and catches a hard shaft of morning light from a window to the
left. Medium shot, shallow depth of field, warm amber and deep green
palette. Sound design: the low hiss of steam and a wood fire ticking.
No dialogue.
Quatro segundos, 720p, gerado com o Veo 3.1 Fast a um centavo por segundo. Repare em quão pouco desse prompt são adjetivos e em quanto dele são instruções sobre as quais o modelo pode agir.
O som é dirigido em frases próprias
O áudio é gerado junto com a imagem, e a orientação do Google é descrevê-lo separadamente: "Recomendamos que você use frases separadas no seu prompt para descrever o áudio." A documentação divide isso em três: efeitos sonoros, ruído ambiente e diálogo — com exemplos distintos para cada um.
Diálogo é onde o folclore erra. A convenção documentada é dois-pontos e nenhuma aspa:
the man in the red hat says: Where is the rabbit?
O exemplo mais longo do Google usa dois interlocutores num prompt só e fecha com a ambiência:
A medium shot in a dimly lit interrogation room. The seasoned detective
says: Your story has holes. The nervous informant, sweating under a single
bare bulb, replies: I'm telling you everything I know. The only other
sounds are the slow, rhythmic ticking of a wall clock and the faint sound
of rain against the window
Os próprios exemplos do Omni prefixam o áudio que não é fala com Sound design:, como em "Sound design: Gentle breeze, distant bird chirps. No dialogue." E quando você quer música especificamente, diga — o Google sinaliza esse como o caso mais provável de ser esquecido: "Isso é especialmente importante se você quer música no seu vídeo".
Duas restrições para projetar em torno: edição de voz não é suportada, e "Subir referências de áudio não é suportado na versão atual da API". Você dirige som com palavras ou não dirige.
Timecodes funcionam, e eles se rebaseiam quando você estende
Tempo não precisa de sintaxe especial — "não há sintaxe precisa necessária e você pode usar linguagem natural", então "Aos 5s o refrão começa no áudio de fundo" é uma instrução válida. Existe também uma forma de timecode entre colchetes:
[0-3s] A person is walking
[3-6s] They stop and turn around
[6-10s] They start running
Agora a armadilha, e ela é real. Quando você estende um clipe existente, 0s deixa de significar o início do vídeo. Passa a significar o início da extensão. O Google diz com todas as letras:
"Se estiver usando timestamps ou uma sintaxe de timecode, 0s se refere ao começo da parte estendida do vídeo. Se estiver estendendo um vídeo de 10s, o corte de cena neste prompt vai acontecer depois de 12s"
Então After 2s cut to a new scene cai na marca dos doze segundos da peça finalizada. Quem estiver montando uma decupagem contra timecodes absolutos vai errar isso uma vez e nunca mais.
Já que você está por aqui: prompts de extensão devem descrever a continuação, não repetir a cena inteira. As formas sugeridas pelo Google são tão curtas quanto "Estenda este vídeo" ou "A cena continua", com acréscimos só onde algo muda — "A música continua no refrão" para áudio, "Mostre os mesmos personagens na cena seguinte" para um corte. A extensão apenas acrescenta ao fim; você não pode prefixar nem inserir no meio.
Edição quer menos palavras, não mais
Tudo acima recompensa detalhe. A edição inverte isso: "Prompts simples funcionam melhor para edição de vídeo. Prompts excessivamente descritivos podem levar a mudanças não intencionais."
O Google publica seus próprios pares de antes e depois, e vale ler como padrão em vez de como dois exemplos:
Avoid: In the video of the man sitting on the sofa, please add a small
black cat that runs from the right side of the screen, jumps onto
his lap, and then he starts to stroke its head while looking down.
Simplify: Add a cat that jumps onto his lap, he begins to pet it.
Keep everything else the same.
Avoid: Please remove the cell phone that the person is holding in their
hand and fill in the background so it looks like they are just
holding their hand empty.
Simplify: Make the phone invisible. Keep everything else the same.
A oração que faz o trabalho nos dois casos é "Keep everything else the same", que o Google recomenda incluir sempre que você editar um aspecto de um plano. Cada detalhe extra que você fornece é mais uma coisa que o modelo pode decidir regerar.
O image-to-video corre no sentido contrário de novo: "Prompts vagos como 'faça se mover' produzem resultados menos convincentes que descrições detalhadas do movimento de câmera, do movimento do sujeito e dos efeitos ambientais." Detalhe para geração, brevidade para edição.
As palavras de câmera que o Google de fato nomeia
O Google publica uma lista de vocabulário, o que é mais confiável que os termos que circulam em threads de dicas de prompt. Movimentos que ele nomeia: estático, pan, tilt, dolly para dentro e para fora, truck para a esquerda e para a direita, pedestal para cima e para baixo, zoom, grua, aéreo ou drone, câmera na mão, whip pan, arco. Ângulos: na altura dos olhos, baixo, alto, olho de pássaro, olho de verme, holandês, close e close extremo, plano médio, plano inteiro, geral ou de apresentação, por cima do ombro, ponto de vista. Efeitos ópticos: grande-angular, teleobjetiva, profundidade de campo rasa e profunda, lens flare, rack focus, olho de peixe e o efeito vertigem — o dolly zoom.
O Google também distingue zoom de dolly explicitamente, porque os modelos confundem os dois: um zoom muda a distância focal, e "Isso é diferente de um dolly, já que a câmera em si não se move."
Carregue a ressalva que o Google enuncia duas vezes, no entanto: "Alguns ângulos de câmera avançados não são oficialmente suportados. Os resultados e a confiabilidade podem variar dependendo do prompt como um todo e do seu caso de uso específico." Nomear um movimento é um pedido, não uma garantia.
Aqui está um plano em arco, um dos movimentos documentados, pedido de forma simples:
Slow arc shot travelling left around a weathered brass sextant resting on
an unrolled nautical chart on a scuffed wooden table. Low winter sunlight
rakes in from the right and the brass catches moving highlights as the
camera travels. Single continuous shot, no scene cuts, shallow depth of
field. Sound design: faint harbour ambience, rigging tapping in wind.
No dialogue.
Termos cinematográficos e de montagem também são documentados — match cut, jump cut, sequência de plano de apresentação, montagem, efeito de split diopter. Termos que você pode ter visto atribuídos ao Google e que não estão em nenhuma das duas páginas: oner, push in e natural smartphone zoom.
Prompts negativos: duas páginas do Google discordam
O Omni não tem parâmetro de prompt negativo. A documentação da API é direta: "Instruções de sistema, temperature, top_p, stop sequences e prompts negativos não são suportados (você pode colocar seus negativos no prompt normal: por exemplo, 'Do not do X')."
E o guia de prompt do Omni recomenda exatamente isso, sugerindo "No dialogue", "No embellishments", "No extra sound effects".
O guia compartilhado de Omni e Veo do Google diz o oposto sobre a formulação:
"Não recomendado: usar linguagem instrutiva ou palavras como 'não' ou 'sem'. Por exemplo, evite prompts como 'sem paredes' ou 'não mostre paredes'. Recomendado: descreva o que você não quer ver. Por exemplo, 'parede, moldura'"
Não vamos fingir que resolvemos isso. A explicação mais provável é que a segunda página está descrevendo o campo dedicado negativePrompt do Veo — que o Omni não tem — enquanto a página do Omni descreve negativos em prosa, que é tudo que o Omni oferece. Isso é inferência, não algo que o Google afirme. Na prática: use a formulação da página do Omni para o Omni e, se um negativo estiver sendo ignorado, tente a outra forma antes de assumir que o modelo não consegue.
Mais uma contradição honesta, já que ela afeta o que você pode prometer a um cliente. O guia de prompt do Omni diz que o modelo renderiza texto na tela "de um jeito correto e legível". O model card da DeepMind lista "renderizar texto perfeitamente preciso" entre as coisas que "continuam sendo um desafio". Os dois são do Google. Teste antes de se comprometer.
Um checklist que você pode usar de verdade
Trabalhando a partir do acima, um prompt que respeita como o modelo se comporta normalmente carrega:
- Uma instrução de quantidade de planos, porque multi-plano é o padrão e provavelmente não é o que você quer
- O sujeito e o movimento dele, especificamente — não "faça se mover"
- Um movimento de câmera documentado, nomeado a partir da lista do Google
- Luz: direção, qualidade, cor
- Uma frase separada para som, prefixada com
Sound design:se não for diálogo - Diálogo como
speaker says: line, dois-pontos, sem aspas - Quaisquer negativos como orações curtas em prosa no fim
- Só para edições: tire quase tudo acima e acrescente "Keep everything else the same"
O resumo do próprio Google sobre a estrutura é mais longo — sujeito, ação, cena, ângulo de câmera, movimento de câmera, lente, estilo visual, elementos temporais, áudio, termos cinematográficos, negativos — com a garantia de que "Você não precisa usar todos os elementos em todo prompt".
Onde rodar isso hoje
Prompting é uma habilidade que se adquire falhando repetidamente, o que torna o preço por falha o número que mais importa. Um teste de quatro segundos no Veo 3.1 Fast custa quatro centavos. O mesmo teste no Gemini Omni 1.1 Flash, no ar aqui desde 28 de agosto de 2026 a nove centavos por segundo, custa trinta e seis — ou cerca de doze se você rascunhar antes em 360p, que é o tier que o release 1.1 acrescentou exatamente para isso. Ao longo de uma tarde aprendendo onde uma instrução de câmera deixa de ser obedecida, essa diferença decide quantas vezes você pode errar.
Então treine a metade transferível na base do barato — quantidade de planos, vocabulário de câmera, direção de som, negativos — tudo isso vem do guia que o Google publica para os dois modelos. Os dois clipes acima foram feitos exatamente assim. Suba para a família Omni quando você precisar do que só ela faz: a sintaxe de tags, a extensão e a consistência guiada por referência. Uma nota sobre as tags de frame às quais este guia dedica mais espaço: agora elas têm um endpoint próprio, o start-end-frame-to-video, que recebe os dois frames como campos, e o image-to-video faz o mesmo para uma única imagem parada de abertura. O Veo 3.1 Fast ainda cobre prática de image-to-video e de primeiro e último frame pelo caminho. Taxas atuais em 28 de agosto de 2026.
Escrevemos sobre o que saiu no 1.1 e sobre o que os rankings de fato dizem a respeito em separado. Navegue por tipo de trabalho a partir de text-to-video, ou leia a especificação legível por máquina se preferir dar diff em parâmetros a ler prosa.
Preços e termos de produto podem mudar. Verifique o preço atual de cada provedor antes de tomar uma decisão de compra.
Perguntas frequentes
Como escrever um prompt para o Gemini Omni 1.1 Flash?
Nomeie a quantidade de planos primeiro, porque o Omni produz múltiplos planos por padrão e você normalmente quer um só. Depois descreva o sujeito e o movimento dele, um movimento de câmera nomeado e a iluminação. Coloque o áudio na frase dele, prefixado com "Sound design:" para o que não é fala, e escreva diálogo como "speaker says: line", com dois-pontos e sem aspas. Acrescente quaisquer negativos como orações curtas no fim.
O que é a tag FIRST_FRAME no Gemini Omni?
É uma tag inline que diz ao Omni para usar uma imagem fornecida como frame de abertura, escrita como a tag seguida da sua descrição. A parceira dela, LAST_FRAME, marca o frame em que terminar e, segundo a documentação do Google, precisa ser usada em conjunto com FIRST_FRAME. Apontar as duas tags para a mesma imagem produz um clipe em loop.
O Gemini Omni suporta prompts negativos?
Não como parâmetro. A documentação da API do Google afirma que prompts negativos não são suportados e diz para você colocar os negativos no prompt normal, como "Do not do X". O guia de prompt do Omni sugere orações curtas como "No dialogue" ou "No extra sound effects". O guia compartilhado de Omni e Veo do Google desaconselha essa formulação, o que parece descrever o campo separado de prompt negativo do Veo e não o Omni.
Por que o Gemini Omni acrescenta cortes de cena que eu não pedi?
Porque múltiplos planos são o padrão. A documentação do Google diz que o Omni vai tentar criar um vídeo com vários planos e construir uma narrativa a partir do seu prompt a menos que seja instruído do contrário. Acrescentar "In a single continuous shot" ou "No scene cuts" ao prompt é a correção documentada.
Como funcionam os timestamps ao estender um vídeo do Omni?
Eles se rebaseiam. Depois que você estende um clipe, 0s se refere ao início da extensão e não ao início do original. O exemplo do Google: estender um vídeo de 10 segundos com uma instrução aos 2s coloca aquele momento aos 12 segundos da peça finalizada. A extensão só acrescenta ao fim — você não pode prefixar conteúdo nem editar o meio de um clipe.
O diálogo deve ir entre aspas no Gemini Omni?
Não. A forma documentada pelo Google é "speaker says: line" — dois-pontos, sem aspas. A alegação amplamente repetida de que aspas disparam um modo de lip-sync não aparece em nenhuma documentação do Google. Aspas surgem nos exemplos do Google apenas para texto que deve ser renderizado na tela, que é provavelmente onde a confusão começou.
Quanto custa praticar prompting no Omni?
Na nossa API, o Gemini Omni 1.1 Flash roda a $0.09 por segundo em 720p, então um teste de quatro segundos sai por $0.36, ou cerca de $0.12 se você rascunhar em 360p, em 28 de agosto de 2026. O Veo 3.1 Fast custa $0.01 por segundo, o que torna o mesmo teste quatro centavos. Como as técnicas de câmera, quantidade de planos e áudio vêm do guia de prompt que o Google publica para os dois modelos, praticar no mais barato custa um nono e treina os mesmos hábitos.