Quando ho iniziato a pensare a come usare l’AI per scrivere articoli, tutorial e contenuti social, il problema non era ottenere testi ben scritti.
Un assistente AI può già produrre qualcosa di grammaticalmente corretto, ordinato e apparentemente professionale. La difficoltà era un’altra: capire se quel testo avrei potuto pubblicarlo davvero a mio nome.
Per insegnare a un assistente come scrivo, avrei potuto fornirgli una lunga raccolta di articoli e post già pubblicati. Avremmo potuto analizzare le parole che utilizzo più spesso, la lunghezza delle frasi, il ritmo dei paragrafi e altri elementi ricorrenti.
Era un approccio ragionevole, ma presentava due problemi.
Il primo era pratico: non avevo intenzione di scrivere dieci nuovi articoli soltanto per estrarne le caratteristiche. Il secondo era più difficile da riconoscere: un testo che ho pubblicato in passato non rappresenta necessariamente il modo in cui voglio scrivere oggi.
Avevamo quindi bisogno di un processo abbastanza leggero da non diventare un progetto infinito, ma sufficientemente preciso da distinguere ciò che mi rappresenta da ciò che trovo semplicemente ben scritto.
Un laboratorio di microprove
Abbiamo deciso di non partire da un questionario sul tono di voce.
Domande come “preferisci un tono formale o informale?” oppure “quanto vuoi essere autorevole?” possono essere utili, ma richiedono di descrivere in astratto qualcosa che spesso riconosciamo meglio quando lo vediamo.
Abbiamo quindi costruito una serie di microprove.
L’assistente mi mostrava due o tre brevi formulazioni della stessa idea. Io potevo scegliere quella che sentivo più vicina, indicare una frase che non avrei mai usato oppure spiegare che cosa mancava. In altri casi rispondevo liberamente a una domanda e lasciavo all’assistente il compito di riordinare il mio pensiero.
Una delle prime prove partiva da un problema molto semplice: come consiglieresti a qualcuno di iniziare a usare l’AI?
Fra diverse possibilità, ho preferito quella che suggeriva di cominciare da un’attività conosciuta bene. Se sai già svolgere un compito, puoi osservare il contributo dell’AI con maggiore consapevolezza. Puoi capire che cosa fa meglio di te, dove il tuo intervento rimane necessario e come migliorare progressivamente il processo.
La scelta non ci ha detto soltanto quali parole preferisco. Ha fatto emergere un modo di costruire il ragionamento:
- partire da una situazione concreta;
- definire un perimetro comprensibile;
- osservare il risultato senza idealizzarlo;
- riconoscere il ruolo della persona;
- trasformare il primo tentativo in un processo di miglioramento.
Questa struttura sarebbe ricomparsa più volte.
Non cercavamo il modo in cui parlo
A un certo punto è emersa una distinzione importante.
Il mio modo spontaneo di esprimermi non coincide necessariamente con il testo che vorrei pubblicare. Quando sviluppo un’idea, posso ripetermi, aprire parentesi o seguire una deviazione prima di tornare al punto principale. Quelle esitazioni non devono essere riprodotte meccanicamente per fare in modo che un testo sembri mio.
Allo stesso tempo, eliminarle non significa appiattire il pensiero.
La formulazione che abbiamo ricavato da una delle prove è diventata una delle indicazioni centrali della skill:
Riordinare il pensiero senza impoverirlo.
L’assistente può rendere il discorso più lineare, calmo ed equilibrato. Può eliminare le ripetizioni superficiali e rendere visibili i collegamenti fra le parti. Non dovrebbe però cancellare un’incertezza reale, trasformare una preferenza in una regola assoluta o rimuovere una distinzione soltanto perché rende la frase più lunga.
La voce che stavamo cercando, quindi, dipendeva meno dalla scelta di alcune parole e più dalla struttura del ragionamento.
Il prompt perfetto non esiste
Una delle prove più utili riguardava un’affermazione comune: per usare bene l’AI bisogna imparare a scrivere il prompt perfetto.
In linea di principio, l’idea sembra ragionevole. Un prompt scritto bene può certamente migliorare il risultato. Il problema nasce quando utilizziamo la parola “perfetto”.
Perfetto rispetto a cosa?
Per valutare un prompt servono dei criteri. Quei criteri cambiano in base al compito, al risultato desiderato e al punto di vista da cui lo osserviamo. Un prompt può essere chiaro ma incompleto, dettagliato ma troppo rigido, efficace in una situazione e poco utile in un’altra.
C’è poi un limite ancora più semplice: chi scrive il prompt non possiede una visione completa del problema. Può dimenticare un’informazione, esprimere male un concetto oppure scoprire soltanto durante il lavoro che il risultato desiderato era diverso da quello immaginato all’inizio.
La conclusione non era che i prompt non contano. Era che risulta più sostenibile costruirli gradualmente.
Puoi partire da una descrizione semplice, osservare ciò che l’assistente ha compreso e precisare poco alla volta quello che manca. Ogni errore o omissione diventa un’indicazione per il passaggio successivo.
Questa prova ha mostrato un altro tratto ricorrente della mia voce: riconoscere la parte ragionevole di una posizione prima di esaminarne i limiti. La critica non dovrebbe fermarsi alla confutazione. Dovrebbe proporre un modello più utile con cui sostituire quello iniziale.
Rendere accessibile non significa banalizzare
Volevamo anche capire come affrontare i concetti tecnici.
Abbiamo provato con una domanda molto comune: che cos’è un’API?
Una definizione semplice e un esempio concreto rendevano il concetto comprensibile, ma sentivo che mancava qualcosa. Per chi non è abituato a pensare al modo in cui comunicano due software, la spiegazione rischiava di rimanere sospesa.
Ho proposto allora di descrivere un’API come una specie di contratto fra due parti.
Una parte formula una richiesta. L’altra mette a disposizione informazioni o operazioni. Il contratto stabilisce che cosa può essere chiesto, quali dati devono essere forniti e in quale forma arriverà la risposta. Se la richiesta non rispetta quelle condizioni, non viene considerata valida.
L’analogia funziona perché offre un’immagine conosciuta con cui entrare in un concetto astratto. Non deve però essere trattata come un’equivalenza perfetta. Un contratto fra persone e un’interfaccia fra software non sono la stessa cosa.
Da questa prova è nata una sequenza utile per le spiegazioni tecniche:
- presentare il concetto con parole familiari;
- mostrare un esempio concreto;
- aggiungere un’immagine quotidiana quando può aiutare;
- chiarire i limiti o le condizioni;
- indicare che cosa può fare il lettore con ciò che ha appena compreso.
Semplificare, in questo caso, non significa togliere complessità dal concetto. Significa ridurre lo sforzo necessario per entrarci.
Una preferenza non è ancora una regola
Durante il processo era facile cadere in una trappola.
Se approvavo una frase breve, avremmo potuto concludere che preferisco sempre le frasi brevi. Se apprezzavo un’analogia, avremmo potuto decidere che ogni spiegazione deve contenerne una. Se una domanda retorica funzionava bene, avremmo potuto trasformarla in un tratto ricorrente di ogni articolo.
Il risultato sarebbe stato una caricatura.
Abbiamo quindi distinto le ipotesi dalle caratteristiche confermate.
Una singola reazione produce un’indicazione da osservare. Una preferenza diventa più affidabile quando compare in contesti diversi oppure quando la confermo esplicitamente. Anche in quel momento, la regola deve conservare le condizioni che la rendono utile.
Per esempio, non abbiamo registrato semplicemente che “Francesco usa le analogie”. L’indicazione è più precisa: un’analogia quotidiana può aiutare quando un concetto astratto rischia di rimanere sospeso, ma non deve fingere di riprodurre perfettamente il funzionamento tecnico.
La differenza sembra piccola, ma impedisce alla skill di applicare meccanicamente una scelta che aveva senso soltanto in un determinato contesto.
Come abbiamo organizzato i file
Dalle microprove sono nati quattro file:
francesco-voice/
├── SKILL.md
└── references/
├── voice-profile.md
├── approved-examples.md
└── format-adaptations.mdSKILL.md contiene le istruzioni necessarie per applicare la voce. Stabilisce l’ordine delle fonti, spiega come conservare il significato originale e indica ciò che non deve essere inventato.
voice-profile.md descrive le caratteristiche confermate, come il tono calmo, il rapporto con il lettore e il modo in cui viene sviluppato un ragionamento. Conserva anche le domande ancora aperte.
approved-examples.md raccoglie alcuni testi che ho riconosciuto come rappresentativi. Ogni esempio è accompagnato dal motivo per cui funziona. Non deve diventare un modello da copiare: serve a rendere concreta una regola che, da sola, potrebbe essere interpretata in molti modi.
format-adaptations.md distingue infine ciò che cambia fra knowledge base, tutorial, articoli e contenuti social.
La voce di fondo dovrebbe rimanere riconoscibile, ma i formati non richiedono la stessa densità. Un tutorial deve accompagnare il lettore attraverso una sequenza affidabile. Un articolo può lasciare più spazio allo sviluppo del ragionamento. LinkedIn richiede una linea di pensiero completa ma più compatta. Su X può essere necessario usare una concatenazione di post quando ridurre tutto a un singolo messaggio eliminerebbe un passaggio essenziale.
Separare questi materiali ci aiuta a non confondere livelli diversi.
Il profilo dice ciò che sappiamo della voce. Gli esempi mostrano da quali evidenze deriva. Gli adattamenti spiegano come cambia nei diversi formati. La skill stabilisce come usare tutto questo durante il lavoro.
Il primo confronto con un contenuto reale
Le microprove erano utili, ma rimanevano esperimenti controllati.
Il primo test reale è arrivato applicando la skill a una bozza editoriale già esistente. In quel caso non dovevamo soltanto verificare il tono. Dovevamo conservare precisione tecnica, fonti, struttura e requisiti del formato.
Il test ci ha aiutato a distinguere due responsabilità.
Le regole editoriali determinavano la struttura richiesta dalla pubblicazione. La voice skill governava invece il modo in cui il ragionamento veniva sviluppato: il linguaggio, le connessioni fra le sezioni, la chiarezza delle spiegazioni e il livello di certezza attribuito alle conclusioni.
La revisione ha confermato che la voce poteva funzionare anche su un testo completo. Non ha però risposto a tutte le domande.
Quel lavoro partiva da una bozza già sviluppata. Dimostrava che la skill era in grado di riconoscere e migliorare una voce, non ancora che potesse costruirla partendo da una richiesta e da un insieme di fonti.
Questo articolo rappresenta il passaggio successivo.
Una skill provvisoria per definizione
La prima versione della skill non cerca di descrivere ogni aspetto della mia voce.
Non sappiamo ancora quale spazio possano avere l’umorismo e l’ironia. Non abbiamo esempi sufficienti per definire differenze stabili fra LinkedIn e X. Un primo test positivo in inglese non basta per stabilire tutte le mie preferenze in quella lingua.
Questi non sono spazi vuoti da riempire con una supposizione.
Sono domande da osservare durante il lavoro reale.
La versione italiana di questo articolo viene prima proprio per questo motivo. Soltanto dopo la sua approvazione prepareremo quella inglese, cercando di conservare la logica e la temperatura emotiva del testo senza tradurne meccanicamente la struttura delle frasi.
Anche i contenuti social diventeranno nuove prove. Potremo capire quanto ragionamento deve rimanere in un post LinkedIn e quando un thread su X conserva meglio l’idea rispetto a una sintesi più aggressiva.
Se quelle preferenze ricompariranno, potranno essere registrate. Se funzioneranno soltanto per questo articolo, rimarranno scelte locali.
Un sistema che impara mentre viene utilizzato
All’inizio pensavo che definire una voce significasse descriverla nel modo più completo possibile.
Il processo ci ha portato in una direzione diversa.
Una voice skill non è una fotografia immutabile della persona e non è una formula capace di produrre automaticamente il testo giusto. È un sistema che conserva ciò che abbiamo imparato, rende visibile ciò che non sappiamo ancora e ci aiuta a verificare entrambe le cose su contenuti reali.
La sua utilità non dipende quindi dall’essere completa fin dal primo giorno.
Dipende dalla capacità di cambiare senza perdere le evidenze che hanno giustificato ogni scelta. Paradossalmente, per rendere una voce più riconoscibile e riproducibile, dobbiamo evitare di trattarla come qualcosa di fisso.