Ricette di prompt text-to-image per Recraft v4.1 per sviluppatori

Perché le ricette di prompt battono i prompt usa-e-getta

Ogni team che chiama un'API text-to-image finisce prima o poi contro lo stesso muro: l'immagine che funzionava bene ha il suo prompt sepolto in una cronologia di chat, in uno script usa-e-getta o nell'app di note di qualcuno. Quando il requisito cambia—"stessa illustrazione, ma fotografica" oppure "aggiungi un titolo nell'immagine"—nessuno sa quali parole contavano davvero, così il prompt viene riscritto da zero e l'output inizia a variare in modo imprevedibile.

Le ricette di prompt risolvono il problema trattando il prompt come un piccolo documento parametrizzato. Uno scheletro, pochi blocchi sostituibili e una breve lista di vincoli. Cambiare stile diventa la modifica di un singolo campo invece di una riscrittura totale: puoi fare il diff dei prompt, revisionarli nelle pull request e ragionare sul perché l'output è cambiato.

Le ricette rendono anche debuggabili le regressioni di qualità. Se le immagini improvvisamente sembrano sbagliate, puoi fare una bisezione: è il blocco del soggetto, il blocco dello stile, le istruzioni di layout o la lista negativa? Con un prompt usa-e-getta, la risposta di solito è "tutti quanti".

Questa guida illustra uno scheletro concreto per il text-to-image di Recraft v4.1 e fornisce le due famiglie di ricette pronte da copiare e incollare più usate dagli sviluppatori: illustrazione e fotografia. La stessa struttura si estende al controllo del layout, al testo nell'immagine e alle liste negative.

Cosa contiene davvero una ricetta

Pensa a ogni ricetta come a quattro parti:

• Scheletro fisso—i blocchi ordinati che ogni prompt nella tua codebase condivide.
• Vocabolario di stile sostituibile—le parole che fanno passare l'output da illustrazione a fotografia.
• Clausole di vincolo—layout, proporzioni, rendering del testo e istruzioni di esclusione.
• Etichetta di versione—così un prompt in produzione è riconducibile alla revisione esatta che ha generato quella risorsa.

Niente di tutto ciò richiede strumenti speciali. Un file JSON per ricetta, committato nel repository insieme al codice che chiama l'API, è sufficiente.

Lo scheletro del prompt: blocchi che restano e blocchi che cambiano

Lo scheletro qui sotto è volutamente noioso. È proprio il punto: la parte stabile non dovrebbe mai aver bisogno di modifiche, così l'attenzione resta su ciò che cambia.

[SUBJECT]        cosa c'è nell'immagine, in linguaggio semplice
[STYLE]          parole del medium e del rendering
[COMPOSITION]    inquadratura, camera o layout, proporzioni
[CONSTRAINTS]    rendering del testo, limiti di palette, regole di esclusione

Quali blocchi restano e quali vengono sostituiti

