Liste de vérification pour la révision des prompts

Maya a besoin de pagination par curseur pour l'exportation des commandes. Elle tape "ajouter la pagination à l'exportation des commandes, rendre ça rapide" et l'envoie. L'assistant devine un framework, invente une forme de réponse et réécrit un fichier qu'elle voulait seulement corriger. Elle retape la demande avec des mots légèrement différents. Même type d'erreur. Après quatre allers-retours, elle a passé plus de temps à diriger que le changement n'aurait pris à écrire à la main. Le prompt manquait des faits que le modèle ne pouvait pas inventer, et reformuler le même manque une quatrième fois ne les fournit pas.

C'est l'écart que la révision comble. Un modèle de langage remplit chaque blanc que vous laissez avec la supposition la plus probable, et une supposition probable n'est pas votre base de code. Les directives de prompting d'Anthropic présentent le modèle comme un employé brillant mais nouveau qui manque de contexte sur vos normes et flux de travail, et offrent un test qui vaut la peine d'être mémorisé : montrez votre prompt à un collègue avec un contexte minimal sur la tâche et demandez-lui de le suivre. S'il serait confus, le modèle le sera aussi. Cette seule règle attrape la plupart des éléments que cette liste de vérification énumère.

Ignorer la révision démarre une boucle, et la boucle est le vrai coût. Chaque nouvelle tentative semble peu coûteuse, donc vous ne vous arrêtez jamais pour diagnostiquer, et la boucle consomme tranquillement plus de temps que lire votre brouillon une fois ne l'aurait fait. La révision est une pause délibérée qui transforme "envoyer et voir" en "vérifier et envoyer". Trente secondes contre une liste de dix lignes est presque toujours moins coûteux qu'une deuxième mauvaise réponse, car une mauvaise réponse doit encore être lue, jugée et remplacée. La liste de vérification est la version structurée du test du collègue : au lieu d'espérer que vous vous souveniez du chemin du fichier et de la contrainte, vous confirmez chacun avant que le modèle ne voie jamais la demande.

Chaque ligne est un oui/non que vous répondez en lisant votre propre brouillon. L'habileté consiste à distinguer un vrai oui d'un oui que vous souhaiteriez vrai. Voici à quoi ressemble une version forte à côté d'une version faible sur les lignes où les gens se trompent le plus.

