効果的なプロンプティング
人々はフレームワークを学ぶのに何週間も費やすのに、 AI とのコミュニケーションを学ぶ時間はゼロ。 そして結果が悪いとモデルを責める。
「出力がダメなら、入力がダメだった。これは避けられない。」
本当に効果があること
- 具体的に:「認証を作って」は曖昧。「セッションベースの認証を bcrypt で、 PostgreSQL セッションストレージ、HTTP-only Cookie」は具体的。
- やらないことを伝える:「シンプルに。頼んでない抽象化を追加しないで。 DI フレームワークなし。」
- なぜかのコンテキストを与える:「これは毎リクエストで実行される」は アプローチを完全に変える。コンテキストが実装を形作る。
Claude は過剰設計しがち。これを予測しましょう。 シンプルなものが欲しいときは「シンプルな実装」や 「不要な抽象化なし」と明示的に言ってください。
公式
良いプロンプトはパターンに従います:
- 具体的は曖昧に勝つ
- 制約はオープンエンドに勝つ
- 例は説明に勝つ
Claude に欲しいものの例を見せられるなら、 言葉で説明するより10倍の価値があります。
モデル選択
Sonnet
速くて安い。道筋が明確なときの実行に良い。 明確に定義されたタスクの実装に使用。
Opus
遅くて高い。複雑な推論と計画に良い。 アーキテクチャ決定と難しい問題のデバッグに使用。
ワークフローのコツ:Opus で計画し、Sonnet で実装する。
Shift+Tab でモデルを切り替えられます。
重要なポイント
- 悪い入力 = 悪い出力。例外なし。
- 具体的に、制約を加え、例を見せる
- やらないことを伝える(過剰設計しがち)
- 計画は Opus、実装は Sonnet