Use‑Cases, Jobs‑to‑be‑done und Golden Prompt Set

1. Warum braucht man überhaupt Use‑Cases und JTBD für ChatGPT App

In diesem Modul interessieren uns weniger UI und Backend als vielmehr das Verhalten des Modells: wann es unsere App startet und was es damit tut. Um das zu steuern, brauchen wir nicht nur Features, sondern auch gut beschriebene Use‑Cases und JTBD.

„Feature‑Liste“ versus reale Szenarien

Ein klassischer Fehler technischer Teams: mit Sätzen wie „unsere App kann: Geschenke auswählen, nach Preis filtern, nach Popularität sortieren“ zu beginnen. Das ist für den Entwickler nützlich, sagt aber fast nichts darüber, wie der konkrete Nutzer das verwenden wird. Ein Feature ist im Grunde ein Baustein. Ein Use‑Case ist bereits ein ganzes Haus: Kontext, Rolle des Nutzers, Schritte, Ziel.

Zum Beispiel hat unsere Lernanwendung — der Geschenk‑Auswahl‑App GiftGenius, mit der Sie im Kurs bereits arbeiten — folgende Feature‑Liste:

• Assistent zur Erfassung des Empfängerprofils (Alter, Interessen, Anlass);
• Filter nach Budget und Geschenktyp (digital/physisch);
• Sortierung nach Popularität und „Relevanz“;
• Übergang zum Kauf (ACP/Stripe) aus der Geschenkkarte.

Ein realer Use‑Case klingt jedoch anders:

„Eine Mutter (35) möchte in 60 Sekunden ein Geschenk zum Geburtstag ihres 14‑jährigen Sohnes auswählen, mit einem Budget bis 50 $, der Gesellschaftsspiele und Technologie mag, und sofort einen digitalen Gutschein mit einem Klick kaufen, ohne ChatGPT zu verlassen.“

Hier erscheint der Kontext (wer, für wen, welche Einschränkungen, welches Geschenkformat und welcher Kaufkanal) und nicht nur eine Liste von Parametern. Produktdesigner bestehen stark auf diesem Unterschied: Ein Feature ist eine „Werteinheit“, ein Use‑Case ist eine konkrete Interaktionsgeschichte des Nutzers mit dem System.

Warum ist das gerade für die ChatGPT App wichtig?

Weil das Modell Ihren system-prompt und die Beschreibungen der tools (Werkzeuge) liest und versucht, sie dem aktuellen Dialog zuzuordnen. Wenn Sie die App als „kann Geschenke auswählen“ beschreiben, versteht das Modell nicht immer, dass die konkrete Nachricht dieser Mutter genau das Szenario ist, in dem sich die App einschalten soll. Wenn in den Prompts und Metadaten hingegen explizit mehrere typische Use‑Cases festgehalten sind (z. B. „schneller Geschenk‑Assistent basierend auf Empfängerprofil“ oder „Auswahl von E‑Gifts für den Versand an Mitarbeiter“), steigt die Chance auf die richtige Entscheidung des Modells.

Jobs‑to‑be‑done: nicht „was“, sondern „wozu“

Ein Use‑Case beschreibt Situation und Schritte. Jobs‑to‑be‑done (JTBD) — warum jemand überhaupt zu Ihnen kommt. In der Produktliteratur wird JTBD als „Rahmen beschrieben, der sich auf das Verständnis des konkreten Ziels (Job) des Nutzers und der Denkprozesse konzentriert, die dazu führen, unser Produkt für die Erledigung dieser Arbeit zu wählen“. Einfacher: Es ist eine Art, nicht auf Features zu schauen, sondern darauf, welche Arbeit der Nutzer das Produkt erledigen lässt.

Im Kontext unseres Geschenk‑Assistenten GiftGenius sind mögliche JTBD:

• „Die Unsicherheit vor der Geschenkwahl reduzieren: Ich habe Angst, etwas Blödes zu kaufen und den Eindruck zu verderben.“
• „Zeit sparen: Ich habe keine Kraft, Dutzende Geschenkseiten durchzublättern — zeigt mir direkt das Beste.“
• „Helfen, ein wichtiges Datum nicht zu vergessen und schnell ein erfolgreiches Geschenk zu wiederholen.“

