Pourquoi Cursor préfère-t-il toujours réécrire un ensemble au lieu d’utiliser une implémentation que vous avez déjà dans votre projet ? Ce genre de plainte est courant, mais Cursor a en fait clairement indiqué la réponse dans le code Réutiliser l’existant : si vous ne lui demandez pas explicitement de « trouver une implémentation existante avant de décider d’en écrire une nouvelle », il peut générer une nouvelle version par défaut.
Pourquoi cela arrive-t-il ?
Les éditeurs IA sont bons pour compléter et générer, mais « généré » ne signifie pas « le meilleur pour votre entrepôt ». Surtout dans les projets anciens, les projets collaboratifs à plusieurs personnes et le monorepo, l’approche vraiment la plus raisonnable est généralement de suivre le modèle existant. Mais si votre invite est simplement « aidez-moi à écrire un test de connexion » ou « ajoutez une couche de cache », il est tout à fait possible de sauter l’étape de récupération et de créer directement une nouvelle roue.
Solutions plus pratiques
La façon la plus directe n’est pas de changer le modèle, mais de mettre les règles en avant. L’idée officielle est d’abord demander à Cursor de réécrire la requête en « Je cherche s’il existe déjà du code capable de faire cela », de chercher d’abord dans la base de code, puis de décider s’il faut créer une nouvelle implémentation. Lors de l’atterrissage, vous pouvez faire ceci :
- Dans les règles du projet, il est indiqué : Cherchez d’abord des implémentations similaires, puis générez un nouveau code.
- Lorsque vous posez une question, ajoutez une phrase : Trouvez d’abord l’usage existant, les composants existants et les services existants, et ne les réécrivez pas immédiatement.
- Donnez-lui un point clair avec un « Files » ou un contexte de chat pour un fichier clé, et ne le laissez pas jouer avec seulement quelques lignes de code à proximité.
Donc le cœur de ce type de problème n’est pas « le curseur ne sera pas réutilisé », mais vous ne lui donnez pas d’ordre de fonctionnement qui doit être réutilisé en premier. Lorsque l’ordre est bien réglé, il se comporte généralement beaucoup plus stable, et c’est plutôt comme un collaborateur capable de s’intégrer dans la base de code existante.
