Optimiseur de Prompt

Optimisez les prompts pour les agents, les instructions système/développeur et les modèles de prompts réutilisables. Traitez le travail sur les prompts comme un workflow guidé par l'évaluation, pas comme du perfectionnement de formulation.

Chargez uniquement les références dont vous avez besoin :

Étape 1 : Définir le contrat du prompt

1. Déterminez si la tâche est :

• créer un nouveau prompt
• affiner un prompt existant
• porter un prompt entre familles de modèles
• déboguer les défaillances de prompts

2. Capturez le contrat avant de réécrire quoi que ce soit :

• famille de modèles cible et snapshot si connu
• surface du prompt : system, developer, user, descriptions d'outils, exemples, schémas
• objectif de la tâche et non-objectifs
• entrées, contexte et outils disponibles pour l'agent
• forme de sortie requise
• critères de succès
• défaillances connues
• contraintes dures : latence, verbosité, sécurité, budget, utilisation d'outils, style

3. Si l'utilisateur ne fournit pas de critères de succès ou d'exemples, construisez un petit ensemble d'évaluation avant de modifier le prompt.

4. Si le vrai goulot d'étranglement est le choix du modèle, la récupération manquante, les schémas d'outils faibles ou un harnais d'évaluation manquant, dites-le. Ne continuez pas à réécrire le texte du prompt quand la défaillance est ailleurs.

Étape 2 : Choisir la stratégie du modèle

Lisez references/model-family-notes.md.

1. Si la famille cible est connue, optimisez spécifiquement pour cette famille.
2. Si la famille cible est inconnue, écrivez :

• un prompt de base portable
• des notes d'adaptateur courtes pour les familles de modèles probables

3. Ne prétendez pas qu'un prompt est universel quand le comportement dépend clairement de la famille de modèles.
4. Épinglez les snapshots de modèles quand le système environnant le supporte.

Étape 3 : Façonner le prompt délibérément

Lisez references/core-patterns.md.

1. Séparez le comportement durable du contexte local à la tâche :

• les politiques stables et les défauts comportementaux appartiennent à system ou developer
• les entrées variables, le contexte récupéré et les instances de tâche appartiennent aux sections utilisateur templatees
• quand le prompt système est assemblé au runtime à partir d'une couche de plateforme et d'une couche de persona créée par le déployeur (par ex., SOUL.md, CLAUDE.md, AGENTS.md), voir « Prompts stratifiés avec plusieurs propriétaires » dans references/core-patterns.md — les règles de comportement de la plateforme ne doivent pas dépendre de ce que contient la couche de déployeur

2. Gardez une instruction unique et autoritaire par comportement :

• si une règle apparaît dans plus d'une couche, choisissez un propriétaire pour elle
• les règles stables entre tâches appartiennent à system ou developer
• les exemples doivent enseigner le format, la gestion des cas limites ou le comportement des outils, pas répéter toute la politique
• les charges utiles utilisateur doivent porter des faits locaux à la tâche, pas des politiques durables

3. Utilisez les marqueurs uniquement quand ils réduisent l'ambiguïté :

• utilisez les en-têtes Markdown ou les balises de style XML pour séparer les instructions, le contexte, les exemples, les règles d'outils et les contrats de sortie
• gardez les noms de balises descriptifs et cohérents
• ne wrapped pas chaque phrase dans du markup

4. Rendez le prompt facile à exécuter :

• mettez un comportement de haute valeur par puce ou ligne quand la tâche est fragile
• préférez les instructions positives aux listes « ne pas faire X »
• placez les règles d'utilisation d'outils, les limites d'escalade et les conditions d'arrêt dans des sections explicites
• gardez la persona légère à moins qu'elle ne change le comportement d'une manière utile
• utilisez la formulation la plus courte qui préserve la contrainte comportementale prévue
• supprimez le remplissage motivationnel, les rappels répétés et les exemples qui n'améliorent pas les évaluations
• pour les prompts de long contexte, placez les preuves avant la requête finale et gardez la demande réelle dans une section terminale claire
• gardez les instructions, les preuves et les schémas dans des blocs distincts afin que le modèle n'ait pas à déduire ce qui est politique par rapport aux données

