Le istruzioni generali¶

Le istruzioni generali sono il livello base della configurazione, presentato al capitolo 1 come il fondamento su cui si appoggiano gli altri livelli. Si configurano nell'area Impostazioni, sezione Profilo, in un campo introdotto dall'indicazione «Quali preferenze personali dovrebbe considerare Claude nelle risposte? Le tue preferenze si applicheranno a tutte le conversazioni, nel rispetto delle linee guida di Anthropic». Il campo è salvato lato server e legato all'account, e vale in ogni nuova conversazione indipendentemente dall'ambiente e dal dispositivo.

Scriverle bene ha un effetto a cascata, perché semplifica la configurazione dei livelli più specifici, che possono dare per assodato il default e limitarsi a esprimere le differenze.

Il capitolo descrive il funzionamento delle istruzioni generali, con quale criterio inserire una regola in questo livello e cosa lasciare altrove. Propone un template come punto di partenza e raccoglie gli anti-pattern ricorrenti.

Quando vengono lette¶

Le istruzioni generali vengono lette all'avvio di ogni nuova conversazione, da claude.ai, da Claude Desktop o dall'app per smartphone.

Le istruzioni sono contesto e non comandi, come visto al capitolo 2. Una conseguenza pratica è che istruzioni contraddittorie al loro interno, ambigue o troppo verbose ne rendono complessa l'applicazione. Una buona configurazione di questo livello è compatta, priva di ripetizioni interne e priva di regole che si annullano a vicenda. È un'osservazione che vale per tutti i livelli, ma per le generali conta di più, perché qui ogni regola entrerà in ogni conversazione futura.

Criteri di collocazione¶

Il criterio guida è che 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, con 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.

Una trappola frequente, specie per chi ha più ambiti di lavoro diversi, è l'accumulo a questo livello di regole provenienti da tutti questi ambiti. Si confida che Claude capisca quando applicare cosa. Il risultato è una configurazione 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 di collocazione¶

Tre esempi rendono concreto il criterio della pervasività.

Il primo riguarda il metodo di lavoro. Le istruzioni generali richiedono a Claude di verificare le fonti, segnalare le assunzioni non verificate, distinguere fra affermazioni verificate e interpretazioni plausibili. È una regola di metodo che vale per la maggior parte dei lavori dell'utente, e ha quindi senso al livello più generale. In un progetto esplicitamente dedicato al brainstorming creativo, dove il rigore metodologico ostacola più di quanto aiuti, la regola può essere allentata da un'istruzione di progetto, senza intaccare il default. Negli altri progetti il metodo torna ad applicarsi, perché la regola generale non è stata modificata, è stata solo sovrastata localmente nel progetto di brainstorming.
Il secondo riguarda il profilo dell'utente. Il ruolo professionale, l'ambito di lavoro abituale, i temi ricorrenti che caratterizzano la propria attività sono informazioni di profilo che orientano Claude in qualsiasi conversazione, e stanno bene nelle generali. Quando si lavora per un cliente specifico, le caratteristiche di quel cliente, il glossario interno, le persone con cui ci si interfaccia, sono informazioni di contesto specifiche di quel rapporto e vanno nelle istruzioni di un progetto dedicato al cliente. La distinzione è fra ciò che identifica il professionista in modo stabile e ciò che caratterizza una committenza fra le tante.
Il terzo riguarda una preferenza che sembra di default ma non lo è. Un esempio è la lunghezza preferita delle risposte. Per la maggior parte del lavoro va bene una lunghezza media, e la regola può stare nelle generali. Esistono però lavori che richiedono risposte sistematicamente più estese, ad esempio i contesti editoriali in cui si producono articoli completi. La scelta è fra due strade. Si scrive la lunghezza media nelle generali e la si specializza nel progetto editoriale con la lunghezza più estesa. Oppure non si scrive nulla nelle generali e si tiene la regola solo nei progetti che ne hanno bisogno. La direzione dipende da quante volte la lunghezza media è effettivamente preferita. Se è il caso predominante, scriverla nelle generali è coerente con la pervasività. Se è una scelta che vale per pochi progetti, scriverla solo nei progetti che ne hanno bisogno tiene le generali più pulite.

I tre esempi seguono lo stesso schema. Nelle generali va ciò che vale per la maggior parte del lavoro. Le specificità di un singolo contesto stanno nei livelli più circoscritti. Le eccezioni rispetto al default si scrivono come variazioni nel livello specifico, lasciando il livello base intatto.

Un template di configurazione commentato¶

Il template che segue è pensato come proposta di partenza, non come modello da replicare. Il criterio di fondo è quello di cui si è parlato, 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.]

Come si vede 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. 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. È il posto in cui si descrive non cosa Claude deve fare, ma come deve affrontare il lavoro.

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.

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 è una configurazione che si contraddice al suo interno e che 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.
La dipendenza implicita dall'ambiente. Vengono inserite istruzioni che presuppongono un percorso del filesystem, un server MCP, una skill locale, senza rendersi conto che l'istruzione arriverà identica su claude.ai, su Desktop locale e sullo smartphone. In due ambienti su tre non funzionerà. La soluzione non è rinunciare a quelle istruzioni, è collocarle nel livello giusto. Il posto naturale sono le istruzioni di un progetto dedicato al lavoro su filesystem, sapendo che valgono solo in Claude Desktop e sul computer che ha quella struttura.
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 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.