Come scrivere prompt per i generatori di app AI (con esempi prima e dopo)

Un buon prompt per un generatore di app AI descrive il prodotto, non il codice: chi lo usa, cosa fa passo dopo passo, quali dati conserva e chi può vedere cosa. Dopo che esiste la prima versione, chiedi una modifica specifica per messaggio, di' cosa deve restare uguale e descrivi i problemi come "ho fatto X, mi aspettavo Y, ho ottenuto Z". Queste tre abitudini risolvono la maggior parte dei risultati deludenti.

Il resto di questa guida mostra gli schemi nel dettaglio, con esempi prima e dopo che puoi adattare.

Perché scrivere prompt per un generatore di app è diverso dal chattare con un'AI

Quando fai una domanda a un assistente in chat, un prompt vago riceve una risposta vaga e vai avanti. Quando scrivi un prompt per un generatore di app AI, la risposta è un programma funzionante. Ogni lacuna nella tua descrizione viene riempita con un'ipotesi, e queste ipotesi diventano codice, tabelle di database e schermate con cui poi dovrai convivere o che dovrai disfare.

Quindi l'obiettivo di un prompt non è suonare intelligente. È lasciare meno decisioni importanti al caso. Non ti servono termini tecnici per questo. Ti serve essere preciso sulle cose che solo tu conosci: i tuoi utenti, il tuo flusso di lavoro e le tue regole.

Cosa includere in un primo prompt

Prima di scrivere qualsiasi cosa, rispondi a queste domande. Ognuna chiude una lacuna su cui l'AI altrimenti tirerebbe a indovinare.

Includi	Perché conta	Esempio
Il prodotto in una frase	Imposta il contesto di ogni decisione successiva	"Un sito di prenotazioni per un barbiere con due postazioni"
Chi lo usa	Decide le schermate e il tono	"Clienti senza appuntamento dal telefono, e il titolare dal computer"
Il flusso principale, passo dopo passo	La cosa che deve funzionare per prima	"Scegli un servizio, scegli un orario, inserisci nome e telefono, ricevi la conferma"
I dati che conserva	Diventa la struttura del database	"Servizi, prenotazioni, clienti"
Chi può vedere o modificare cosa	Decide login e permessi	"Solo il titolare vede tutte le prenotazioni"
Aspetto e stile, in breve	Evita uno stile predefinito generico	"Scuro, semplice, pulsanti grandi"
Cosa lasciare fuori per ora	Mantiene piccola la prima versione	"Niente pagamenti né recensioni per ora"

L'ultima riga è sottovalutata. Dire cosa non vuoi impedisce all'AI di aggiungere un blog, una pagina dei prezzi e una iscrizione alla newsletter che non hai mai chiesto.

Prima e dopo: il primo prompt

Prima:

Fammi un'app per la mia palestra.

Il generatore deve indovinare tutto: membri o staff? Corsi o allenamento personale? Pagamenti? Otterrai qualcosa che sembra un sito per palestre e non fa ciò che ti serve.

Dopo:

Costruisci un'app per le prenotazioni dei corsi di una piccola sala yoga. I soci vedono i corsi di questa settimana (nome, insegnante, orario, posti rimasti), prenotano un posto e annullano fino a due ore prima. I soci si registrano con email e password. Il titolare della sala accede per aggiungere corsi, vedere chi è prenotato e segnare le presenze. Conserva corsi, soci e prenotazioni in un database. Design calmo, chiaro e comodo sul telefono. Niente pagamenti per ora.

La seconda versione è comunque breve. Risponde semplicemente alle domande della tabella qui sopra.

Descrivi il comportamento, non l'implementazione

Spesso ottieni risultati migliori descrivendo cosa deve succedere invece di come costruirlo.

Prima:

Aggiungi un useEffect che recupera le prenotazioni e un componente modale per modificarle.

Dopo:

Quando il titolare clicca su una prenotazione, apri un pannello dove può cambiare l'orario o annullarla. Le modifiche devono comparire subito nell'elenco.

Il primo prompt blocca l'AI su una tecnica specifica che potrebbe non adattarsi a come è costruita l'app. Il secondo le dice il risultato e lascia che scelga l'approccio giusto per il codice che ha già scritto. Se sei uno sviluppatore e hai una preferenza forte, dilla, ma abbinala al risultato.

Sii concreto sulle regole

