20個のコーディング用プロンプトで、 AIの当て推量を止める
AIが出すダメなコードの多くは、あなたが残した情報の穴をモデルが勝手に埋めることから生まれます。ここにあるプロンプトは、その穴を一つずつ塞ぎます。書く前に読ませ、直す前にテストさせ、推測には順位をつけて口に出させます。
[かっこ]の部分は、自分のコード、エラー、目的に置き換えてください。
01. 手を入れる前に影響範囲を洗い出す
自分が書いていないコードを変更する前に。
下のコードを読んで。まだコードは書かず、変更もしないで。 次の点を教えて。 1. 何をするコードか、3文以内で。 2. 入力、呼び出し元、実行環境について、このコードが置いている前提をすべて。 3. [変えたい内容を書く]としたら、何がどこで壊れるか。 答えるのに別のファイルが必要なら、ファイル名を挙げて、そこで止まって。 [コードを貼る]
02. 誰かが修正を書く前に原因に順位をつける
まだ説明のつかないバグがあるとき。
エラーと、その周辺のコードです。 可能性が高い原因を3つ、高い順に挙げて。それぞれについて、原因だと確認できる、または除外できる、ログ1行かテスト1つを教えて。 修正案は出さないで。確認は私が行い、どの原因だったかを伝えます。 エラーとスタックトレース: [エラーを貼る] コード: [関連するコードを貼る]
03. 失敗するテストを書いたら、そこで止まる
新しいコードや修正を頼む前に。
[関数または機能]のテストを[テストフレームワーク]で書いて。 通常のケース、次のエッジケース:[すでに分かっているものを挙げる]、そして私が見落としていそうなケースを最低2つ含めて。その2つは、なぜ重要かを1行ずつ添えて。 どのテストも、現在のコード、または未実装の状態では失敗するようにして。実装は書かないで。
残りの17個のプロンプトを無料で開く
Whiziのニュースレターに登録すると、このパックの続きを読めます。
- 呼び出される当番の目線で差分をレビューする
- 挙動を一つも変えずにリファクタリングする
- 最初に読む5つのファイルを選ぶ
- 実際のスキーマに沿ってクエリを書く
- 正規表現と、それを裏づけるテスト例をもらう
- ネイティブが書いたように読める移植をする
- 実際のプロファイルから時間の行き先を突き止める
- 信頼できない入力を入口から出口まで追う
- 初めての人でも使えるREADMEを書く
- 差分からコミットメッセージを書く
- 自分のコードを使って概念を学ぶ
- APIを設計して、その設計に反論する
- サイトを止めない移行を計画する
- モデルに質問させる
- 壊れる入力を洗い出す
- 依存関係のアップグレードで自分のコードの何が壊れるかを調べる
- 別のモデルに最初のモデルを採点させる