Le istruzioni generali di Claude: configurarle bene

Le istruzioni generali sono il livello base della configurazione di Claude, il campo di testo libero nella sezione Profilo delle impostazioni che vale in ogni nuova conversazione a prescindere dall’ambiente e dal dispositivo utilizzato. Costituiscono il fondamento su cui poggiano tutti gli altri livelli della configurazione, descritti nella mappa della serie, vengono introdotte con questa frase: “Quali preferenze personali dovrebbe considerare Claude nelle risposte? Le tue preferenze si applicheranno a tutte le conversazioni, nel rispetto delle linee guida di Anthropic.“.
Scriverle bene ha un effetto a cascata, perché semplifica la configurazione dei livelli specifici, che possono dare per assodato il default e limitarsi a esprimere le differenze.

Le pagine che seguono descrivono come entrano in gioco nelle conversazioni, come si collocano nella gerarchia, cosa ha senso scrivere qui e cosa no, e si chiudono con uno scheletro commentato da usare come punto di partenza.

Quando entrano in gioco

Entrano in gioco nel contesto di ogni nuova conversazione aperta da claude.ai, da Claude Desktop o dall’app per smartphone, a prescindere dal dispositivo. Ci sono però alcuni aspetti meno immediati che vale la pena mettere a fuoco, perché cambiano l’esito effettivo.

Il primo riguarda il momento dell’aggiornamento. Quando si modificano le istruzioni generali e si salva, la nuova versione entra in vigore dalle conversazioni successive. Le chat già aperte continuano con la versione letta al momento del loro avvio, perché è in quel momento che le istruzioni vengono composte nel contesto. Se una nuova regola deve applicarsi subito a una conversazione in corso, va richiamata esplicitamente nel turno successivo, oppure occorre avviare una chat nuova.

Il secondo riguarda il modo in cui le istruzioni vengono effettivamente lette dall’assistente. Non sono comandi che Claude esegue meccanicamente, sono contesto che entra nel prompt di sistema insieme ad altri elementi, e Claude interpreta l’insieme per produrre le risposte. Questo significa che istruzioni contraddittorie al loro interno, ambigue o troppo verbose riducono l’efficacia del livello anziché rinforzarla. Una buona configurazione generale è compatta, priva di ripetizioni interne e priva di regole che si annullano a vicenda.

La posizione nella gerarchia

Le istruzioni generali sono il livello base della configurazione, sempre attivo. Gli altri livelli della serie, istruzioni di progetto, istruzioni Cowork e stili di scrittura, si sovrappongono a queste quando sono presenti e pertinenti, senza cancellarle. La metafora giusta non è la sostituzione, è la stratificazione, ogni livello più specifico aggiunge, affina e, quando serve, prevale sul livello più generale.

In caso di conflitto fra livelli, prevale il livello più specifico. Quando la contraddizione è solo apparente e le regole operano su piani diversi, si combinano senza bisogno di scegliere.

L’esempio più nitido è quello linguistico. Se le istruzioni generali richiedono a Claude di rispondere in italiano, e un progetto relativo a una committenza internazionale specifica che tutti i documenti vanno in inglese, nelle chat di quel progetto Claude scrive in inglese. La regola di progetto prevale perché è più specifica ed è stata scelta per un contesto che richiede un trattamento diverso. Se invece le istruzioni generali richiedono l’italiano e un progetto specifica un registro formale, le due regole convivono senza contraddirsi, Claude risponderà in italiano con registro formale.

Gli stili di scrittura operano su un piano leggermente diverso, influenzano come Claude scrive, non cosa fa, e vengono trattati nell’articolo dedicato. Un’ultima osservazione, le istruzioni date nel corso di una conversazione sono sempre l’ultima parola. Se in una chat viene chiesto esplicitamente a Claude di rispondere in inglese, in quella risposta scriverà in inglese anche se le istruzioni generali chiedono l’italiano. L’istruzione di chat è semplicemente il livello più specifico che esista, quello del momento.

Criteri di collocazione

Il criterio guida è la pervasività, qui vanno le regole che devono essere applicate in ogni conversazione, a prescindere dal progetto, dall’ambiente e dallo strumento in uso in quel momento. Tutto ciò che è specifico di un ambito appartiene a livelli più circoscritti.

