Les quatre contraintes qui font fonctionner chaque prompt ci-dessous
Avant les prompts, les règles qu'ils partagent tous. Les ajouter à n'importe quel prompt de code améliore le résultat plus qu'un changement de modèle.
Indiquez votre version. Les données d'entraînement sont biaisées vers la version majeure sur laquelle on a le plus écrit, ce qui n'est souvent pas celle que vous utilisez. Nous utilisons [framework] [version], [langage] [version] évite la plupart des réponses obsolètes.
Limitez le diff. Demandez un correctif et vous obtenez souvent un refactoring. Change le moins de choses possible, préserve la structure et les noms existants, et liste chaque ligne modifiée avec une raison en une ligne est la phrase la plus utile de ce document.
Demandez des hypothèses avant des solutions. Un modèle à qui l'on demande ce qui ne va pas vous donne une supposition présentée comme une conclusion. Un modèle à qui l'on demande des causes classées et des vérifications peu coûteuses vous donne un plan de débogage.
Exigez le mode de défaillance. Qu'est-ce que cela pourrait casser, et est-ce que cela corrige la cause ou le symptôme ? détecte la catégorie d'assistance IA la plus coûteuse : un changement qui fait disparaître le symptôme alors que le défaut reste.
Débogage
1. Hypothèses classées
Voici l'erreur, le code concerné et ce que j'ai déjà écarté. Ne me donne pas encore de correctif. Liste les quatre causes les plus probables classées par probabilité, et pour chacune la vérification la moins coûteuse qui la confirmerait ou l'éliminerait. Erreur : [coller]. Code : [coller]. Déjà écarté : [liste]. Stack : [langage, framework, versions].
2. Le bug intermittent
Ceci échoue par intermittence, environ [fréquence], dans [conditions]. Énumère les catégories de défaillance intermittente qui pourraient produire ce symptôme précis : timing, ordre, épuisement des ressources, dépendance externe, état qui fuit entre les exécutions, horloge ou fuseau horaire, mise en cache. Pour chacune, dis ce que le code confirme ou contredit, et ce que je devrais exactement journaliser pour les distinguer. Code : [coller].
3. Ça marche en local
Ceci fonctionne en local et échoue dans [environnement]. Liste chaque catégorie de différence d'environnement qui pourrait causer ce symptôme précis : configuration, variables d'environnement, versions, système de fichiers et sensibilité à la casse, fuseau horaire et locale, réseau et DNS, permissions, limites de ressources, et différences de build ou de packaging. Classe par probabilité selon le symptôme, et donne-moi la commande de diagnostic pour chacune.
4. Explique le correctif avant que je l'applique
Explique pourquoi ce correctif fonctionne, ce qu'il ne corrige pas, et ce qu'il pourrait casser. Si la vraie cause est ailleurs et qu'il s'agit d'un correctif de symptôme, dis-le directement.
Revue de code
5. Revoir un diff
Revois ce diff comme un relecteur exigeant. Catégories par ordre de priorité : bugs de correction, problèmes de sécurité, modes de défaillance non gérés, conditions de concurrence, puis style. Pour chaque constat, donne la sévérité, la ligne précise, et pourquoi cela compte dans cette base de code plutôt qu'en général. Ne commente pas le formatage. Si le diff est solide, dis-le au lieu d'inventer des constats. Conventions : [décrire]. Diff : [coller].
6. La passe sécurité
Revois ce code spécifiquement pour les problèmes de sécurité : injection, failles d'authentification et d'autorisation, désérialisation non sûre, secrets dans le code ou les logs, entrée non validée atteignant une opération sensible, et risque de dépendance. Pour chacun, donne le chemin d'attaque concrètement plutôt que de nommer la catégorie. Précise clairement ce que tu ne peux pas évaluer sans voir [déploiement, couche d'authentification, sensibilité des données].
7. L'audit des modes de défaillance
Pour chaque appel externe dans ce code, indique ce qui se passe quand il est lent, quand il échoue, quand il renvoie des données inattendues, et quand il réussit partiellement. Lesquels ne sont actuellement pas gérés, et lesquels seraient silencieux ?
Ce dernier trouve plus de vrais problèmes de production qu'une revue générale, car il interroge les chemins pour lesquels personne n'a écrit de test.
Refactoring et architecture
8. Le plan de refactoring
Propose un plan séquencé pour refactoriser [description]. Contraintes : l'API publique de [x] ne peut pas changer, nous déployons en continu donc chaque étape doit être livrable indépendamment, et les tests doivent passer après chaque étape. Pour chaque étape, donne le changement, le risque, comment le vérifier, et comment revenir en arrière. Ordonne par risque, du plus faible au plus élevé. N'écris pas encore le code.
9. Défends l'autre camp
Je choisis [approche A] plutôt que [approche B] pour [contexte et contraintes]. Fais le meilleur plaidoyer possible pour B. Que faudrait-il de vrai dans nos contraintes pour que B soit correct, et est-ce le cas ici ? Ne conclus pas que les deux sont valables.
10. Comprendre ce que tu as hérité
Voici les principaux fichiers source. Produis : les points d'entrée, le flux de données de la requête à la réponse, l'état partagé et où il est modifié, les dépendances externes et ce qui se passe quand chacune est indisponible, et les trois zones les plus susceptibles de contenir des bugs selon la complexité et le couplage. Précise explicitement ce que tu ne peux pas déterminer à partir de ce que j'ai fourni.
Cette dernière instruction compte. Les modèles décriront le comportement d'un fichier que vous n'avez pas collé, déduit de son nom. Forcer une liste explicite d'inconnues vous dit quoi aller lire.
Tests
11. Les tests que vous n'auriez pas écrits
Écris des cas de test pour cette fonction, en te concentrant sur les entrées que je n'ai probablement pas envisagées : limites, vide et null, unicode, valeurs très grandes, appels concurrents, et toute hypothèse implicite de l'implémentation. Pour chaque test, précise l'hypothèse qu'il vérifie. Fonction : [coller].
12. Teste la suite de tests
Voici une fonction et ses tests existants. Quel comportement n'est pas couvert ? Précisément : chemins d'erreur, valeurs limites, interactions entre paramètres, et tout ce que l'implémentation fait sans qu'aucun test ne l'affirme. Ne réécris pas les tests existants.
Le second est le prompt à plus forte valeur et il est rarement utilisé. Les pourcentages de couverture indiquent quelles lignes se sont exécutées, pas quels comportements sont réellement figés, et c'est dans cet écart que vivent les régressions.
Le modèle du second avis
L'habitude la plus rentable de tout ce pack, et celle qui exige plus d'un modèle.
Obtenez une réponse d'un modèle. Puis changez et transmettez-la :
Un autre ingénieur a proposé cette solution à ce problème. Trouve ce qui ne va pas : correction dans les cas limites, concurrence, gestion des erreurs, performance à [échelle], ou une approche plus simple qui a été manquée. Si c'est réellement solide, dis-le clairement plutôt que d'inventer des objections. Problème : [coller]. Solution proposée : [coller].
Deux résultats, et les deux sont utiles. Soit le second modèle trouve une vraie faille, que vous connaissez désormais avant de fusionner, soit il est d'accord malgré la consigne de contester, ce qui est une confirmation significative. Itérer avec le même modèle ne donne ni l'un ni l'autre, car un modèle qui relit son propre résultat est surtout d'accord avec lui même.
Utilisez-le pour les décisions coûteuses à rater : un changement de schéma, un correctif de concurrence, tout ce qui touche à l'authentification ou à l'argent. Pas pour le travail courant. Voir comparer des modèles côte à côte, changer de modèle en cours de conversation, et écrire et déboguer du code avec plusieurs modèles pour tout le workflow réuni au même endroit.
Ce à quoi faire attention
API inventées. Des noms de méthodes, des paramètres et des clés de configuration présentés avec assurance qui n'existent pas, surtout pour les bibliothèques récemment modifiées. La signature aura l'air correcte. Vérifiez la documentation réelle avant de construire sur quoi que ce soit d'inconnu.
Aucun signal de confiance. Un correctif juste et un autre subtilement faux arrivent avec la même assurance. Le ton ne vous dit rien.
Dérive de périmètre silencieuse. C'est exactement pour cela que la deuxième contrainte existe.
Théâtre de sécurité. Nommer des classes de vulnérabilités dans votre code est une première passe utile. Ce n'est pas un audit, et le modèle ne connaît pas votre modèle de menace, votre déploiement, ni la sensibilité de vos données.
Gardez les prompts que vous utilisez chaque semaine à un endroit où vous pouvez les coller, et placez les contraintes permanentes dans les instructions d'un projet pour qu'elles s'appliquent automatiquement à chaque conversation de ce projet.
- Indiquez votre langage, votre framework et votre version dans chaque prompt de code
- Ajoutez la phrase qui limite le diff à tout prompt qui produit du code
- Demandez des hypothèses classées et des vérifications peu coûteuses avant de demander un correctif
- Demandez toujours ce qu'un correctif pourrait casser et s'il traite le symptôme
- Appliquez le modèle du second avis sur tout ce qui est coûteux à rater
- Demandez ce que la suite de tests existante ne couvre pas, pas seulement plus de tests
- Vérifiez les API inconnues dans la documentation réelle
- Gardez les prompts que vous utilisez chaque semaine à portée de main
Questions fréquentes
Ces prompts fonctionnent-ils uniquement avec Claude ?
Non. Ils sont écrits pour le style de raisonnement soigné à long contexte que Claude maîtrise bien, et ils fonctionnent directement avec GPT et Gemini aussi. En fait, plusieurs sont mieux utilisés entre modèles différents : le prompt de second avis en exige deux, et le prompt « défends l'autre camp » est plus utile quand le modèle qui argumente n'a pas fait le choix initial.
Quel modèle utiliser pour quel prompt ?
Comme point de départ : Claude pour le raisonnement subtil, les architectures inconnues et expliquer pourquoi quelque chose se comporte ainsi ; GPT pour l'implémentation rapide sur un terrain bien connu et une sortie structurée stricte ; un modèle à grand contexte quand la question couvre plus de code qu'un prompt normal ne peut en contenir confortablement. Puis ajustez cela avec une semaine de vos propres comparaisons, car la bonne réponse dépend plus de votre stack que de n'importe quel benchmark.
Est-ce un remplacement pour un outil de code agentique ?
Non, ils résolvent des problèmes différents. Un agent vit dans votre dépôt et modifie des fichiers. Ces prompts sont pour la couche de raisonnement : comprendre une erreur, revoir un diff, planifier un refactoring, débattre d'une approche. La plupart des développeurs utilisent les deux, et le choix du modèle compte davantage ici car vous évaluez le raisonnement plutôt que le diff produit.
Comment l'empêcher de réécrire du code que je n'ai pas demandé ?
Ajoutez ceci au prompt : change le moins de choses possible, préserve la structure et les noms existants, et liste chaque ligne modifiée avec une raison en une ligne. Le refactoring non demandé est la principale raison pour laquelle les suggestions IA deviennent invérifiables, et limiter le diff fait la différence entre un changement que vous pouvez raisonner et un que vous devez relire depuis zéro.
Puis-je coller du code propriétaire ?
Whizi ne s'entraîne pas sur vos conversations et la politique de données de chaque fournisseur est consultable avant d'activer ce modèle, mais la politique de votre employeur est la contrainte qui prévaut et elle varie beaucoup. Là où des restrictions s'appliquent, reproduire le problème sous forme d'exemple minimal qui préserve la structure et retire la logique métier est généralement à la fois permis et un meilleur prompt, car cela retire les détails qui monopolisaient l'attention.