Wenn du den Code im Cursor-Multirepository-Arbeitsbereich nicht findest, überprüfe, ob das richtige Root-Verzeichnis geöffnet ist. Viele Leute öffnen das Elternverzeichnis, das Softlink-Verzeichnis oder einzelne Unterpakete, wodurch Cursor nur einen Teil der Datei indexiert und der Agent die Implementierung in einem anderen Repository natürlich nicht finden kann.
Schau, wo du es zuerst öffnest.
Schau dir das oberste Verzeichnis im Explorer auf der linken Seite von Cursor an. Wenn du ein Monorepo ändern möchtest, solltest du das Monorepo-Root-Verzeichnis öffnen; Wenn du nur 'Pakete/Web' öffnest, sieht der Agent möglicherweise keine 'Pakete/API', keine gemeinsamen Komponenten und Root-Konfigurationen.
Umgekehrt, wenn Sie ein übergroßes Elternverzeichnis wie '~/work' mit einem Dutzend Einträgen öffnen, ist der Index langsamer und es ist einfacher, überflüssigen Code in den Kontext einzufügen.
Mehrere Arbeitsbereiche sollten im Umfang klar sein
Arbeitsplätze mit mehreren Lagerhäusern sind nicht immer besser. Du kannst Frontend, Backend und öffentliche Bibliotheken zum Arbeitsbereich hinzufügen, aber sei klar, wenn du fragst: "Suche nur im Web und in API-Roots, schau dir keine archivierten Projekte an." ”
Wenn die Ergebnisse des Cursor-Indexes instabil sind, verwenden Sie zunächst eine Dateisuche, um zu bestätigen, ob die Zieldatei sichtbar ist, und lassen Sie dann den Agenten sie durchsuchen. Dokumente sind nicht zu finden, und es ist unmöglich, dass Agenten das aus dem Nichts wissen.
Überprüfe, ob Regeln ignoriert werden
.cursorignore, .cursorindexingignore und .gitignore können alle Reads und Indizes auf unterschiedlichen Ebenen beeinflussen. Ein häufiges Problem in großen Repositories ist, 'dist' und 'build' zu ignorieren, aber sie ignorieren auch den Build-Typ, das Schema und das Client-SDK, was dazu führt, dass dem Agenten der Schlüsselkontext fehlt.
Es wird empfohlen, Dateien, die "generierbar, aber das Verständnis beeinflussen", separat zu bewerten und sie nicht überall zu ignorieren.
Auflösungsreihenfolge
Der erste Schritt ist, die korrekte Projektwurzel wieder zu öffnen. Der zweite Schritt besteht darin, sicherzustellen, dass die Zieldatei in der normalen Suche gefunden werden kann. Der dritte Schritt ist die Überprüfung des Cursor-Indexstatus. Der vierte Schritt ist, die Ignorierungsregeln zu bereinigen. Der fünfte Schritt ist, den Weg in der Frage zu benennen.
Die zuverlässigste Möglichkeit zu fragen ist: "Bitte suchen Sie zuerst nach der Bestelloberfläche in 'packages/api', dann finden Sie den Aufruf in 'packages/web' und ändern Sie schließlich nur den Plan." Das ist viel höher als die Trefferquote von "Hilf mir, den Bestellfehler zu beheben".