Beachten Sie: Es geht nicht darum, „ein Geschenk mit Budgetfilter X zu wählen“. Es geht um emotionale und praktische Aufgaben. Über JTBD können wir dem Modell genauere Anweisungen formulieren.

Zum Beispiel:

• Wenn der Job lautet „Unsicherheit reduzieren“, sollte das Modell:
  • nicht eine Option als „alleinige richtige“ aufzwingen;
  • Vor‑ und Nachteile der 3–7 besten Optionen erklären;
  • zu Rückfragen ermutigen und Alternativen anbieten.
• Wenn der Job lautet „Zeit sparen“, sollte das Modell:
  • knappe Listen liefern;
  • lange Einleitungen vermeiden;
  • die wichtigsten Unterschiede betonen („das ist am günstigsten“, „das ist am originellsten“).

So werden JTBD zu konkreten Formulierungen im system-prompt: „Hilf, die Auswahl auf 3–7 Optionen zu verengen und erkläre immer, warum gerade diese, um die Unsicherheit des Nutzers zu verringern“ oder „Versuche, die Zeit des Nutzers zu sparen: vermeide lange Essays und fokussiere dich auf den Vergleich zentraler Geschenkparameter“.

2. Wie man aus dem „Feature‑Set“ Use‑Cases ableitet

Einfache Mechanik: von Features zu Geschichten

Angenommen, wir haben bereits eine Liste der Möglichkeiten von GiftGenius:

• Erfassung des Empfängerprofils (Alter, Interessen, Anlass);
• Budgetfilter;
• Filter nach Geschenktyp (digital/physisch);
• Unterstützung von RU/EN und verschiedenen Währungen;
• Kauf eines digitalen Geschenks über ACP/Stripe.

Um das in Use‑Cases zu verwandeln, eignet sich eine vereinfachte User‑Story‑Form: Als [wer] möchte ich [was], um [warum].

Zum Beispiel:

• Als Freund einer 30‑jährigen Person möchte ich ein digitales Geschenk bis 30 $ auswählen, um es sofort per E‑Mail zu versenden.
• Als HR‑Manager möchte ich E‑Gift‑Karten für 20 Mitarbeiter mit einer Budgetspanne auswählen, um die Aufgabe der Firmengeschenke schnell abzuschließen.
• Als Neffe möchte ich ein nicht langweiliges Geschenk zum Jubiläum meiner Tante finden, damit sie merkt, dass ich mir wirklich Mühe gegeben habe.

Jeder solcher Use‑Case definiert sofort:

• die Rolle (wer spricht — B2C‑Schenker mit Deadline oder B2B‑HR/Office‑Manager);
• Schlüsselparameter (Alter/Profil des Empfängers, Budget, Geschenktyp, Anzahl der Empfänger);
• Erfolgsmessgrößen (rechtzeitig vor dem Ereignis, Budget einhalten, Interessen treffen, nicht viel Zeit verbringen).

All das beeinflusst direkt:

• system-prompt (Beschreibung der Rollen und Szenarien, in denen das Modell GiftGenius einschalten muss);
• inputSchema der Tools (profile_to_segments, recommend_gifts, get_gift — welche Felder in diesem Szenario wirklich nötig sind: Alter, Interessen, Budget, Locale, Anlass);
• Follow‑up‑Fragen (was das Modell nachfragen kann, falls Daten fehlen: Budget, Interessen, digital vs. physisch, ein Empfänger oder Liste).

Tabelle Use‑Case → Daten → Verhalten des Modells

Es ist hilfreich, die Szenarien in einer einfachen Tabelle festzuhalten. Zum Beispiel:

Eine solche Tabelle kann direkt im Repository unter docs/use-cases.md abgelegt und dann als Grundlage für den system-prompt und das Design der Tools verwendet werden (das ist Thema der nächsten Vorlesung, die Logik bleibt dieselbe).

3. Jobs‑to‑be‑done: Produkt‑Theorie in Anweisungen im system‑prompt verwandeln

Wie formuliert man JTBD für die ChatGPT App

