Dare istruzioni che funzionano

Immagina di dare un compito a un collega bravissimo ma appena arrivato in ufficio. Non conosce la tua azienda, non ha mai visto i tuoi clienti, non sa come scrivi di solito una mail. Nessuno gli ha detto niente di tutto questo, eppure gli chiedi «sistemami questo testo» e ti aspetti che indovini il resto. Un assistente AI si trova esattamente in questa posizione, a ogni conversazione nuova che apri.
Desiderio contro istruzione
«Sistemami questo testo» è un desiderio: dice cosa vuoi in generale, ma non dice come si riconosce che ci sei riuscito. «Rendi questo testo adatto a un cliente che non conosce ancora il progetto, massimo mezza pagina, tono formale ma non freddo» è un’istruzione. La differenza non sta nella lunghezza della frase, sta nel fatto che la seconda versione dice come giudicare il risultato. Chi legge quel testo, quanto deve essere lungo, che tono deve avere: sono tre informazioni che il tuo collega appena arrivato non può indovinare, e nemmeno un agente può.
Vale la pena notare cosa succede quando ometti queste informazioni: l’agente non si blocca, non ti chiede chiarimenti a meno che tu non glielo permetta esplicitamente. Produce comunque qualcosa, scegliendo lui il destinatario immaginario, la lunghezza, il tono. A volte indovina, spesso no, e quando non indovina la colpa sembra dello strumento mentre in realtà è mancata l’istruzione.
Le tre cose che mancano quasi sempre
La maggior parte delle richieste deludenti manca di una di queste tre cose, e nessuna richiede gergo tecnico per essere spiegata:
- Per chi è il risultato. Un riassunto per te, che conosci già il progetto, è diverso da un riassunto per il tuo capo, che lo vede per la prima volta.
- Che forma deve avere. Un elenco puntato, un paragrafo continuo, una mail con saluto e firma, una tabella con colonne precise: sono quattro risultati diversi anche partendo dallo stesso materiale.
- Cosa non va bene. Un controesempio concreto vale più di dieci righe di spiegazione astratta. Dire «non deve sembrare una scusa» è vago; dire «evita frasi come “purtroppo non è stato possibile”» è un’istruzione che si può seguire.
Un esempio vero
Devi preparare la scaletta di una riunione di domani con il tuo team, partendo da appunti sparsi presi in due chiamate diverse. La prima versione della richiesta, quella che verrebbe naturale, è «fammi una scaletta da questi appunti». Il risultato che arriva è ragionevole ma generico: punti nell’ordine in cui li hai scritti tu, senza gerarchia fra quello che è urgente e quello che può aspettare.
La seconda versione aggiunge le tre cose che mancavano: «Questa scaletta è per il mio team, che conosce già il progetto ma non ha seguito le due chiamate. Voglio un elenco di massimo sei punti, ordinati per urgenza, ognuno con una riga di contesto. Non voglio un riassunto di tutto quello che è stato detto, voglio solo le decisioni da prendere domani.» Il risultato cambia radicalmente: sei punti, ordinati, con la domanda a cui il team deve rispondere invece del resoconto di quello che è già successo. Stesso materiale di partenza, istruzione diversa, output utilizzabile subito invece che da riscrivere.
Quando l’errore è tuo e quando non lo è
Dare queste tre informazioni non garantisce un risultato perfetto, ma cambia la diagnosi quando qualcosa va storto. Se non hai detto per chi è il testo, che forma deve avere, e cosa non va bene, e il risultato non ti convince, la causa più probabile sei tu: hai lasciato scegliere all’agente cose che sapevi e non hai detto. Se invece hai dato tutte e tre le informazioni con chiarezza e il risultato è ancora sbagliato, a quel punto il problema probabilmente è un limite reale dello strumento su quel compito specifico, non una tua mancanza. Sapere distinguere i due casi ti evita due errori opposti: incolpare lo strumento troppo presto, o insistere a lungo su un compito che lo strumento semplicemente non sa fare bene.
Una cosa da fare, adesso
Prendi l’ultima richiesta che hai fatto a un assistente AI, quella che ti ha lasciato un po’ deluso. Riscrivila aggiungendo le tre cose: per chi è il risultato, che forma deve avere, un esempio di cosa non va bene. Manda entrambe le versioni, la vecchia e la nuova, e confronta gli output uno accanto all’altro. Nella maggior parte dei casi la differenza si vede a colpo d’occhio.
Un prompt da cui partire
[Descrivi il compito in una frase].
Il risultato è per [chi lo userà, cosa già sa e cosa no].
Deve avere questa forma: [elenco, paragrafo, mail, tabella — specifica].
Non va bene se: [un esempio concreto di errore da evitare].
Materiale di partenza: [testo, appunti, dati].
Dove andare adesso
Quando il risultato è ancora sbagliato dopo aver dato queste tre cose con chiarezza, il capitolo successivo del percorso pro, Dal prompt al workflow, ti mostra cosa fare quando lo stesso tipo di richiesta ti ricapita spesso: a quel punto non stai più scrivendo un prompt, stai progettando un processo.