• Rôle et objectif. Faible : "aidez-moi avec l'exportation." Fort : "Vous travaillez dans notre service d'administration Node; ajoutez la pagination par curseur à l'exportation des commandes pour qu'un client puisse récupérer 10k lignes par pages sans délai d'attente." La version forte nomme le rôle et un résultat vérifiable d'un seul souffle.
• Contexte, présent et épuré. Deux modes d'échec tirent dans des directions opposées. Faible par omission : pas de chemin de fichier, pas de framework, pas de mention que l'exportation est déjà en flux. Faible par inondation : le fichier entier de 800 lignes collé alors que seul le gestionnaire est important. Fort : le chemin du fichier, l'unique assistant à réutiliser, et la seule règle qui contraint le changement. Anthropic suggère d'exprimer le contexte comme un court ensemble de faits qui façonnent la décision et de garder le matériel brut clairement séparé, afin que les faits qui dirigent la réponse ne soient pas enterrés sous ceux qui ne le font pas.
• Contraintes en tant que règles. Faible : "rendre ça rapide" ou "garder ça propre," sur lesquels le modèle ne peut pas agir. Fort : "ne pas changer le schéma de réponse au-delà de l'ajout de nextCursor; réutiliser paginate() de lib/pagination.ts; garder le gestionnaire sous 80 lignes." Une contrainte que le modèle peut vérifier est une contrainte qui survit au contact avec la sortie.
• Format de sortie nommé. Faible : le laisser ouvert, puis être ennuyé qu'il ait réécrit le fichier. Fort : "retourner uniquement un diff unifié, pas de prose," ou "retourner JSON avec les clés orders et nextCursor." Quand la forme est facile à se tromper, ajoutez un court exemple. Les directives d'Anthropic sont directes ici : un bon exemple vaut mieux que cinq adjectifs, et les exemples à quelques coups (utilisez-en trois à cinq, chacun enveloppé pour qu'il se lise comme un échantillon) sont parmi les moyens les plus fiables de fixer le format et le ton.
• Formulation positive. Faible : "ne pas utiliser markdown." Fort : "répondre en paragraphes de prose simple." Dire au modèle quoi faire le guide plus fiablement que lui dire quoi éviter, car l'instruction pointe vers une cible au lieu d'un mur.
• Instruction placée en dernier. Lorsque vous collez un long fichier ou journal, mettez la demande réelle après celui-ci. Anthropic rapporte que déplacer la requête à la fin d'un prompt à long contexte peut améliorer la qualité de la réponse jusqu'à 30 % sur des entrées complexes et multi-documents. Une demande coincée au milieu rivalise avec tout ce qui l'entoure.
• Succès testable et incertitude gérée. Faible : "rendre ça bon." Fort : "reste sous 200 ms pour 10k lignes," plus une ligne disant au modèle de s'arrêter et de demander si l'assistant ne convient pas plutôt que d'en inventer un nouveau. Une définition de terminé pour laquelle vous pourriez écrire un test est une que vous pouvez réellement vérifier.

Vous n'avez pas besoin d'un score parfait. Vous devez trouver la ligne qui est un vrai non et corriger celle-là. La plupart des prompts échoués manquent une seule chose, et la correction est généralement une phrase, pas une réécriture.

Quelques pièges font que la liste de vérification semble terminée alors que le prompt est encore faible.

• Cochant des cases que vous souhaiteriez vraies. Le point d'échec est de lire "contraintes explicites" et de penser "rapide compte." Ce n'est pas le cas. Si vous ne pouvez pas imaginer le test, la ligne est encore un non. Soyez votre propre collègue sceptique.
• Confondre révision avec évaluation. Cette liste de vérification juge un prompt avant qu'il ne s'exécute. Elle ne dit rien sur la tenue du prompt à travers de nombreuses entrées au fil du temps. Un prompt qui passe la révision peut encore dériver ou échouer sur les entrées que vous n'avez pas envisagées. Cette question continue appartient à la Liste de vérification d'évaluation des prompts, qui évalue les sorties par rapport à une grille sur un ensemble d'entrées fixe d'environ 50 à 200 cas, le petit ensemble doré et organisé que les équipes exécutent à chaque changement pour détecter les régressions. Utilisez la révision pour livrer un bon premier prompt; utilisez l'évaluation pour faire confiance à un prompt sur lequel vous comptez.
• Surréagir au prompt. Les anciennes habitudes poussent les gens à crier : "CRITIQUE : vous DEVEZ retourner JSON, JAMAIS ajouter de prose." Les modèles actuels suivent bien les instructions normales et peuvent sur-réagir à un langage forcé et en majuscules, en faisant plus que demandé ou en traitant chaque clause comme urgente. Ramenez-le à une formulation simple. La clarté fait le travail, pas le volume.
• Traiter la révision comme l'ensemble du travail. Un prompt propre produit une réponse; il ne s'en porte pas garant. La révision se termine au moment où le modèle répond. À partir de là, la sortie n'est que du code, et le code gagne la confiance en étant lu.

En équipe, la révision rapporte deux fois. Un prompt bien révisé par une personne devient un prompt que n'importe qui peut réutiliser, car le rôle, le contexte et le format sont sur la page au lieu d'être dans la tête d'une seule personne. Les prompts sauvegardés, le CLAUDE.md d'un projet, et les extraits partagés sont là où les bons prompts révisés vont vivre, pour que la prochaine personne commence à partir d'un brouillon réussi.

Pour votre prochaine tâche réelle, n'adoptez pas toutes les dix lignes à la fois. Choisissez la ligne que vous sautez le plus souvent, probablement "format de sortie nommé" ou "le succès est testable," et forcez un oui dessus avant votre prochain envoi. Lorsque vous délimitez le travail de codage, commencez par le Brief de session de codage IA et Donner le bon contexte à l'IA pour que le prompt ait des faits à référencer. Lorsque l'assistant retourne un diff, passez à la Liste de vérification de révision de code IA et au guide Réviser le code IA en toute sécurité. La révision vous donne une question forte; ceux-ci gèrent si vous pouvez faire confiance à la réponse.