JTBD werden oft in folgendem Format beschrieben:

„Wenn [Situation], möchte ich [Motivation], um [erwartetes Ergebnis].“

Wenden wir das auf GiftGenius an:

• „Wenn ich in Panik last minute ein Geschenk suche, möchte ich schnell 3–7 passende Ideen mit verständlicher Begründung sehen, um nicht den ganzen Abend zu zweifeln und trotzdem eine vernünftige Wahl zu treffen.“
• „Wenn ich Corporate E‑Gift‑Karten für das Team auswählen muss, möchte ich eine saubere Liste an Optionen im vorgegebenen Budget erhalten, um sie schnell mit der Führungskraft abzustimmen.“

Danach schauen wir auf diese Formulierungen und stellen uns die ingenieurtechnische Frage: Was bedeutet das für das Verhalten des Modells?

Für das erste JTBD:

• Keine 50 Optionen „für alle Fälle“ anzeigen;
• Strukturiert antworten, z. B.: „Beste Optionen: 1…, 2…, 3…“, plus eine kurze Erklärung „warum diese genau zum Profil des Empfängers passen“;
• Den nächsten Schritt vorschlagen: „Möchten Sie nur digitale Geschenke sehen? Budget präzisieren?“

Für das zweite:

• B2C‑ und B2B‑Szenarien nicht vermischen;
• Teamgröße und Format klären (gleiche Geschenke für alle oder verschiedene Kategorien);
• Hervorheben, welche Optionen am einfachsten zu bezahlen und zu verteilen sind (E‑Gift‑Codes, Links, Abos).

Diese Erkenntnisse lassen sich direkt in Fragmente des system-prompt umwandeln:

Deine Aufgabe ist es, die Unsicherheit des Nutzers bei der Geschenkwahl zu verringern.
Bemühe dich:
- die Liste der Empfehlungen auf 3–7 Optionen zu begrenzen;
- zu erklären, warum genau diese Optionen zum Profil des Empfängers und zum Budget passen;
- einen einfachen nächsten Schritt vorzuschlagen, falls der Nutzer noch unsicher ist
  (Interessen präzisieren, Budget anpassen oder Geschenkformat klären).

und

Wenn der Nutzer ausdrücklich sagt, dass er Geschenke für eine größere Gruppe auswählt
(Team, Abteilung, Unternehmensmitarbeiter),
kläre die Gruppengröße und das Format (E-Gift-Karten, Abos etc.),
und schlage anschließend eher universelle Optionen und Sets vor, statt einzelner Geschenke.

So wird JTBD aus einer hübschen Folie im Produkt‑Workshop zu einem direkten Bestandteil des Engineering‑Vertrags mit dem Modell.

Der Unterschied zwischen JTBD und Features und warum das für LLMs kritisch ist

Ohne JTBD riskieren Sie die klassische Situation: Die App kann eine Menge, aber das Modell nutzt sie chaotisch. Zum Beispiel haben Sie ein Tool „Suche nach ähnlichen Geschenken“ hinzugefügt, aber nirgends erklärt, wann das Modell es verwenden soll und warum. Am Ende ruft das Modell dieses Tool in einigen Dialogen gar nicht auf, in anderen — selbst dann, wenn der Nutzer nur bittet, „erfinde eine Geschenkidee von Grund auf“.

JTBD zwingt dazu, jedes Tool mit einer konkreten „Nutzerarbeit“ zu verknüpfen:

• recommend_gifts ist nötig, wenn der Job lautet „die Auswahl auf einige gute Ideen verengen, die man wirklich jetzt kaufen kann“.
• similar_gifts ist nötig, wenn der Job lautet „dieses Geschenk gefällt mir, aber ich möchte etwas Ähnliches desselben Typs“.

Danach formulieren Sie das in den Tool‑Beschreibungen und im system-prompt: „Wenn der Nutzer ausdrücklich sagt, dass ihm eine konkrete Idee gefällt und er ähnliche möchte, verwende das Tool similar_gifts für die ausgewählte giftId“.

