Configuration des règles de curseur pour que l'IA cesse de casser votre style de base de code

Lors de mon premier mois avec Cursor, chaque modification d'agent a fonctionné et semblait toujours erronée : onglets dans lesquels mon dépôt utilise des espaces, exportations par défaut dans une base de code de ceux nommés, tests écrits dans un style que notre CI rejette. Le correctif n'était pas meilleur. C'étaient des fichiers de règles, correctement configurés.

Le curseur lit les règles de .cursor/rules dans votre dépôt. Commencez avec un fichier de règles au niveau du projet couvrant les éléments non négociables : le gestionnaire de packages, l'ordre d'importation, les conventions de dénomination et les deux ou trois modèles utilisés par votre base de code qui diffèrent des valeurs par défaut courantes. Gardez-le sous environ 50 lignes - un fichier de règles que personne ne conserve devient du bruit que le modèle apprend à ignorer.

La fonctionnalité sous-estimée concerne les règles par répertoire. Notre répertoire de composants obtient une règle : composants de fonction uniquement, accessoires saisis en ligne, pas d'exportation par défaut. Notre répertoire de serveur en reçoit un autre : pas d'importation côté client, chaque gestionnaire valide l'entrée. Cette division a fait plus pour la qualité de sortie que tout ce que j'ai écrit dans le fichier global, car le modèle ne voit que les règles qui s'appliquent aux fichiers qu'il touche.

Trois règles ont gagné leur place par pure répétition. Premièrement : "Après l'édition, exécutez la commande lint existante et corrigez toutes les erreurs que vous avez introduites." Deuxièmement : « Faites correspondre le style d'importation du fichier que vous modifiez, et non le style que vous préférez. » Troisièmement : « Si une modification nécessite une nouvelle dépendance, arrêtez-vous et demandez au lieu d'installer. » Ce dernier est arrivé après que j'ai trouvé cinq nouveaux packages dans un diff qui en avait besoin.

Ce que j'ai arrêté de faire : répéter les instructions de style dans chaque message de discussion. Avec les règles en place, mes invites décrivent l'intention (ce qu'il faut construire, ce qu'il faut éviter) et le fichier de règles gère le style maison. L'invite est devenue plus courte et le résultat est devenu plus cohérent, ce qui correspond à l'ensemble du jeu.

Une habitude de maintenance : lorsque l'agent fait la même erreur à plusieurs reprises, ajoutez une règle au lieu de le gronder dans le chat. Les corrections du chat meurent avec la conversation ; fichiers de règles composés. Mon fichier de règles s'est agrandi d'environ deux lignes par semaine, et chaque ligne contient une correction de bug.

Questions fréquemment posées :

Q : Les fichiers de règles ralentissent-ils le curseur ?

R : Pas visiblement. Ils sont injectés dans le contexte à côté de votre invite. Le coût réel est un fichier de règles volumineux qui dilue l'attention, c'est pourquoi je plafonne le mien et supprime les règles que la base de code est devenue trop grande.

Q : Les règles doivent-elles être intégrées au repo ?

R : Oui, si vous souhaitez que toute l’équipe en profite, traitez-la comme une configuration linter. Conservez les préférences personnelles dans les règles au niveau de l'utilisateur plutôt que dans le fichier de projet.

Q : En quoi les règles sont-elles différentes de la simple écriture d'une bonne invite système ?

R : Les règles s'appliquent automatiquement à chaque demande dans leur portée, survivent au fil des sessions et sont versionnées avec le code. Une invite système dans votre tête ne profite à personne d’autre qu’à vous et s’évapore à chaque fois que vous démarrez une nouvelle conversation.