In Cursor sehen .cursorignore und .cursorindexingignore ähnlich aus, erfüllen aber nicht denselben Zweck. Viele große Repositories mischen beides von Anfang an, und das Ergebnis ist entweder Indexierung, Durcheinandersetzung oder Blockierung des Codes, der ursprünglich von KI gesehen werden sollte.
Der einfachste Unterschied besteht darin, dass .cursorindexingignore nur den Index beeinflusst und die meisten KI-Leseleistungen nicht beeinflusst, während .cursorignore aggressiver ist, diese Dateien daran hindert, in den Index einzudringen, und zudem Zugriffspfade wie Tab, Agent, Inline Edit und @-Referenzen beeinflusst. Das heißt, das eine ist Performance und Suche, das andere ist Zugriffskontrolle.
Wenn du die Suche in der Codebasis sauberer und schneller machen willst, weil das Monorepo zu groß ist, zu viele Kompilierungsprodukte und die Dokumentation zu unübersichtlich ist, verwende zuerst .cursorindexingignore. Da diese Dokumente möglicherweise keine Indexierung wert sind, möchte man KI nicht unbedingt komplett daran hindern, sie bei Bedarf einzusehen.
Umgekehrt, wenn Sie ausdrücklich nicht möchten, dass bestimmte Verzeichnisse in den AI-Routine-Workflow eintreten, wie z. B. Zugangsdaten, private Konfigurationen und überflüssige Teilprojekte, ist .cursorignore besser geeignet. Dort steht: "Lass diesen Inhalt nicht in die Haupt-KI-Zugriffsfläche gelangen", nicht einfach "Nicht einbetten".
Warum verwenden viele Menschen den Rückwärtsgang? Denn wenn du "ignorieren" siehst, verstehst du es standardmäßig als Bedeutung. Daher wird das Leistungsproblem als Sicherheitsproblem behandelt oder als Indexproblem. Typische Folgen sind:
1. Verwendung von .cursorignore, um eine Reihe großer Verzeichnisse zu blockieren, die du nicht indexieren möchtest, was zu einem engen Sichtbarkeitsbereich führt, wenn die KI antwortet.
2. Schreibe nur .cursorindexingignore, in der Annahme, dass sensible Dateien blockiert wurden, aber die eigentliche KI könnte sie trotzdem auf anderen Pfaden begegnen.
In der Praxis ist eine sehr nützliche Einteilung: Spawn, Cache, riesige Logs und Drittanbieter-Pakete, wobei die Priorität .cursorindexingignore; Wenn du den Inhalt wirklich nicht im normalen KI-Kontext eingeben möchtest, füge .cursorignore hinzu. Nach dem Schreiben gehe zu Cursor's Indexing & Docs, um die enthaltenen Dateien anzusehen, oder nutze git check-ignore, um die Regeln zu überprüfen, verlasse dich nicht auf Raten.
Diese beiden Dokumente sind also nicht, wer wen ersetzt, sondern jedes hat seine eigene Ebene. Je komplexer das große Repository, desto mehr sollte es von Anfang an "zur Beschleunigung der Indexierung" und "zur Reduzierung des Exposure Pipe-Zugangs" trennen. Ich kann das nicht klar erkennen, und je mehr ich es einstelle, desto chaotischer wird es.