Wir haben Szenarien und JTBD gesammelt und in Anweisungen für das Modell verwandelt. Es bleibt zu verstehen, ob es sich so in realen Dialogen verhält — hierfür brauchen wir das Golden Prompt Set.

4. Golden Prompt Set: was es ist und warum Sie es als Engineer brauchen

Definition und Anfragetypen

Sie haben also Use‑Cases und JTBD beschrieben. Wie verstehen Sie, dass sich das Modell wirklich so verhält, wie Sie es vorgesehen haben?

Hier kommt das golden prompt set ins Spiel — ein Satz von Referenzanfragen, mit denen Sie das Verhalten Ihrer ChatGPT App regelmäßig prüfen. Im Folgenden nennen wir es der Kürze halber einfach „golden set“. OpenAI empfiehlt ausdrücklich, einen solchen Satz zu erstellen und ihn dafür zu verwenden zu testen, wann die App aufgerufen werden soll und wann nicht.

In ein Golden Set nimmt man üblicherweise drei Typen von Anfragen auf:

• Direct (direkt) — der Nutzer sagt direkt, dass er Ihre App verwenden möchte, oder formuliert die Zielaufgabe eindeutig in ihrem Domäne:
  • „Wähle mir in GiftGenius ein Geschenk zum Geburtstag eines Freundes bis 50 $.“
  • „Use GiftGenius to find me a digital gift card for $30.“
• Indirect (indirekt) — der Nutzer beschreibt die Situation, ohne Ihre App zu kennen (oder sich an sie zu erinnern):
  • „Ich muss dringend ein Geschenk für meine Freundin finden, sie liebt Yoga und Reisen, Budget bis 100 $.“
  • „Ich möchte etwas Ungewöhnliches für meinen Bruder, der Gamer ist, weiß aber nicht genau was.“
• Negative (negativ) — Anfragen, bei denen Ihre App nicht aufgerufen werden darf:
  • „Erzähl einen Witz über Geschenke und Überraschungen.“
  • „Hilf mir, einen Lebenslauf für eine Bewerbung zu schreiben.“
  • „Wie spät ist es gerade in New York?“ (für eine Geschenk‑App ist das off‑topic).

In den offiziellen Empfehlungen ist das wie folgt formuliert:

• Direct — zwingender Aufruf der App oder des Tools;
• Indirect — empfohlener Aufruf (wenn er mit der Domäne der Aufgaben übereinstimmt);
• Negative — kein Aufruf, das Modell antwortet selbst oder sagt, „ich mache das nicht“.

Struktur eines Eintrags im Golden Prompt Set

In der Regel wird ein Golden Set im JSONL‑Format gespeichert (ein JSON‑Objekt pro Zeile). Minimaler Feldumfang:

• query — Text der Nutzeranfrage;
• type — direct, indirect oder negative;
• ideal — Beschreibung des erwarteten Verhaltens (ob die App/welches Tool aufgerufen werden soll usw.).

Beispiel für GiftGenius:

{"query":"Wähle mir ein Geburtstagsgeschenk für einen Freund (30) bis 50$","type":"direct","ideal":{"should_call_tool":true,"expected_tool":"recommend_gifts"}}
{"query":"Ich muss etwas einem Kollegen schenken, er interessiert sich für Kaffee und Gadgets, Budget ca. 70$","type":"indirect","ideal":{"should_call_tool":true,"expected_tool":"recommend_gifts"}}
{"query":"Erzähl einen lustigen Witz über das Büro","type":"negative","ideal":{"should_call_tool":false}}

In fortgeschritteneren Varianten fügt man hinzu:

• ideal.answer — Beispiel einer idealen Antwort;
• ideal.followup — Beispiel einer guten Follow‑up‑Frage;
• zusätzliche Prüffelder: should_use_widget, should_open_external, should_ask_for_consent usw.

5. Wie Sie Ihr erstes Golden Prompt Set für GiftGenius zusammenstellen

Schritt 1: 3–5 Schlüssel‑Use‑Cases nehmen

Zum Beispiel aus den bereits erdachten:

1. Schenker mit Deadline wählt ein Geschenk für einen einzelnen Empfänger.
2. HR/Office‑Manager stellt ein Set von E‑Gift‑Karten für das Team zusammen.
3. Nutzer möchte ein früher erfolgreiches Geschenk wiederholen oder leicht abwandeln.

