Codexはコードが出てきた瞬間に書き換えますが、これはモデルが書けないからではなく、タスクの説明がプロジェクトを理解するためにモデルに求めていないからです。 正しい方法は、Codexに既存の実装を検索し、慣習を確認し、チェーンを呼び出し、最小限のスコープまで変更させることです。
ただ「手伝って、実現させて」なんて言うだけじゃない
「ログイン機能を作る」や「支払いの問題を修正する」と言うだけで、Codexは新しいファイルを作成し、コンポーネントを書き直し、共通の経験に基づいて理にかなっていると思われる構造を追加することもあります。 古いプロジェクトでは既存のアーキテクチャと簡単に戦えます。
より良い冒頭文は「まだファイルを変えずに、プロジェクトに既にあるログイン、権限、インターフェースリクエスト、エラー処理メソッドを検索し、再利用したいファイルをリストアップしてください」です。 このステップで「作成モード」から「メンテナンスモード」に引き戻すことができます。
変化の前に計画を立てておけ
Codexは3つのものを出力します:関連ファイル、変更が必要なポイント、変更不要な境界です。 例えば、「『src/auth』だけを変更し、ルーティングシステムを移動しないでください; 既存のトーストとフォームチェックサムが使用されます。 「テストのみ、ログイン失敗シナリオを補足してください」と書いています。
もし計画に多数の新しいファイルがある場合は、一時停止して既存のモジュールを再利用できない理由を説明させてください。 多くの場合、このステップの後、スキームは縮小されます。
プロンプトはこう書けます
「まず既存の実装を読み再利用し、新しい並列アーキテクチャは作らないでください。 まず関連文書を検索し、現在のプロジェクトで同様の論理にどう対処するかを説明し、その後に最小限の変更計画を提示してください。 確認なしにファイルを編集しないでください。 ”
このプロンプトはカーソル、Claudeコード、Copilotチャットでも同様に役立ちます。 AIプログラミングツールはあまりにも広範な目標を恐れ、「要件の達成」を「セットの再構築」と理解します。
本当にプロジェクトを見ているかどうかを判断してください
実際のファイル名、関数名、ルート名、テスト入口を参照しているか確認してください。 答えが「通常」と「作成を推奨」とだけ書かれていて、プロジェクト内の証拠がなければ、コーディングには入れないほうがいいです。
高い読解力を持つAIプログラミングのQ&Aは、ツールをプロジェクトに合わせて機能させてはならないという核心を指摘しがちです。 コデックスも同様で、まず検索してから修正するので、変更してから修正するよりもずっと安定しています。
