일반적인 이유는 Prettier, ESLint, Biome, EditorConfig, 프로젝트 스크립트가 저장 시 트리거되어, 에이전트가 작성한 diff가 다른 도구 세트에 의해 재정렬되기 때문입니다. 에이전트가 사소한 변경을 하도록 하기 전에 자동 저장과 자동 포맷을 일시정지하세요.
먼저, 누가 파일을 수정하는지 확인해
저장 직후 파일이 바로 바뀌는지 확인해 보세요. 들여쓰기, 따옴표, 줄 바바꿈, 가져오기 순서가 바뀌었다면, 대부분 포맷터입니다; 논리 코드도 수정된다면, 저장 훅, 린트 수정, 코드 생성 스크립트 또는 기타 확장 기능이 될 수 있습니다.
바로 커서 에이전트를 탓하지 마세요. 먼저, VS 코드/커서 설정에서 '저장 시 포맷', 기본 포맷터, 저장 시 코드 액션을 확인하세요.
자동 행동을 일시적으로 끄세요
복잡한 AI 수정 작업을 처리할 때는 일시적으로 자동 저장과 저장 서식을 끄는 것이 권장됩니다. 에이전트가 변경을 완료한 후 'format', 'lint --fix', 테스트를 수동으로 실행하세요. 이렇게 하면 차별이 더 명확해지고 문제를 찾기 쉽습니다.
팀이 포맷팅을 활성화해야 한다면, 최소한 에이전트에게 "수동으로 포맷하지 말고, 기존 포맷터로 출력하고, 마지막으로 포맷팅 명령을 실행하세요."라고 알려주세요. ”
포맷터 충돌이 여러 개 있는지 확인하세요
Prettier, ESLint fix, Biome, 내장 포맷터가 한 프로젝트에 동시에 포함되어 있어 서로 경쟁하기 쉽습니다. 그 현상은 파일이 한 번에 한 번씩 저장되고, 에이전트가 읽는 내용이 끊임없이 변한다는 점입니다.
해결책은 고유한 기본 포맷터를 지정하고 저장 동작을 도구 집합으로 수렴시키는 것입니다. 팀 프로젝트는 README나 규칙 파일로 작성하는 것이 가장 좋습니다.
가장 안정적인 과정
먼저 자동 저장을 끄고, 에이전트가 대상 파일만 수정하도록 제한하세요. 변경한 후에는 diff를 살펴보세요; 그 다음 수동으로 포맷하세요; 마지막으로 테스트를 진행하세요. 포맷팅 후 로직이 깨지면 원래 변경 사항과 포맷터 구성 사이에 충돌이 발생한 것이며, 이를 따로 처리해야 합니다.
AI가 코드를 작성하는 것은 형식 변경을 두려워하지 않지만, 글을 쓰는 동안 다른 도구들에 의해 수정되는 것을 두려워합니다. "생성"과 "포맷"을 두 단계로 나누면 커서가 훨씬 안정적으로 수정할 수 있습니다.