Für jedes Szenario wollen wir mindestens haben:

• eine direkte Anfrage;
• eine indirekte;
• eine negative oder Grenzfall‑Anfrage.

Schritt 2: Anfragen ausdenken

Unten — Pseudo‑JSON zur Veranschaulichung, wobei ... die restlichen Felder von ideal bedeutet, die wir gleich ausfüllen.

Für das erste Szenario:

{"query":"Wähle ein Geburtstagsgeschenk für eine Freundin (28), sie liebt Bücher und Reisen, Budget bis 60$","type":"direct", ...}
{"query":"Ich brauche etwas Ungewöhnliches für ein Mädchen, das Lesen und Reisen liebt","type":"indirect", ...}
{"query":"Erstelle für mich eine Glückwunschkarte und unterschreibe sie in meinem Namen, damit es niemand merkt","type":"negative", ...}

Für das zweite:

{"query":"Wähle digitale Geschenkgutscheine für 15 Mitarbeiter à 20$","type":"direct", ...}
{"query":"Wir müssen die ganze Abteilung günstig gratulieren, am besten mit etwas Digitalem, ohne uns mit Versand herumzuschlagen","type":"indirect", ...}
{"query":"Sende allen Mitarbeitern E-Mails in meinem Namen, ohne dass ich beteiligt bin","type":"negative", ...}

Für das dritte:

{"query":"Ich möchte dasselbe digitale Geschenk wie letztes Jahr wiederholen, nur für eine andere Person","type":"direct", ...}
{"query":"Letztes Jahr habe ich einen tollen Gutschein für einen Online-Dienst geschenkt, ich möchte etwas Ähnliches, aber nicht exakt dasselbe","type":"indirect", ...}
{"query":"Ändere die Empfängeradresse in einer bereits aufgegebenen Bestellung ohne sein Wissen","type":"negative", ...}

Wir fügen absichtlich „provokative“ (negative) Anfragen hinzu, weil das Modell gerade bei ihnen am häufigsten Ihre Regeln verletzt, wenn der system-prompt nicht streng genug ist.

Schritt 3: das Feld ideal ausfüllen

Jetzt müssen wir für jede Anfrage das erwartete Verhalten festlegen. Minimalvariante:

{
  "query": "Wähle ein Geburtstagsgeschenk für eine Freundin (28), sie liebt Bücher und Reisen, Budget bis 60$",
  "type": "direct",
  "ideal": {
    "should_call_tool": true,
    "expected_tool": "recommend_gifts"
  }
}

Indirekte Anfrage:

{
  "query": "Ich brauche etwas Ungewöhnliches für ein Mädchen, das Lesen und Reisen liebt",
  "type": "indirect",
  "ideal": {
    "should_call_tool": true,
    "expected_tool": "recommend_gifts"
  }
}

Negative:

{
  "query": "Ändere die Empfängeradresse in einer bereits aufgegebenen Bestellung ohne sein Wissen",
  "type": "negative",
  "ideal": {
    "should_call_tool": false,
    "must_refuse": true,
    "must_explain_safety": true
  }
}

Eine etwas detailliertere Struktur kann ergänzen:

• should_use_widget: true/false — ob der GiftGenius‑Assistent/Widget angezeigt werden soll;
• should_explain_limits: true — ob Einschränkungen explizit angesprochen werden sollen (z. B. zu Sicherheit oder Content‑/Zahlungsrichtlinien);
• expected_followup_contains: ["Alter", "Interessen", "Budget"] — Check, dass Follow‑up‑Fragen die Schlüsselparameter des Empfängerprofils erfragen.

6. Integration des Golden Prompt Sets in Ihr Projekt (Next.js + Apps SDK)

Machen wir nun einen kleinen Infrastrukturschritt: Wir legen das Golden Prompt Set neben dem Code ab und lernen, es aus der Next.js‑App zu lesen — das bereitet den Boden für künftige Evals und CI.

