Per ottenere una risposta utile non servono parole segrete o una formula magica. Serve far capire all’assistente che cosa vogliamo ottenere e quali elementi del contesto contano. Possiamo iniziare con una richiesta semplice, osservare il risultato e aggiungere le informazioni che mancano. In questa lezione impariamo a costruire richieste chiare e a migliorarle attraverso il dialogo.

La stessa abitudine aiuta in ChatGPT e in Codex. In ChatGPT possiamo precisare il tipo di spiegazione, il pubblico e il formato. In Codex possiamo descrivere il risultato atteso, la cartella o il codice interessato, i vincoli e come verificare il lavoro. Il modo di formulare la richiesta cambia con il compito, ma l’obiettivo resta concreto: ridurre le ambiguità e rendere il risultato controllabile.

Obiettivi della lezione

• Distinguere una richiesta generica da una richiesta con contesto sufficiente.
• Definire obiettivo, destinatario, materiali, vincoli e forma dell’output.
• Usare richieste successive per chiarire o correggere il risultato.
• Adattare la consegna a un compito didattico, amministrativo o di programmazione.
• Controllare il risultato e indicare criteri di qualità prima di riutilizzarlo.

Durata indicativa: 60–75 minuti, con dimostrazione e laboratorio guidato.

1. Partire dal risultato desiderato

Prima di scrivere, chiediamoci: “Alla fine, che cosa voglio avere in mano?”. Potrebbe essere una spiegazione, una bozza, una scaletta, una checklist, un confronto, un piano o una modifica a un programma. Se il risultato è vago nella nostra mente, la risposta rischia di diventare generica. Possiamo anche dire all’assistente che cosa non sappiamo ancora: in quel caso gli chiediamo di farci una domanda alla volta, prima di preparare la versione completa.

Confrontiamo due richieste. “Parlami della fotosintesi” nomina un argomento, ma lascia aperte molte scelte: per chi è la spiegazione? Quanto deve essere lunga? Serve un esempio? “Spiega la fotosintesi a una classe seconda della scuola secondaria di secondo grado, con parole semplici, un esempio quotidiano e tre domande finali” delimita un compito riconoscibile. Non garantisce una risposta perfetta, ma dà al modello indicazioni migliori per iniziare.

Da ricordare: la richiesta è una consegna di lavoro. Il risultato desiderato guida le informazioni da aggiungere.

 

 

2. Gli elementi che rendono chiara una richiesta

Non dobbiamo inserire ogni elemento in ogni prompt. Scegliamo quelli che incidono davvero sul risultato. Per una risposta breve può bastare una frase; per un compito articolato conviene descrivere con più cura destinatario, materiali, limiti e criteri di verifica.

Obiettivo e destinatario

Diciamo che cosa deve fare l’assistente e chi userà il risultato. “Prepara una comunicazione” è poco preciso; “scrivi una bozza di email alle famiglie per comunicare il cambio di orario, con tono formale e frasi brevi” indica azione, destinatario e situazione. Se il livello del lettore conta, nominiamolo: principianti, colleghi, studenti di una classe specifica, tecnici che conoscono già il progetto.

Contesto e materiali

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 “usa il testo allegato come riferimento e segnalami i punti che non contiene”, così 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’errore; Codex può esaminare i file autorizzati, ma la richiesta deve chiarire quale esito cerchiamo.

Vincoli e criteri

I vincoli definiscono ciò che la risposta deve rispettare: lunghezza, tono, lingua, lessico, scadenza, strumenti ammessi o parti da non modificare. I criteri descrivono che cosa renderà il risultato accettabile. Per esempio: “includi obiettivi osservabili”, “non inserire dati personali”, “mantieni le intestazioni presenti”, “indica i test eseguiti”. Se una regola è davvero obbligatoria, scriviamola in modo esplicito.

Formato e livello di dettaglio

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.

Una traccia flessibile

OBIETTIVO + CONTESTO + VINCOLI + FORMATO Aggiungi destinatario, materiali e criteri quando cambiano la qualità del risultato. La traccia aiuta a ricordare cosa chiarire, ma non è un modulo da compilare sempre per intero.

 

 

3. Costruire la richiesta passo per passo

Partiamo dal nucleo: “Prepara una verifica sulla fotosintesi”. Poi individuiamo ciò che manca. A chi è destinata? Quanto deve durare? Quali argomenti sono già stati svolti? Quali tipi di esercizio servono? Come deve essere organizzato il documento? Possiamo aggiungere queste informazioni tutte insieme oppure chiedere all’assistente di farci le domande necessarie.

Prima bozza e versione più precisa

Richiesta iniziale	Richiesta arricchita
Prepara una lezione sull’energia.	Sono docente di scienze in una classe terza. Prepara una lezione di 50 minuti sulle trasformazioni dell’energia. Gli studenti conoscono già energia cinetica e potenziale. Organizza il risultato in: obiettivi, spiegazione, esempio guidato, attività a coppie e tre domande di verifica. Usa un linguaggio accessibile e segnala i concetti da controllare sul libro di testo.

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’attività troppo complessa, non occorre ricominciare: basta chiedere di ridurre i prerequisiti e proporre materiali più semplici.

