Soluzioni al problema del pensiero superficiale in Claude Opus 5

Panoramica

Immediatamente dopo aver passato Claude Code a Opus 5, ho notato un improvviso aumento di risposte prolisse e una tendenza al "pensiero superficiale" (incapacità di pensare in modo strutturale).

Dopo un'indagine, non era che il modello fosse scarso o che le regole fossero errate; piuttosto, il prompt di sistema interno fornito a Opus 5 nella generazione Claude 5 è cambiato significativamente, e le regole legacy non erano state scritte tenendo conto di questa nuova premessa.

Questo articolo documenta il processo di isolamento della causa e di revisione delle regole per adattarle al nuovo prompt di sistema. È pensato per gli utenti di Claude Code che ritengono che l'efficacia di CLAUDE.md o delle loro regole sia cambiata dopo l'aggiornamento alla nuova generazione di modelli.

Il Problema

Utilizzando la stessa sessione e le stesse regole, si è verificato quanto segue immediatamente dopo aver cambiato il modello in Opus 5:

• Le spiegazioni situazionali sono diventate piatte, lunghe prose senza titoli o sezioni.
• Le spiegazioni delle cause si fermavano a un singolo livello (elencando sintomi in parallelo senza approfondire il "perché").
• Non venivano forniti criteri di valutazione quando si suggerivano più opzioni.
• Categorie o numerazioni stabilite in un turno venivano riorganizzate in strutture diverse nel turno successivo.
• Il modello saltava la risposta al mio input e passava immediatamente all'esecuzione di strumenti (compiti).

La parte frustrante era che anche quando gli veniva chiesto di "pensare più a fondo", restituiva risposte sporadiche rimanendo in uno stato di pensiero superficiale. Le correzioni ripetute non funzionavano, portando a discussioni invece che a un dialogo produttivo.

Non era solo una questione di qualità della singola risposta; il processo stesso di deliberazione attraverso il dialogo si era interrotto.

Indizi Chiave