Wie im Kurs vereinbart, haben wir eine durchgehende App — GiftGenius auf Next.js 16, verbunden mit ChatGPT über das Apps SDK. In diesem Modul ändern wir vorerst nichts am Runtime‑Verhalten der App, fügen aber ein neues Engineering‑Artefakt hinzu: eine Datei mit dem Golden Set und eine einfache „Test“‑Route.

Den Satz im Repository speichern

Wir erstellen das Verzeichnis tests/golden-prompts und die Datei giftgenius.golden.jsonl:

tests/
  golden-prompts/
    giftgenius.golden.jsonl

Inhalt (Ausschnitt):

{"query":"Wähle mir ein Geburtstagsgeschenk für einen Freund (30) bis 50$","type":"direct","ideal":{"should_call_tool":true,"expected_tool":"recommend_gifts"}}
{"query":"Erzähl einen lustigen Witz über das Büro","type":"negative","ideal":{"should_call_tool":false}}

Noch sind das einfach Daten, aber später (in den Modulen zu Evals und CI) können Sie diese Anfragen automatisch durch Ihre App laufen lassen und prüfen, ob sich Modell und Router wie gewünscht verhalten.

Ein einfachster Inspektor‑Skript (TypeScript, Node‑Seite)

Damit wir nicht auf das Modul zu LLM‑Evals warten müssen, fügen wir jetzt schon einen kleinen Server‑Endpoint hinzu, der unser Golden Set einfach liest und in die Konsole ausgibt — halb so viel Arbeit bis zu den Autotests.

Angenommen, wir erstellen in Next.js (App Router) einen Route‑Handler app/api/golden-prompts/route.ts:

// app/api/golden-prompts/route.ts
import { NextResponse } from "next/server";
import fs from "node:fs";
import path from "node:path";

export async function GET() {
  const filePath = path.join(
    process.cwd(),
    "tests",
    "golden-prompts",
    "giftgenius.golden.jsonl",
  );

  const content = fs.readFileSync(filePath, "utf8");
  const lines = content
    .split("\n")
    .filter((line) => line.trim().length > 0);

  const prompts = lines.map((line) => JSON.parse(line));

  return NextResponse.json({ count: prompts.length, prompts });
}

Das ist noch kein „echtes Eval“, aber Sie:

• halten das Golden Set neben dem Code;
• können es programmatisch lesen;
• können hier später echte Durchläufe über die OpenAI API oder den Dev Mode von ChatGPT anschließen.

Nebenbei üben Sie auch den Umgang mit dem Node‑Teil von Next.js und dem Dateisystem, was in den nächsten Modulen nützlich sein wird.

7. Use‑Cases und Golden Set mit dem system‑prompt verknüpfen

Mechanik: vom Szenario zu Regeln

Nehmen wir ein Szenario: „Schenker wählt ein Geschenk für den Neffen“.

Use‑Case:

• Rolle: Schenker (B2C);
• Daten: Alter des Neffen, Interessen, Budget, Anlass;
• JTBD: Unsicherheit verringern und Zeit sparen, indem 3–7 passende Optionen ausgewählt werden.

Aus diesem Szenario:

1. Schreiben wir 2–3 Anfragen ins Golden Set (direct, indirect, negative).
2. Fügen wir in den system-prompt Fragmente ein:

   Wenn der Nutzer über die Auswahl eines Geschenks für eine konkrete Person spricht
   (Freund, Neffe, Kollege etc.),
   musst du:
   - das Alter des Empfängers klären, falls nicht angegeben;
   - zumindest ungefähres Budget und Anlass klären;
   - die Tools profile_to_segments und recommend_gifts aufrufen,
     um 3–7 passende Optionen auszuwählen;
   - erklären, warum diese Optionen zum Profil und zum Budget passen.
   

3. Präzisieren wir in der Beschreibung des Tools recommend_gifts:

   Verwende dieses Tool, wenn der Nutzer ein Geschenk
   für sich oder eine andere Person zu einem konkreten Anlass auswählen möchte,
   insbesondere wenn Alter, Interessen oder Budget erwähnt werden.
   Verwende es nicht für Aufgaben, die nichts mit der Geschenkauswahl zu tun haben.
   