• SUBJECT—resta. Di solito è l'unico blocco che la tua logica di prodotto dovrebbe parametrizzare (un nome di prodotto, una descrizione di scena dall'input utente).
• STYLE—sostituito. La differenza tra illustrazione e fotografia vive quasi interamente qui.
• COMPOSITION—in gran parte sostituito, ma la forma delle istruzioni resta la stessa (prima l'inquadratura, poi le proporzioni).
• CONSTRAINTS—parzialmente condiviso. La lista negativa e la regola "nessun testo se non specificato" sono spesso globali; le istruzioni di rendering del testo sono per richiesta.

Un template minimo come dato

{
  "recipe_id": "product-hero",
  "version": "3",
  "subject": "a ceramic coffee mug on a plain surface",
  "style": "{{style_block}}",
  "composition": "centered, generous negative space above the subject, square aspect",
  "constraints": ["no text in image", "no watermark"],
  "negatives": "{{negative_list_v2}}"
}

Il segnaposto {{style_block}} è la giuntura. Il resto è o condiviso tra le ricette o fornito dal chiamante. Quando in futuro aggiungerai un terzo stile—per esempio 3D isometrico—aggiungerai solo un blocco di stile, non un nuovo file di prompt.

Un promemoria pratico: mantieni l'ordine dei blocchi costante in ogni ricetta. Non è garantito che il modello sia sensibile all'ordine in modo documentato, ma il tuo team lo è. Un ordine coerente rende i prompt comparabili e le revisioni affiancate significative.

Ricetta illustrazione: stile piatto, vettoriale ed editoriale

La ricetta illustrazione è il punto di partenza per la maggior parte dei team, perché l'illustrazione tollera bene la semplificazione—il che la rende una buona scelta per testare lo scheletro senza combattere con il fotorealismo.

Illustrazione piatta

[SUBJECT] a developer workspace with a laptop, notebook and coffee mug
[STYLE] flat vector illustration, solid fills, no gradients, bold simple shapes, limited four-color palette, clean geometric forms
[COMPOSITION] centered composition, even margins, square aspect
[CONSTRAINTS] no text in image, no shadows, no textures

Le parole che guidano questo look: piatto, riempimenti pieni, nessun gradiente, forme audaci e semplici. Ogni parola conta. Togli "nessun gradiente" e spesso vedrai ombre morbide insinuarsi.

Icona in stile vettoriale

[SUBJECT] a single shield icon with a checkmark
[STYLE] minimal vector icon, uniform stroke weight, rounded line caps, two-tone, high contrast on plain background
[COMPOSITION] centered, icon fills most of the frame, square aspect
[CONSTRAINTS] no text, no background scenery, no gradients

I prompt per icone traggono beneficio da qualificatori espliciti—singolo, spessore del tratto uniforme—perché senza di essi spesso ottieni una piccola scena invece di un simbolo grafico.

Illustrazione editoriale

[SUBJECT] a person reviewing charts on a large screen
[STYLE] editorial illustration, muted palette, subtle grain, hand-drawn line quality, slightly abstracted human figures, magazine feature style
[COMPOSITION] subject offset to the right, breathing room on the left, landscape aspect
[CONSTRAINTS] no text in image, no photorealism, no logos

Lo stile editoriale sta nella via di mezzo: più materico e con più carattere del vettoriale piatto, ma chiaramente non fotografia. Abbinare palette tenue e grana sottile è proprio ciò che gli impedisce di scivolare verso uno dei due estremi.

Consiglio di ottimizzazione: cambia un solo aggettivo di stile alla volta. Sostituire "palette tenue" con "palette vibrante" è un vero esperimento; cambiare cinque parole insieme no.

Ricetta fotografia: realismo, studio e inquadratura lifestyle

La ricetta fotografia usa lo stesso scheletro, solo con un vocabolario diverso. Nota che il blocco del soggetto resta quasi identico—questo è il ritorno della templatizzazione.

Prodotto pulito in studio

[SUBJECT] a ceramic coffee mug on a plain surface
[STYLE] professional studio product photography, soft diffused key light, gentle falloff, neutral background, sharp focus, realistic material detail
[COMPOSITION] centered, slight three-quarter angle, generous negative space above, square aspect
[CONSTRAINTS] no text in image, no props, no harsh reflections

Il vocabolario fotografico si raggruppa attorno a luce (diffusa morbida, caduta), ottica (messa a fuoco nitida, profondità di campo) e realismo dei materiali (dettaglio materico realistico). Il vocabolario dell'illustrazione si raggruppa attorno a forma e riempimento. Questo contrasto è l'intera differenza tra le due famiglie di ricette.

Lifestyle ambientato

[SUBJECT] a person working at a wooden desk near a window
[STYLE] candid lifestyle photography, natural window light, shallow depth of field, warm neutral tones, realistic skin and fabric texture
[COMPOSITION] over-the-shoulder framing, subject left of center, landscape aspect
[CONSTRAINTS] no text in image, no visible brand marks, no exaggerated saturation

Candid e luce naturale della finestra allontanano l'output dalla lucidità da studio. Se il risultato sembra troppo posato, di solito è sia un problema di composizione sia di stile—aggiungere "inquadratura sopra la spalla" funziona meglio che accumulare aggettivi.

Convertire una ricetta illustrazione in fotografia

Data una ricetta illustrazione funzionante, la conversione è meccanica:

1. Sostituisci l'intero blocco [STYLE] con il vocabolario fotografico.
2. Adatta [COMPOSITION] solo se l'inquadratura cambia (l'angolo conta di più in fotografia).
3. Mantieni [SUBJECT] identico byte per byte.
4. Conserva le voci negative globali; rimuovi quelle specifiche dell'illustrazione che non si applicano più, come "nessun gradiente".

Se il risultato fotografico inventa o perde elementi del soggetto, molto probabilmente il blocco del soggetto è sottodescritto—correggi lì, non aggiungere parole di stile compensative.

Controllare layout e rendering del testo

Layout e testo sono le due cose che gli sviluppatori più spesso si aspettano che il modello indovini, e proprio le due che vale più la pena rendere esplicite. Trattale come blocchi di prompt separati, distinti dallo stile.

Linguaggio di posizionamento che vincola davvero

Vago: "un'immagine banner per una landing page."

Esplicito:

[COMPOSITION] landscape 16:9 frame; subject occupies the right two-thirds;
left third is empty open space suitable for a headline; horizon line at
lower third; nothing enters the left third

Tre abitudini rendono più solide le istruzioni di posizionamento:

• Nomina prima la cornice, poi descrivi il posizionamento ("cornice orizzontale 16:9").
• Rendi esplicita l'area riservata e dichiara che nulla vi entra. Lo spazio vuoto non è lo stato predefinito.
• Ancora alla regola dei terzi, invece di usare parole non misurabili come "leggermente fuori centro".

Rendering del testo

Quando vuoi che del testo compaia nell'immagine, isolalo in un blocco e cita la stringa esatta:

[TEXT] render exactly the words "Ship faster" in a bold sans-serif,
placed in the reserved left third, vertically centered, single line,
high contrast against a plain background. No other text anywhere.

Punti che riducono le iterazioni:

• Cita la stringa letterale—non riformularla mai nel prompt.
• Scrivi "esattamente" e "nessun altro testo"—altrimenti spuntano parole extra sugli angoli o sugli oggetti di scena.
• Specifica il numero di righe ("riga singola"), altrimenti l'a capo diventa un'ipotesi.
• Specifica uno sfondo a contrasto ("su sfondo semplice"), così il testo ha qualcosa su cui poggiare.
• Tieni il testo completamente fuori dal blocco [STYLE]; mescolarli rende entrambi più difficili da ottimizzare.

Se una richiesta richiede tipografia multi-elemento precisa, tratta il testo generato come punto di partenza e pianifica a valle un vero layer di testo. Il controllo del testo a livello di prompt va bene per titoli brevi ed etichette, non per corpi di testo densi.

Liste negative: cosa escludere e come versionarle

La lista negativa è il tuo controllo di qualità più economico. Invece di descrivere ciò che vuoi, nomina le modalità di fallimento che rifiuti di accettare.

Categorie che vale la pena escludere

Organizza le voci negative per categoria, così puoi ampliarle senza creare contraddizioni:

• Artefatti testuali—parole in più, glifi illeggibili, filigrane, firme.
• Artefatti di composizione—soggetti tagliati, arti troncati, elementi duplicati, bordi disordinati.
• Artefatti di rendering—sfocatura, banding, sovrasaturazione, effetto HDR aggressivo, pelle plastificata.
• Igiene dei contenuti—marchi, loghi riconoscibili, ritratti di persone reali.
• Deriva di stile—fotorealismo in una ricetta illustrazione, sensazione da illustrazione in una ricetta fotografia.

Quest'ultima categoria è quella che i team dimenticano più spesso. Se la tua ricetta illustrazione continua a derivare verso il realismo, una voce negativa esplicita è spesso più affidabile che accumulare aggettivi di stile.

Mantienile brevi e non contraddittorie

Liste negative troppo lunghe si ritorcono contro. Se una voce negativa entra in conflitto con un'istruzione positiva, il risultato diventa instabile e non riesci a capire quale clausola ha prevalso. Due regole:

1. Non negare mai ciò che hai richiesto. Se il blocco di composizione chiede ombre per dare profondità, non elencare anche "nessuna ombra" a livello globale.
2. Preferisci lo specifico al generico. "Nessuna filigrana" è operativo; "niente cose brutte" è rumore.

Versiona le liste negative insieme ai prompt

Le voci negative cambiano il comportamento di ogni ricetta che le referenzia, quindi richiedono la stessa tracciabilità dei prompt:

{
  "negative_list_id": "global-v2",
  "entries": ["watermark", "signature", "stray text", "cropped subject", "duplicated elements", "oversaturated colors"]
}

Referenzia la lista per ID da ogni ricetta e incrementa l'ID quando la modifichi. Quando la qualità dell'output scende dopo un deployment, "la lista negativa è cambiata?" diventa una riga da controllare nel diff, non un'indagine.

Confronta l'output reale prima di andare in produzione

Prima di aver guardato un output reale, una ricetta è solo un'ipotesi. Il flusso di confronto qui sotto è volutamente leggero—dovrebbe richiedere minuti, non uno sprint.

Il flusso

1. Congela tutto tranne una variabile. Stesso blocco del soggetto, stessa composizione, stesse voci negative e, se l'API espone un seed, stesso seed. Cambia solo il blocco di stile.
2. Genera una piccola matrice. Due o tre varianti di stile abbinate a due o tre soggetti rappresentativi di solito bastano a far emergere una ricetta scadente.
3. Revisiona affiancato, non in sequenza. Le revisioni sequenziali invitano al bias di recenza—l'ultima immagine sembra la migliore solo perché è la più fresca.
4. Valuta rispetto al requisito, non al gusto. Scrivi a cosa serve la risorsa (banner hero, set di icone, testata editoriale) e controlla le proprietà specifiche che contano davvero: lo spazio riservato è davvero vuoto? C'è testo estraneo? C'è deriva di stile?
5. Promuovi consapevolmente. Solo le revisioni di ricetta che superano la revisione entrano nel codice di prodotto, con la loro etichetta di versione.

Cosa tenere d'occhio

• Coerenza tra soggetti. Un blocco di stile che funziona su un soggetto e crolla su un altro non è pronto.
• Rispetto dei vincoli. Il terzo sinistro riservato rimane vuoto? La stringa esatta citata compare una sola volta?
• Cluster di fallimenti. Se lo stesso artefatto appare in più varianti, dovrebbe finire nella lista negativa, non in un ritocco dello stile.

Tieni tutto nel repository

Conserva insieme i JSON delle ricette, le versioni delle liste negative e i record delle revisioni. Quando fra sei mesi qualcuno chiederà perché l'immagine hero ha questo aspetto, la risposta sarà un commit, non un ricordo.

Una volta che una ricetta ha superato questo ciclo, passare tra illustrazione e fotografia per un dato soggetto diventa una modifica a un singolo campo—proprio la proprietà di manutenzione che lo scheletro è stato progettato per offrire. Esegui queste ricette sul text-to-image di Recraft v4.1 attraverso un'API unificata e versiona ogni revisione del prompt insieme al codice che la chiama.