Come impedire a Claude Code di inventare risposte quando non conosce la soluzione (Configurazione dettagliata)

Claude Code ti mente in faccia ogni giorno. Funzioni inventate, import fasulli, "test superati" quando non è stato eseguito nulla. La soluzione è una configurazione a 4 livelli che rende costoso mentire.

Claude ti dice che il bug è stato risolto. Due ore dopo scopri che la funzione che ha chiamato non è mai esistita.

La maggior parte degli sviluppatori impara a ricontrollare tutto e a dare la colpa al modello. La vera soluzione intercetta ogni bugia prima che lasci la tua macchina.

Ecco la configurazione completa per l'onestà 👇

Perché Claude si inventa le cose in primo luogo

Claude è un predittore di testo. Quando non sa qualcosa, predice un testo che sembra corretto. I nomi di funzioni inventati sembrano veri. Le sciocchezze pronunciate con sicurezza vengono lette allo stesso modo della verità pronunciata con sicurezza.

Non puoi distinguere la differenza finché il tuo codice non si rompe due ore dopo in un modo che richiede un'altra ora per il debug.

La soluzione non è un modello più intelligente. È rendere l'output di Claude verificabile in tempo reale e rendere "non lo so" più economico dell'indovinare.

4 livelli qui sotto. Insieme riducono le invenzioni a circa zero.

Livello 1: Le regole di onestà in CLAUDE.md

Il primo livello è un insieme di regole in CLAUDE.md che dicono a Claude esattamente quando ammettere l'incertezza e come. Inserisci questo nella root del tuo progetto:

1## Regole di onestà (leggi a ogni turno)
2
3Prima di affermare che una funzione, una classe o un import esista, verificalo leggendo
4il file o eseguendo un grep. Non inventare mai simboli.
5
6Se non puoi verificare qualcosa, dì "Non ho verificato questo" esplicitamente.
7Non scrivere codice che dipende dall'affermazione non verificata.
8
9Se un'attività ti chiede di usare una libreria che non hai mai visto referenziata in questo
10progetto, chiedi prima di aggiungerla.
11
12Se un'attività coinvolge test o build, non affermare il successo a meno che tu non abbia
13effettivamente eseguito il comando di test o build in questa sessione.
14
15Non inventare mai messaggi di errore, risposte API o stack trace. Se non
16li hai visti, dillo.
17
18Quando non sai veramente, la risposta corretta è "Non lo so" o
19"Devo prima controllare." Entrambe sono meglio di un'ipotesi sicura.

Queste regole sembrano ovvie.

Non lo sono, perché di default Claude è ottimizzato per sembrare utile, e "non lo so" sembra inutile a meno che non gli venga dato esplicito permesso.

L'ultima riga è la più importante. È la licenza per "non lo so", e la maggior parte delle persone non la concede mai.

Livello 2: Il pattern di verifica prima di scrivere

Il secondo livello costringe Claude a verificare prima di scrivere. Aggiungi questo a CLAUDE.md sotto le regole di onestà:

1## Protocollo di verifica
2
3Prima di scrivere o modificare codice che usa un simbolo (funzione, classe, tipo,
4costante), fai una delle seguenti:
5
61. Leggi il file in cui è definito e conferma la firma
72. Esegui `grep -r "nomeSimbolo" .` o usa lo strumento Glob per trovarlo
83. Controlla package.json, requirements.txt, Cargo.toml o equivalente per
9   la dipendenza
10
11Se salti la verifica, prefissa il codice con un commento:
12`// NON VERIFICATO: Non ho confermato che questo simbolo esista`
13
14La modalità pianifica-poi-esegui è preferita per qualsiasi attività che tocchi più di un
15file. Usa Shift+Tab per entrare in modalità pianificazione prima di iniziare.

Questo costa a Claude qualche chiamata extra agli strumenti per sessione. Ti fa risparmiare le ore che avresti passato a fare il debug di chiamate a funzioni false.

Livello 3: Gli hook che intercettano le bugie in tempo reale

Il terzo livello sono gli hook in settings.json che eseguono un type checker o un linter ogni volta che Claude scrive un file. Se Claude ha inventato un import, il checker fallisce immediatamente, e Claude deve risolverlo prima di dichiarare l'attività completata.

1{
2  "hooks": {
3    "PostToolUse": [
4      {
5        "matcher": "Write(*.ts|*.tsx)|Edit(*.ts|*.tsx)",
6        "hooks": [
7          { "type": "command", "command": "npx tsc --noEmit --pretty false 2>&1 | head -20" }
8        ]
9      },
10      {
11        "matcher": "Write(*.py)|Edit(*.py)",
12        "hooks": [
13          { "type": "command", "command": "ruff check --quiet $file && pyright $file 2>&1 | head -20" }
14        ]
15      },
16      {
17        "matcher": "Write(*.rs)|Edit(*.rs)",
18        "hooks": [
19          { "type": "command", "command": "cargo check --message-format=short 2>&1 | head -20" }
20        ]
21      }
22    ]
23  }
24}

L'output dell'hook torna a Claude come contesto. Se tsc dice "Impossibile trovare il modulo 'foo'", Claude lo vede immediatamente e corregge l'import inventato. Nessun codice inventato sopravvive a un controllo PostToolUse.