Le regole di business sono il punto in cui le app costruite con l'AI sbagliano più spesso, perché per te sono ovvie e per l'AI sono invisibili. Scrivile per esteso.

Limiti: "Un socio può avere al massimo tre prenotazioni future."
Tempi: "Le cancellazioni si chiudono due ore prima dell'inizio del corso."
Casi limite: "Se un corso è al completo, mostra un pulsante lista d'attesa invece di Prenota."
Permessi: "Gli insegnanti vedono le presenze dei propri corsi ma non quelle degli altri insegnanti."

Ogni regola è una frase. Se ne ometti una, l'app o non la applicherà o ne inventerà una versione propria.

Dopo la prima versione: una modifica per messaggio

Quando qualcosa è in funzione nell'anteprima, passa dal descrivere l'intero prodotto a chiedere piccole modifiche verificabili.

Prima:

Il design non va, la prenotazione non funziona bene e voglio una vista calendario e delle email.

Dopo (come quattro messaggi separati):

Quando prenoto l'ultimo posto di un corso, il corso mostra ancora "1 posto rimasto". Dovrebbe mostrare "Completo" e nascondere il pulsante Prenota.

Aggiungi nella pagina del programma un calendario a vista settimanale, una colonna per giorno. Mantieni la vista a elenco attuale come opzione.

Rendi le schede dei corsi più compatte sui telefoni: padding più piccolo, nome dell'insegnante sulla stessa riga dell'orario.

Invia al socio un'email di conferma quando prenota.

Perché funziona:

Ogni modifica è abbastanza piccola perché l'AI la faccia giusta in un solo passaggio.
Puoi verificarne una prima di passare alla successiva.
Se una va storta, puoi annullare solo quel passaggio senza perdere gli altri.

Di' cosa mantenere

Quando chiedi una modifica a qualcosa che già funziona, di' all'AI cosa non deve cambiare. È il modo più semplice per evitare le regressioni (cose che funzionavano e si rompono dopo una modifica).

Riprogetta la sezione principale della home con un titolo più grande e una foto a destra. Mantieni la navigazione, i colori e tutto ciò che sta sotto la sezione principale esattamente com'è.

Lo stesso vale per i dati: "Aggiungi un campo telefono ai soci. Non rimuovere né rinominare nessun campo esistente."

Usa screenshot e testo esatto

Frasi come "la cosa in alto" sono ambigue. La maggior parte dei generatori di app AI accetta immagini, e uno screenshot con una breve nota è più veloce di un paragrafo di descrizione.

Allega uno screenshot e scrivi "il pulsante cerchiato in rosso si sovrappone al menu sui telefoni".
Incolla il testo esatto di ogni messaggio di errore invece di parafrasarlo.
Cita le etichette a schermo esattamente: "il pulsante Salva modifiche nella pagina Impostazioni".

Per i bug, usa questa forma:

Nella pagina delle prenotazioni ho cliccato Annulla su una prenotazione per domani. Mi aspettavo che sparisse dal mio elenco. Invece non è successo nulla e la prenotazione è ancora lì dopo il refresh. Correggilo e verifica che l'annullamento funzioni.

La nostra guida su come fare debug di un'app costruita con l'AI approfondisce questo punto.

Pianifica prima per le modifiche grandi

Per tutto ciò che tocca molte parti dell'app — aggiungere account utente a un'app che non ne aveva, aggiungere pagamenti, cambiare la struttura dei dati — chiedi un piano prima che il codice cambi.

Prima di cambiare qualcosa, spiegami come aggiungeresti gli account di team: quali nuove tabelle, quali pagine cambiano e cosa succede agli utenti esistenti. Non modificare ancora il codice.

Leggi il piano. Se ha frainteso qualcosa, correggere un paragrafo costa molto meno che correggere una funzionalità già finita. Molti generatori hanno una modalità dedicata per questo; su Mythex è la modalità Piano, accanto a Costruisci e Chiedi.

Cosa evitare

Evita	Perché	Invece
"Rendilo migliore" / "Fallo risaltare"	Nessun obiettivo, quindi l'AI cambia cose a caso	Nomina la modifica: "più spazio bianco tra le sezioni, titoli più grandi"
Un unico prompt gigante con dieci funzionalità	Gli errori si accumulano; difficile da verificare	Una funzionalità per messaggio
Incollare chiavi API nella chat	Le chiavi finiscono nella cronologia della chat	Usa i segreti o le impostazioni d'ambiente del generatore
Discutere con un risultato rotto	Ogni correzione si accumula sul bug	Torna indietro, poi riformula
Specificare codice che non capisci	Blocca una soluzione poco adatta	Descrivi il comportamento che vuoi
Chiedere una sicurezza "di livello enterprise"	Non significa nulla di specifico	Elenca le regole reali: chi può vedere cosa