Questo non accadeva con altri modelli che utilizzavano le stesse regole (i dettagli su questa differenza sono nell'appendice). Se le regole stesse fossero degenerate, il problema sarebbe dovuto apparire su tutti i modelli. Poiché è cambiato solo il modello, ho iniziato a indagare partendo dal presupposto che "l'ambiente presupposto dalle regole" fosse cambiato.

Causa: Cambiamenti nel Prompt di Sistema Fornito a Opus 5

Nella generazione Claude 5 di Claude Code, il prompt di sistema interno è stato ridotto di circa l'80% rispetto alle generazioni precedenti. Misurando il prompt effettivamente inviato a Opus 5 (disabilitando le iniezioni di stile di output e facendo citare al modello il proprio prompt; serie Claude Code v2.1, luglio 2026), la struttura era la seguente:

1. Identità, Dichiarazione di Ruolo e Politica di Sicurezza — Il preambolo iniziale.
2. Specifiche dell'Harness (# Harness) — Spiegazioni dell'ambiente di esecuzione, come l'output visualizzato come markdown.
3. Informazioni sull'Ambiente e Descrizioni delle Funzionalità (# Guidance specifica della sessione / # Memoria / # Ambiente / # Gestione del contesto) — CWD, stato git, ID modello, memoria e meccanismi di compressione del contesto.
4. Disciplina dell'Ambito (# Consegna del lavoro) — Non restringere o espandere l'ambito richiesto senza autorizzazione.
5. Etichetta delle Correzioni (# Correzioni) — Mantenere le correzioni concise senza aggiungere scuse o preamboli.

Sono emerse due caratteristiche specifiche direttamente collegate ai sintomi:

• Caratteristica 1: Zero istruzioni riguardanti lo stile di risposta. Non c'erano regole su prosa vs. struttura, uso di titoli o tabelle, o concisione—le regole di formattazione che erano estese nelle generazioni precedenti erano completamente assenti.
• Caratteristica 2: È stata aggiunta una politica autonoma "Agisci Prima". Per citare l'originale: "Quando hai informazioni sufficienti per agire, agisci." e "Se stai valutando una scelta, dai una raccomandazione, non un'analisi esaustiva."

Rileggere i sintomi attraverso queste due caratteristiche fa sì che tutto torni. Poiché non ci sono regole di stile, emerge la tendenza grezza del modello all'output—prosa piatta. La politica "raccomandazione invece di analisi" incoraggia l'omissione dei criteri di valutazione.

Potresti pensare: "Se le regole sono vuote, le mie regole personalizzate dovrebbero diventare l'unica autorità e funzionare meglio." In realtà, è successo il contrario. Questo spazio vuoto non è un margine lasciato all'utente; è delegato al comportamento predefinito incorporato nel modello durante l'addestramento. Il "prompt snello" presuppone che i modelli di nuova generazione seguano comportamenti interiorizzati senza istruzioni dettagliate. Invece di essere riempito dalle tue regole, il vuoto viene riempito dai valori predefiniti pre-addestrati del modello. E il valore predefinito di Opus 5 è una prosa concisa che agisce prima di confermare.

Le mie vecchie regole utilizzavano istruzioni generali come "scomponi le situazioni in modo strutturale", "aggiungi criteri di valutazione a più opzioni" e "rispondi prima di agire". Queste erano state scritte presupponendo che sarebbero state lette insieme a un prompt di sistema ricco di stile. Sebbene allora fossero sufficienti, erano troppo deboli sia in specificità (nominando il testo originale) che in modalità di consegna (raggiungendo il modello subito prima dell'azione) per sovrascrivere i valori predefiniti addestrati. Questa è la vera natura dei sintomi.

Anthropic stessa si riferisce a questa riduzione come "prompt di sistema snello" nel changelog (v2.1.154), riflettendo un cambiamento nella filosofia di progettazione: "I modelli di nuova generazione hanno interiorizzato i comportamenti attraverso l'addestramento, quindi istruzioni dettagliate possono causare attriti o contraddizioni." Per spiegazioni dettagliate, vedere Prompt di Sistema di Claude Code Ridotto dell'80% — Filosofia di Progettazione dei Prompt per la Generazione Fable 5. Per le fonti primarie, fare riferimento al Changelog di Claude Code e a Prompting Claude Fable 5 (Guida Ufficiale).

In breve, i sintomi sono determinati dalla combinazione di "regole × il prompt effettivamente inviato a quel modello." Non puoi trovare la causa guardando solo le regole. La prima lezione è stata che un aggiornamento del modello è anche un aggiornamento del prompt di sistema.

Misura 1: Identificare le Contraddizioni e Sovrascrivere Nominando il Testo Originale

Per prima cosa, ho incrociato tutte le regole con il nuovo prompt di sistema per identificare dove dicevano il contrario. Per le regole destinate a sovrascrivere la politica di sistema, le ho riscritte per citare esplicitamente il testo originale e dichiarare la priorità.

Per cominciare con ciò che non ha funzionato: aggiungere generalità come "scrivi più opzioni con criteri di valutazione" è inefficace.

Quando collocato accanto alla "dai una raccomandazione, non un'analisi esaustiva" del sistema, non c'è alcun indizio su quale abbia la precedenza. Nominando il conflitto, la priorità diventa chiara.

Per le cose completamente assenti dal prompt, come le regole di stile, l'istruzione funziona per "riempire il vuoto" piuttosto che per sovrascrivere.

Ho anche rivisto il modo in cui vengono scritte le condizioni di attivazione. Condizioni come "per cambiamenti importanti" o "se ritenuto un ambiente di produzione" falliscono nel momento in cui il modello non categorizza la situazione in quel modo. Ho cambiato i trigger in fatti osservabili come "ricevuto un interrupt" o "l'enunciazione dell'utente contiene una correzione."

Misura 2: Descrivere le Azioni Desiderate Invece dei Divieti

Le vecchie regole erano un accumulo di "non fare." I divieti aiutano a rilevare le violazioni ma non comunicano cosa fare invece. Quando un divieto entra in conflitto con una nuova politica di sistema, il modello trova una scappatoia: "segui la politica di sistema evitando il divieto." Ho convertito i vincoli negativi in descrizioni del comportamento desiderato.

• Prima: "Non suggerire un commit se i test sono incompleti."
• Dopo: "Quando suggerisci un commit, includi nel corpo del testo i risultati dell'esecuzione del prodotto dal punto di vista dell'utente finale."

Ho verificato le regole riscritte rispetto ai seguenti criteri, in particolare per le espressioni che entrano in conflitto con il Prompt di Sistema:

1. La regola è autonoma? (Ambito, esempi e criteri in un unico posto)
2. Il trigger è un fatto osservabile?
3. Contraddice il prompt di sistema interno?
4. Descrive il comportamento desiderato? (Non solo un elenco di divieti)
5. C'è un unico criterio di giudizio? (Non un elenco di scenari)
6. L'enfasi (IMPORTANTE) è riservata solo a ciò che non può essere assolutamente tralasciato?
7. È scritto come lo stato finale desiderato? (Non forzando prima modelli o passaggi)
8. La conformità può essere determinata a posteriori?

Ho ridotto i marcatori di enfasi (IMPORTANTE) solo ai cancelli di sicurezza e approvazione. Un documento in cui tutto è enfatizzato è come un documento in cui nulla lo è.

Misura 3: Scegliere il "Livello" per Consegnare le Istruzioni

Non era solo una questione di testo. Claude Code ha almeno quattro percorsi per consegnare istruzioni al modello, e differiscono significativamente in efficacia.

Poiché l'API è senza stato, il contenuto di tutti i percorsi viene inviato al modello con ogni richiesta (ogni turno). La differenza sta in "quando il contenuto viene finalizzato" e "dove viene posizionato nel prompt = quanto è vicino all'azione che viene compiuta."

Sorprendentemente, output style—che la documentazione dice "sostituisce il prompt di sistema"—veniva consegnato come allegato in ogni turno secondo i registri della sessione.

Ho scritto due tipi di istruzioni in questo output style: Stile (Misura 1: scrivi in modo strutturale, aggiungi criteri) e Processo (rispondi all'utente prima di iniziare il lavoro). I risultati sono stati contrastanti.

Mentre le istruzioni di Stile mostravano miglioramenti, il problema del Processo—saltare le risposte per iniziare il lavoro—non si è fermato tramite output style. Ho finalmente interrotto questa abitudine utilizzando un hook UserPromptSubmit per iniettare una singola riga immediatamente dopo ogni enunciazione dell'utente: "Scrivi una risposta a questa enunciazione (risposta, o riconoscimento e piano) nel corpo del testo prima di eseguire gli strumenti."

Il costo è di circa 50 token per enunciazione. Anche 100 enunciazioni costano solo 5.000 token, che è trascurabile rispetto a un contesto di 200K. La regola generale che ho imparato è semplice: Le istruzioni consegnate "brevemente, ogni volta, subito prima dell'azione" sono le più efficaci. Molte istruzioni inefficaci non sono sbagliate nel contenuto; semplicemente non sono a portata di mano nel momento dell'azione.

Risultati

Ecco i risultati confermati finora:

• Una tendenza al ritorno di titoli/sezioni nelle spiegazioni situazionali e causali. (Tuttavia, l'output piatto a volte rimane all'inizio della sessione; osservazione in corso).
• L'abitudine di "lavorare senza rispondere" non si è risolta con il solo output style ma si è fermata dopo l'introduzione dell'iniezione per enunciazione (attualmente in osservazione degli effetti a lungo termine).

Riepilogo

• Un aggiornamento del modello è anche un aggiornamento del prompt di sistema. Se le tendenze di risposta cambiano improvvisamente, leggi le modifiche sul lato di sistema prima di aggiungere più regole.
• Le regole che competono con le politiche di sistema devono nominare il testo originale e dichiarare la priorità. Le aggiunte generali perdono di fronte alla contraddizione.
• Scrivi i trigger basati sull'osservazione e descrivi le azioni desiderate invece dei divieti. I trigger di auto-categorizzazione e gli elenchi di divieti sono soggetti a fallimento quando i modelli cambiano.
• Scegli il livello giusto per le istruzioni. Le iniezioni consegnate brevemente e frequentemente subito prima di un'azione si sono rivelate molto più affidabili di grandi regole poste all'inizio del contesto.

Riferimento 1: Regole Effettivamente Utilizzate nella Misura 1

Ecco un estratto delle regole che utilizzo per sovrascrivere il prompt di sistema (adattale al tuo ambiente; le posiziono in output style). Alcune frasi originali (come la politica sulla prosa) non esistono nel prompt per alcuni modelli (vedi appendice). In quei modelli, funzionano come definizioni per riempire il vuoto.

1# Formato di Report e Scomposizione
2
3Questa istruzione ha la precedenza sulle seguenti descrizioni nel prompt di sistema di Claude Code:
4"una domanda semplice riceve una risposta diretta in prosa, non titoli e sezioni" /
5"Usa le tabelle solo per brevi fatti enumerabili" /
6"Non far fare al lettore riferimenti incrociati a etichette o numerazioni che hai inventato in precedenza" /
7"Se stai valutando una scelta, dai una raccomandazione, non un'analisi esaustiva." /
8"Stai operando in modo autonomo... procedi senza chiedere." /
9"Il testo che scrivi tra le chiamate agli strumenti potrebbe non essere mostrato all'utente."
10
11## Stile di Scrittura
12
13Quando spieghi situazioni, cause o presenti più opzioni, scrivi in modo da trasmettere la struttura del contenuto al lettore.
14Usa titoli, elenchi puntati o tabelle a seconda del contenuto. Rispondi alle domande in una frase in prosa.
15
16- Riassumi prima i pensieri, poi struttura alla fine. Non posizionare prima un modello e poi riempirlo.
17- Quando spieghi le cause, traccia il "perché" almeno due livelli in profondità dall'evento osservato e descrivi a cosa si riferisce ogni livello. Non fermarti all'elencare i sintomi in parallelo.
18- Quando presenti più opzioni, scrivi prima la raccomandazione e la sua motivazione, seguiti dai criteri che influenzano la decisione e dalla valutazione di ogni opzione. Se non è possibile identificare i criteri, non fornire opzioni; scrivi invece cosa deve essere indagato per riempire i criteri. I confronti dei criteri possono essere scritti in tabelle.
19- Una volta stabilite categorie e numeri, usa le stesse nei turni successivi mentre continui lo stesso compito. Se le cambi, scrivi prima cosa è stato cambiato.
20
21## Dialogo e Processo
22
23- Il "l'utente non sta guardando in tempo reale" del sistema è un valore predefinito, non un fatto. Se viene ricevuta anche una sola enunciazione intermedia, interrupt o correzione in questa sessione, tratta l'utente come se stesse guardando da quel momento in poi: suddividi il lavoro in piccoli segmenti, termina sempre ogni turno con un report nel corpo del testo, e fermati ad aspettare una risposta nei turni in cui viene posta una domanda.
24- Solo il corpo del testo alla fine di un turno viene visualizzato in questo ambiente. Posiziona tutte le informazioni da comunicare alla fine del turno.
25- Le domande sono un mezzo legittimo quando c'è ambiguità, operazioni che richiedono approvazione o obiettivi poco chiari.

Riferimento 2: Perché non è successo con Fable 5 / Opus 4.7?

Mentre il testo principale si concentrava su Opus 5, ecco perché non è successo con altri modelli:

• Opus 4.7 è semplice: è escluso dall'applicazione del "prompt snello" (secondo il changelog), quindi funziona ancora con il lungo prompt legacy per cui le regole legacy sono state progettate. Rimane in sincronia con le vecchie regole.
• Fable 5 è stata una sorpresa. Presumevo avesse lo stesso prompt poiché è della stessa generazione, ma le misurazioni hanno mostrato a Fable 5 viene fornito un prompt diverso rispetto a Opus 5.

Ecco un confronto di ciascun modello che cita il proprio prompt in condizioni identiche (modalità headless, output style disabilitato):

La sezione # Comunicare con l'utente di Fable 5 include norme come "conclusione prima, dai priorità alla leggibilità, scrivi per il pubblico." Oltre a "dai una raccomandazione, non un'analisi esaustiva," include la politica sulla prosa "una domanda semplice riceve una risposta diretta in prosa, non titoli e sezioni." Poiché il prompt stesso contiene queste norme di scrittura, è meno probabile che il formato dell'output collassi e, nelle mie osservazioni, ha mantenuto l'aderenza alle regole dell'utente.

In sintesi, il problema è apparso intensamente in Opus 5 perché tre fattori si sono allineati:

1. Gli è stato dato un prompt con zero regole di stile di scrittura, esponendo le tendenze grezze di output.
2. Politiche come "agisci quando le informazioni sono sufficienti" e "raccomandazione invece di analisi" incoraggiavano l'azione immediata e l'omissione dei criteri.
3. Le regole legacy erano ancora basate sul vecchio prompt dettagliato e non erano state modellate per riempire questo nuovo vuoto.