Optimiseur de Prompt

Optimise les prompts pour les agents, les instructions système/développeur et les modèles de prompt réutilisables. Traite le travail sur les prompts comme un workflow piloté par l'évaluation, pas comme du polissage de texte.

Charge uniquement les références dont tu as besoin :

Étape 1 : Définir le contrat du prompt

1. Détermine si la tâche consiste à :

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

2. Capture 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
• échecs connus
• contraintes strictes : 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, construis un petit ensemble d'évaluation avant d'éditer le prompt.

4. Si le vrai goulot d'étranglement est le choix du modèle, une récupération manquante, des schémas d'outils faibles ou un harnais d'évaluation manquant, dis-le. Ne continue pas à réécrire le texte du prompt quand l'échec est ailleurs.

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

Lis references/model-family-notes.md.

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

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

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

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

Lis references/core-patterns.md.

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

• la politique stable et les defaults comportementaux appartiennent à system ou developer
• les entrées variables, le contexte récupéré et les instances de tâches appartiennent aux sections user-facing avec template
• quand le système prompt est assemblé à l'exécution à partir d'une couche de plateforme et d'une couche persona rédigée par le déployeur (par ex. SOUL.md, CLAUDE.md, AGENTS.md), vois « Layered prompts with multiple owners » dans references/core-patterns.md — les règles de comportement de la plateforme ne doivent pas dépendre de ce que contient la couche déployeur

2. Garde une instruction autoritaire par comportement :

• si une règle apparaît dans plus d'une couche, choisis 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, non répéter toute la politique
• les payloads utilisateur doivent porter des faits locaux à la tâche, pas la politique durable

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

• utilise 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
• garde les noms de balises descriptifs et cohérents
• ne mets pas du markup autour de chaque phrase

4. Rends le prompt facile à exécuter :

• mets un comportement de haute valeur par bullet ou ligne quand la tâche est fragile
• préfère les instructions positives aux listes « ne fais pas X »
• place les règles d'utilisation d'outils, les limites d'escalade et les conditions d'arrêt dans des sections explicites
• garde la persona légère sauf si elle change le comportement de manière utile
• utilise le libellé le plus court qui préserve la contrainte comportementale voulue
• coupe le remplissage motivationnel, les rappels répétés et les exemples qui n'améliorent pas les évaluations
• pour les prompts en long contexte, place l'evidence avant la requête finale et garde la demande réelle dans une section finale claire
• garde les instructions, l'evidence et les schémas dans des blocs distincts pour que le modèle n'ait pas à déduire ce qui est politique versus données

5. Traite les exemples comme des assets de prompt de première classe :

• commence simple avant d'ajouter des exemples
• ajoute des exemples uniquement quand ils améliorent le contrôle de format, la gestion des cas limites ou le comportement des outils
• garde les exemples structurellement cohérents
• préfère les démonstrations positives aux démonstrations d'anti-patterns uniquement

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

Lis references/meta-optimization-loop.md.

1. Commence avec le prompt actuel ou un premier brouillon simple.
2. Note-le sur une tranche représentative :

• au moins un cas de chemin heureux
• au moins un rejeu d'échec
• au moins un cas ambigu
• au moins un cas limite
• au moins un cas « devrait refuser », « devrait demander » ou « devrait différer » le cas échéant

3. Transforme les échecs en critiques explicites :

• identifie ce que le prompt sous-spécifie, sur-spécifie ou contredit
• écris les critiques comme des édits actionnables, pas des plaintes vagues

4. Génère un petit faisceau de prompts candidats :

• une réparation diff-minimale
• une réécriture structure-first
• une variante centrée sur l'exemple ou la règle d'outil quand c'est le goulot probable
• un adaptateur spécifique au fournisseur quand le comportement entre modèles est le problème

5. Compare les candidats sur la même tranche d'évaluation.
6. Garde le meilleur candidat et enregistre ce qui a changé et pourquoi.
7. Préserve l'evidence pour chaque round :

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

8. Teste le gagnant sur une tranche retenue avant de finaliser.
9. Arrête quand les scores stagnent, les édits oscillent, les coûts montent sans gain de qualité, ou le problème restant est hors du contrôle du prompt.

Garde les édits minimaux et causaux. Enregistre ce que tu as supprimé ainsi que ce que tu as ajouté. Si tu changes tout à la fois, tu n'apprends rien sur ce qui a vraiment aidé.

Étape 5 : Produire un livrable réutilisable

Retourne :

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, inclus une explication brève de style diff des plus grands changements comportementaux.

Étape 6 : Protéger contre les modes d'échec courants

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

Ne fais pas :

• optimiser le libellé 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 sans raison prouvée
• laisser les règles stables dériver dans le payload 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 échecs d'utilisation d'outils uniquement dans le système prompt quand le vrai problème est la description d'outil ou le schéma
• ajouter des marqueurs partout et confondre structure et clarté
• utiliser une persona gonflée comme substitut aux règles de comportement concrètes

Standard de sortie

Le paquet 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