Sulle chiavi API: se ti servono un servizio di pagamento o di email, metti le loro chiavi nei segreti del progetto invece che nel prompt. Vedi cosa sono le variabili d'ambiente e i segreti se è un concetto nuovo.

Modelli di prompt riutilizzabili

Adattali sostituendo le parti tra parentesi quadre.

Nuova app:

Costruisci un [tipo di app] per [chi]. Loro [flusso principale, passo dopo passo]. [Secondo tipo di utente] accede per [cosa fa]. Conserva [dati] in un database. [Aspetto e stile]. Lascia fuori [cose per dopo].

Nuova funzionalità:

Aggiungi [funzionalità] alla pagina [pagina]. Quando [utente] fa [azione], [cosa deve succedere]. Solo [chi] può [farlo]. Mantieni [cose esistenti] come sono.

Modifica al design:

Nella pagina [pagina], cambia [elemento specifico] in [modifica specifica]. Mantieni [cosa mantenere]. Verifica che sia corretto su uno schermo di larghezza da telefono.

Bug:

Nella pagina [pagina], ho [passi]. Mi aspettavo [atteso]. Invece [effettivo, più il testo esatto dell'errore]. Correggilo e verifica che il flusso funzioni.

Domanda senza modifiche:

Non cambiare nessun codice. Spiegami come funziona [parte dell'app] e dove vengono conservati i [dati].

Scrivere una specifica più lunga

Per progetti più grandi può aiutare scrivere prima una scheda di una pagina e incollarla come primo prompt: gli utenti, i flussi principali, i dati, le regole e ciò che è fuori dal perimetro. Puoi anche farti aiutare dall'AI a redigerla — la nostra guida su come scrivere un documento dei requisiti di prodotto con l'AI spiega come. Limita solo la richiesta di costruzione iniziale al flusso principale e aggiungi il resto passo dopo passo.

Prompt in Mythex

Tutto quanto sopra funziona su Mythex. Alcuni dettagli utili:

Modalità Costruisci, Piano e Chiedi. Usa Piano per modifiche grandi o rischiose e Chiedi quando vuoi una spiegazione senza modifiche.
Checkpoint. Dopo ogni modifica riuscita Mythex salva un checkpoint, e Ripristina a questo punto su una risposta riporta indietro il progetto. Puoi anche modificare un messaggio precedente e inviarlo di nuovo per provare un prompt diverso da quel punto.
Scheda dei segreti. Quando l'agente ha bisogno di una chiave API, lo chiede tramite una scheda nella chat, così il valore viene salvato come segreto del progetto invece di finire nel tuo messaggio.
Immagini. Allega screenshot o mockup e l'agente li guarderà.

La documentazione ha una breve pagina sui prompt efficaci e una sull'iterare senza ricostruire. Se parti da zero, come costruire un'app con l'AI accompagna in un progetto completo, e come progettare un'app dall'aspetto curato con l'AI tratta i prompt per la cura visiva.

Domande

Quanto deve essere lungo un prompt per un generatore di app AI?

Per la prima versione di solito basta un paragrafo breve di quattro-otto frasi: chi usa l'app, il flusso principale, i dati che conserva e chi può vedere cosa. Dopo, funzionano meglio prompt più corti che chiedono una modifica alla volta.

Devo dire all'AI quale framework o linguaggio usare?

Solo se hai un motivo, per esempio uno sviluppatore che prenderà in mano il codice o un servizio che funziona solo con un certo stack. Altrimenti descrivi il prodotto e lascia che il generatore scelga valori predefiniti sensati.

Perché l'AI continua a cambiare cose che non le ho chiesto di cambiare?

Di solito perché il prompt era generico ("migliora tutto") o non diceva cosa mantenere. Indica con precisione la cosa da cambiare, di' cosa deve restare uguale e chiedi una sola modifica per messaggio.

È meglio correggere un risultato sbagliato con altri prompt o ricominciare?

Se l'ultima modifica ha peggiorato le cose, torna alla versione precedente e riformula, invece di accumulare correzioni sopra. Inizia un nuovo progetto solo quando è cambiata l'idea stessa.