タスクを与える前にコンテキストを与える

AIはあなたが見るようにはプロジェクトを見られない。フレームワークのバージョンも、ファイル構造も、すでに確立した規約も知らない。これを飛ばすと、AIは推測する——しかも下手に推測する。さらに悪いことに、自信満々に推測する。だから出力は、あなたの実際のコードベースとぶつかるまではもっともらしく見える。

同じ要求に対するこの二つのプロンプトを比べてみよう。

メールを検証する関数を追加して。

これは Express と Zod でバリデーションする TypeScript バックエンドです。
すでに src/schemas/ で Zod スキーマを使って入力を検証しています。
そのスタイルでメールバリデーションのスキーマを追加してください。メールは
lowercase、max 254 chars で、src/config.ts にある既存の
BLOCKED_DOMAINS リストの使い捨てドメインは拒否すること。

最初のプロンプトは、あなたが望まない正規表現を使うかもしれない、コードベースに合わないスタイルの汎用的なコードを生む。二つ目はそのまま貼り付けられるコードを生む。ルールはこうだ。スタックを、規約を、そしてAIが再利用すべき既存の部品を述べよ。

良いプロンプトはこれらの部品を下から上へ順に積み上げる——土台にコンテキスト、頂上近くに実際の要求を:

        ┌──────────────────────────────┐
        │   例                         │  入力1つ → 出力
        ├──────────────────────────────┤
        │   制約                       │  してはいけない事
        ├──────────────────────────────┤
        │   エッジケース               │  空・無効・エラー
        ├──────────────────────────────┤
        │   入力 / 出力                │  型と形
        ├──────────────────────────────┤
        │   ゴール                     │  明確なタスク1つ
        ├──────────────────────────────┤
        │   コンテキスト               │  スタック・ファイル・パターン
        └──────────────────────────────┘
              まず土台から ▲

エンターを押す前に役立つ心の中のチェックリスト。言語とフレームワーク(重要ならバージョンまで)、関連するファイルやモジュール、プロジェクトにすでにあるパターン、そしてAIが好むべき、または避けるべきライブラリ。毎回四つすべてが要るわけではない——だが答えがそのうちの一つによって変わるなら、それを名指せ。迷ったら、新しいコードが合わせるべき実際のシグネチャ、型、または設定を貼り付けよ。数行の既存コードは、一段落の説明よりはるかに、あなたの規約をAIに教える。