AI가 코드베이스 스타일을 위반하지 않도록 커서 규칙 설정

Cursor를 사용한 첫 달에는 모든 에이전트 편집이 제대로 작동했지만 여전히 잘못된 느낌을 받았습니다. 내 저장소에서 공백을 사용하는 탭, 명명된 코드베이스의 기본 내보내기, CI가 거부하는 스타일로 작성된 테스트 등이 있었습니다. 수정 사항이 더 잘 표시되지 않았습니다. 규칙 파일이었고 올바르게 설정되었습니다.

커서는 저장소의 .cursor/rules에서 규칙을 읽습니다. 협상할 수 없는 항목(패키지 관리자, 가져오기 순서, 명명 규칙, 코드베이스에서 사용하는 공통 기본값과 다른 2~3개 패턴)을 다루는 하나의 프로젝트 수준 규칙 파일로 시작하세요. 약 50줄 미만으로 유지하십시오. 아무도 유지하지 않는 규칙 파일은 모델이 무시하도록 학습하는 노이즈가 됩니다.

과소평가된 기능은 디렉터리별 규칙입니다. 우리의 컴포넌트 디렉토리는 규칙을 따릅니다: 함수 컴포넌트만, 인라인으로 입력된 props, 기본 내보내기 없음. 서버 디렉토리에는 또 다른 기능이 있습니다. 클라이언트 측 가져오기가 없으며 모든 핸들러가 입력을 검증합니다. 이 분할은 제가 전역 파일에 작성한 것보다 출력 품질에 더 많은 영향을 미쳤습니다. 왜냐하면 모델은 자신이 접촉하는 파일에 적용되는 규칙만 보기 때문입니다.

세 가지 규칙은 순수한 반복을 통해 자리를 잡았습니다. 첫째: '편집 후 기존 lint 명령을 실행하고 발생한 모든 오류를 수정하세요.' 둘째: '선호하는 스타일이 아닌 편집 중인 파일의 가져오기 스타일을 일치시키세요.' 셋째: '변경 사항에 새로운 종속성이 필요한 경우 설치하는 대신 중지하고 문의하세요.' 마지막 패키지는 diff에서 하나가 필요한 5개의 새 패키지를 찾은 후에 나왔습니다.

내가 그만둔 일: 모든 채팅 메시지에서 스타일 지침을 반복하는 것입니다. 규칙이 적용되면 내 메시지는 무엇을 만들 것인지, 무엇을 피해야 하는지 등의 의도를 설명하고 규칙 파일이 주택 스타일을 처리합니다. 프롬프트는 더 짧아지고 출력은 더 일관되게 되었습니다. 이것이 바로 게임 전체입니다.

한 가지 관리 습관: 상담원이 같은 실수를 반복할 때 채팅에서 꾸짖기보다는 규칙을 추가해 보세요. 채팅 수정은 대화와 함께 사라집니다. 규칙 파일 복합. 내 규칙 파일은 일주일에 약 두 줄씩 늘어났으며, 각 줄에는 버그 수정이 포함되어 있습니다.

자주 묻는 질문:

Q: 규칙 파일로 인해 커서 속도가 느려지나요?

A: 눈에 띄지는 않습니다. 프롬프트와 함께 컨텍스트에 삽입됩니다. 실제 비용은 관심을 희석시키는 비대한 규칙 파일입니다. 이것이 바로 제가 제한을 두고 코드베이스가 초과된 규칙을 삭제하는 이유입니다.

Q: 규칙을 리포지토리에 적용해야 합니까?

A: 예, 팀 전체가 혜택을 받기를 원한다면 Linter 구성처럼 취급하십시오. 프로젝트 파일 대신 사용자 수준 규칙에서 개인 기본 설정을 유지하세요.

Q: 규칙은 단순히 좋은 시스템 프롬프트를 작성하는 것과 어떻게 다릅니까?

A: 규칙은 해당 범위 내의 모든 요청에 자동으로 적용되고, 세션 전반에 걸쳐 유지되며, 코드로 버전이 지정됩니다. 머리 속 시스템 메시지는 본인 외에는 누구에게도 도움이 되지 않으며 새로운 채팅을 시작할 때마다 사라집니다.