코덱스가 나쁜 코드를 바꿀 때, 가장 금기시되는 것은 모든 곳에서 수동으로 삭제하는 것입니다. 먼저 diff를 유지해서 어떤 파일이 변경되었는지 확인하고, Git의 세부 수준에 따라 롤백하세요. 이렇게 하면 프로젝트를 복원할 뿐만 아니라 문제의 단서를 남기고 다음번에 같은 구덩이를 반복하는 것을 방지할 수 있습니다.
가장 먼저 할 일: 무엇이 바뀌었는지 먼저 확인하세요
프로젝트 루트 디렉터리에서 'git status'를 실행하면 'git diff'를 확인하세요. 변경사항이 많다면 직접 제거하지 말고, 먼저 비즈니스 코드, 설정 파일, 잠금 파일, 생성 파일, 테스트 파일별로 분류하세요. 많은 실패는 사실 한두 개의 구성 또는 가져오기 경로에서만 발생하며, 모든 결과를 잃을 필요는 없습니다.
아직 커밋하지 않았다면, 임시 패치를 저장하는 것을 권장합니다: git diff > codex-bad-change.patch. 이 문서는 출시용이 아니라 향후 비교용입니다.
더 안정적으로 후퇴하는 방법
파일이 고장 났다면 그 파일만 복원하고, 저장소 전체를 비우지 마세요. 편집기의 소스 제어 패널을 사용해 파일별로 버릴 수도 있고, Git의 파일 수준 복구를 사용할 수도 있습니다.
코덱스 변경이 여러 파일에 걸쳐 있다면, 각 파일이 왜 변경되었는지 설명하게 하세요. 설명할 수 없는 문서는 먼저 제거되며; 명확하게 설명하되 파일에 버그를 구현한 뒤 부분적으로 수정하세요.
다음에는 너무 많이 바꾸지 않는 방법
Codex는 한 번에 한 가지 목표만 처리하게 합니다: 먼저 테스트를 작성하고, 구현을 변경한 후 검증을 실행합니다. 한 메시지로 리팩토링, 버그 수정, UI 변경, 성능 최적화를 하지 마세요. 작업이 복잡할수록 차별을 되돌리기가 더 어려워집니다.
시작 전에 "한 번에 최대 3개의 변경을 하고, 수정 전에 계획을 나열하며, 완료 후 실제 변경 및 검증 명령어를 나열한다"고 지정할 수도 있습니다. "이로 인해 통제력을 잃을 확률이 크게 줄어듭니다.
기트 없이 어떻게 해야 할까
Git이 없는 프로젝트의 경우, AI가 변경하기 전에 현재 디렉터리를 복사하고 백업하세요. 더 나은 방법은 즉시 Git을 초기화하고 현재 실행 가능한 상태를 한 번에 커밋하는 것입니다. AI 프로그래밍 도구는 빠른 변경에 좋지만, 롤백 포인트가 있을 때만 가능합니다.
결론은 간단합니다: 코덱스는 코드를 바꾸는 것이 나쁘지 않지만, 무서운 점은 차이도, 커밋도, 경계도 없다는 것입니다. 먼저 증거를 남기고 문서에 따라 되돌리기만 하면 대부분의 문제는 빠르게 복구할 수 있습니다.
