- \n
- Distinguere una richiesta generica da una richiesta con contesto sufficiente.<\/li>\n
- Definire obiettivo, destinatario, materiali, vincoli e forma dell\u2019output.<\/li>\n
- Usare richieste successive per chiarire o correggere il risultato.<\/li>\n
- Adattare la consegna a un compito didattico, amministrativo o di programmazione.<\/li>\n
- Controllare il risultato e indicare criteri di qualit\u00e0 prima di riutilizzarlo.<\/li>\n<\/ul>\n
Durata indicativa: <\/strong>60\u201375 minuti, con dimostrazione e laboratorio guidato.<\/p>\n
![\"\"](\"https:\/\/www.vr-m.it\/sito\/wp-content\/uploads\/2026\/10\/Mappa-concettuale-Lezione-4.png\")
<\/a><\/p>\n1. Partire dal risultato desiderato<\/h1>\n
Prima di scrivere, chiediamoci: \u201cAlla fine, che cosa voglio avere in mano?\u201d. Potrebbe essere una spiegazione, una bozza, una scaletta, una checklist, un confronto, un piano o una modifica a un programma. Se il risultato \u00e8 vago nella nostra mente, la risposta rischia di diventare generica. Possiamo anche dire all\u2019assistente che cosa non sappiamo ancora: in quel caso gli chiediamo di farci una domanda alla volta, prima di preparare la versione completa.<\/p>\n
Confrontiamo due richieste. \u201cParlami della fotosintesi\u201d nomina un argomento, ma lascia aperte molte scelte: per chi \u00e8 la spiegazione? Quanto deve essere lunga? Serve un esempio? \u201cSpiega la fotosintesi a una classe seconda della scuola secondaria di secondo grado, con parole semplici, un esempio quotidiano e tre domande finali\u201d delimita un compito riconoscibile. Non garantisce una risposta perfetta, ma d\u00e0 al modello indicazioni migliori per iniziare.<\/p>\n
Da ricordare: <\/strong>la richiesta \u00e8 una consegna di lavoro. Il risultato desiderato guida le informazioni da aggiungere.<\/p>\n
<\/p>\n
<\/p>\n
2. Gli elementi che rendono chiara una richiesta<\/h1>\n
Non dobbiamo inserire ogni elemento in ogni prompt. Scegliamo quelli che incidono davvero sul risultato. Per una risposta breve pu\u00f2 bastare una frase; per un compito articolato conviene descrivere con pi\u00f9 cura destinatario, materiali, limiti e criteri di verifica.<\/p>\n
Obiettivo e destinatario<\/h2>\n
Diciamo che cosa deve fare l\u2019assistente e chi user\u00e0 il risultato. \u201cPrepara una comunicazione\u201d \u00e8 poco preciso; \u201cscrivi una bozza di email alle famiglie per comunicare il cambio di orario, con tono formale e frasi brevi\u201d indica azione, destinatario e situazione. Se il livello del lettore conta, nominiamolo: principianti, colleghi, studenti di una classe specifica, tecnici che conoscono gi\u00e0 il progetto.<\/p>\n
Contesto e materiali<\/h2>\n
Aggiungiamo solo le informazioni necessarie per capire il caso. Se abbiamo un programma, un documento o un esempio, indichiamo quale materiale usare e come trattarlo. Possiamo dire \u201cusa il testo allegato come riferimento e segnalami i punti che non contiene\u201d, cos\u00ec evitiamo che la bozza sembri basata su informazioni non fornite. In un progetto di codice, specifichiamo la cartella, il comportamento atteso o il messaggio d\u2019errore; Codex pu\u00f2 esaminare i file autorizzati, ma la richiesta deve chiarire quale esito cerchiamo.<\/p>\n
Vincoli e criteri<\/h2>\n
I vincoli definiscono ci\u00f2 che la risposta deve rispettare: lunghezza, tono, lingua, lessico, scadenza, strumenti ammessi o parti da non modificare. I criteri descrivono che cosa render\u00e0 il risultato accettabile. Per esempio: \u201cincludi obiettivi osservabili\u201d, \u201cnon inserire dati personali\u201d, \u201cmantieni le intestazioni presenti\u201d, \u201cindica i test eseguiti\u201d. Se una regola \u00e8 davvero obbligatoria, scriviamola in modo esplicito.<\/p>\n
Formato e livello di dettaglio<\/h2>\n
Diciamo come vogliamo leggere o riutilizzare il risultato: una tabella, una lista numerata, una bozza pronta da rivedere, un testo discorsivo, una sequenza di passaggi o un file specifico. Possiamo indicare la lunghezza approssimativa e chiedere titoli chiari. Evitiamo prescrizioni inutili: il formato serve a rendere il risultato pratico, non a riempire il prompt di regole.<\/p>\n
Una traccia flessibile<\/h2>\n
OBIETTIVO + CONTESTO + VINCOLI + FORMATO <\/strong>Aggiungi destinatario, materiali e criteri quando cambiano la qualit\u00e0 del risultato. La traccia aiuta a ricordare cosa chiarire, ma non \u00e8 un modulo da compilare sempre per intero.<\/p>\n
<\/p>\n
<\/p>\n
3. Costruire la richiesta passo per passo<\/h1>\n
Partiamo dal nucleo: \u201cPrepara una verifica sulla fotosintesi\u201d. Poi individuiamo ci\u00f2 che manca. A chi \u00e8 destinata? Quanto deve durare? Quali argomenti sono gi\u00e0 stati svolti? Quali tipi di esercizio servono? Come deve essere organizzato il documento? Possiamo aggiungere queste informazioni tutte insieme oppure chiedere all\u2019assistente di farci le domande necessarie.<\/p>\n
Prima bozza e versione pi\u00f9 precisa<\/h2>\n
\n\n
\n Richiesta iniziale<\/strong><\/td>\n Richiesta arricchita<\/strong><\/td>\n<\/tr>\n \n Prepara una lezione sull\u2019energia.<\/td>\n Sono docente di scienze in una classe terza. Prepara una lezione di 50 minuti sulle trasformazioni dell\u2019energia. Gli studenti conoscono gi\u00e0 energia cinetica e potenziale. Organizza il risultato in: obiettivi, spiegazione, esempio guidato, attivit\u00e0 a coppie e tre domande di verifica. Usa un linguaggio accessibile e segnala i concetti da controllare sul libro di testo.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n La seconda consegna rende espliciti il pubblico, il tempo, le conoscenze iniziali, la struttura e un criterio di controllo. Possiamo comunque rivederla dopo aver letto la prima risposta. Se il modello propone un\u2019attivit\u00e0 troppo complessa, non occorre ricominciare: basta chiedere di ridurre i prerequisiti e proporre materiali pi\u00f9 semplici.<\/p>\n
Chiedere chiarimenti prima della risposta<\/h2>\n
Se le informazioni mancanti sono decisive, diciamolo. \u201cPrima di scrivere la bozza, fammi fino a tre domande sui destinatari, sul tono e sui dati che posso condividere.\u201d Questa modalit\u00e0 \u00e8 utile quando stiamo progettando una lezione, una procedura o una modifica software e non abbiamo ancora fissato tutte le scelte. Possiamo anche chiedere un confronto tra due opzioni, spiegando quale criterio conta di pi\u00f9.<\/p>\n
Suddividere i lavori ampi<\/h2>\n
Per un compito grande, procediamo per tappe. Prima chiediamo una proposta di struttura, poi rivediamo la scaletta, infine sviluppiamo le sezioni approvate. In un\u2019attivit\u00e0 di programmazione possiamo chiedere a Codex di esaminare il progetto e riassumere come funziona, definire la modifica, intervenire e descrivere i controlli svolti. Suddividere permette di accorgersi presto se l\u2019assistente ha capito male e di correggere la rotta senza rifare tutto.<\/p>\n
<\/p>\n
<\/p>\n
4. Un esempio per ogni ruolo<\/h1>\n
Docente: progettare una lezione<\/h2>\n
Un docente pu\u00f2 descrivere materia, classe, durata, prerequisiti e forma della lezione. Per esempio: \u201cSono docente di storia in una classe seconda. Progetta 45 minuti sulla vita quotidiana nell\u2019antica Roma, partendo dalle conoscenze indicate nel file allegato. Alterna una spiegazione breve e un\u2019attivit\u00e0 in piccoli gruppi. Concludi con una domanda di verifica e segnala ci\u00f2 che hai ricavato dal file rispetto a ci\u00f2 che stai proponendo tu.\u201d<\/p>\n
Dopo aver letto la bozza, il docente pu\u00f2 precisare: \u201cL\u2019attivit\u00e0 deve funzionare senza dispositivi. Riduci la spiegazione iniziale a dieci minuti e aggiungi una breve consegna per gli studenti.\u201d Il dialogo serve a mettere a punto il materiale; il docente resta responsabile della correttezza storica e dell\u2019adeguatezza alla classe.<\/p>\n
Personale amministrativo: preparare una comunicazione<\/h2>\n
Chi lavora in amministrazione pu\u00f2 indicare destinatario, scopo, tono, informazioni gi\u00e0 confermate e struttura richiesta. Per esempio: \u201cPrepara una bozza di avviso per il personale sull\u2019aggiornamento dell\u2019orario di ricevimento. Usa i dati riportati nel testo allegato; non aggiungere dettagli mancanti. Inserisci un oggetto, un breve testo e un elenco dei passaggi da verificare prima dell\u2019invio. Lascia tra parentesi quadre le informazioni non ancora confermate.\u201d Non inseriamo dati personali o riservati se non \u00e8 autorizzato e necessario.<\/p>\n
Programmatore: chiarire una modifica<\/h2>\n
Per Codex, descriviamo comportamento atteso, punto del progetto se noto, vincoli e verifica. Per esempio: \u201cEsamina questa cartella e individua dove viene validato il campo email nel modulo di registrazione. Prima riassumi il comportamento attuale e proponi una modifica che accetti le maiuscole senza cambiare il formato visualizzato. Poi implementa il cambiamento e indica quali controlli hai eseguito. Mantieni lo stile del progetto e non modificare file non pertinenti.\u201d<\/p>\n
Se non conosciamo ancora il punto del codice, chiediamo prima un\u2019analisi. Poi, una volta chiarito l\u2019intervento, diamo l\u2019autorizzazione operativa e rivediamo le differenze. La richiesta deve indicare il risultato e lasciare spazio a Codex per esplorare i file rilevanti, senza impartire dettagli tecnici inventati.<\/p>\n
<\/p>\n
<\/p>\n
5. Migliorare la risposta attraverso il dialogo<\/h1>\n
Dopo la prima risposta, confrontiamola con il risultato che avevamo in mente. Se \u00e8 troppo lunga, chiediamo di accorciarla specificando cosa conservare. Se \u00e8 generica, aggiungiamo un esempio o il contesto mancante. Se contiene un errore, indichiamo il passaggio e chiediamo una correzione motivata o una verifica su una fonte attendibile. Un feedback come \u201cnon mi convince\u201d esprime un\u2019impressione; una richiesta come \u201cmantieni la struttura, semplifica il secondo paragrafo e aggiungi un esempio per studenti di 14 anni\u201d indica che cosa fare.<\/p>\n
Quando la risposta non funziona<\/h2>\n
- \n
- Troppo generica: aggiungi destinatario, contesto o un caso concreto.<\/li>\n
- Troppo lunga: indica una lunghezza e quali informazioni devono restare.<\/li>\n
- Fuori tema: ribadisci l\u2019obiettivo e chiarisci quale materiale usare.<\/li>\n
- Formato scomodo: descrivi la forma in cui vuoi leggere o riutilizzare il risultato.<\/li>\n
- Informazione dubbia: chiedi fonti o verifica il dato prima di usarlo.<\/li>\n
- Codice modificato oltre il necessario: indica quali file o comportamenti rientrano nella modifica e rivedi il diff.<\/li>\n<\/ul>\n
Attivit\u00e0 guidata<\/h2>\n
Scegli un compito reale ma semplice. Scrivi una prima richiesta senza pensarci troppo; rileggila e aggiungi le informazioni che avrebbero aiutato un collega a svolgerlo. Invia la richiesta, controlla il risultato e formula almeno una revisione precisa. Infine confronta la prima e l\u2019ultima versione: quali aggiunte hanno migliorato davvero il lavoro?<\/p>\n
Traccia da riutilizzare<\/h2>\n
- \n
- Obiettivo: che cosa voglio ottenere?<\/li>\n
- Destinatario e contesto: chi user\u00e0 il risultato e che cosa deve sapere l\u2019assistente?<\/li>\n
- Materiali: quali file o fonti deve usare? Che cosa deve segnalare come non specificato?<\/li>\n
- Vincoli: che cosa deve rispettare o evitare?<\/li>\n
- Formato: come voglio ricevere il risultato e con quale livello di dettaglio?<\/li>\n
- Verifica: quali criteri user\u00f2 per controllarlo?<\/li>\n<\/ul>\n
Verifica finale<\/h2>\n
Una richiesta pi\u00f9 lunga \u00e8 sempre migliore?<\/strong><\/p>\n
Risposta attesa: <\/strong>No. \u00c8 utile aggiungere le informazioni che cambiano il risultato.<\/p>\n
Che cosa conviene fare quando manca un\u2019informazione decisiva?<\/strong><\/p>\n
Risposta attesa: <\/strong>Chiedere chiarimenti prima di far produrre la versione completa.<\/p>\n
Perch\u00e9 indicare il formato?<\/strong><\/p>\n
Risposta attesa: <\/strong>Per ottenere un risultato pi\u00f9 facile da leggere, controllare e riutilizzare.<\/p>\n
La prima risposta deve essere definitiva?<\/strong><\/p>\n
Risposta attesa: <\/strong>No. Si pu\u00f2 migliorare con correzioni precise e successive.<\/p>\n
Che cosa resta sotto la nostra responsabilit\u00e0?<\/strong><\/p>\n
Risposta attesa: <\/strong>Controllare accuratezza, adeguatezza, fonti e modifiche prima di riutilizzarle.<\/p>\n
Fonte ufficiale<\/h2>\n
- \n
- OpenAI Help Center, Prompt engineering best practices for ChatGPT \u2014 https:\/\/help.openai.com\/en\/articles\/10032626-prompt-engineering-best-practices-for-chatgpt<\/li>\n<\/ul>\n
Nota: <\/strong>questa lezione propone una traccia flessibile; non esiste una formula che garantisca sempre il risultato. Le risposte e le modifiche vanno controllate prima dell\u2019uso.<\/em><\/p>\n
- OpenAI Help Center, Prompt engineering best practices for ChatGPT \u2014 https:\/\/help.openai.com\/en\/articles\/10032626-prompt-engineering-best-practices-for-chatgpt<\/li>\n<\/ul>\n