プロンプト設計の実践ガイド

プロンプトをコードのように扱います。プロンプトに構造を与え、バージョンを付け、評価します。以下に、Starsg の数十の制作パスを経て生き残った 6 つのプラクティス、つまり一貫して変化をもたらしたプラクティスを、重要な傾向がある順に示します。

1。役割と目標を設定する

最初の 1 ～ 2 行は、モデルが誰であるか、誰に向けて書かれているか、成功とはどのようなものであるかなど、モデルの視点を固定する必要があります。用語の密度、トーン、含める内容の選択はすべてそのアンカーから外れます。「冗長すぎない」または「学術的すぎない」という理由でモデルを後から引っ張り戻すよりもはるかに安価です。しっかりしたオープニングは、アイデンティティ、聴衆、目標という 3 つのことに答えます。

役割設定テンプレート

あなたは開発関連エンジニアです。
対象者: HTTP API には慣れているが、LLM やトークンベースの価格設定には慣れていないバックエンド エンジニア。
目標: 3 分以内に、読者が Starsg を統合する価値があるかどうかを判断し、次のステップを説明できるようにします。
素朴だがプロフェッショナルな口調を使いましょう。マーケティングの綿密なマーケティングは避けてください。

2。タスクを明示的に書く

「製品宣伝文を書く」では、すべての決定がモデルに委ねられます。すべての実行は推測です。再利用可能な指示には少なくとも 5 つの要素があります: アクション (書く/要約する/翻訳する)、オブジェクト (何を)、対象者 (誰に向けて)、トーン/スタイル、長さまたは形。これらを詳しく説明すると、出力の安定性がすぐに 1 段階上がります。

❌ 曖昧すぎる

製品の紹介文を書いてください。

✅ 5つの要素すべて

~200 の言葉で言えば、バックエンド エンジニア向けに、Starsg の 3 つの差別化要因 (統合ゲートウェイ、キーごとの課金、マルチモデル フォールバック) を紹介します。口調：プロフェッショナルかつ控えめ。 「力を与える」や「次世代」などの言葉は避けてください。具体的な行動喚起で終わります。

3。コンテキストと例を提供します (いくつかのショット)

要件が抽象的であればあるほど、より多くの例が利益を得ることができます。 1 ～ 3 つの「入力 → 期待される出力」のペアについては、10 行の説明に相当します。少数ショットは、フォーマットが固​​定されている場合 (分類、抽出、JSON)、スタイルを言葉で説明するのが難しい場合、またはドメインに独自の慣例がある場合 (法律、医療、社内システム) に特に決定的です。簡単なケースだけではなく、実際の分布をカバーする例を作成してください。

少数ショット抽出例

以下のサポートチケットのテキストから、«タイプ / スコープ / 重大度» の 3 つのフィールドを抽出します。 JSONのみを出力します。

例 1:
入力: ユーザーは広州地域全体でログインの失敗を報告します。電話サポートは多忙を極めています。
出力: {"type":「ログイン」、"scope":「広州地域」、"severity":「P1」}

例 2:
入力: テスト口座に間違った残高が表示されます。内部 QA のみが影響を受けます。
出力: {"type":「アカウント」、"scope":「内部 QA」、"severity":「P3」}

次に処理します:
入力: 北京 API ゲートウェイは 502 を返します。すべての有料ユーザーが影響を受けます。

4。出力形式を制限する

ダウンストリーム システムが消費するものはすべて解析可能である必要があります。 JSON?スキーマとフィールド ノートを提供します。リスト？数と項目ごとの形状を固定します。長さのキャップ?そう言ってください。 「フィールドが欠落している場合は、フィールドを null に設定します。発明しないでください」のような句を追加すると、幻覚はかなり軽減されます。

JSON 出力制約

このスキーマと厳密に一致して、以下の履歴書を JSON に変換します。
{
  "name":文字列、
  "yearsOfExperience":番号、
  "skills": string[], // 最大 5、小文字
  "summary": 文字列 // <= 60 単語
}
ソースにフィールドが記載されていない場合は、それを null に設定します。発明しないでください。周囲のテキストなしで、JSON のみを出力します。

5。複雑なタスクを分解する (思考の連鎖を使用して)

モデルに「分析 + 計画 + 制作」を一度に依頼すると、通常、詳細が失われるか、推論が最終的な答えとして扱われます。 2 つのオプション: 内部で段階的に考えさせるか、作業を自分で複数のターンに分割するかです。監査可能なワークフローの場合は後者を好みます。すべての中間ファイルを保持して、後でどのステップが失敗したかを特定できるようにします。

ステップバイステップのテンプレート

製品スペックをご案内します。 3 つのステップで処理し、それぞれを ## 見出しで区切ります。

## 1。重要な情報
箇条書き: ターゲット ユーザー、コア シナリオ、必須の機能、明示的に範囲外のもの。

## 2。リスクや不明な点
仕様内のあいまいな点や矛盾した点をそれぞれ 1 文ずつ列挙します。

## 3。次のステップ
PM に、優先順位に従って、具体的で実行可能な次のアクションを 3 つ与えます。

仕様:
<<<

>>>

6。反復して評価する

適切なプロンプトは書かれるのではなく、反復されるのです。固定評価セット (通常 + エッジ + 敵対的をカバーする 20 ～ 50 ケース) を構築します。プロンプト変更ごとに実行し、ヒット率、平均長、トークンコストを記録します。プロンプトをコードのようにバージョン管理します。すべての変更には理由と回帰ベースラインがあり、「今回は良くなった」ということはありません。