Claude vous ment en face tous les jours. Des fonctions inventées, des imports bidons, des « tests passent » alors que rien n'a été exécuté. La solution est une configuration en 4 couches qui rend le mensonge coûteux.
Claude vous dit que le bug est corrigé. Deux heures plus tard, vous découvrez que la fonction qu'il a appelée n'a jamais existé.
La plupart des développeurs apprennent à tout revérifier et à blâmer le modèle. La vraie solution attrape chaque mensonge avant qu'il ne quitte votre machine.
Voici la configuration complète pour l'honnêteté 👇
Pourquoi Claude invente des choses en premier lieu
Claude est un prédicteur de texte. Quand il ne sait pas quelque chose, il prédit un texte qui semble correct. Des noms de fonctions inventés ressemblent à de vrais noms. Des absurdités livrées avec assurance se lisent comme des vérités livrées avec assurance.
Vous ne pouvez pas faire la différence jusqu'à ce que votre code plante deux heures plus tard d'une manière qui prend encore une heure à déboguer.
La solution n'est pas un modèle plus intelligent. C'est rendre la sortie de Claude vérifiable en temps réel et rendre « je ne sais pas » moins coûteux que de deviner.
4 couches ci-dessous. Ensemble, elles réduisent la fabrication à presque zéro.
Couche 1 : Les règles d'honnêteté dans CLAUDE.md
La première couche est un ensemble de règles dans CLAUDE.md qui disent exactement à Claude quand admettre l'incertitude et exactement comment. Mettez ceci dans la racine de votre projet :
1## Règles d'honnêteté (à lire à chaque tour)23Avant d'affirmer qu'une fonction, une classe ou un import existe, vérifiez-le en lisant4le fichier ou en exécutant un grep. N'inventez jamais de symboles.56Si vous ne pouvez pas vérifier quelque chose, dites explicitement « je n'ai pas vérifié ceci ».7N'écrivez pas de code qui dépend de l'affirmation non vérifiée.89Si une tâche vous demande d'utiliser une bibliothèque que vous n'avez jamais vue référencée dans ce10projet, demandez avant de l'ajouter.1112Si une tâche implique des tests ou des builds, ne prétendez pas au succès à moins d'avoir13réellement exécuté la commande de test ou de build dans cette session.1415N'inventez jamais de messages d'erreur, de réponses d'API ou de traces de pile. Si vous16ne les avez pas vus, dites-le.1718Quand vous ne savez vraiment pas, la bonne réponse est « je ne sais pas » ou19« je dois d'abord vérifier ». Les deux sont meilleurs qu'une supposition confiante.
Ces règles semblent évidentes.
Elles ne le sont pas, car par défaut Claude est optimisé pour paraître utile, et « je ne sais pas » semble inutile à moins que vous ne lui donniez une permission explicite.
La dernière ligne est la plus importante. C'est la licence « je ne sais pas », et la plupart des gens ne l'accordent jamais.
Couche 2 : Le modèle vérification-avant-écriture
La deuxième couche force Claude à vérifier avant d'écrire. Ajoutez ceci à CLAUDE.md sous les règles d'honnêteté :
1## Protocole de vérification23Avant d'écrire ou de modifier du code qui utilise un symbole (fonction, classe, type,4constante), faites l'une des choses suivantes :561. Lisez le fichier où il est défini et confirmez la signature72. Exécutez `grep -r "nomDuSymbole" .` ou utilisez l'outil Glob pour le trouver83. Vérifiez package.json, requirements.txt, Cargo.toml, ou l'équivalent pour9 la dépendance1011Si vous sautez la vérification, préfixez le code avec un commentaire :12`// NON VÉRIFIÉ : Je n'ai pas confirmé que ce symbole existe`1314Le mode planifier-puis-exécuter est préféré pour toute tâche touchant plus d'un15fichier. Utilisez Shift+Tab pour entrer en mode planification avant de commencer.
Cela coûte à Claude quelques appels d'outils supplémentaires par session. Cela vous fait gagner les heures que vous auriez passées à déboguer des appels de fonctions fictifs.
Couche 3 : Les hooks qui attrapent les mensonges en temps réel
La troisième couche est constituée de hooks dans settings.json qui exécutent un vérificateur de type ou un linter chaque fois que Claude écrit un fichier. Si Claude a inventé un import, le vérificateur échoue instantanément, et Claude doit le corriger avant de prétendre que la tâche est terminée.
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}
La sortie du hook est renvoyée à Claude comme contexte. Si tsc dit « Impossible de trouver le module 'foo' », Claude le voit immédiatement et corrige l'import fabriqué. Aucun code inventé ne survit à une vérification PostToolUse.
Pour les tâches impliquant des tests, ajoutez un hook Stop qui exécute la suite avant que Claude ne puisse déclarer la session terminée :
1"Stop": [2 {3 "hooks": [4 { "type": "command", "command": "npm test 2>&1 | tail -30" }5 ]6 }7]
Maintenant, Claude ne peut pas dire « terminé, les tests passent » sans les avoir réellement exécutés. Le hook les exécute.
Le résultat est renvoyé à Claude. S'ils échouent, Claude doit les corriger ou admettre qu'ils ne passent pas.
Couche 4 : Le sous-agent vérificateur de faits
La quatrième couche est un sous-agent dont le seul travail est de vérifier les affirmations de Claude avant qu'elles ne soient livrées.
Mettez ceci dans .claude/agents/fact-checker.md :
1---2name: fact-checker3description: Utilisez cet agent après que Claude a fait des affirmations sur ce que fait le code, quels tests ont réussi, ou ce qu'une bibliothèque supporte. Invoquez avant tout commit, avant tout résumé destiné à l'utilisateur, et après toute tâche impliquant de nouvelles dépendances.4tools: Read, Grep, Glob, Bash5model: sonnet6---78Vous vérifiez les affirmations, vous n'écrivez pas de code.910Lorsqu'il est invoqué, faites ceci :11121. Identifiez chaque affirmation factuelle dans la conversation récente. Exemples :13 « la fonction X fait Y », « les tests passent », « la bibliothèque Z supporte W »,14 « cet import est correct ».15162. Pour chaque affirmation, vérifiez-la indépendamment :17 - Affirmations de code : lisez le fichier réel et confirmez18 - Affirmations de test : exécutez les tests vous-même19 - Affirmations de bibliothèque : vérifiez le package réel ou sa documentation20 - Affirmations d'import : confirmez que le package est dans le manifeste des dépendances21223. Produisez un rapport :23 - VÉRIFIÉ : affirmation, preuve (fichier:ligne ou sortie de commande)24 - FAUX : affirmation, ce qui est réellement vrai25 - NON VÉRIFIABLE : affirmation, pourquoi vous n'avez pas pu le vérifier2627N'acceptez jamais les affirmations « faites-moi confiance ». Ne faites jamais vos propres affirmations. Si vous28ne pouvez pas vérifier, la sortie correcte est NON VÉRIFIABLE.
Invoquez cet agent avant les commits ou avant de partager les résultats avec votre équipe. Il attrape les mensonges que les 3 autres couches ont manqués.
La licence « je ne sais pas »
Claude a été entraîné pour être utile, et admettre son ignorance semble inutile. Alors il devine, et la supposition semble correcte.
La solution est d'accorder la permission de ne pas savoir. CLAUDE.md en est la moitié. Votre réaction est l'autre moitié. Récompensez « je n'ai pas vérifié ceci » avec patience et vous obtenez un Claude honnête à chaque session. Punissez-le avec frustration et Claude retourne à ses suppositions.
Pas une configuration, une habitude. La correction la plus sous-estimée de la pile.
Comment savoir si ça fonctionne réellement
Trois signes dans vos sessions quotidiennes.
Claude demande avant d'ajouter des dépendances. « Dois-je ajouter X ou utiliser la bibliothèque standard ? » au lieu d'un npm install silencieux.
Claude référence fichier:ligne quand il parle de code existant. « validateToken dans src/auth/middleware.ts:47 fait Y » au lieu de « la fonction validateToken fait Y. »
tsc et votre linter arrêtent de crier. Les hooks attrapent les rares fabrications instantanément et Claude s'auto-corrige, donc au moment où vous regardez, les mensonges ont disparu.
Vous ne voyez pas ces signes après un jour ou deux ? Une couche n'est pas chargée. Généralement CLAUDE.md, mauvais emplacement ou mauvais nom.
Erreurs courantes qui maintiennent Claude dans le mensonge
CLAUDE.md est trop long. Claude lit la première partie et parcourt le reste. Placez les règles d'honnêteté dans les 50 premières lignes.
Les hooks enregistrent en silence. Si la sortie n'atteint pas stdout, Claude ne sait pas qu'il a menti. Assurez-vous que la sortie du hook retourne à la session.
Vous sautez le mode planification. C'est là que Claude expose les mauvaises hypothèses avant d'écrire. Sautez-le et vous sautez le moment le moins coûteux pour attraper les mensonges.
Vous n'appelez pas le vérificateur de faits. Un sous-agent ne fonctionne que si vous l'invoquez réellement. Faites de @fact-checker une partie de votre flux de commit.
Vous réagissez mal au « je ne sais pas. » Punissez l'honnêteté une fois et Claude retourne à ses suppositions. Les 3 autres couches ne tiennent pas sans celle-ci.
L'audit d'honnêteté en 5 minutes
1 minute : copiez les règles d'honnêteté et le protocole de vérification de CLAUDE.md dans la racine de votre projet.
1 minute : copiez le bloc de hooks dans ~/.claude/settings.json ou .claude/settings.json.
2 minutes : créez .claude/agents/fact-checker.md avec le modèle ci-dessus.
1 minute : exécutez une tâche que vous vérifieriez normalement deux fois. Surveillez la sortie de tsc revenant à Claude. Confirmez que Claude dit « vérifié » ou « je n'ai pas vérifié ceci » explicitement.
Terminé. La fabrication passe de « une session sur deux » à « rare et immédiatement attrapée. » Le modèle n'est pas devenu plus intelligent. Votre configuration, oui.
Merci d'avoir lu !