5. Traitez les exemples comme des actifs de prompt de première classe :

• commencez simplement avant d'ajouter des exemples
• ajoutez des exemples uniquement quand ils améliorent le contrôle de format, la gestion des cas limites ou le comportement des outils
• gardez les exemples structurellement cohérents
• préférez les démonstrations positives aux démonstrations anti-pattern uniquement

Étape 4 : Exécuter la boucle d'optimisation méta

Lisez references/meta-optimization-loop.md.

1. Commencez par le prompt actuel ou un premier brouillon simple.
2. Évaluez-le sur une tranche représentative :

• au moins un cas heureux
• au moins une relecture d'échec
• au moins un cas ambigu
• au moins un cas limite
• au moins un cas « devrait refuser », « devrait demander » ou « devrait déférer » si pertinent

3. Transformez les défaillances en critiques explicites :

• identifiez ce que le prompt sous-spécifie, sur-spécifie ou contredit
• écrivez les critiques comme des modifications actionnables, pas des plaintes vagues

4. Générez un petit beam de prompts candidats :

• une réparation à diff minimal
• une réécriture axée sur la structure
• une variante centrée sur l'exemple ou la règle d'outil quand c'est le goulot d'étranglement probable
• un adaptateur spécifique au fournisseur quand le comportement entre modèles est en question

5. Comparez les candidats sur la même tranche d'évaluation.
6. Gardez le meilleur candidat et enregistrez ce qui a changé et pourquoi.
7. Préservez les preuves pour chaque round :

• version du prompt
• cas d'évaluation
• sortie du modèle
• raison de la défaillance
• scores pertinents

8. Testez le gagnant sur une tranche de rétention avant de finaliser.
9. Arrêtez quand les scores plafonnent, les modifications oscillent, le coût augmente sans gain de qualité ou le problème restant est en dehors du contrôle du prompt.

Gardez les modifications minimales et causales. Enregistrez ce que vous avez supprimé ainsi que ce que vous avez ajouté. Si vous changez tout à la fois, vous n'apprenez rien sur ce qui a vraiment aidé.

Étape 5 : Produire un livrable réutilisable

Retournez :

1. Target
2. Success Criteria
3. Optimized Prompt
4. Adapter Notes
5. Eval Set
6. Optimization Log
7. Residual Risks

Si l'utilisateur a fourni un prompt existant, incluez une explication concise de style diff des plus grands changements comportementaux.

Étape 6 : Se protéger contre les modes de défaillance courants

Lisez references/transformed-examples.md quand la tâche est ambiguë ou le premier brouillon est faible.

Ne faites pas :

• optimiser la formulation avant de définir la cible d'évaluation
• mélanger les instructions, les exemples et le contexte brut sans limites
• garder la même règle dans plusieurs couches à moins qu'il n'y ait une raison prouvée
• laisser les règles stables dériver dans la charge utile utilisateur juste parce que le modèle de prompt actuel le rend pratique
• demander aux modèles de raisonnement de révéler la chaîne de pensée juste parce que la tâche est difficile
• garder les instructions héritées contradictoires dans le même prompt
• surapprendre à partir d'un ou deux exemples
• garder les exemples qui n'améliorent pas le comportement mesuré
• résoudre les défaillances d'utilisation d'outils uniquement dans le prompt système quand le vrai problème est la description ou le schéma de l'outil
• ajouter des marqueurs partout et confondre la structure avec la clarté
• utiliser une persona gonflée comme substitut aux règles de comportement concrètes

Norme de sortie

Le package de prompt final doit être réutilisable par un autre ingénieur sans redécouvrir :

• à quoi sert le prompt
• quelle famille de modèles il cible
• comment le succès est mesuré
• ce qui a changé pendant l'optimisation
• quels risques restent ouverts