E tu chi diavolo sei?
Come Claude e Gemini gestiscono il tuo "contesto personale", perché devi imparare a scriverlo bene (e in inglese) e controllarlo spesso.
⏱ Lettura: gg minuti.
TL;DR
C’è un campo di testo, sepolto sotto un paio di click nei Settings di Google Gemini e Anthropic Claude, che la maggior parte degli utenti lascia vuoto o riempie una volta e dimentica per sempre. È il posto dove dici al modello chi sei, prima ancora di aprire bocca. Anthropic e Google lo hanno progettato in modo piuttosto diverso, l'uno statico e dichiarativo, l'altro dinamico e inferenziale e, per quanto breve, quel testo viene ricaricato a ogni singolo turno della conversazione. È solo un dettaglio, ma è un dettaglio che ti costa tempo, token e qualità della risposta se lo ignori.
1. Che cos’è, e perché non è un optional
Il “prompt di contesto personale”, detto anche system-level personalization, profile instructions, Saved Info è un blocco di testo persistente che dovresti scrivere una sola volta e che il modello riceve, silenziosamente, prima di ogni tua richiesta. Non è memoria nel senso in cui la intendiamo noi (non è un ricordo che il sistema costruisce osservandoti), è più simile a un biglietto da visita che consegni ogni mattina al tuo maggiordomo, perché il tuo maggiordomo è molto sollecito, ma anche terribilmente smemorato.
Perché è importante? Perché un modello linguistico, per costruzione, non ha alcuna informazione pregressa su di te se non quella che gli fornisci nella finestra di contesto attiva1. Ogni conversazione nuova è, cognitivamente, un incontro con uno sconosciuto. Il prompt di contesto personale è il modo per abbreviare quel primo, imbarazzante giro di presentazioni e per farlo con coerenza, invece di improvvisare ogni volta (cosa che ci farebbe ottenere risposte diverse alle stesse domande).
Perché va usato, in pratica: riduce il tasso di errore di calibrazione (il modello smette di scegliere il registro sbagliato, il livello di dettaglio sbagliato, le assunzioni sbagliate sul tuo background), e libera te dal dover ripetere le stesse cose a ogni chat. Non è marginale: è probabilmente la singola impostazione con il miglior rapporto costo/beneficio che un utente avanzato può configurare.
Anthropic vs Google: due filosofie diverse
La differenza nella scelta di gestione di questo parametro tra Anthropic e Google non è estetica, ma architetturale.
Anthropic tratta il contesto personale come testo dichiarativo e statico. Su Claude.ai esistono tre livelli distinti e sovrapponibili: le Instructions a livello di profilo (account-wide, si applicano a tutte le conversazioni; in parole semplici: quello che scrivi nelle preferenze), le Project instructions (valide solo dentro un progetto specifico) e le Skills2, che dal 2026 hanno sostituito gli Styles come meccanismo per definire comportamenti attivabili on-demand. Il principio è: tu scrivi, il sistema applica alla lettera, nessuna inferenza nel mezzo. Le istruzioni sono impostazioni a livello di account che aiutano Claude a comprendere le indicazioni generali da considerare nelle risposte, e qualsiasi istruzione aggiunta viene applicata a tutte le conversazioni dell’utente. È un sistema trasparente ma “cieco”: Claude non sa se quello che hai scritto sei ancora tu oggi, applica il testo così com’è, punto.
Google, con Gemini, ha costruito qualcosa di più simile a un sistema di raccomandazione che a un modulo di configurazione. Sopra alla componente statica (Saved Info, dove scrivi o detti informazioni su di te, fatti personali, preferenze di stile, contesto di progetti in corso, insomma, di nuovo quello che scrivi nelle preferenze) c’è uno strato dinamico e opt-in chiamato personalizzazione, in cui un modello di ragionamento decide, turno per turno, se attingere o meno a fonti come la cronologia delle ricerche, le chat passate o le app collegate. Il modello di ragionamento avanzato analizza il prompt e determina se la cronologia delle ricerche può migliorare la risposta, e fornisce una sintesi di come Gemini personalizza le risposte, mostrando quali fonti, informazioni salvate, chat passate o altro, sono state effettivamente usate.
In altre parole: Anthropic ti dà un dizionario che il modello consulta sempre; Google ti dà un archivio che il modello decide se aprire o no.
La conseguenza pratica è con Claude, quello che scrivi nel campo Instructions è garantito essere presente a ogni turno. Con Gemini, la Saved Info è comunque persistente e dichiarativa (stesso principio di Anthropic), ma se attivi la personalizzazione dinamica stai delegando al modello anche la decisione se e quanto contesto extra iniettare, un compromesso fra rilevanza automatica e prevedibilità che vale la pena conoscere prima di lamentarsi che “Gemini si ricorda cose a caso” oppure “sa tutto di te” (certo che lo sa! : )
Soldi! Sì, soldi!
Questo è il punto che quasi nessuno spiega chiaramente, e che invece cambia il modo in cui dovresti scriverlo. Il testo che inserisci nelle Instructions non viene letto una volta e “capito” in modo permanente: viene prepended, cioè anteposto, al prompt di sistema a ogni singola chiamata che fai al modello, dalla prima battuta della conversazione all’ultima. Ogni tuo messaggio, ogni risposta di Claude, ogni turno di un thread lungo trecento messaggi: il blocco di contesto personale viaggia lì, sempre, silenziosamente, in ogni singola richiesta inviata al modello.
Questo ha due implicazioni concrete:
Costo in token. Ogni parola nel tuo prompt di contesto è un pezzo di finestra di contesto che non è disponibile per il resto della tua domanda, il documento che hai allegato, la cronologia della chat. Su una singola richiesta l’overhead è trascurabile; su una sessione lunga, moltiplicato per decine di turni, smette di esserlo.
La sintesi deve essere una virtù, ma non un sacrificio. Quando salvi del testo nel campo preferenze, Claude lo antepone al prompt di sistema di ogni nuova conversazione. Il che significa che la sintesi non è un vezzo minimalista, è risparmio computazionale reale, moltiplicato per ogni turno. Ma, ed è la parte che conta, la sintesi non deve mai avvenire a scapito della funzionalità. Una riga tagliata per accorciare il testo, se elimina un’istruzione che effettivamente cambiava il comportamento del modello, non è ottimizzazione: è un errore. Il test operativo è semplice: per ogni frase del tuo prompt di contesto, chiediti “se la tolgo, la risposta del modello cambia in modo osservabile?” Se la risposta è no, taglia. Se è sì, resta.
Perché in inglese è meglio
Qui parlo con un livello di confidenza medio, non assoluto: è una raccomandazione tecnica ragionata, non un dato che ho potuto verificare con una fonte primaria specifica su questo singolo aspetto. I modelli linguistici di ultima generazione, Claude compreso, sono addestrati su corpora a schiacciante prevalenza anglofona, e i loro tokenizzatori (gli algoritmi che spezzano il testo in unità elaborabili dal modello, tipicamente BPE — Byte Pair Encoding3) sono ottimizzati su quella distribuzione. Il risultato pratico, ben documentato nella letteratura sulla tokenizzazione multilingue, è che una stessa istruzione in inglese occupa mediamente meno token della sua traduzione in italiano, e viene processata con minore ambiguità semantica interna al modello che “ragiona” internamente in una rappresentazione più vicina all’inglese di addestramento, indipendentemente dalla lingua in cui poi ti risponde.
Per un prompt di contesto che viene ricaricato a ogni turno, questo non è un dettaglio da purista: è un moltiplicatore di efficienza, seppur difficile da quantificare. La raccomandazione pratica è: scrivi le istruzioni di comportamento in inglese conciso e diretto (”Address me as X”, “Never use Y”, “Default to Z”), e riserva l’italiano per ciò che deve restare in italiano, per esempio l’istruzione esplicita sulla lingua di conversazione.
Un accenno a CLAUDE.md (ne parleremo presto)
Chi usa Claude Code, l’agente da riga di comando di Anthropic, incontra un meccanismo imparentato ma distinto: il file CLAUDE.md. Non è un campo di settings, è un file markdown vero e proprio che vive nel repository o nella home directory, e che Claude Code legge all’inizio di ogni sessione per ricevere istruzioni persistenti su progetto, workflow personale o intera organizzazione, con un secondo meccanismo, l’auto memory, che lascia che Claude accumuli da solo appunti basati sulle correzioni e le preferenze dell’utente. È concettualmente cugino del prompt di contesto personale (stesso obiettivo: non ripetersi), ma con logiche di caricamento, gerarchia e limiti di lunghezza sufficientemente diverse da meritare un trattamento a parte. Ne riparleremo.
Come testare e snellire il prompt (e come capire quando è il caso di fermarsi)
Il metodo che consiglio è lo stesso, con differenze minime, su Claude e su Gemini.
Fase di stesura. Scrivi la prima versione lunga, senza preoccuparti della sintesi. Include tutto ciò che ti viene in mente: ruolo, tono desiderato, cose da evitare, terminologia specifica, esempi di risposta buona e cattiva.
Fase di test. Apri 4-5 conversazioni scollegate tra loro, su compiti diversi che rappresentano il tuo uso reale (una tecnica, una creativa, una analitica, una banale). Osserva dove il modello devia dalle istruzioni: quella deviazione è il segnale che l’istruzione era troppo vaga, mal posizionata, o in conflitto con un’altra. Su Claude questo è più facile da isolare perché l’applicazione è deterministica: se un’istruzione non viene seguita, il problema è nella formulazione, non nella decisione del modello di “non ritenerla rilevante”. Su Gemini, se hai attivato la personalizzazione dinamica, ricordati che il sistema stesso può mostrarti quali fonti ha usato per personalizzare una risposta. Usa quella trasparenza per capire se il problema è nel testo salvato o nella decisione di non attingervi.
Fase di potatura. Applica il test di cui abbiamo già parlato: ogni riga deve superare la domanda “la sua assenza cambierebbe qualcosa?”. Le istruzioni negative e specifiche (”non aprire con un elogio”, “non usare elenchi puntati salvo richiesta esplicita”) tendono a essere più efficaci, a parità di lunghezza, di quelle generiche e positive (”sii chiaro e conciso”, frase che il modello non ha modo di mettere davvero in pratica, semplicemente perché non sa cosa NON sta già facendo).
Quando fermarsi. Il criterio è la legge dei rendimenti decrescenti: quando due o tre modifiche consecutive non producono alcuna differenza osservabile nel comportamento su un campione ragionevole di richieste reali, hai raggiunto il punto di stabilità. Non esiste una lunghezza “corretta” universale, dipende da quanto è eterogeneo il tuo uso. Un prompt di contesto personale che supera le 400-500 parole comincia quasi sempre a contenere ridondanze o istruzioni situazionali che dovrebbero stare altrove (project instructions su Claude, istruzioni contestuali per singola chat su Gemini).
Esempio 01: prompt di contesto personale per professore ordinario di cibernetica, specializzato in AI.
Address me as [Nome]. Never use academic titles.
I am a full professor of cybernetics, specialized in AI systems,
with active research and public writing on strategic/military
analysis, hacking and bio-hacking, and computational creativity.
Assume graduate-level technical fluency by default — do not
define standard ML/AI terms unless I ask, but always footnote
acronyms and lesser-known names when the output is meant for
publication to a general educated audience.
Default register: precise, unadorned, no academic ornamentation.
Occasional dry humor is welcome; forced humor is not.
When asked for factual claims, sources, or citations: never
fabricate. If verifiable data is insufficient, say so explicitly
and ask before proceeding.
For long-form or analytical writing: favor depth and structured
argument over brevity. For code or technical debugging: favor
efficiency and precision over conversational prose.
Always respond in Italian unless I explicitly switch language.8. Esempio “perfetto” — laureando in cibernetica, tesi sulla storia dell’AI
Address me as [Nome]. I am a graduate student in cybernetics
writing a thesis on the history of artificial intelligence.
Assume undergraduate-to-graduate familiarity with AI concepts,
but explain historiographical and epistemological framing
explicitly — I'm still building fluency there, not in the
technical AI content itself.
Every factual, biographical, or bibliographic claim must be
traceable to a verifiable, citable source. If you're not certain
a source exists or says what I'd need it to say, tell me
explicitly rather than approximating. Distinguish clearly
between established historical fact and historiographical
interpretation or debate.
When helping me structure arguments: play devil's advocate
before agreeing with my framing. Flag when a claim I'm making
is contested in the literature, even if I didn't ask.
Prefer primary sources and peer-reviewed historiography over
popular science summaries when both are available.
Always respond in Italian unless I explicitly switch language.Testo semplice, Markdown o XML?
La documentazione ufficiale di entrambi i fornitori converge, con sfumature diverse, sulla stessa risposta: quando il blocco di testo contiene più tipi di contenuto distinti: un ruolo, delle regole di stile, dei vincoli, del contesto biografico, la struttura esplicita aiuta il modello a non mescolarli, e questo vale sia per Claude sia per Gemini.
Per Anthropic la posizione è la più netta delle due: la guida ufficiale al prompt engineering raccomanda esplicitamente i tag in stile XML (<instructions>, <context>, <formatting> e simili) per separare le sezioni di un prompt complesso, sostenendo che Claude sia stato addestrato a prestare particolare attenzione a questo tipo di delimitatori. Non esistono tag “riservati” o predefiniti, qualunque nome descrittivo funziona, l’importante è usarlo in modo coerente. Va detto con onestà, però, che questa raccomandazione è documentata per l’uso via API e per i system prompt in generale: Anthropic non pubblica una guida specifica sul formato ottimale per il campo Instructions dell’interfaccia consumer di Claude.ai. Il meccanismo di iniezione è però lo stesso: quel testo finisce comunque prepended al prompt di sistema, quindi non c’è ragione tecnica per aspettarsi che il vantaggio della struttura sparisca lì. È un’inferenza ragionevole, sebbene non si tratti di un dato verificato punto per punto.
Un’ulteriore nota di cautela, sempre da fonte Anthropic: la documentazione più recente sul context engineering osserva che la formattazione esatta del prompt sta probabilmente diventando meno determinante man mano che i modelli diventano più capaci, il che non significa “la struttura non serve”, ma “non serve ossessionarsi sulla sintassi perfetta se il contenuto è già chiaro”.
Per Google/Gemini l’indicazione è sovrapponibile ma più esplicitamente permissiva sull’alternativa: la guida ufficiale al prompt design suggerisce sia i tag XML sia le intestazioni Markdown come delimitatori efficaci, con un avvertimento pratico che vale la pena riportare perché è l’unico vero disaccordo utile tra le fonti: non mischiare mai i due stili nello stesso prompt: si sceglie un formato e ci si attiene a quello, per coerenza interna.
Tradotto in pratica:
Sotto le 300-400 parole (il range che già identifica “sano” un prompt di contesto personale), la prosa semplice o al massimo qualche intestazione Markdown leggera è probabilmente sufficiente: il guadagno da una strutturazione XML pesante, su un testo già breve e a bassa ambiguità interna, è marginale.
Se il blocco cresce, o se contiene sezioni logicamente distinte che rischiano di essere lette come un unico flusso indistinto (per esempio: chi sei, come vuoi essere chiamato, regole di stile, cosa evitare, lingua), vale la pena separarle esplicitamente. Ecco un esempio:
<identity>
Address me as [Nome]. Never use academic titles.
Full professor of cybernetics, specialized in AI systems.
</identity>
<expertise>
Active research and public writing on: strategic/military
analysis, hacking and bio-hacking, computational creativity.
</expertise>
<style>
Precise, unadorned, no academic ornamentation.
Occasional dry humor welcome; forced humor is not.
Assume graduate-level technical fluency by default.
</style>
<sourcing_rules>
Never fabricate facts, sources, or citations.
If verifiable data is insufficient, say so explicitly
and ask before proceeding.
</sourcing_rules>
<output_calibration>
Long-form/analytical writing: favor depth over brevity.
Code/debugging: favor efficiency over conversational prose.
</output_calibration>
<language>
Always respond in Italian unless I explicitly switch language.
</language>Non è una versione “migliore” in senso assoluto: si tratta della stessa informazione, resa più difficile da fraintendere quando il modello deve capire dove finisce una regola e dove ne inizia un’altra. Il criterio per decidere se vale la pena è, ancora una volta, empirico: se noti che il modello ogni tanto applica una regola di stile a un contesto dove non c’entra, o confonde un vincolo con una preferenza, è il segnale che la struttura piatta non basta più.
Ogni quanto rivederlo, e perché
Non è un file “scrivi una volta e dimentica”, per tre ragioni concrete e verificabili.
La prima: i modelli sottostanti cambiano. Un’istruzione calibrata su una versione di un modello può essere interpretata diversamente, meglio, peggio, o semplicemente in modo differente, da una versione successiva. Non hai modo di saperlo se non testando periodicamente.
La seconda: i meccanismi stessi di personalizzazione evolvono come prodotto, non solo come modello. Un esempio concreto e recentissimo è proprio quello di Anthropic: gli Styles, un meccanismo di personalizzazione che esisteva fino a poco tempo fa, sono stati assorbiti dalle Skills e chi aveva costruito flussi di lavoro attorno agli Styles ha dovuto, a un certo punto, accorgersi del cambiamento e adattarsi.
La terza, la più banale ma la più trascurata: cambi tu. Il te di sei mesi fa aveva priorità, progetti e forse anche un tono comunicativo diverso da quello attuale. Un prompt di contesto scritto un anno fa e mai più toccato è, con altissima probabilità, un prompt che sta dando istruzioni leggermente sbagliate su chi sei oggi.
Sitografia di riferimento
Anthropic — Understanding Claude’s personalization features, Claude Help Center.
Anthropic — Styles are moving to skills, Claude Help Center.
Anthropic — How Claude remembers your project, Claude Code Docs.
Anthropic — Use XML tags to structure your prompts, Claude Docs.
Anthropic — Effective context engineering for AI agents, Anthropic Engineering.
Google — Gemini gets personal, with tailored help from your Google apps, The Keyword.
Google — Gemini Apps Privacy Hub, Gemini Apps Help.
Google — Prompt design strategies, Gemini API Docs.
Google — Saved Info, Gemini.
La finestra di contesto è la quantità massima di testo (misurata in token) che un modello può “vedere” contemporaneamente in una singola interazione, tutto ciò che sta fuori da quella finestra, per il modello, semplicemente non esiste.
Le Skills in Claude sono pacchetti di istruzioni e comportamenti attivabili on-demand in una conversazione, pensati per sostituire il precedente sistema di Styles (personalizzazione del formato/tono delle risposte).
Byte Pair Encoding (BPE) è l’algoritmo di tokenizzazione più diffuso nei modelli linguistici moderni: comprime il testo in sotto-unità (token) la cui granularità dipende dalla frequenza con cui certe sequenze di caratteri compaiono nel corpus di addestramento da cui la maggiore efficienza per le lingue sovra-rappresentate in quel corpus. Se vuoi saperne di più, ascolta questo episodio del podcast:
#002 - I token e il mostro di Frankenstein
“Menti, codici e fantasmi” è un podcast di cibernetica e intelligenza artificiale.