Adoptez les trois réflexes du praticien - recouper avec la documentation officielle, tester soi-même, traquer les signaux d'hallucination - avant d'intégrer quoi que ce soit.
Ouvrir cette leçon dans KodokonUne hallucination n'est pas une réponse absurde : c'est une réponse plausible et fausse - une méthode qui devrait exister mais n'existe pas, une option renommée depuis deux versions, un comportement par défaut inversé. C'est précisément ce qui rend les développeurs confirmés vulnérables : le code halluciné est idiomatique, bien nommé, cohérent avec l'écosystème. Il a l'air juste. Trois réflexes non négociables avant d'intégrer quoi que ce soit : recouper avec la documentation officielle de la version que vous utilisez, tester le code vous-même dans un contexte minimal, et faire auditer la réponse - y compris par le modèle lui-même.
Reprends ta réponse précédente et audite-la comme si elle venait de quelqu'un d'autre.
1. Liste chaque affirmation technique vérifiable : nom d'API ou de fonction, comportement décrit, valeur par défaut, numéro de version.
2. Pour chacune, donne ton niveau de confiance : certain / probable / à vérifier.
3. Pour chaque « à vérifier », indique exactement quoi chercher dans la documentation officielle : nom de la page, de la fonction ou du module concerné.
4. Signale tout ce qui pourrait dépendre de la version ou de la plateforme, en précisant à partir de quelle version c'est valable si tu le sais.
Sois plus sévère avec toi-même que je ne le serais : une affirmation surclassée en « certain » me coûte plus cher qu'une affirmation sous-classée.Cet auto-audit ne prouve rien - un modèle peut être confiant et faux - mais il transforme une prose fluide en liste de faits vérifiables, chacun avec son point d'entrée dans la doc. C'est vous qui vérifiez ; l'IA a juste préparé le terrain. Apprenez aussi à repérer les signaux d'alerte : une API exactement taillée pour votre besoin (trop belle pour être vraie), un mélange de conventions de versions différentes dans le même extrait, un aplomb parfaitement uniforme - les vraies expertises disent « ça dépend » ; l'hallucination, jamais -, et l'absence de toute mention de limite ou de cas particulier. Aucun signal n'est une preuve, mais chacun doit déclencher une vérification.
Tu viens d'affirmer que [affirmation précise à vérifier].
1. Aide-moi à concevoir le test le plus court possible pour le vérifier moi-même : le fichier minimal à créer, la commande exacte à lancer, le résultat précis que je dois observer si tu as raison - et ce que j'observerai à la place si tu as tort.
2. Ensuite, joue l'avocat du diable : dans quels cas ton affirmation serait-elle fausse ? Version, plateforme, configuration, mode strict ou non - passe tout en revue.
Je lancerai le test moi-même : ne me demande pas de te croire sur parole, donne-moi les moyens de te contredire.Ce prompt applique au quotidien un principe scientifique : une affirmation vaut quelque chose si elle est falsifiable - si vous savez ce que vous observeriez au cas où elle serait fausse. Dix lignes dans un fichier jetable et une exécution valent tous les degrés de confiance déclarés. Pour le recoupement documentaire, trois habitudes : vérifiez dans la doc de votre version (les modèles mélangent allègrement les époques d'une API), consultez le changelog quand un comportement semble avoir changé, et gardez un REPL ou un fichier de brouillon ouvert en permanence - le coût de vérification doit être si bas que vous n'ayez jamais d'excuse pour sauter l'étape.