Les développeurs rencontrent les prompts à deux endroits : lorsqu’ils demandent à un assistant IA de modifier du code, et lorsqu’ils écrivent des prompts livrés dans une application. Les compétences se recoupent, mais les modes de défaillance diffèrent. Ce guide couvre les deux.
Partie 1 : Les prompts pour assistants de programmation IA
Écrivez une spécification, pas un souhait
Un assistant de programmation à qui l’on donne une seule phrase doit en déduire le périmètre, les contraintes et ce que signifie « terminé ». Donnez-lui ce que vous mettriez dans un bon ticket.
fix login issue and make google login work and don't break anything
## Objective
Fix the login failure and make Google login work.
## Constraints
- Do not change the existing email and password flow.
- Keep the public API of AuthService unchanged.
## Edge cases
- Expired or revoked OAuth tokens.
- A Google account whose email already exists as a password account.
## Testing
- Add unit tests for the token exchange and the account-linking path.
## Acceptance criteria
- Existing auth tests pass. New tests cover both edge cases.
## Expected output
A summary of the cause, then the changed files as diffs.
Le second prompt demande une minute de plus à écrire et évite un aller-retour du type « ce n’est pas ce que je voulais dire ». L’extension VS Code de PromptFlowEngine génère cette structure à partir d’une tâche d’une ligne et des fichiers concernés.
Fournissez le bon code, pas tout le code
Les fenêtres de contexte sont grandes, mais l’attention n’est pas illimitée. Incluez les fichiers que touche la modification, les interfaces qu’elle doit respecter et un exemple des conventions du projet. Laissez de côté les fichiers générés, les fichiers de verrouillage et les modules sans rapport.
Dites ce qui ne doit pas changer
Les assistants optimisent pour la demande. Si la rétrocompatibilité, une interface publique ou les performances comptent, dites-le. « Ne casse rien » n’est pas une contrainte qu’un modèle peut vérifier ; « garde inchangé le schéma de réponse de GET /orders » en est une.
Demandez un plan pour les grosses modifications
Pour tout ce qui dépasse une petite retouche, demandez d’abord le plan, relisez-le, puis demandez l’implémentation. C’est l’enchaînement de prompts appliqué au code, et il détecte une mauvaise approche avant qu’une ligne ne soit écrite.
Vérifiez ce qui revient
Lisez le diff. Lancez les tests. Pour les modifications importantes, écrivez un prompt de revue qui donne au modèle la tâche d’origine et les fichiers modifiés, et demandez-lui de lister où la modification ne respecte pas les critères d’acceptation.
Partie 2 : Les prompts dans votre application
Gardez les prompts sous gestion de versions
Un prompt fait partie du comportement de votre programme. Stockez-le dans un fichier, relisez les changements dans des pull requests et étiquetez les versions. Voir la gestion et le versionnement des prompts.
Utilisez des modèles avec des variables délimitées
Ne concaténez jamais l’entrée de l’utilisateur dans les instructions. Utilisez des variables nommées et enveloppez chacune dans des balises.
PROMPT = """Classify the support ticket in the tags as billing, bug, or other.
Return only the label.
<ticket>
{ticket}
</ticket>"""
Exigez une sortie structurée et validez-la
Si votre code analyse la réponse, demandez du JSON conforme à un schéma, utilisez la fonction de sortie structurée du fournisseur quand elle existe et validez le résultat avant de l’utiliser. Voir les prompts de sortie structurée.
Budgétez les tokens
Sachez combien de tokens utilise votre prompt fixe, car vous le payez à chaque appel. Comptez avec le vrai tokeniseur du modèle, pas avec une estimation en caractères. Voir l’optimisation des tokens.
Testez les prompts en CI
Les contrôles statiques détectent les régressions qui n’ont pas besoin d’un modèle : un format de sortie supprimé, une section dupliquée, un nombre de tokens au-dessus du budget, une clé d’API validée dans le dépôt. La barrière de test des prompts les exécute à chaque pull request.
- run: promptflow check "prompts/**/*.md" --min-score 70 --max-tokens 1500
Traitez la sortie du modèle comme non fiable
La sortie peut être fausse, et elle peut être détournée par du texte injecté dans l’entrée. Ne la transmettez pas à un shell, à une requête SQL ou à une page HTML sans la même validation que pour une entrée utilisateur. Voir la sécurité des prompts.
Appeler le moteur depuis du code
Les mêmes contrôles sont disponibles par HTTP sans clé, ce qui est pratique pour un test d’intégration rapide ou un outil interne :
curl -s https://promptflowengine.com/api/v1/analyze \
-H 'content-type: application/json' \
-d '{"prompt":"Write something about our product."}'
Voir l’API HTTP pour les points de terminaison, ou connectez-la à un agent de programmation via MCP.