Prompting per Gemini Omni: la sintassi a tag che Google documenta e nessuno cita

Quasi tutti i consigli sul prompting di Omni pubblicati questa settimana sono inventati.

Il "framework a cinque elementi tratto dalla documentazione ufficiale di Google" che una mezza dozzina di guide cita non sta su nessuna pagina Google che siamo riusciti a trovare, e le guide che lo citano non concordano nemmeno sul fatto che gli elementi siano cinque o sei. Anche l'affermazione che mettere il dialogo tra virgolette faccia passare il modello in una modalità di lip-sync non compare in nessun documento Google — le virgolette compaiono negli esempi di Google solo per il testo renderizzato sullo schermo.

Quello che Google documenta davvero è più utile e non l'ha scritto quasi nessuno: una sintassi a tag che permette a un solo prompt di rivolgersi a immagini e clip specifiche chiamandole per nome. È da lì che parte questa guida.

Due note su ciò che segue

Tutto quello che qui è citato viene dalle pagine di Google — la sezione sulla guida ai prompt della documentazione API di Gemini Omni, e la guida al prompting condivisa che copre insieme Omni e Veo. Dove Google tace, lo diciamo invece di riempire il vuoto con qualcosa che suoni autorevole.

Le clip qui sotto sono state generate con Veo 3.1 Fast sulla nostra API, non con Omni. Gemini Omni 1.1 Flash non è ancora su E2X, e non illustreremo una guida con girato di un modello facendolo passare per un altro. Le tecniche che dimostrano — vocabolario di camera, l'istruzione a inquadratura singola, la direzione del suono — vengono dalla guida ai prompt che Google pubblica per entrambi i modelli, quindi si trasferiscono. La sintassi a tag della sezione successiva no: quella parte è solo di Omni, e la mostriamo come sintassi e non come output.

La sintassi a tag

Omni accetta tag inline che puntano a input specifici. È la parte della documentazione con la minore copertura da parte di terzi e con più da guadagnare a leggerla.

Per i frame:

<FIRST_FRAME> a woman is walking

<LAST_FRAME> segna il frame su cui atterrare, e Google è esplicita sul fatto che "deve essere usato con" <FIRST_FRAME>. Quando un prompt diventa abbastanza complicato da rendere ambigua la posizione, esiste una forma di dichiarazione esplicita:

