커서 멀티 저장소 작업 공간에서 코드를 찾지 못하면, 올바른 루트 디렉터리가 열려 있는지 확인하세요. 많은 사람들이 부모 디렉터리, 소프트 링크 디렉터리, 또는 개별 서브패키지를 열어 커서가 파일의 일부만 인덱싱하게 되고, 에이전트는 자연스럽게 다른 저장소에서 구현물을 찾지 못합니다.
먼저 어디서 열었는지 봐
커서 왼쪽에 있는 탐색기 최상위 디렉터리를 보세요. 모노레포를 변경하고 싶다면, 모노레포 루트 디렉터리를 열어야 합니다; 'packages/web'만 열면 에이전트가 'packages/api', 공유 컴포넌트, 루트 구성을 못할 수 있습니다.
반대로, '~/work'처럼 12개의 항목이 있는 과도한 상위 디렉터리를 열면 인덱스가 느려지고 불필요한 코드를 문맥에 섞기 쉬워집니다.
여러 작업 공간은 범위가 명확해야 합니다
다중 창고 작업 공간이 항상 더 나은 것은 아닙니다. 프론트엔드, 백엔드, 공개 라이브러리를 작업 공간에 추가할 수 있지만, 요청할 때는 "웹과 API 루트에서만 검색하고, 아카이브된 프로젝트는 마세요."라고 명확히 하세요. ”
커서 인덱스 결과가 불안정하면, 먼저 파일 검색을 통해 대상 파일이 보이는지 확인한 후 에이전트가 검색하도록 합니다. 문서는 찾을 수 없고, 에이전트가 아무것도 모르는 것은 불가능합니다.
규칙 무시를 확인해
.cursorignore, .cursorindexingignore, .gitignore는 모두 읽기와 인덱스에 서로 다른 수준으로 영향을 줄 수 있습니다. 대규모 저장소에서 흔히 발생하는 문제 중 하나는 'dist'와 'build'를 무시하는 것인데, 빌드 유형, 스키마, 클라이언트 SDK도 무시하여 에이전트가 핵심 맥락을 갖추지 못하게 됩니다.
"일반화 가능하지만 이해에 영향을 미친" 파일은 별도로 평가하고 전반적으로 무시하지 않는 것이 권장됩니다.
결의명령
첫 번째 단계는 올바른 프로젝트 루트를 다시 여는 것입니다. 두 번째 단계는 일반 검색에서 대상 파일을 찾을 수 있는지 확인하는 것입니다. 세 번째 단계는 커서 인덱스 상태를 확인하는 것입니다. 네 번째 단계는 무시 규칙을 정리하는 것입니다. 다섯 번째 단계는 질문 속 경로의 이름을 밝히는 것입니다.
가장 신뢰할 만한 질문 방법은 "먼저 'packages/api'에서 주문 인터페이스를 검색하고, 'packages/web'에서 호출을 찾고, 마지막으로 계획만 수정해 주세요."입니다. 이 비율은 '주문 버그 고쳐줘'보다 훨씬 높습니다.
