Nella pratica, quando l’obiettivo è ottenere un output affidabile (un testo pubblicabile, un’analisi, un piano operativo, del codice che non si rompa al primo edge case), la differenza la fa la struttura, non l’ispirazione del momento. Un prompt non deve essere una singola frase ispirata, ma un piccolo documento di progetto, con sezioni distinte che riducono ambiguità, allineano aspettative e rendono il risultato più ripetibile.
Se chiedi a un modello di ragionare “al buio”, userà assunzioni. Se invece gli dai un perimetro (scopo, contesto, vincoli, criteri di successo), lo costringi a giocare sul tuo campo. E quando il campo è definito bene, l’output smette di sembrare un tentativo e inizia ad assomigliare a un deliverable.
Partiamo dalla rappresentazione grafica qui sotto riportata.
Task
La sezione “Task” è la più ovvia e, proprio per questo, la più sottovalutata. Non è “scrivimi un articolo su X”, ma “voglio fare X per ottenere Y”. Quella coda (“così da…”) cambia tutto perché trasforma la richiesta in un obiettivo misurabile.
Invece di “Spiegami OAuth”, un task più robusto è “Voglio una spiegazione di OAuth 2.0 che un team di prodotto non tecnico possa usare per decidere se integrare un login social, con pro e contro e un glossario minimale”. Qui il modello capisce subito che deve evitare formalismi inutili e puntare su decisioni e trade-off.
Context files
Il blocco “Context Files” è la versione adulta del “ti do due informazioni in più”. In un ambiente di lavoro reale, il modello spesso deve rispettare documenti esistenti come linee guida editoriali, policy legali, tone of voice, una knowledge base interna, la struttura di un prodotto, un set di API.
L’idea, qui, è dichiarare esplicitamente cosa deve leggere prima di rispondere. Anche se non stai davvero allegando file, la lezione resta valida: separa il “materiale di riferimento” dalla richiesta.
Un esempio concreto in ambito customer support: “Prima di rispondere, usa queste note: politica rimborsi (entro 14 giorni, eccezioni per licenze attivate), tono: empatico e diretto, non promettere tempi di risoluzione”. Il risultato cambia perché il modello smette di inventare policy “ragionevoli” e si ancora a quelle reali.
Reference
Dare un riferimento, cioè un esempio di output “buono”, e poi spiegare che cosa lo rende tale. Non è solo “imita questo stile”, ma “questo testo funziona perché fa A, evita B, mantiene C”.
Un modo pratico per usarlo: prendi un articolo che ti piace e reverse-engineeralo in regole operative. Per esempio: “Paragrafi brevi, definizioni subito, un esempio ogni concetto, niente frasi autocelebrative, chiusura con implicazioni pratiche”. Quando traduci lo stile in regole, il modello smette di “provare a sembrare simile” e inizia a rispettare vincoli.
Se cerchiamo un esempio concreto in ambito engineering potremo pensare alla necessità di avere una documentazione API uniforme, allegare un endpoint già documentato bene e dire “questo è lo standard, replica la stessa struttura (overview, auth, request, response, errori, esempi)” ti evita pagine incoerenti.
Success brief
Il “Success Brief” è la sezione che trasforma un prompt da richiesta a consegna. Qui non stai descrivendo cosa scrivere, ma cosa deve succedere dopo che qualcuno lo legge.
Ci sono quattro leve ricorrenti: tipo di output e lunghezza, reazione del destinatario, cosa evitare (il famoso “non deve suonare generico o da AI”), e che cosa conta come successo (approvazione, decisione, azione).
Un esempio molto concreto: “Scrivi una landing page di 400-600 parole per un tool di observability. Il lettore deve capire in 30 secondi perché è diverso da Datadog per team piccoli. Evita gergo e superlativi. Successo significa che richiede una demo”. Notare come cambia la traiettoria, il modello non riempie con descrizioni vaghe, ma cerca argomentazioni e struttura orientate alla conversione.
Rules
La sezione “Rules” è la tua assicurazione contro gli incidenti tipici come inventare fonti, dare consigli legali o medici fuori contesto, usare un tono sbagliato, ignorare brand guidelines, includere informazioni non verificate.
Regole efficaci, poche, chiare, e verificabili. “Non citare dati numerici senza fonte”, “se non sai, chiedi”, “non usare elenchi puntati”, “non utilizzare metafore”, “mantieni un registro neutro”.
Per un team che produce report potrebbe essere efficace: “Se manca un dato, segnala l’incertezza. Non colmare i buchi con stime. Se trovi conflitti tra fonti, mettili in evidenza”. È il modo più rapido per ridurre output “sicuri” ma sbagliati.
Plan e Alignment
“Plan” e “Alignment” servono a rendere il processo osservabile. Se il modello esplicita i passaggi che seguirà, tu puoi intercettare errori di direzione prima che diventino pagine da riscrivere.
Per un articolo, un piano efficace può essere: definizione del concetto, perché importa, scomposizione in sezioni, esempi, errori comuni, checklist finale. Poi l’allineamento: “Conferma che questa è la direzione”. In un flusso ideale, questa fase ti fa risparmiare più tempo di quanto ne consumi.
Anche quando non vuoi “interrompere” il modello per chiedere conferme, puoi integrare il concetto in modo unilaterale: “Segui questo piano in 5 parti e non deviare”. Funziona sorprendentemente bene, soprattutto con richieste lunghe.
Conversation
Non strettamente necessario, ma utile, è definire anche le regole della conversazione. Questo è un approccio utile quando la richiesta è ambigua o quando l’errore costa tempo e reputazione. In contesti editoriali o aziendali, però, non sempre vuoi un dialogo lungo. Quindi puoi usare una variante: “Se manca un’informazione critica, fai una sola domanda, altrimenti procedi dichiarando le assunzioni”. In pratica, stai definendo una policy di conversazione.
Un esempio: “Se il pubblico non è specificato, assumi ‘lettore tech generalista’. Se il paese non è specificato per temi legali, limita la risposta a principi generali e segnala la variabilità”. È un modo pulito per evitare blocchi continui senza sacrificare accuratezza.
Mettiamo tutto insieme
[TITOLO / NOME PROMPT]
Relazione per Consiglio di Amministrazione (template strutturato)
========================
1) TASK
========================
Voglio che tu scriva una relazione per il Consiglio di Amministrazione su: [TEMA_CENTRALE]
Lo scopo è: [OBIETTIVO_RELazione] (es. aggiornare, supportare una decisione, ottenere approvazione, definire priorità)
La relazione deve portare a questo esito pratico: [ESITO_ATTESO] (es. delibera, via libera al budget, cambio strategia, presa d’atto)
Contesto temporale: [PERIODO_RIFERIMENTO] (es. Q1 2026, mese corrente, H2 2025)
Azienda / unità: [AZIENDA_O_BU] | Paese/mercati coinvolti: [MERCATI]
========================
2) CONTEXT FILES / CONTESTO (INCOLLA QUI)
========================
Leggi e usa come vincolanti le informazioni qui sotto prima di scrivere:
[CONTESTO_AZIENDALE_E_STRATEGIA]
- (es. priorità strategiche, roadmap, vincoli, iniziative in corso)
[DATI_E_NUMERI]
- KPI principali: [KPI_LISTA]
- Andamento vs target: [SCOSTAMENTI]
- Note su qualità dati (se applicabile): [LIMITI_DATI]
[DECISIONI_PREGRESSE_E_FOLLOW-UP]
- Decisioni CdA precedenti rilevanti: [DECISIONI_PASSATE]
- Azioni concordate e stato: [AZIONI_E_STATO]
[VINCOLI_E_POLICY]
- Vincoli legali/regolatori: [VINCOLI_LEGALI]
- Policy interne: [POLICY_INTERNE]
- Sensibilità/confidenzialità: [LIVELLO_CONFIDENZIALITA]
========================
3) REFERENCE (ESEMPIO DI OUTPUT + BLUEPRINT)
========================
Ecco un riferimento del tipo di relazione che considero “buona” (incollalo qui, se disponibile):
[TESTO_RIFERIMENTO_O_ESTRATTI]
Queste sono le regole estratte dal riferimento, da seguire in modo rigoroso:
- Always aprire con un Executive Summary di massimo [N_RIGHE_EXEC_SUMMARY] righe, focalizzato su decisioni e impatti.
- Always separare chiaramente fatti (dati) da interpretazioni (letture) e da raccomandazioni (azioni).
- Always usare un linguaggio sobrio, non promozionale, adatto a un CdA.
- Always esplicitare rischi, trade-off e dipendenze.
- Never usare gergo tecnico non spiegato o acronimi senza definizione.
- Never “riempire” con frasi vaghe: ogni sezione deve contenere informazioni verificabili o motivazioni chiare.
========================
4) SUCCESS BRIEF
========================
Tipo di output: relazione in formato [FORMATO_OUTPUT] (es. memo, report, briefing) lunga circa [LUNGHEZZA] (parole/pagine)
Destinatari: [DESTINATARI] (es. CdA, CEO, CFO, Comitato Controllo e Rischi)
Cosa devono pensare/sentire/fare dopo la lettura:
- Capire: [COMPRENSIONE_DESIDERATA]
- Decidere: [DECISIONE_RICHIESTA]
- Agire: [AZIONI_CHE_DEVONO_PARTIRE]
Tono: [TONO] (es. istituzionale, diretto, pragmatico)
“Non deve suonare come”:
- [COSA_EVITARE_1] (es. marketing, eccessivamente entusiasta)
- [COSA_EVITARE_2] (es. troppo tecnico, prolisso)
- [COSA_EVITARE_3] (es. generico, “da AI”)
Successo significa che:
- [METRICA_DI_SUCCESSO_1] (es. approvazione della proposta)
- [METRICA_DI_SUCCESSO_2] (es. allineamento su priorità e next step)
- [METRICA_DI_SUCCESSO_3] (es. nessuna richiesta di chiarimenti sui numeri chiave)
========================
5) RULES (VINCOLI OPERATIVI)
========================
Segui queste regole senza eccezioni:
1) Se un dato numerico non è presente nel contesto, non inventarlo. Scrivi “dato non disponibile” e indica che cosa servirebbe per completarlo.
2) Se ci sono incertezze o assunzioni, dichiarale nella sezione “Assunzioni e limiti”.
3) Mantieni la struttura richiesta e usa titoli chiari.
4) Non usare tono autocelebrativo. Niente superlativi non supportati.
5) Evita riferimenti a “come AI”, “come modello linguistico”, o meta-commenti sul prompt.
6) Se emergono rischi rilevanti, inserirli sempre con probabilità/impatti in forma qualitativa: [SCALA_RISCHIO] (es. basso/medio/alto).
7) Evita elenchi infiniti: massimo [MAX_BULLET] punti per lista, se necessari.
8) Lingua: [LINGUA] (es. italiano) | Variante: [VARIANTE_LINGUA] (es. formale, neutra)
========================
6) CONVERSATION (COME GESTIRE LE DOMANDE)
========================
Se mancano informazioni critiche, fai al massimo [NUM_DOMANDE_MAX] domande mirate.
Se non sono consentite domande o non ricevi risposta, procedi comunque:
- dichiarando le assunzioni
- evidenziando i dati mancanti
- proponendo opzioni alternative basate su scenari
========================
7) PLAN (PIANO DI ESECUZIONE)
========================
Prima di scrivere la relazione completa:
A) Elenca le 3 regole più importanti (tra quelle sopra) per questa specifica richiesta.
B) Proponi un piano in massimo 5 passi su come costruirai la relazione.
C) Poi scrivi la relazione seguendo questa struttura:
STRUTTURA RELAZIONE:
1. Executive Summary (max [N_RIGHE_EXEC_SUMMARY] righe)
2. Contesto e obiettivo della relazione
3. Stato attuale (dati, fatti, evidenze)
4. Analisi e interpretazione (cause, trend, implicazioni)
5. Opzioni sul tavolo (min [N_OPZIONI], max [N_OPZIONI_MAX]) con pro/contro
6. Raccomandazione (scelta proposta e motivazione)
7. Impatti (economici, operativi, reputazionali) + dipendenze
8. Rischi e mitigazioni
9. Next step e decisioni richieste al CdA (con elenco chiaro delle delibere)
10. Assunzioni e limiti (cosa manca, come colmarlo)
11. Allegati / Appendice (se applicabile): [ALLEGATI]
========================
8) ALIGNMENT (CONTROLLO FINALE)
========================
Prima di consegnare, verifica e dichiara:
- Che ogni sezione richiesta è presente.
- Che nessun dato è stato inventato.
- Che le decisioni richieste sono formulate in modo esplicito.
- Che il tono è coerente con [TONO] e con un documento per CdA.
Poi consegna la versione finale.
========================
INPUT RAPIDO (RIEMPI LE VARIABILI)
========================
[TEMA_CENTRALE]=
[OBIETTIVO_RELAZIONE]=
[ESITO_ATTESO]=
[PERIODO_RIFERIMENTO]=
[AZIENDA_O_BU]=
[MERCATI]=
[KPI_LISTA]=
[SCOSTAMENTI]=
[LIMITI_DATI]=
[DECISIONI_PASSATE]=
[AZIONI_E_STATO]=
[VINCOLI_LEGALI]=
[POLICY_INTERNE]=
[LIVELLO_CONFIDENZIALITA]=
[FORMATO_OUTPUT]=
[LUNGHEZZA]=
[DESTINATARI]=
[COMPRENSIONE_DESIDERATA]=
[DECISIONE_RICHIESTA]=
[AZIONI_CHE_DEVONO_PARTIRE]=
[TONO]=
[COSA_EVITARE_1]=
[COSA_EVITARE_2]=
[COSA_EVITARE_3]=
[METRICA_DI_SUCCESSO_1]=
[METRICA_DI_SUCCESSO_2]=
[METRICA_DI_SUCCESSO_3]=
[SCALA_RISCHIO]=
[MAX_BULLET]=
[LINGUA]=
[VARIANTE_LINGUA]=
[NUM_DOMANDE_MAX]=
[N_RIGHE_EXEC_SUMMARY]=
[N_OPZIONI]=
[N_OPZIONI_MAX]=
[ALLEGATI]=Perché funziona
Il valore di questa struttura è operativo. Stai separando intenzione (task), informazioni (contesto), standard (reference), obiettivo misurabile (success), vincoli (rules) e processo (plan). Ognuna di queste sezioni riduce uno specifico tipo di errore: fraintendimenti, inventare dettagli, output troppo generico, tono fuori target, risultati non azionabili.
I prompt strutturati diventano riutilizzabili. Quando una squadra trova una “ricetta” che produce buoni risultati, può versionarla come un template e farci onboarding. A quel punto non stai più “parlando con un modello”, stai costruendo un’interfaccia di lavoro.
Se l’articolo ti è piaciuto restiamo in contatto su linkedin a: https://www.linkedin.com/feed/
#prompting #promptengineering #llm #claude #aiwriting #productivity #workflow #context #alignment #successcriteria
Nerd per passione e per professione da oltre 30 anni, lavoro nel mondo dell’innovazione tecnologica come CTO e consulente, progettando ecosistemi software complessi e scalabili. Parallelamente mi dedico alla formazione informatica, condividendo esperienze e buone pratiche maturate sul campo.
Scopri di più sulla mia attività di consulenza su lucedigitale.com Mi trovi anche su LinkedIn
By
