In questa guida
Il feedback dei tester è utile solo quando cambia l'app. Se costruisci soprattutto con i prompt, la strada più breve dalla nota di un tester a una correzione passa da un buon prompt. Un prompt vago produce una modifica vaga, e una modifica che non verifichi può rompere qualcos'altro. Questa pagina ti dà un ciclo da ripetere per ogni round di feedback.
Il ciclo
- Raccogli
- Dai priorità
- Scrivi il prompt
- Applica e leggi la modifica
- Verifica su un dispositivo reale
- Dillo al tester
1. Raccogli feedback strutturato
"È rotto" è difficile da usare. Chiedi ai tester sempre gli stessi pochi campi: cosa hanno fatto, cosa si aspettavano, cosa è successo, dispositivo e versione del sistema operativo. Una segnalazione in quella forma può essere incollata in un prompt quasi senza modifiche. Vedi come scrivere un feedback utile per lo sviluppatore e il modello di segnalazione bug.
2. Dai priorità prima di scrivere il prompt
Non mandare dieci segnalazioni all'assistente in una volta. Ordinale per impatto e sforzo (guida): prima arresti anomali e flussi principali bloccati, per ultime le rifiniture. Lavora su un problema per prompt. Le modifiche piccole sono più facili da verificare e da annullare.
3. Scrivi un prompt preciso
Un buon prompt contiene quattro cose:
- Contesto: quale schermata o funzione, in una o due frasi.
- La segnalazione: passaggi, risultato atteso, risultato effettivo, dispositivo e sistema operativo.
- Il limite: "cambia solo ciò che serve; non rifattorizzare codice non correlato".
- Una verifica: come saprai che funziona, incluso un comportamento vicino che deve restare uguale.
Versione da copiare e incollare: modello di prompt dalla segnalazione del tester alla correzione.
Se non riesci a riprodurre il problema, dillo nel prompt e chiedi all'assistente di spiegare la sua ipotesi prima di cambiare il codice. Non chiedergli di "sistemare tutto ciò che c'è in questa segnalazione".
4. Leggi la modifica
Non devi capire ogni riga, ma guarda cosa è cambiato: quali file, quante righe. Un bug di una riga che produce una modifica in dieci file merita una seconda occhiata. Tieni ogni correzione in un commit o punto di salvataggio separato, così puoi tornare indietro.
5. Verifica su un dispositivo reale
Esegui i passaggi esatti della segnalazione su un telefono reale, idealmente del tipo usato dal tester. Poi esegui il comportamento vicino che hai indicato come "deve restare uguale". L'emulatore è una prima verifica; il telefono reale è la prova. Vedi perché un emulatore non basta.
6. Chiudi il ciclo
Dì al tester cosa hai cambiato e chiedigli di ricontrollare. Chi vede le proprie note usate tende a scrivere note migliori la volta successiva. Non dichiariamo una percentuale per questo; è semplicemente il modo in cui il feedback diventa un'abitudine invece di un episodio isolato.
Quando la correzione non tiene
- L'assistente "ha sistemato" ma i passaggi falliscono ancora: rimanda la stessa segnalazione con ciò che hai osservato dopo la modifica.
- La correzione ha rotto qualcos'altro: annulla, poi aggiungi il comportamento rotto alla riga "deve restare uguale".
- Due tentativi senza progressi: descrivi il problema con parole tue, più piccolo e con meno contesto.
Tieni un registro breve
Una riga per segnalazione: data, problema, dispositivo, prompt usato, risultato. Dopo qualche round vedrai quali tipi di segnalazioni producono correzioni pulite.
Dove si inserisce AppReviewX
AppReviewX ti dà feedback privato e strutturato da altri sviluppatori, in un formato che si adatta a questo ciclo. Un feedback che scrivi ti dà un credito, i crediti servono a ottenere feedback sulla tua app, e i nuovi account partono con 0 crediti.
Correlati: hub del vibe coding, prime recensioni oneste dalla store, motivi di rifiuto dallo store, test su dispositivo reale.
Inizia gratis e metti in pratica il ciclo.