Per le attività che coinvolgono test, aggiungi un hook Stop che esegue la suite prima che Claude possa dichiarare la sessione conclusa:

1"Stop": [
2  {
3    "hooks": [
4      { "type": "command", "command": "npm test 2>&1 | tail -30" }
5    ]
6  }
7]

Ora Claude non può dire "fatto, test superati" senza averli effettivamente eseguiti. L'hook li esegue.

Il risultato torna a Claude. Se falliscono, Claude deve risolverli o ammettere che non sono superati.

Livello 4: Il subagente fact-checker

Il quarto livello è un subagente il cui unico compito è rivedere le affermazioni di Claude prima che vengano rilasciate.

Inserisci questo in .claude/agents/fact-checker.md:

1---
2name: fact-checker
3description: Usa questo agente dopo che Claude ha fatto affermazioni su cosa fa il codice, quali test sono stati superati o cosa supporta una libreria. Invocalo prima di qualsiasi commit, prima di qualsiasi riepilogo per l'utente e dopo qualsiasi attività che ha coinvolto nuove dipendenze.
4tools: Read, Grep, Glob, Bash
5model: sonnet
6---
7
8Verifichi le affermazioni, non scrivi codice.
9
10Quando vieni invocato, fai questo:
11
121. Identifica ogni affermazione fattuale nella conversazione recente. Esempi:
13   "la funzione X fa Y", "i test sono superati", "la libreria Z supporta W",
14   "questo import è corretto".
15
162. Per ogni affermazione, verificala in modo indipendente:
17   - Affermazioni sul codice: leggi il file effettivo e conferma
18   - Affermazioni sui test: esegui i test tu stesso
19   - Affermazioni sulla libreria: controlla il pacchetto effettivo o la sua documentazione
20   - Affermazioni sull'import: conferma che il pacchetto sia nel manifest delle dipendenze
21
223. Produci un report:
23   - VERIFICATO: affermazione, evidenza (file:riga o output del comando)
24   - SBAGLIATO: affermazione, cosa è vero in realtà
25   - NON VERIFICABILE: affermazione, motivo per cui non hai potuto controllarla
26
27Non accettare mai affermazioni "fidati di me". Non fare mai affermazioni tue. Se non
28puoi verificare, l'output corretto è NON VERIFICABILE.

Invoca questo agente prima dei commit o prima di condividere i risultati con il tuo team. Intercetta le bugie che gli altri 3 livelli hanno perso.

La licenza per "non lo so"

Claude è stato addestrato per essere utile, e ammettere l'ignoranza sembra inutile. Quindi indovina, e l'ipotesi sembra giusta.

La soluzione è concedere il permesso di non sapere. CLAUDE.md è metà della soluzione. La tua reazione è l'altra metà. Ricompensa "Non ho verificato questo" con pazienza e ottieni Claude onesto in ogni sessione. Puniscilo con frustrazione e Claude torna a indovinare.

Non una configurazione, ma un'abitudine. La soluzione più sottovalutata nell'intero stack.

Come capire che funziona davvero

Tre segnali nelle tue sessioni quotidiane.

Claude chiede prima di aggiungere dipendenze. "Devo aggiungere X o usare la stdlib?" invece di un silenzioso npm install.

Claude fa riferimento a file:riga quando parla di codice esistente. "validateToken in src/auth/middleware.ts:47 fa Y" invece di "la funzione validateToken fa Y."

tsc e il tuo linter smettono di urlare. Gli hook intercettano le rare invenzioni all'istante e Claude si autocorregge, quindi quando guardi, le bugie sono sparite.

Non vedi questi segnali dopo un giorno o due? Un livello non è stato caricato. Di solito CLAUDE.md, posizione o nome sbagliati.

Errori comuni che mantengono Claude bugiardo

CLAUDE.md è troppo lungo. Claude legge la prima parte e scansiona il resto. Metti le regole di onestà nelle prime 50 righe.

Gli hook registrano in silenzio. Se l'output non raggiunge stdout, Claude non sa di aver mentito. Assicurati che l'output dell'hook torni alla sessione.

Salta la modalità di pianificazione. È lì che Claude espone presupposti sbagliati prima di scrivere. Saltala e salti il momento più economico per intercettare le bugie.

Non chiami il fact-checker. Un subagente funziona solo se lo invochi effettivamente. Rendi @fact-checker parte del tuo flusso di commit.

Reagisci male a "non lo so." Punisci l'onestà una volta e Claude torna a indovinare. Gli altri 3 livelli non reggono senza questo.

L'audit di onestà in 5 minuti

1 minuto: copia le regole di onestà e il protocollo di verifica di CLAUDE.md nella root del tuo progetto.

1 minuto: copia il blocco degli hook in ~/.claude/settings.json o .claude/settings.json.

2 minuti: crea .claude/agents/fact-checker.md con il template qui sopra.

1 minuto: esegui un'attività che normalmente ricontrolleresti. Osserva l'output di tsc che torna a Claude. Conferma che Claude dica esplicitamente "verificato" o "non ho verificato questo".

Fatto. Le invenzioni passano da "ogni due sessioni" a "rare e intercettate immediatamente." Il modello non è diventato più intelligente. La tua configurazione sì.

Grazie per aver letto!