何かを組み込む前に、実践者の3つの反射を身につけよう - 公式ドキュメントと突き合わせ、自分でテストし、幻覚(ハルシネーション)の兆候を狩る。
このレッスンを Kodokon で開く幻覚(ハルシネーション)とは、ばかげた答えのことではない。もっともらしく、そして間違っている答えのことだ - 存在すべきなのに存在しないメソッド、2バージョン前に名前が変わったオプション、逆にされたデフォルトの振る舞い。まさにそれが、有能な開発者を無防備にする。幻覚のコードは慣用的で、命名がよく、エコシステムと一貫している。正しく見えるのだ。何かを組み込む前の、譲れない3つの反射: あなたが使うバージョンの公式ドキュメントと突き合わせる、最小限のコンテキストで自分でコードをテストする、そして答えを監査させる - モデル自身によってを含めて。
あなたの直前の答えを取り上げ、それが別の誰かから来たものであるかのように監査してください。
1. 検証可能な技術的主張をすべて挙げてください: APIまたは関数の名前、記述された振る舞い、デフォルト値、バージョン番号。
2. それぞれについて、あなたの確信度を示してください: 確実 / たぶん / 要確認。
3. 「要確認」の各項目について、公式ドキュメントで何を調べればいいかを正確に述べてください: 該当するページ、関数、モジュールの名前。
4. バージョンやプラットフォームに依存しうるものはすべて指摘し、分かるならどのバージョンから成り立つかを明記してください。
私が自分でやるよりも、自分自身に厳しくしてください: 「確実」と過大評価された主張は、過小評価されたものより私にとってコストが高いのです。この自己監査は何も証明しない - モデルは確信をもちながら間違っていることがある - が、流暢な散文を検証可能な事実のリストに変えてくれる。それぞれにドキュメントへの入り口がついている。検証するのはあなたであり、AIはただ地ならしをしただけだ。危険信号を見抜くことも学ぼう: あなたのニーズにぴったり合わせて切られたAPI(話がうますぎる)、同じ一片の中に混ざった異なるバージョンの慣習、完璧に一様な確信 - 本物の専門知識は「場合による」と言うが、幻覚は決して言わない - そして、限界やエッジケースへの言及がまったくないこと。どの単独の兆候も証拠ではないが、そのどれもが検証の引き金になるべきだ。
あなたはたった今、[検証すべき正確な主張]と述べました。
1. それを自分で検証するための、可能な限り短いテストを設計する手助けをしてください: 作るべき最小限のファイル、実行する正確なコマンド、あなたが正しければ私が観察すべき正確な結果 - そして、あなたが間違っていれば代わりに観察するもの。
2. 次に、あえて反対の立場を取ってください: どのような場合にあなたの主張は偽になりますか? バージョン、プラットフォーム、設定、strictモードかどうか - すべてを洗い出して。
私は自分でテストを実行します: 私にあなたを信じろと言わないで、あなたに反論する手段をください。このプロンプトは、日々の仕事に科学の原理を当てはめる。主張は、それが反証可能なら値打ちがある - もし偽だと分かったら何を観察するはずかを知っているなら。使い捨てのファイルの中の10行と1回の実行は、どんな宣言された確信度にも勝る。ドキュメントとの突き合わせには、3つの習慣がある。あなたのバージョンのドキュメントで検証する(モデルはAPIの時代を平気で混ぜる)、振る舞いが変わったように見えたら変更履歴を確認する、そしてREPLか作業用ファイルを常に開いておく - 検証のコストは、そのステップを飛ばす言い訳を決して持てないほど低くあるべきだ。