On This Page8 sections
Ce guide repose sur les informations de septembre 2026. Les tarifs, modèles et intitulés peuvent évoluer ; il ne s’agit pas de données en temps réel.
Donnez à l’agent des contraintes de projet utiles sans transformer chaque demande en spécification complète.
Rédigez des règles vérifiables
Commencez par les commandes de validation, les dossiers source importants et une ou deux contraintes architecturales. « Utiliser la fonction de validation des formulaires existante » est plus concret que « écrire du code propre ». Ce sont des conseils de rédaction ; noms de fichiers et règles d’activation varient selon l’outil.
Une instruction de départ
Adaptez cet exemple au dépôt, puis enregistrez-le avec la fonction de règles ou d’instructions documentée par votre outil.
Before editing, inspect the nearest existing implementation.
Use the package manager already configured in this repository.
Run the relevant checks for changed behavior.
Report any check you could not run and why.
Do not edit generated output directly.Vérifiez qu’une règle s’applique réellement
Essayez une tâche simple où l’instruction modifie une action observable. Examinez le résultat et les commandes, puis limitez la règle si elle intervient hors sujet. Révisez les règles avec le dépôt, comme les instructions de compilation.
Une première tâche complète : modifier, vérifier et relire
-
Choisissez un petit dépôt qui compile déjà. Enregistrez un état Git propre et la commande de contrôle qui réussit avant toute modification.
-
Définissez un résultat observable, par exemple un champ obligatoire dans un formulaire existant. Précisez fichiers, validation existante et comportements à conserver.
-
Demandez un plan bref avant l’édition. Vérifiez les composants concernés, le flux de données et les contrôles prévus ; complétez d’abord le contexte manquant.
-
Relisez les différences par étapes, y compris dépendances, fichiers générés, variables d’environnement et gestion des erreurs. Testez réussite et échec.
-
Notez le résultat accepté, le temps de revue et la consommation. Recommencez sur une seconde tâche représentative avant de choisir un forfait ou de migrer l’équipe.
Un modèle de consigne à adapter
Objectif : changement visible par l’utilisateur.
Contexte : fichiers concernés et implémentation existante.
Contraintes : conserver API publique et dépendances.
Vérification : contrôles du projet et cas d’échec.
Fin : fichiers modifiés, contrôles exécutés et limites restantes.Quand le résultat ne fonctionne pas
Une réponse réussie ne prouve pas la validité du code. Si les mauvais fichiers changent, réduisez le périmètre et indiquez le point d’entrée. Reproduisez les commandes dans le même terminal. Pour MCP, distinguez démarrage, identifiants et configuration. En cas de quota épuisé, vérifiez solde et modèle avant de relancer. Gardez des correctifs petits et réversibles.
Questions avant de changer
Un abonnement payant donne-t-il un usage illimité de l’agent ?
Non. Tarif, usage inclus, accès aux modèles et dépassements sont distincts. La complétion illimitée ne signifie pas des requêtes illimitées.
Faut-il connecter tous les serveurs MCP ?
Commencez par l’intégration nécessaire. Vérifiez démarrage, outils et contexte transmis avant d’en ajouter une autre.
Comment comparer deux éditeurs ?
Utilisez le même dépôt, la même tâche et les mêmes critères. Comparez changements corrects, revue, configuration et consommation réelle.
Guides TRAE associés
Continue Reading
More articles connected to the same themes, protocols, and tools.
Referenced Tools
Browse entries that are adjacent to the topics covered in this article.