Chiedere chiarimenti prima della risposta

Se le informazioni mancanti sono decisive, diciamolo. “Prima di scrivere la bozza, fammi fino a tre domande sui destinatari, sul tono e sui dati che posso condividere.” Questa modalità è 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ù.

Suddividere i lavori ampi

Per un compito grande, procediamo per tappe. Prima chiediamo una proposta di struttura, poi rivediamo la scaletta, infine sviluppiamo le sezioni approvate. In un’attività 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’assistente ha capito male e di correggere la rotta senza rifare tutto.

 

 

4. Un esempio per ogni ruolo

Docente: progettare una lezione

Un docente può descrivere materia, classe, durata, prerequisiti e forma della lezione. Per esempio: “Sono docente di storia in una classe seconda. Progetta 45 minuti sulla vita quotidiana nell’antica Roma, partendo dalle conoscenze indicate nel file allegato. Alterna una spiegazione breve e un’attività in piccoli gruppi. Concludi con una domanda di verifica e segnala ciò che hai ricavato dal file rispetto a ciò che stai proponendo tu.”

Dopo aver letto la bozza, il docente può precisare: “L’attività deve funzionare senza dispositivi. Riduci la spiegazione iniziale a dieci minuti e aggiungi una breve consegna per gli studenti.” Il dialogo serve a mettere a punto il materiale; il docente resta responsabile della correttezza storica e dell’adeguatezza alla classe.

Personale amministrativo: preparare una comunicazione

Chi lavora in amministrazione può indicare destinatario, scopo, tono, informazioni già confermate e struttura richiesta. Per esempio: “Prepara una bozza di avviso per il personale sull’aggiornamento dell’orario 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’invio. Lascia tra parentesi quadre le informazioni non ancora confermate.” Non inseriamo dati personali o riservati se non è autorizzato e necessario.

Programmatore: chiarire una modifica

Per Codex, descriviamo comportamento atteso, punto del progetto se noto, vincoli e verifica. Per esempio: “Esamina 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.”

Se non conosciamo ancora il punto del codice, chiediamo prima un’analisi. Poi, una volta chiarito l’intervento, diamo l’autorizzazione 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.

 

 

5. Migliorare la risposta attraverso il dialogo

Dopo la prima risposta, confrontiamola con il risultato che avevamo in mente. Se è troppo lunga, chiediamo di accorciarla specificando cosa conservare. Se è 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 “non mi convince” esprime un’impressione; una richiesta come “mantieni la struttura, semplifica il secondo paragrafo e aggiungi un esempio per studenti di 14 anni” indica che cosa fare.

Quando la risposta non funziona

• Troppo generica: aggiungi destinatario, contesto o un caso concreto.
• Troppo lunga: indica una lunghezza e quali informazioni devono restare.
• Fuori tema: ribadisci l’obiettivo e chiarisci quale materiale usare.
• Formato scomodo: descrivi la forma in cui vuoi leggere o riutilizzare il risultato.
• Informazione dubbia: chiedi fonti o verifica il dato prima di usarlo.
• Codice modificato oltre il necessario: indica quali file o comportamenti rientrano nella modifica e rivedi il diff.

Attività guidata

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’ultima versione: quali aggiunte hanno migliorato davvero il lavoro?

Traccia da riutilizzare

• Obiettivo: che cosa voglio ottenere?
• Destinatario e contesto: chi userà il risultato e che cosa deve sapere l’assistente?
• Materiali: quali file o fonti deve usare? Che cosa deve segnalare come non specificato?
• Vincoli: che cosa deve rispettare o evitare?
• Formato: come voglio ricevere il risultato e con quale livello di dettaglio?
• Verifica: quali criteri userò per controllarlo?

Verifica finale

Una richiesta più lunga è sempre migliore?

Risposta attesa: No. È utile aggiungere le informazioni che cambiano il risultato.

Che cosa conviene fare quando manca un’informazione decisiva?

Risposta attesa: Chiedere chiarimenti prima di far produrre la versione completa.

Perché indicare il formato?

Risposta attesa: Per ottenere un risultato più facile da leggere, controllare e riutilizzare.

La prima risposta deve essere definitiva?

Risposta attesa: No. Si può migliorare con correzioni precise e successive.

Che cosa resta sotto la nostra responsabilità?

Risposta attesa: Controllare accuratezza, adeguatezza, fonti e modifiche prima di riutilizzarle.

Fonte ufficiale

• OpenAI Help Center, Prompt engineering best practices for ChatGPT — https://help.openai.com/en/articles/10032626-prompt-engineering-best-practices-for-chatgpt

Nota: questa lezione propone una traccia flessibile; non esiste una formula che garantisca sempre il risultato. Le risposte e le modifiche vanno controllate prima dell’uso.