Come costruire un prompt riutilizzabile per i task ripetitivi

Capita quasi sempre così: il prompt si scrive, si usa una volta e si perde. La volta dopo si riscrive da capo, un po’ diverso, e il risultato è un po’ diverso.

Un prompt riutilizzabile è un’altra cosa: è un modello con dei buchi da riempire, che produce risultati confrontabili ogni volta che lo usi. Costruirne uno costa una mezz’ora la prima volta e cambia il modo in cui usi l’AI per il lavoro ripetitivo.

Il problema con i prompt scritti al volo

Chiedere all’AI di riassumere un documento funziona. Chiederlo dieci volte in dieci modi diversi produce dieci riassunti che non si possono confrontare fra loro: uno è lungo, uno è schematico, uno risponde a domande che non avevi fatto.

Se il compito torna, il prompt deve essere stabile. Altrimenti stai rifacendo ogni volta una scelta che avevi già fatto.

Le cinque parti di un prompt riutilizzabile

Un prompt che regge nel tempo ha una struttura, e le parti sono sempre queste. Sono cinque e non quattro come nella guida di base linkata in fondo: la differenza è il ruolo, che su un modello riusato da più persone cambia il risultato abbastanza da meritare una riga a sé.

Ruolo. Chi deve essere il modello mentre lavora. Non è decorazione: “sei un revisore di contratti che cerca clausole ambigue” produce un’attenzione diversa da “sei un assistente”.

Compito. Una sola azione, espressa con un verbo. Se nel compito compare una “e” che unisce due verbi, quasi sempre vanno separati in due prompt.

Contesto variabile. La parte che cambia ogni volta, delimitata in modo chiaro. È il buco da riempire.

Formato dell’output. Come deve essere strutturata la risposta. È la parte che rende i risultati confrontabili, e quasi tutti la saltano.

Regole e limiti. Cosa non deve fare, e soprattutto cosa deve fare quando un’informazione non c’è.

Come si scrive, in pratica

Parti da un caso vero. Non scrivere il modello in astratto: fai il lavoro una volta a mano con l’AI, ottieni un risultato che ti soddisfa, e solo dopo trasforma quella conversazione in modello.

Poi separa il fisso dal variabile. Rileggi quello che hai scritto e segna cosa cambierà la prossima volta. Quelle parti diventano segnaposto espliciti, scritti in modo che si vedano:

Sei un [RUOLO].
Il tuo compito è [AZIONE SINGOLA].

Testo su cui lavorare:
---
[CONTENUTO]
---

Restituisci il risultato in questo formato:
[STRUTTURA]

Regole:
- se un'informazione non è presente nel testo, scrivi "non indicato"
- non aggiungere commenti prima o dopo il risultato

I delimitatori attorno al contenuto non sono un vezzo: riducono il rischio che il testo su cui stai lavorando venga letto come istruzione. Se incolli un’email che contiene la frase “ignora quanto sopra”, senza delimitatori il modello può prenderla sul serio.

Riducono, non eliminano. Il problema si chiama prompt injection, e a oggi non ha una soluzione definitiva: un testo costruito apposta può chiudere il delimitatore e uscire dal recinto. Per il lavoro d’ufficio su documenti tuoi la mitigazione basta; se il testo che entra arriva da fuori e l’output fa partire qualcosa da solo, serve un controllo umano in mezzo, non un delimitatore più robusto.

La regola che fa la differenza

Su cosa fare quando manca un dato.

Un modello a cui non dici niente, davanti a un’informazione assente, tende a produrre la risposta più plausibile. Non mente per malizia: completa il pattern. Il risultato è un dato inventato che ha esattamente lo stesso aspetto di un dato vero, e quindi non lo becchi rileggendo.

L’istruzione esplicita costa una riga e cambia il comportamento:

Se un'informazione non è presente, scrivi "non indicato".
Non dedurla, non stimarla, non completarla con quello che ti sembra probabile.

Se stai costruendo un prompt che qualcun altro userà, questa riga non è opzionale.

Come si prova che funziona

Un prompt riutilizzabile va provato su casi difficili, non su casi comodi.

Prendi tre input reali: uno tipico, uno incompleto, uno anomalo. Il tipico serve a verificare che il formato esca giusto. L’incompleto serve a verificare che il modello dichiari cosa manca invece di riempirlo. L’anomalo serve a scoprire dove si rompe.

Se sull’incompleto il modello inventa, il prompt non è pronto e nessuna quantità di uso lo migliorerà.

Dove tenerli

Un prompt riutilizzabile che vive nella cronologia di una chat è perso. Serve un posto: un documento condiviso, una nota, una cartella di file di testo.

Il criterio è che un collega deve poterlo trovare e usare senza chiederti niente. Se per usarlo serve una spiegazione a voce, non è ancora un modello: è un appunto tuo.

Quando un prompt viene usato spesso da più persone, il passo successivo è dargli un’interfaccia, cioè un campo da riempire e un pulsante. A quel punto si entra nel territorio delle microapp, ma è un passo che ha senso solo dopo che il prompt ha dimostrato di funzionare così com’è.

Quando non conviene

Se un compito lo fai una volta ogni tanto e ogni volta è davvero diverso, costruire un modello è tempo sprecato: scrivi il prompt al volo e vai avanti.

La soglia pratica è la terza volta. Alla terza volta che riscrivi qualcosa di simile, quello è il momento di fermarsi e farne un modello.

Per la parte più generale su come porre le domande all’AI, prompt engineering: come parlare con l’AI per ottenere risultati utili copre le basi. E se lavori dentro Microsoft 365, vale la pena sapere prima cosa lo strumento fa e cosa no: Microsoft Copilot 365, cosa fa davvero e cosa non fa.

Un prompt scritto bene è una decisione presa una volta sola. È il motivo per cui vale la mezz’ora.