利益:
- インライン完了を使用してチャット モードを正しいタスク タイプにマップする機能
- 入出力コントラクト、エッジケース、スタイル制約を含む強力な制作プロンプトを作成する機能
- 生成されたコードと新しく提案された依存関係をマージ前に検証する機能
開発者が AI と最初に接触するのは、多くの場合、オートコンプリート (入力時に次の行を提案する機能) か、チャット ウィンドウに「その関数を入力してください」と言うときです。どちらも同じエンジンを使用しますが、異なる分野が必要です。この単元では、コード生成をランダムな「書き留める」作業から、出力が予測可能で検証可能なエンジニアリング ステップに変換します。
目標は、AI をタイピング マシンを高速化するツールから、設定した制約内で動作する見習いに変えることです。よく指導された実習生は時間を節約します。指導を受けていない実習生は混乱を引き起こしますが、後で片付けなければなりません。
2 つの使用モード: インライン補完とチャット
エディターに入力すると、インライン補完が機能します。関数シグネチャまたはコメント行を入力すると、残りの部分が提案されます。速度の点では優れていますが、コンテキストが狭く、すぐ近くのコードのみが表示されます。だからこそ、コメントに自分の意図を明確に書いた方が効果的です。たとえば、 // ユーザーの電子メールを検証し、無効なコメントの場合は ValidationError をスローすると、以下の提案が大幅に改善されます。
チャット モードは、「このクラスにページネーションを追加する」、「そのサービスのインターフェイスを抽出する」など、より大規模で構造化されたタスク用です。ここでは、役割、コンテキスト、形式を与える贅沢があります。一般的なルールは、小さくて流れるようなタスクについては完了し、思考と構造を必要とするタスクについては会話です。
ヒント: 「Tab」による補完の提案を盲目的に受け入れないでください。提案された行を少し読んでください。不正な変数名または逆の条件がここから漏れるのが最も一般的です。
意図をコードに変換する手順
- 契約を定義します。関数の入力、出力、エラーの動作は何ですか? 「電子メールを取得し、有効であれば正規化して、無効であればエラーをスローする」ようなものです。
- 制約を述べます。外部依存関係を使用しないのですか?特定のスタイルガイド?パフォーマンスの制限はありますか?
- 例を挙げてみましょう。入出力のペア (「ali@x.com → 有効、ali@ → エラー」) により、モデルの意図の理解が予測から精度へと移行します。
- 小さな部分を求めてください。 1 つの機能、1 つの責任。次に、次の項目に進みます。
- 生成されたコードを読んで実行します。コンパイル + 簡単な手動試行が、最も安価な保証手順です。
ミニケース3個
ケース 1 — コメント主導の制作により精度が向上します。開発者は最初に空の本文で日付解析関数をリクエストし、3 ラウンドで正しい結果を取得しました。 2 回目の試行では、4 行のコメント (受け入れられる形式、タイムゾーンルール、エラー条件) を使用して関数を定義してリクエストしたところ、最初のラウンドで機能したコードが届きました。同じモデル、同じ日に。違いは意図の明確さだけでした。
ケース 2 — バージョンを指定しないとコストがかかります。あるチームは、Node.js 用に作成されたコード内の fs.promises を従来のコールバック ベースの API に置き換えることに苦労していました。 「Use Node 20, ESM, async/await」という行がプロンプトに追加されたとき、本番環境は初めてプロジェクトに従いました。修正に費やした平均 12 分がリセットされました。
ケース 3 — ボイラープレート コードの実際のゲイン。マイクロサービスには、6 つの新しい DTO (データ転送オブジェクト - レイヤー間でデータを運ぶ単純なデータ クラス) とその検証ルールが必要でした。以前は約 90 分かかっていた手作業が、AI によって作成およびレビューされると 35 分に短縮されました。コードの繰り返しが多く、パターンが明確であるため、AI はここで最も効率的な領域で機能しました。
4 つのコピー可能なテンプレート
コントラクトベースの関数生成:
役割: あなたは勤勉な {{言語}} 開発者です。関数契約:- 名前: {{name}}- 入力: {{タイプとその意味}}- 出力: {{タイプと意味}}- エラー ステータス: {{いつスローされる/返される内容}}制約: {{外部依存関係なし / スタイル / パフォーマンス}}例: - {{input_1}} -> {{output_1}}- {{entry_2}} -> {{error_2}}最初に署名と短い計画を入力し、次にコードを記述します。関数だけを使ってテストを作成します。
既存のスタイルに一致させる (コードベースに適応させる):
以下は私たちのプロジェクトの関数の例です。命名、エラー処理、コメントのスタイルについては、こちらをご覧ください。同じスタイルで {{new_task}} の関数を作成します。例: {{current_code}}
スケルトンから埋め込みまで (スタブ→実装):
コメント内の TODO に従って、以下の関数スケルトンを入力します。署名と戻り値の型を変更します。存在しないヘルパー関数を作成しないでください。必要に応じて、「このヘルパーが必要です」とお知らせください。 {{スケルト_コッド}}
代替アプリの比較:
{{task}} の 2 つの異なる実装を指定します: (a) 読みやすさを優先する、(b) パフォーマンスを優先する。それぞれの下に「いつが望ましいか」を 1 文書きます。
弱いプロンプト / 強いプロンプト
弱者: 「メール認証機能を書いてください。」
Strong: 「TypeScript 5、標準ライブラリのみ。isValidEmail(input: string): boolean と記述します。スペースを削除し、大文字と小文字を区別しないようにします。a@b.co は有効です。a@、@b.co、空の文字列は無効です。正規表現を使用する場合は、あまり複雑にしないでください。コメントを 2 行追加してください。」
強力なバージョン。言語、バージョン、署名、エッジケース、およびスタイル制約を返します。したがって、生成されたコードは機能し、プロジェクトに適合します。
アプローチ
いつ使用するか
注意
インライン補完
流れの中の小さなインサート
提案を読まずに受け入れないでください
チャットでの受託制作
新しい関数/クラス
例と特殊なケースを提示する
スタイルサンプルによる制作
既存のコードに追加する
現在のサンプルコードを選択してください
スケルトンの詰め物
署名は修正済み、本文は空白です
署名の変更
コードの重複と依存関係の罠
AI は、作業を容易にするために新しいライブラリを推奨することがよくあります。これは正確な場合もありますが、プロジェクトに不要な依存関係を追加したり、存在しないパッケージを示唆したりする場合もあります (幻覚)。ルール: 新しい依存関係をそれぞれ確認します。パッケージが実際に存在し、維持されており、適切なライセンスを持っていることを確認するまでは、パッケージをプロジェクトに追加しないでください。ほとんどの場合、プロジェクトに既に存在するヘルパーの方が、新しいパッケージよりも優れています。
注意: AI によって提案されたインポート行を確認してください。存在しないパッケージ名 (「タイポスクワッティング」と呼ばれる偽のパッケージに似ている場合もあります) は、コンパイルを中断し、セキュリティ上のリスクを引き起こします。
よくある間違い
- モデルによって決定された署名を持つ。入出力タイプを固定しないと、プロダクションごとに異なるシグネチャが付属し、統合が困難になります。
- エッジケースは言うまでもありません。空の入力、null、負の数値、非常に大きな値 — これらを指定しない場合、モデルはエッジをスキップして「ハッピー パス」を書き込みます。
- 提案をテストせずに組み合わせる。機能しているように見えるコードが、実際に機能するとは限りません。
- 不必要な依存を受け入れる。ワンライナーのためにライブラリ全体を追加すると、技術的負債が生じます。
- スタイルの不一致。プロジェクトの他の部分とは異なる名前付けとエラー処理により、コード ベースが不規則になります。
要約すると
コード生成は、意図を明確なコントラクトに変換する場合に強力です。インライン補完は、小規模なインストリーム タスクや、会話の構造を確立するタスクに使用します。入出力タイプ、エッジケース、バージョン、スタイルを指定します。モデルの例を挙げてください。新しい依存関係をそれぞれ検証します。そして生成されたすべての部分を実行して読み取ります。 AI は定型的で反復的なコードで最も効果を発揮します。設定した制限内でその場で実行できます。
アプリケーションタスク
作成する必要がある実際の小さな関数をプロジェクトから選択します。まず、「契約ベースの関数生成」テンプレートを使用して AI に出力し、入出力タイプ、2 つのエッジ ケース、およびスタイル制約を与えます。生成されたコードをコンパイルし、2 つの異なる入力で試します。次に、同じ関数を再度実行します。今度はコンテキストなしで「これを書いてください」と質問し、2 つの出力を 1 行ずつ比較します。どのエッジ ケースが見逃され、修正がいくつ必要か?
チェックリスト
- [ ] インライン補完を使用したチャット モードをどこで使用するかを知っています。
- [ ] 関数生成における入出力規約とエッジケースを決定します。
- [ ] プロンプトに言語とバージョン情報を追加するのが習慣になっています。
- [ ] 作成された各部品を組み立てる前にコンパイルしてテストします。
- [ ] AI が提案する新しい依存関係をそれぞれ、その存在と必要性を検証することで確認します。
- [ ] 生成されたコードがプロジェクトのスタイルと一致していることを確認します。