Rientra bene nelle istruzioni generali il profilo personale dell’utente, nella misura in cui influenza il modo in cui Claude risponde, cioè il ruolo professionale, l’ambito di lavoro abituale, i riferimenti tematici ricorrenti. Rientrano le preferenze linguistiche e tonali di default, tipicamente la lingua desiderata, il registro preferito, il livello di brevità o di approfondimento. Rientrano le metodologie di default, per esempio il modo in cui Claude deve verificare i fatti, segnalare le assunzioni non verificate, distinguere fra affermazioni verificate e interpretazioni plausibili. Rientrano, infine, le istruzioni di base sull’uso degli strumenti e delle skill, nei limiti in cui valgono per tutti i lavori dell’utente.

Non rientrano, e vanno spostate altrove, alcune categorie specifiche. Le istruzioni che riguardano un singolo progetto, un cliente, una committenza, un tema monografico, appartengono alle istruzioni di progetto. Le istruzioni che dipendono dall’ambiente, percorsi di file locali, server MCP, skill salvate sul filesystem, vanno ricondotte ai livelli che vivono in Claude Desktop, con l’attenzione alla portabilità discussa nell’articolo mappa. I compiti puntuali, le richieste specifiche, i prompt di task vanno direttamente nella chat. Le regole che valgono solo per una conversazione o per una serie breve di conversazioni trovano posto negli stili di scrittura o nell’istruzione che apre la chat.

Una trappola frequente, specie per chi ha più ambiti di lavoro diversi, è l’accumulo a questo livello di regole provenienti da tutti questi ambiti, confidando che Claude capisca quando applicare cosa. Il risultato è un’istruzione generale che si contraddice al suo interno e che diluisce l’efficacia di tutte le regole, incluse quelle scritte bene. Conviene tenere le istruzioni generali come un profilo di base leggero e coerente, e spostare le specificità nei progetti.

Esempi concreti di collocazione e di conflitto

Il primo esempio riguarda la lingua, se nelle istruzioni generali la lingua richiesta è l’italiano la regola vale ovunque. All’apertura di un progetto relativo a una committenza internazionale, dove tutti i documenti e le conversazioni devono essere in inglese, quella regola va scritta come istruzione di progetto. Nelle chat di quel progetto prevarrà l’inglese. Non c’è bisogno di togliere la regola generale, che continua a valere fuori del progetto.

Un secondo esempio riguarda le metodologie, le istruzioni generali richiedono verifica sistematica delle fonti e segnalazione delle assunzioni non verificate. In un progetto esplicitamente di brainstorming, dove il rigore metodologico ostacola più di quanto aiuti, le istruzioni di progetto possono contenere una regola che allenta la verifica in favore della produzione di ipotesi. Non si toglie la regola di base, la si specializza per un contesto che richiede un approccio diverso.

Un terzo esempio riguarda il rapporto fra istruzioni e stili di scrittura. Se le istruzioni generali chiedono di evitare il grassetto e usare il corsivo per l’enfasi, quello è il default. Quando viene attivato uno stile che, per finalità specifiche, usa il grassetto, prevale lo stile. L’istruzione non è stata cancellata, semplicemente non è più il livello più specifico.

Un quarto esempio è quello dell’istruzione data nel corso della chat. Le istruzioni generali chiedono italiano, ma in una singola conversazione l’utente chiede «per questa risposta usa l’inglese». Quella risposta arriva in inglese. L’istruzione di chat è il livello più specifico che esista, vale per quella risposta o per il tratto di conversazione a cui è riferita, salvo nuove istruzioni successive.

In tutti i casi, quando due regole non sono davvero in conflitto perché operano su piani diversi, si combinano. Se le istruzioni generali chiedono italiano e un progetto chiede registro formale, nelle chat di quel progetto Claude risponderà in italiano con registro formale, senza bisogno di scegliere.

Un template di configurazione commentato