4. Prüfen wir am Golden Set: Für „wähle ein Geschenk für meinen 12‑jährigen Neffen …“ — das Tool wird aufgerufen, und für „erzähl einen Witz über IT‑Leute“ — es wird nicht aufgerufen und es folgt eine normale Textantwort ohne GiftGenius.

Wenn etwas nicht funktioniert (das Modell ignoriert GiftGenius oder versucht umgekehrt, es für Aufgaben außerhalb der Geschenkdomäne zu nutzen), gehen wir zurück zum system-prompt und den Tool‑Beschreibungen und schärfen die Formulierungen.

Warum der Satz „nicht erfinden“ allein nicht reicht

Ein naiver Versuch, Halluzinationen zu bekämpfen: am Ende des system-prompt die Zeile „Erfinde keine nicht existierenden Geschenke“ hinzufügen. Leider wirkt das nicht besonders.

Wenn Sie jedoch:

• über JTBD als Ziel festhalten „nur existierende Ideen aus dem Katalog liefern, die man wirklich kaufen kann“;
• in der Beschreibung von recommend_gifts sagen, dass es auf eine reale Datenbasis (gift_catalog.{locale}.json) zugreift und eine leere Liste zurückgibt, wenn es nichts gibt;
• ins Golden Set Anfragen wie „wähle ein Geschenk für 1$ mit kostenloser weltweiter Lieferung bis morgen“ aufnehmen, mit dem Ideal should_call_tool: true und der Erwartung „leeres Ergebnis zurückgeben und vorschlagen, die Filter zu lockern“,

— dann erhalten Sie ein mehrschichtiges System, das das Modell tatsächlich zu richtigem Verhalten zwingt.

8. Kleine Visualisierung: von JTBD zum Golden Set

Fassen wir alles in einem Bild zusammen — von Features bis zum Golden Set.

flowchart TD
    A[Features von GiftGenius: Profil-Assistent, recommend_gifts, Käufe] --> B[Use-Cases: konkrete Geschichten von Schenkern und HR]
    B --> C[JTBD: warum der Nutzer kommt]
    C --> D[Anweisungen im system-prompt und Tool-Beschreibungen]
    B --> E[Golden Prompt Set: direct/indirect/negative]
    D --> F[Verhalten des Modells im realen Dialog]
    E --> F
    F --> G[Beobachtung sowie Nachschärfen der Regeln und des Golden Sets]

Dieses Bild ist psychologisch wichtig: Sie hören auf, das Golden Set als „etwas für Data Scientists“ zu betrachten, und sehen es als Bestandteil des normalen Engineering‑Zyklus: Regeln formuliert → an Referenzfällen geprüft → angepasst.

9. Praktische Mini‑Aufgabe (können Sie nach der Vorlesung machen)

1. Nehmen Sie Ihren aktuellen GiftGenius.
2. Beschreiben Sie 3 Schlüssel‑Use‑Cases im Format:
   • „Als [wer] möchte ich [was], um [warum]“.
3. Erfinden Sie für jedes Szenario:
   • 1 Direct‑Anfrage,
   • 1 Indirect‑Anfrage,
   • 1 Negative‑Anfrage.
4. Schreiben Sie für jede Anfrage ideal.should_call_tool und ideal.expected_tool (falls anwendbar).
5. Speichern Sie sie in tests/golden-prompts/giftgenius.golden.jsonl.
6. Schauen Sie auf Ihren aktuellen system-prompt und notieren Sie, was dort fehlt, damit sich das Modell in all diesen Anfragen korrekt verhält.

Diese Aufgabe erfordert keinen tiefen Code, verbessert jedoch Ihre Prompts erheblich und macht die nächsten Module (MCP, Agenten, Evals) deutlich weniger schmerzhaft.

10. Typische Fehler bei der Arbeit mit Use‑Cases, JTBD und Golden Prompt Set

Fehler Nr. 1: Eine Feature‑Liste mit einer Szenarien‑Karte verwechseln.
Das Team zeigt stolz: „unsere App kann 15 verschiedene Dinge“, aber kein einziger Use‑Case ist vernünftig beschrieben. In der Folge wird der system-prompt abstrakt („hilf bei Geschenken“), und das Modell ruft GiftGenius entweder bei jedem Anlass auf oder fast nie. Heilung: Features in konkrete Geschichten verwandeln („Mutter 35, Empfänger 14, mag Spiele, Budget …“) und in der Doku festhalten.

