Cursorのマルチリポジトリワークスペースでコードが見つからない場合は、正しいルートディレクトリが開かれているか確認してください。 多くの人が親ディレクトリやソフトリンクディレクトリ、または個々のサブパッケージを開くため、Cursorはファイルの一部しかインデックスできず、エージェントは当然ながら他のリポジトリで実装を見つけられなくなります。
最初に開ける場所を見てみろ
Explorerのカーソル左側にある最上位ディレクトリを見てください。 モノリポジトリを変更したい場合は、モノリポジトリのルートディレクトリを開くべきです。 もし「packages/web」だけを開くと、エージェントは「packages/api」や共有コンポーネント、root設定を見られないことがあります。
逆に、例えば「~/work」のような12個のアイテムが入った大きすぎる親ディレクトリを開くと、インデックスは遅くなり、余計なコードを文脈に混ぜ込みやすくなります。
複数のワークスペースは明確な範囲で設定すべきです
複数倉庫のワークスペースが必ずしも優れているわけではありません。 フロントエンド、バックエンド、パブリックライブラリをワークスペースに追加できますが、尋ねる際は「ウェブとAPIのルートのみで検索し、アーカイブされたプロジェクトは見ないでください」と明確に伝えてください。 ”
カーソルインデックスの結果が不安定な場合は、まずファイル検索でターゲットファイルが見えるかどうかを確認し、その後エージェントに検索させます。 書類は見つからず、エージェントが突然知ることは不可能です。
ルール無視の確認
.cursorignore、.cursorindexingignore、.gitignoreはいずれも読み取りやインデックスに異なるレベルで影響を与えます。 大規模なリポジトリでよくある問題は「dist」と「build」を無視することですが、ビルドタイプ、スキーマ、クライアントSDKも無視するため、エージェントが重要なコンテキストを欠いてしまうことがあります。
「一般化可能だが理解に影響を与える」ファイルについては別々に評価し、全体的に無視しないことが推奨されます。
決議命令
最初のステップは正しいプロジェクトのルートを再開することです。 次のステップは、ターゲットファイルが通常の検索で見つけられるかどうかを確認することです。 3つ目のステップはカーソルインデックスの状態を確認することです。 第四のステップは、無視するルールを整理することです。 第五段階は、質問の中の経路を名前で示すことです。
最も信頼できる尋ね方は、「まず『packages/api』の注文インターフェースを検索し、その後『packages/web』で呼び出しを見つけ、最後にプランのみを変更してください」です。 これは「注文バグを直すのを手伝って」というヒット率よりもずっと高いです。