Lo scheletro che segue è pensato come punto di partenza, non come modello da replicare. Il criterio di fondo è quello di cui si è parlato, cioè la pervasività. Le sezioni sono indicative, possono essere fuse, divise o rinominate in base alle proprie abitudini. Quello che conta è che ogni blocco contenga solo regole che valgono davvero in ogni conversazione.

## Profilo

[Chi è l'utente dal punto di vista professionale, il ruolo, l'ambito di lavoro, i temi principali su cui opera. Solo gli elementi pervasivi, non le specificità dei singoli progetti.]

## Preferenze di default

[Lingua, tono, registro, livello di brevità o di approfondimento
desiderati come default. Queste preferenze possono essere
specializzate o sovrascritte da livelli più specifici.]

## Metodo

[Come Claude deve gestire le fonti, le assunzioni non verificate, la distinzione fra fatti, interpretazioni plausibili e speculazioni.
Regole metodologiche trasversali.]

## Strumenti e skill

[Indicazioni sull'uso di strumenti e skill che valgono per tutti i lavori dell'utente. Nulla che presupponga un ambiente o un dispositivo specifico.]

Qualche osservazione sul modo in cui è costruito lo scheletro. Le quattro sezioni coprono le famiglie di regole che ha senso tenere a questo livello e lasciano fuori tutto il resto. La sezione Profilo non è un curriculum, è il minimo che serve a Claude per capire il contesto del suo interlocutore, quindi poche righe orientative, non un elenco esaustivo di competenze. La sezione Preferenze di default raccoglie le scelte di forma, con l’accortezza di non scrivere regole che si sa già di voler modificare spesso nei progetti, perché in quei casi è meglio mettere la regola direttamente nelle istruzioni di progetto. La sezione Metodo è quella che porta più valore ed è anche la più trascurata dagli utenti alle prime armi, perché è la più astratta. La sezione Strumenti e skill va tenuta leggera, qualsiasi regola che dipenda dall’ambiente appartiene a un altro livello.

Anti-pattern ricorrenti

Alcuni errori si ripetono con sufficiente frequenza da meritare una menzione esplicita. Il primo, e probabilmente il più comune, è l’accumulo di regole provenienti da ambiti diversi. Quando si lavora su più progetti, ciascuno con le sue specificità, nel dubbio si tende a inserire tutto nelle istruzioni generali, confidando che Claude capisca di volta in volta quale regola applicare. Il risultato è un’istruzione generale che si contraddice al suo interno e che, paradossalmente, perde efficacia anche sulle regole scritte bene, perché il contesto diventa rumoroso e le priorità relative si sfocano. La soluzione è spostare le specificità nei progetti, lasciando qui solo ciò che vale sempre.

Il secondo errore è la dipendenza implicita dall’ambiente. Vengono inserite istruzioni che presuppongono un percorso del filesystem, un server MCP, una skill locale, senza rendersi conto che quell’istruzione arriverà identica su claude.ai, sul pc dell’ufficio e sullo smartphone. Su due ambienti su tre, semplicemente non funzionerà. La soluzione non è rinunciare a quelle istruzioni, è collocarle nel livello giusto, cioè tipicamente le istruzioni di un progetto dedicato al lavoro su filesystem, sapendo che valgono solo in Claude Desktop e sul computer che ha quella struttura.

Il terzo errore è l’eccesso di lunghezza e ridondanza. Le istruzioni generali non sono un documento contrattuale, sono un contesto che viene letto e interpretato. Un testo molto lungo con regole ripetute, sinonimi che in realtà dicono cose leggermente diverse, eccezioni dentro eccezioni, produce un’interpretazione meno accurata di un testo più breve e pulito. La revisione periodica di questa configurazione, per rimuovere ciò che non serve più o riformulare ciò che si è chiarito nel tempo, è parte dell’igiene di lavoro.

Verso le istruzioni di progetto

Una configurazione pulita a questo livello semplifica la vita a tutti i livelli successivi, perché ogni istruzione più specifica può dare per assodato il default e limitarsi a dire in cosa si discosta. Il prossimo articolo della serie affronta le istruzioni di progetto, cioè il livello in cui comincia la specializzazione della configurazione in base al contesto di lavoro, e in cui i meccanismi di prevalenza appena visti diventano operativi nella pratica quotidiana.