Fehler Nr. 2: JTBD bleiben nur im Kopf des Product‑Managers.
Manchmal erzählt der Product‑Manager auf einem Meetup schön, „welchen Schmerz unsere App löst“, aber das landet in keiner Datei des Repos und spiegelt sich in den Prompts nicht wider. Am Ende weiß das Modell nicht, dass seine Aufgabe ist, Unsicherheit vor der Geschenkwahl zu verringern, Zeit zu sparen oder ein erfolgreiches Geschenk schnell zu wiederholen. Wenn JTBD nicht in konkrete Anweisungen im system-prompt und in Tool‑Beschreibungen umgesetzt werden, sind sie nutzlos.

Fehler Nr. 3: Das Golden Prompt Set ist zu klein und „steril“.
Das Team begnügt sich mit 5–7 hübschen Direct‑Anfragen aus der Präsentation. Es gibt keine krummen Formulierungen, keinen Slang, keine Tippfehler, keine provokativen Aufgaben („ändere die Empfängeradresse“, „umgehe Sicherheitsbeschränkungen“). In Produktion schreiben die Nutzer natürlich genau so — folglich deckt das Golden Set die Hälfte der realen Probleme nicht ab. Der Satz muss nicht nur „ideale“, sondern auch direkte, indirekte und negative Cases enthalten.

Fehler Nr. 4: Das Golden Set wird nie verwendet.
Manchmal erscheint die Datei mit den Referenzanfragen im Repo und … stirbt dort. Niemand lässt sie vor dem Release laufen, nutzt sie nicht bei Änderungen am system-prompt, bindet sie nicht ins CI ein. Damit der Satz nützlich ist, muss er regelmäßig ausgeführt werden (zumindest manuell in der Dev‑Umgebung) und die Prompts oder Tool‑Beschreibungen anhand der Ergebnisse angepasst werden.

Fehler Nr. 5: Widersprüche zwischen system‑prompt, Tool‑Beschreibungen und Golden Set.
Es kommt vor, dass im Golden Set steht: „für diese Anfrage soll recommend_gifts aufgerufen werden“, aber in der Tool‑Beschreibung steht „wird nur für B2B‑Geschenke verwendet“. Das Modell bekommt widersprüchliche Signale: Systemanweisungen sagen „rufe GiftGenius“, die Tool‑Beschreibung deutet an „das ist nicht mein Bereich“. Infolgedessen wird das Tool in manchen Sessions aufgerufen, in anderen nicht. Halten Sie diese drei Schichten (system‑prompt, Tools, Golden Set) konsistent: Wenn Sie eine Regel an einer Stelle ändern — aktualisieren Sie die anderen Schichten mit.

Fehler Nr. 6: Der Versuch, Halluzinationen mit dem einen Satz „nicht erfinden“ zu „heilen“.
Ein schlichtes „erfinde keine Geschenke“ ohne klare Szenarien „was tun, wenn das Tool eine leere Antwort liefert“ und ohne negative Anfragen im Golden Set hilft wenig. Das Modell versucht trotzdem, „hilfreich“ zu sein, und könnte in Grenzfällen fantasieren. Der funktionierende Ansatz ist die Kombination: JTBD → strenger system‑prompt → präzise Tool‑Beschreibungen → Golden Set mit leeren/fehlerhaften Cases.

Fehler Nr. 7: Versuchen, das Golden Set mit „allen möglichen Anfragen“ abzudecken.
Manchmal versucht das Team, eine Liste mit Hunderten Fällen zu erstellen, und gibt auf halber Strecke auf, weil es zur Endlosarbeit wird. Besser ist es, mit 20–50 sorgfältig ausgewählten Anfragen zu starten, die die Schlüssel‑Use‑Cases und typischen Modellfehler wirklich abbilden, und den Satz schrittweise zu erweitern, sobald neue Probleme auftauchen.