Codexが悪いコードを変更するとき、最もタブーなのは手動で削除することです。 まず差分を保持してどのファイルが変更されたか確認し、その後Gitの細分度に従ってロールバックしてください。 これによりプロジェクトを復元できるだけでなく、問題の手がかりを残し、次回の穴の繰り返しを防ぐことができます。
まず最初に:何が変わったか確認してください
プロジェクトのルートディレクトリで「git status」を実行し、「git diff」を確認してください。 多くの変更がある場合は、直接削除せず、まずファイルごとに分類してください:ビジネスコード、設定ファイル、ロックファイル、生成ファイル、テストファイル。 多くの失敗は実際には1つか2つの設定やインポートパスだけで起こるため、すべての結果を失う必要はありません。
まだコミットしていない場合は、一時的なパッチを保存することをお勧めします:git diff > codex-bad-change.patch。 この文書はローンチ用ではなく、将来の比較用です。
より安定した後退方法
ファイルだけが壊れている場合は、そのファイルだけを復元し、リポジトリ全体を空にしないでください。 エディターのソースコントロールパネルでファイルごとに破棄することもできますし、Gitのファイルレベルリカバリーを使うこともできます。
もしコデックスの変更が多くのファイルにまたがるなら、なぜ各ファイルが変更されたのか説明させてください。 説明できない文書はまず削除されます。 はっきり説明しつつ、ファイルにバグを実装し、部分的に修正してください。
次はあまり変えすぎないようにする方法
Codexは一度に一つの目標だけを処理します:まずテストを書き、その後実装を変更し、最後に検証を実行する。 リファクタリングやバグ修正、UIの変更、パフォーマンス最適化を一つのメッセージで行わせないでください。 作業が混乱すればするほど、差分を元に戻すのが難しくなります。
また、始める前に「最大3つの変更を行い、修正前の計画をリストアップし、完成後に実際の変更と検証コマンドを記載する」と指定することもできます。 「これにより制御を失う可能性が大幅に減ります。
ギットなしでどうすればいいか
Gitを使わないプロジェクトの場合は、AIに変更させる前に現在のディレクトリをコピーしてバックアップしてください。 より良い方法は、すぐにGitを初期化し、現在の実行可能な状態を一度だけコミットすることです。 AIプログラミングツールは素早い変更に優れていますが、ロールバックポイントがある場合に限ります。
結論はシンプルです:Codexはコード変更がひどくありませんが、恐ろしいのは違いもコミットも境界線も存在しないことです。 まず証拠を残し、その後文書に従って修正すれば、ほとんどの問題は迅速に回復できます。
