Cosa deve davvero contenere un prompt di build?
Quattro cose, e lo dico dopo averne viste circa duecento trasformarsi in siti finiti: cos'è, per chi è, gli elementi indispensabili e — facoltativamente — un'atmosfera. Tutto il resto è rumore che il builder riempirà comunque con valori predefiniti, quindi la vera abilità non è scrivere di più, ma capire su quali di questi quattro punti hai davvero un'opinione e dire solo quella.
Parti da cos'è, e limitati a una categoria, non a una specifica. "Un sito di prenotazioni per uno studio di yoga" è meglio di "un sito dove le persone vedono gli orari e cliccano un pulsante per prenotare un posto e ricevere una conferma" anche se la seconda frase contiene più informazioni. La categoria attiva i valori predefiniti che il builder ha già — i calendari assomigliano a calendari, i flussi di prenotazione assomigliano a flussi di prenotazione — mentre la descrizione lo costringe a ricostruire la categoria da zero.
Devo indicare per chi è pensato?
Non è obbligatorio, ma è la riga che le persone saltano e non dovrebbero. "Per gli studenti già iscritti allo studio" e "per persone che scoprono lo studio per la prima volta" producono siti diversi in quasi tutti gli aspetti che contano — tono del testo, se c'è un grande hero promozionale o un layout diretto al calendario, se i prezzi sono in evidenza (i nuovi visitatori ne hanno bisogno) o nascosti (i clienti abituali li conoscono già). Una frase qui può risolvere cento piccole ambiguità che una pagina di richieste di funzionalità non risolverebbe mai. Se il pubblico è davvero generico, ometti questa parte — non inventarne uno solo per riempire il campo.
Quanti elementi indispensabili dovrei elencare?
Due o tre. Il test che uso: rifiuteresti il primo build se mancasse questo elemento? "Calendario delle lezioni, pagamenti online, biografie degli istruttori" supera questo test per uno studio di yoga — senza un calendario non è una versione più piccola del sito, è un sito diverso. "Un'iscrizione alla newsletter nel footer" quasi non lo supera mai; è un bel di più, e i bei di più vanno nella chat di follow-up dopo aver visto un piano, non stipati nel prompt iniziale dove competono con le cose che contano.
Questo è onestamente l'ingrediente che le persone sbagliano peggio, in entrambe le direzioni. Zero elementi irrinunciabili e il builder indovina, a volte male. Otto elementi irrinunciabili e il builder li tratta tutti come ugualmente portanti, e il risultato sembra un elenco di funzionalità travestito da sito web — niente gerarchia, niente respiro. Se dovessi insistere su un solo ingrediente da non saltare, sarebbe questo. Anche una sola frase su "le due cose che lo rendono tuo" fa risparmiare quasi sempre un giro di scambi, perché è l'unica informazione che il builder non può dedurre dalla sola categoria.
Devo specificare un'atmosfera?
Solo se ne hai una. Molti buoni prompt la saltano del tutto, ed è normale — il direttore artistico sceglie comunque una direzione stilistica, che tu la specifichi o meno. Un'atmosfera di due parole ("calda e disegnata a mano," "clinica e veloce," "come una sala giochi anni '90") indirizza semplicemente quella scelta invece di lasciarla ai valori predefiniti della categoria. Se hai una reazione forte — sai di volere sfondi color crema e font serif caldi, o sai di odiare gli angoli arrotondati — vale la pena spendere quella frase. "Pulito e moderno," tra l'altro, non conta. Non è un'atmosfera, è l'assenza di una, e non orienta nulla pur costandoti comunque uno spazio.
Perché non descrivere tutto ciò a cui sto pensando?
Perché il builder obbedisce. Questo è il vero modo in cui le cose vanno storte, e non è ciò che ci si aspetta — non è che troppa informazione confonda il builder, è che ogni frase che scrivi viene letta come un'istruzione, comprese quelle abbozzate che scarteresti volentieri a un secondo sguardo. Ho visto qualcuno scrivere "forse una sezione testimonianze, non sono sicuro" e ricevere in cambio una sezione testimonianze con tre citazioni segnaposto, perché "forse, non sono sicuro" è un'esitazione per un lettore umano e una richiesta di funzionalità per un sistema che ti prende alla lettera.
Questo non avrebbe importanza se sotto-specificare fosse costoso, come lo è con un team di sviluppatori umani, dove l'ambiguità ti costa due settimane prima che qualcuno noti che è stata costruita la cosa sbagliata. Qui non è costoso. Il builder pianifica prima di costruire — vedi una proposta concreta prima che qualcosa venga fissato nel codice — quindi sotto-specificare ti costa una correzione di cinque minuti in la chat, mentre sovra-specificare mette subito in campo tutte le tue idee più abbozzate proprio nel momento in cui hai meno informazioni per sapere quali valga la pena tenere. Dieci parole di requisiti reali battono duecento parole di flusso di coscienza, non perché più informazione sia negativa in astratto, ma perché in questa interfaccia specifica ogni parola in più è un impegno.
C'è anche un costo più silenzioso: appiattisce la gerarchia. Elenca dodici funzionalità con pari enfasi e il builder non ha alcun segnale su quali tre ti interessino davvero, quindi o dà a tutte e dodici lo stesso peso visivo (disordinato) oppure indovina la priorità (a volte sbagliando, e ora stai correggendo un'ipotesi invece di dichiarare una preferenza). Tre elementi irrinunciabili detti chiaramente proteggono quella gerarchia. Dodici in un paragrafo la cancellano.
Come si presenta davvero un buon prompt?
| Prompt | Perché funziona |
|---|---|
| "Un diario di allenamento per arrampicatori — sessioni, gradi, grafici di progresso." | Cosa più tre elementi irrinunciabili, dieci parole di requisiti in totale. Nessuna nota sul pubblico, perché "arrampicatori che registrano il proprio allenamento" è ovvio dalla categoria — salta correttamente l'unico ingrediente che qui non serve a nulla. |
| "Una landing page per il mio podcast sull'agricoltura urbana, calda ed editoriale, con un elenco episodi e un modulo di iscrizione." | Cosa, pubblico implicito da "il mio podcast," atmosfera, due funzionalità. Non specifica quale player incorpora gli episodi o quanti mostrarne per pagina — sono domande da secondo giro, non da prompt iniziale. |
| "Un gioco di hockey da tavolo per due giocatori, fisica realistica, una sola tastiera." | I giochi rendono questo schema evidente: genere più l'unico vincolo che definisce davvero come si gioca. "Fisica realistica" e "una sola tastiera" non sono tanto funzionalità quanto le due decisioni che determinano se il gioco assomiglia a quello che avevi in mente. Colore del tavolo, scie del disco, interfaccia del punteggio — li propone il builder, tu reagisci. |
Ciò che accomuna tutti e tre non è la brevità fine a se stessa, è che ogni parola ha un ruolo. Togli "calda ed editoriale" dal prompt del podcast e ottieni una pagina podcast generica; togli "agricoltura urbana" e la parola sull'atmosfera non ha più nulla a cui riferirsi. Questo è il vero test per capire se un prompt è ben formato — non il conteggio delle parole. Preferirei un prompt di 40 parole in cui ogni frase si guadagna il suo posto rispetto a un prompt di 15 parole conciso per il gusto di esserlo che però tralascia silenziosamente un elemento irrinunciabile.
E se ho già colori del brand o foto reali?
Allegali. Non descriverli. Ho visto persone scrivere un paragrafo accurato per fissare una palette del brand con un linguaggio quasi esadecimale — "un verde foresta intenso, tendente allo spento" — mentre la linea guida del brand vera e propria era già in un PDF sulla loro scrivania. Un colore descritto è un'ipotesi che il builder deve ricostruire; uno allegato è semplicemente corretto. Menu reali, foto reali, risorse del brand — le funzionalità di conoscenza e riferimento li inseriscono direttamente nella build, e i fatti battono sempre le descrizioni dei fatti.