[# Sources <FIRST_FRAME>@Image1 <LAST_FRAME>@Image2]

Punti entrambi i tag sulla stessa immagine e ottiene un loop. Google lo documenta direttamente — la clip torna al punto da cui è partita:

[# Sources <FIRST_FRAME>@Image1 <LAST_FRAME>@Image1]

Per le reference, i tag sono numerati e partono da zero:

in the style of <IMAGE_REF_0> a woman <IMAGE_REF_1> is walking

Quella singola riga prende lo stile da un'immagine e il soggetto da un'altra. L'equivalente video è <VIDEO_REF_0>, anch'esso indicizzato da zero, con un limite netto: "i riferimenti video supportano un massimo di 3 clip, fino a 3 secondi ciascuna", e qualsiasi audio in una clip di riferimento viene ignorato.

Il modo in cui questo fallisce è che il modello tratta una reference come un frame di apertura letterale. La soluzione di Google è un'istruzione da appendere al prompt:

Use the given image(s) as references for video generation.
The images should not be used as literal initial frames.

Un confine da conoscere prima di progettarci intorno: "il riferimento o il ragionamento attraverso più video non è supportato." Più riferimenti immagine vanno benissimo — l'esempio di Google stesso ne usa sei — ma il prompting multi-video degrada.

Omni taglia la Sua clip in più inquadrature, a meno che non lo fermi

È la riga più sorprendente della documentazione, e spiega molto output confuso:

"Per impostazione predefinita Omni Flash proverà a creare un video con qualche inquadratura diversa. Tenterà di costruire una narrazione interessante a partire dal prompt. Se ha bisogno che il video in output contenga una scena sola, deve chiederlo esplicitamente nel prompt"

Chieda otto secondi di una persona che attraversa una porta e può ricevere tre stacchi. Il modello non La sta fraintendendo. Sta facendo ciò che fa di default.

La soluzione è una sola clausola, e Google ne dà tre formulazioni: "In a single unbroken scene", "In a single continuous shot", oppure "No scene cuts".

Ecco quell'istruzione al lavoro, con un movimento di camera documentato e una riga di suono attaccata:

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.

Quattro secondi, 720p, generati con Veo 3.1 Fast a un centesimo al secondo. Noti quanto poco di quel prompt sia fatto di aggettivi e quanto invece sia fatto di istruzioni su cui il modello può agire.

Il suono si dirige in frasi sue

L'audio è generato insieme all'immagine, e l'indicazione di Google è di descriverlo separatamente: "Consigliamo di usare frasi separate nel prompt per descrivere l'audio." La documentazione lo divide in tre — effetti sonori, rumore d'ambiente e dialogo — con esempi distinti per ciascuno.

È sul dialogo che il folklore sbaglia. La convenzione documentata è due punti e niente virgolette:

the man in the red hat says: Where is the rabbit?

L'esempio più lungo di Google mette due parlanti in un solo prompt e chiude con l'ambiente:

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

Gli esempi di Omni fanno precedere l'audio non parlato da Sound design:, come in "Sound design: Gentle breeze, distant bird chirps. No dialogue." E quando vuole della musica in particolare, lo dica: Google segnala questo come il caso che più probabilmente viene dimenticato — "Questo è particolarmente importante se vuole musica nel Suo video".

Due vincoli su cui progettare: l'editing della voce non è supportato, e "il caricamento di riferimenti audio non è supportato nella versione attuale dell'API". Il suono lo dirige a parole, o non lo dirige affatto.

I timecode funzionano, e si riazzerano quando estende

Il timing non richiede una sintassi speciale — "non serve una sintassi precisa e può usare il linguaggio naturale", quindi "At 5s the chorus starts in the background audio" è un'istruzione valida. Esiste anche una forma di timecode tra parentesi quadre:

[0-3s] A person is walking
[3-6s] They stop and turn around
[6-10s] They start running

Ora la trappola, ed è una trappola vera. Quando estende una clip esistente, 0s non significa più l'inizio del video. Significa l'inizio dell'estensione. Google lo scrive nero su bianco:

"Se usa timestamp o una sintassi a timecode, 0s si riferisce all'inizio della parte estesa del video. Se sta estendendo un video di 10s, lo stacco di scena in questo prompt avverrà dopo 12s"

Quindi After 2s cut to a new scene atterra al dodicesimo secondo del pezzo finito. Chi costruisce una scaletta di inquadrature su timecode assoluti sbaglierà questa cosa una volta, e poi mai più.

Già che ci siamo: i prompt di estensione dovrebbero descrivere la continuazione, non ridire tutta la scena. Le forme suggerite da Google sono brevi come "Extend this video" o "The scene continues", con aggiunte solo dove qualcosa cambia — "The music continues into the chorus" per l'audio, "Show the same characters in the next scene" per uno stacco. L'estensione accoda soltanto: non può anteporre né innestare nel mezzo.

L'editing vuole meno parole, non di più

Tutto quello che precede premia il dettaglio. L'editing lo ribalta: "I prompt semplici funzionano meglio per l'editing video. Prompt eccessivamente descrittivi possono portare a modifiche indesiderate."

Google pubblica le sue coppie prima-e-dopo, e vale la pena leggerle come uno schema più che come due esempi:

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.

La clausola che fa il lavoro in entrambi i casi è "Keep everything else the same", che Google consiglia di includere ogni volta che modifica un solo aspetto di un'inquadratura. Ogni dettaglio in più che fornisce è un'altra cosa che il modello potrebbe decidere di rigenerare.

L'image-to-video va di nuovo nella direzione opposta: "Prompt vaghi come 'fallo muovere' producono risultati meno convincenti di descrizioni dettagliate del movimento di camera, del movimento del soggetto e degli effetti ambientali." Dettaglio per la generazione, brevità per l'editing.

Le parole di camera che Google nomina davvero

Google pubblica un elenco di vocabolario, che è più affidabile dei termini che circolano nei thread di consigli sui prompt. I movimenti che nomina: statico, pan, tilt, dolly in e out, truck a sinistra e a destra, pedestal su e giù, zoom, crane, aereo o drone, camera a mano, whip pan, arc. Le angolazioni: a livello d'occhio, dal basso, dall'alto, a volo d'uccello, a raso terra, olandese, primo piano e primissimo piano, mezzo busto, figura intera, campo largo o d'ambientazione, sopra la spalla, soggettiva. Gli effetti ottici: grandangolo, teleobiettivo, profondità di campo ridotta e profonda, lens flare, rack focus, fisheye, e l'effetto vertigine — il dolly zoom.

Google distingue anche esplicitamente lo zoom dal dolly, perché i modelli li confondono: uno zoom cambia la lunghezza focale, e "Questo è diverso da un dolly, perché la camera stessa non si muove."

Si porti dietro però la cautela che Google ripete due volte: "Alcune angolazioni di camera avanzate non sono ufficialmente supportate. I risultati e l'affidabilità possono variare a seconda del prompt complessivo e del Suo caso d'uso specifico." Nominare un movimento è una richiesta, non una garanzia.

Ecco un arc shot, uno dei movimenti documentati, chiesto in modo semplice:

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.

Anche i termini cinematografici e di montaggio sono documentati — match cut, jump cut, sequenza di inquadrature d'ambientazione, montaggio, effetto split diopter. Termini che potrebbe aver visto attribuiti a Google e che non stanno su nessuna delle due pagine: oner, push in e natural smartphone zoom.

Prompt negativi: due pagine Google si contraddicono

Omni non ha un parametro di prompt negativo. La documentazione API è netta: "Istruzioni di sistema, temperature, top_p, stop sequence e prompt negativi non sono supportati (può mettere i Suoi negativi nel prompt normale: ad esempio, 'Do not do X')."

E la guida ai prompt di Omni raccomanda esattamente quello, suggerendo "No dialogue", "No embellishments", "No extra sound effects".

La guida condivisa Omni-e-Veo di Google dice l'opposto sulla formulazione:

"Non consigliato: usare linguaggio istruttivo o parole come 'no' o 'non'. Per esempio, eviti prompt come 'niente muri' o 'non mostrare muri'. Consigliato: descriva ciò che non vuole vedere. Per esempio, 'muro, cornice'"

Non faremo finta di risolvere la contraddizione. La spiegazione più probabile è che la seconda pagina stia descrivendo il campo dedicato negativePrompt di Veo — che Omni non ha — mentre la pagina di Omni descrive i negativi in prosa, che è tutto ciò che Omni offre. Questa è un'inferenza, non qualcosa che Google afferma. In pratica: usi la formulazione della pagina di Omni per Omni, e se un negativo viene ignorato provi l'altra forma prima di dare per scontato che il modello non sappia farlo.

Un'altra contraddizione da riportare onestamente, visto che incide su ciò che può promettere a un cliente. La guida ai prompt di Omni dice che il modello renderizza il testo a schermo "in modo corretto e leggibile". La model card di DeepMind mette il "rendere testo perfettamente accurato" tra le cose che "restano una sfida". Sono entrambe Google. Testi prima di impegnarsi.

Una checklist che può usare davvero

Lavorando su quanto sopra, un prompt che rispetta il comportamento del modello di solito porta con sé:

1. Un'istruzione sul numero di inquadrature, perché il multi-shot è il default e probabilmente non è quello che vuole
2. Il soggetto e il suo movimento, in modo specifico — non "fallo muovere"
3. Un movimento di camera documentato, nominato dalla lista di Google
4. La luce: direzione, qualità, colore
5. Una frase separata per il suono, preceduta da Sound design: se non è dialogo
6. Il dialogo come speaker says: line, due punti, niente virgolette
7. Eventuali negativi come brevi clausole in prosa alla fine
8. Solo per le modifiche: tolga quasi tutto quanto sopra e aggiunga "Keep everything else the same"

Il riassunto della struttura fatto da Google è più lungo — soggetto, azione, scena, angolazione di camera, movimento di camera, obiettivo, stile visivo, elementi temporali, audio, termini cinematografici, negativi — con la rassicurazione che "Non serve usare tutti gli elementi in ogni prompt".

Dove far girare tutto questo oggi

Il prompting è un'abilità che si acquisisce sbagliando ripetutamente, il che rende il prezzo per fallimento il numero che conta di più. Un test da quattro secondi su Veo 3.1 Fast costa quattro centesimi. Lo stesso test su Gemini Omni 1.1 Flash, live qui dal 28 agosto 2026 a nove centesimi al secondo, ne costa trentasei — o circa dodici se lo abbozza prima a 360p, che è il tier aggiunto dalla release 1.1 esattamente per questo. Nell'arco di un pomeriggio passato a scoprire dove un'istruzione di camera smette di essere rispettata, quella differenza decide quante volte può permettersi di sbagliare.

Quindi si alleni sulla metà trasferibile spendendo poco — numero di inquadrature, vocabolario di camera, direzione del suono, negativi — che vengono tutti dalla guida che Google pubblica per entrambi i modelli. Entrambe le clip qui sopra sono state fatte esattamente così. Salga alla famiglia Omni quando Le serve ciò che solo lei sa fare: la sintassi a tag, l'estensione e la coerenza guidata da reference. Una nota sui tag di frame a cui questa guida dedica più spazio: ora hanno un endpoint tutto loro, start-end-frame-to-video, che prende i due frame come campi, e image-to-video fa lo stesso per un singolo fermo immagine di apertura. Lungo la strada Veo 3.1 Fast coprirà comunque la pratica di image-to-video e primo e ultimo frame. Tariffe correnti al 28 agosto 2026.

Abbiamo scritto a parte cosa è uscito con la 1.1 e cosa dicono davvero le classifiche a riguardo. Sfogli per job da text-to-video, oppure legga la spec leggibile da macchina se preferisce fare il diff dei parametri invece di leggere prosa.

I prezzi e le condizioni di prodotto possono cambiare. Verifichi il pricing corrente di ogni provider prima di prendere una decisione d'acquisto.

Domande frequenti

Come si scrive un prompt per Gemini Omni 1.1 Flash?

Indichi per prima cosa il numero di inquadrature, perché Omni di default produce più inquadrature e di solito ne vuole una. Poi descriva il soggetto e il suo movimento, un movimento di camera nominato e la luce. Metta l'audio in una frase sua, preceduta da "Sound design:" se non è parlato, e scriva il dialogo come "speaker says: line", con i due punti e senza virgolette. Aggiunga eventuali negativi come brevi clausole in fondo.

Che cos'è il tag FIRST_FRAME in Gemini Omni?

È un tag inline che dice a Omni di usare un'immagine fornita come frame di apertura, scritto come il tag seguito dalla Sua descrizione. Il suo compagno LAST_FRAME segna il frame su cui finire e, secondo la documentazione di Google, va usato insieme a FIRST_FRAME. Puntare entrambi i tag sulla stessa immagine produce una clip in loop.

Gemini Omni supporta i prompt negativi?

Non come parametro. La documentazione API di Google afferma che i prompt negativi non sono supportati e Le dice di mettere i negativi nel prompt normale, per esempio "Do not do X". La guida ai prompt di Omni suggerisce brevi clausole come "No dialogue" o "No extra sound effects". La guida condivisa Omni e Veo di Google sconsiglia quella formulazione, il che sembra descrivere il campo di prompt negativo separato di Veo e non Omni.

Perché Gemini Omni aggiunge stacchi di scena che non ho chiesto?

Perché le inquadrature multiple sono il default. La documentazione di Google dice che Omni proverà a creare un video con più inquadrature e a costruire una narrazione a partire dal Suo prompt, a meno che non gli venga detto diversamente. Aggiungere "In a single continuous shot" o "No scene cuts" al prompt è la soluzione documentata.

Come funzionano i timestamp quando si estende un video Omni?

Si riazzerano. Una volta che estende una clip, 0s si riferisce all'inizio dell'estensione e non all'inizio dell'originale. L'esempio di Google: estendendo un video di 10 secondi con un'istruzione a 2s, quel momento finisce a 12 secondi nel pezzo finito. L'estensione accoda soltanto — non può anteporre contenuto né modificare la parte centrale di una clip.

Il dialogo va messo tra virgolette per Gemini Omni?

No. La forma documentata da Google è "speaker says: line" — due punti, senza virgolette. L'affermazione ampiamente ripetuta che le virgolette attivino una modalità di lip-sync non compare in nessuna documentazione Google. Le virgolette compaiono negli esempi di Google solo per il testo destinato a essere renderizzato a schermo, ed è probabilmente da lì che è nata la confusione.

Quanto costa fare pratica con il prompting di Omni?

Sulla nostra API Gemini Omni 1.1 Flash gira a $0.09 al secondo a 720p, quindi un test da quattro secondi è $0.36, o circa $0.12 se abbozza a 360p, al 28 agosto 2026. Veo 3.1 Fast costa $0.01 al secondo, il che porta lo stesso test a quattro centesimi. Dato che le tecniche di camera, numero di inquadrature e audio vengono dalla guida ai prompt che Google pubblica per entrambi i modelli, fare pratica su quello più economico costa un nono e allena le stesse abitudini.