System‑Prompt und der „rollenbasierte Vertrag“ der ChatGPT App

1. System‑Prompt als Vertrag, nicht als hübscher Text

In den vorherigen Modulen haben wir die ChatGPT App aus architektonischer Sicht betrachtet: Widget, tools und MCP‑Server. In dieser Lektion wechseln wir dazu, mit welchen Worten wir dem Modell seine Rolle erklären: was es tun darf, was nicht, und wie es die Werkzeuge nutzt. Im Grunde entwerfen wir den System‑Prompt als Vertrag zwischen Ihnen und dem Modell.

Im normalen Chat mit ChatGPT sind Sie vielleicht an Prompts wie „Stell dir vor, du bist ein lustiger Piraten‑Assistent“ oder „Erkläre alles so, als ob ich fünf Jahre alt wäre“ gewöhnt. Das ist alles Persona und Stil. Im Kontext der ChatGPT App hat der Begriff System‑Prompt eine ganz andere Bedeutung.

Der System‑Prompt ist hier die erste, vor dem Nutzer verborgene Nachricht der Rolle system, die dem Modell vorgibt:

• wer es innerhalb Ihrer App ist;
• worauf es fokussiert ist;
• worum es sich NICHT kümmert;
• wie und wann es die Werkzeuge Ihrer Anwendung aufrufen soll.

Im Kern ist das eine Verhaltensspezifikation, sehr nah an einem formalen Vertrag. Wenn vereinbart – versucht das Modell, sich daran zu halten. Wenn nicht – verhält es sich wie ein gewöhnliches „allgemeines“ ChatGPT und Ihre schöne App bleibt außen vor.

Wichtig ist, dass für die ChatGPT App dieser System‑Prompt:

• an die App selbst gebunden ist, nicht an einen konkreten einzelnen Dialog;
• Rahmen sowohl für das Widget als auch für Aufrufe der tools setzt;
• so lange „lebt“, wie die App‑Sitzung lebt (solange der Nutzer mit Ihrer Anwendung interagiert).

Vereinfacht gesagt lautet die Vereinbarung: Sie geben dem Modell Werkzeuge und beschreiben seine Rolle – welcher Assistent es ist, was es tut, was es nicht tut, wie es die Werkzeuge einsetzt und wie es mit Nutzerdaten umgeht. Das Modell wiederum bemüht sich, sich genau so zu verhalten.

2. Wo der System‑Prompt in der Architektur lebt

Damit es nicht wie eine magische Entität wirkt, ist es hilfreich, ihn im Schema zu sehen.

sequenceDiagram
    participant User as Benutzer
    participant ChatGPT as ChatGPT + Modell
    participant App as Ihre ChatGPT App
    participant MCP as MCP/Backend

    Note over ChatGPT: Bei der Initialisierung der App
erhält das Modell den System‑Prompt

    User->>ChatGPT: "Finde ein Geschenk für einen Freund bis 50 $"
    ChatGPT->>ChatGPT: Wendet den System‑Prompt + die Tools‑Beschreibungen an
    ChatGPT->>App: callTool recommend_gifts(...)
    App->>MCP: HTTP /tools/recommend_gifts
    MCP-->>App: Geschenkeliste
    App-->>ChatGPT: Tool-Ergebnis (JSON)
    ChatGPT-->>User: Text + Hinweis auf ein Widget mit Karten

Der System‑Prompt gelangt zum Modell, wenn die App initialisiert wird – also wenn ChatGPT entscheidet, Ihre Anwendung mit dem Dialog zu „verbinden“. Danach läuft jede Entscheidung von ChatGPT – ob ein Tool gerufen wird, ob ein Widget vorgeschlagen wird, was gesagt wird, wenn keine Daten vorliegen – bereits durch das Prisma dieses Vertrags.

Aus Sicht des Codes in der Apps SDK ist das meist nur ein String, der irgendwo neben der App‑Konfiguration liegt, zum Beispiel:

// app/config/systemPrompt.ts
export const giftGeniusSystemPrompt = `
Du bist GiftGenius, ein Assistent zur Auswahl von Geschenken...
`;

Und dann geht dieser String dorthin, wo Ihre Anwendung mit ChatGPT verdrahtet ist. Die technische „Umrahmung“ kann variieren, aber für Sie ist wichtig: Der System‑Prompt ist ein genauso echter Code‑Artefakt wie ein Tool‑Schema oder eine React‑Komponente – und sollte ebenso sorgfältig entworfen und versioniert werden.

Jetzt, da klar ist, wo der System‑Prompt in der Architektur lebt und wie er zum Modell gelangt, ist am wichtigsten, was genau hineingehört, damit er ein Vertrag ist – und nicht nur die Beschreibung einer „netten Persona“.

3. Rolle der App und Verantwortungsgrenzen

Der erste und wichtigste Abschnitt jedes soliden System‑Prompt ist: wer du bist und wofür du verantwortlich bist.

Der Unterschied zwischen „Persona“ und „App‑Vertrag“ ist simpel: „Du bist ein Pirat und sprichst im Seemannsstil“ – das betrifft den Ton; „Du bist die Schnittstelle zu unserem Geschenkekatalog, wählst Geschenke aus und mischst dich nicht in andere Themen ein“ – das ist bereits ein Vertrag.

Für unsere Lernanwendung GiftGenius, die Geschenke vorschlägt, kann der Kern der Rolle so aussehen:

Rolle:
- Du bist GiftGenius, der Assistent unseres Dienstes zur Auswahl von Geschenken.
- Deine Aufgabe ist es, dem Nutzer bei der Auswahl eines passenden Geschenks zu helfen – ausschließlich anhand unseres Katalogs.
- Du gibst keine medizinischen, juristischen oder finanziellen Ratschläge.

Achten Sie auf die Schwerpunkte.

Erstens definieren wir die Domäne eng: ausschließlich Geschenkauswahl im Rahmen unseres Dienstes. So verhindert man, dass das Modell statt Ihrer App „Quantenphysik erklärt“ oder seltsame Workflows um andere Anwendungen herum baut.

Zweitens fixieren wir explizit was die App nicht tut. Zum Beispiel:

• keine Ratschläge zu Themen gibt, die nichts mit Geschenken und Einkäufen zu tun haben;
• keine Geschenke erfindet, die nicht im Katalog stehen;
• nicht anstelle des Nutzers entscheidet, sondern Optionen anbietet und begründet.

Solche negativen Einschränkungen sind oft wichtiger als positive Anweisungen: Das Modell kann ohnehin „alles“ – im System‑Prompt schneiden Sie das Überflüssige ab.

Für komplexere Umgebungen, in denen ein Entwickler mehrere Apps hat (z. B. „Geschenkauswahl“ und „Sendungsverfolgung von Bestellungen“), ist es im System‑Prompt sinnvoll, ausdrücklich zu schreiben, dass du dich in dieser App nur um die Geschenkauswahl kümmerst, keine Bestellverwaltung/Logistik übernimmst und keine anderen Anwendungen startest. Das reduziert das Risiko, dass das Modell verwechselt, „wessen Aufgabe“ etwas ist.

4. Wann die App aufrufen und wann selbst antworten

Der nächste kritische Block des Vertrags: Regeln zur Nutzung der Werkzeuge.

Wenn man sie nicht festlegt, geht es meist in eine von zwei Extreme:

• das Modell ruft Ihre App fast nie auf, weil es einfacher und günstiger ist, „aus dem Kopf“ zu antworten;
• oder umgekehrt: Es ruft die Werkzeuge bei jeder Kleinigkeit auf, selbst bei rein theoretischen Fragen.

Im System‑Prompt für die App sollte ziemlich klar festgehalten werden:

• in welchen Fällen die Werkzeuge zu verwenden sind;
• in welchen Fällen selbst zu antworten ist – ohne tools;
• was zu tun ist, wenn der Nutzer ausdrücklich bittet, „die Anwendung nicht zu starten“.

Beispieltext für GiftGenius:

Arbeit mit Werkzeugen:
- Verwende die App-Tools, wenn du Fakten aus dem Katalog brauchst (Geschenkeliste, Preise, Produkttypen, Lieferbarkeit und Rabatte).
- Antworte selbst, wenn die Frage theoretisch ist und keinen Katalogzugriff erfordert (z. B. "Welche Geschenke schenkt man üblicherweise zum Einzug?").
- Wenn der Nutzer ausdrücklich bittet, "die Anwendung nicht zu öffnen" oder "ohne Widget zu antworten", respektiere das und rufe keine Tools auf.

Hier passieren mehrere wichtige Dinge.

Erstens koppeln wir den Aufruf der tools an den Fragetyp: Fakten/Katalogdaten → Werkzeug; allgemeine Theorie → das Modell antwortet selbst.

Zweitens adressieren wir ausdrücklich das Respektieren der Nutzerintention: Wenn jemand schreibt „Bitte nichts starten, nur erklären“, sollte das Modell dieses Signal nicht ignorieren.

Drittens steuern wir damit die Häufigkeit der App‑Nutzung. Ein guter System‑Prompt hilft dem Modell, ein Gleichgewicht zu finden: Die App wird genutzt, wenn es nötig ist, wird aber kein aufdringliches Pop‑up, das sich immer vordrängelt.

Später, in der nächsten Lektion zu UX‑Anweisungen, sprechen wir separat darüber, wie das Modell den Start des Widgets ankündigen und was es nach Abschluss des Szenarios sagen sollte. Hier interessieren uns die Entscheidungsregeln: App nutzen oder nicht.

5. Sicherer Einsatz von tools und Umgang mit Nutzerdaten

Nun zu Sicherheit und gesundem Menschenverstand.

Die Werkzeuge Ihrer App können unterschiedlich sein:

• solche, die mit öffentlichen Daten arbeiten (Geschenkekataloge, Warenverfügbarkeit, Lieferbedingungen);
• solche, die mit personenbezogenen Daten arbeiten und/oder Handlungen im Namen des Nutzers ausführen (Bestellung anlegen, Abbuchen von Mitteln, Einstellungen ändern).

Im System‑Prompt sollte festgelegt werden, wie das Modell mit diesen Unterschieden umgehen soll.

Ein typischer Satz von Regeln:

Sicherheit und Datenschutz:
- Führe keine Handlungen aus, die die Einwilligung des Nutzers erfordern (Kauf, Abschluss eines Abos, Änderung personenbezogener Daten), ohne ausdrückliche Bestätigung im Chat.
- Übermittle an die Tools nicht mehr Daten als für deren Arbeit notwendig (Datenminimierung).
- Wenn die Anfrage sensible Daten betrifft (Gesundheit, Finanzen, Kinder), frage zuerst, ob der Nutzer die Übermittlung dieser Daten in die Anwendung bestätigt.

Damit lösen wir mehrere Aufgaben auf einmal.

Erstens schützen wir den Nutzer vor unerwarteter Aktivität: Das Modell darf nicht eigenständig ein Geschenk kaufen oder eine Bestellung auslösen, wenn Sie ein solches Tool bereitgestellt haben. Zuerst die textliche Bestätigung, dann der Tool‑Aufruf.

Zweitens reduzieren wir das Risiko unnötiger Datenweitergabe: Das Modell neigt dazu, „alles, was es sieht“, in die Tool‑Argumente zu ziehen; Sie fordern hingegen ausdrücklich, sich auf minimal erforderliche Felder zu beschränken.

Drittens heben wir sensible Domänen hervor, in denen es auch ohne Finanz‑Tool rechtliche/ethische Risiken geben kann.

Gute Praxis ist es, bei riskanten Werkzeugen zusätzlich in deren Beschreibung (description) zu vermerken, dass sie Zustand verändern oder Zahlungen auslösen, und dies im System‑Prompt zu spiegeln. So entsteht eine doppelte Barriere: im Vertrag und in der Beschreibung des konkreten Tools.

6. Format und Stil des System‑Prompt: wie eine Spezifikation schreiben

Einer der häufigsten Fehler ist es, den System‑Prompt wie Marketingtext zu schreiben: „Du bist ein innovativer, unglaublich kluger Assistent, der die Welt besser macht …“. Klingt schön, bringt dem Modell aber nichts. Es interessiert sich für:

• wer bin ich;
• was ist zu tun;
• was ist zu unterlassen;
• wie sind die Werkzeuge zu nutzen;
• wie ist mit Daten und anderen Apps umzugehen.

Behandeln Sie den System‑Prompt daher besser wie eine Spezifikation:

• in logische Blöcke gliedern: „Rolle“, „Aufgaben“, „Grenzen“, „Arbeit mit Werkzeugen“, „Sicherheit“;
• innerhalb der Blöcke kurze, eindeutig verständliche Sätze verwenden;
• „tun“ und „nicht tun“ ausdrücklich trennen (ja, Listen sind im Prompt selbst durchaus sinnvoll).

Ein Auszug eines strukturierten Prompts für GiftGenius könnte so aussehen:

Rolle:
- Du bist GiftGenius, der Assistent unseres Dienstes zur Auswahl von Geschenken.

Aufgaben:
- Hilf dem Nutzer, Geschenke passend zu Aufgabe, Interessen des Empfängers und Budget zu wählen.
- Erkläre Vor- und Nachteile jeder Option in klarer, einfacher Sprache.

Nicht tun:
- Erfinde keine Geschenke, die nicht im Katalog stehen.
- Versprich keine Servicefunktionen, die es nicht gibt (z. B. kostenlose Lieferung, wenn laut Katalog kostenpflichtig).

Den Stil hält man am besten neutral und „trocken“: Das ist kein Verkaufstext, sondern ein Vertrag. Je weniger Zweideutigkeit, desto stabiler das Verhalten.

Eine weitere wichtige Praxis: Versionierung und Ablage des System‑Prompt im Repository zusammen mit dem Code. Prompts haben ebenfalls Versionen, und Änderungen daran können das Verhalten genauso brechen wie Änderungen in der TypeScript‑Logik. Es ist viel angenehmer, im PR‑Review einen Diff zu sehen:

- Erfinde keine Geschenke, die nicht im Katalog stehen.
+ Erfinde keine Geschenke, die nicht im Katalog stehen, selbst wenn der Nutzer ausdrücklich bittet, "sich etwas auszudenken".

als zu versuchen, sich daran zu erinnern, dass man „die Formulierung mal eben im Interface leicht angepasst“ hat.

7. Vollständiges Beispiel eines System‑Prompt für unsere Lern‑App

Fassen wir alles zusammen und schreiben einen sauberen System‑Prompt für unsere Lern‑GiftGenius. Wir teilen ihn in Abschnitte, damit er leichter zu lesen und zu pflegen ist.

Zuerst beschreiben wir Rolle und Aufgaben:

Rolle:
- Du bist GiftGenius, der Assistent unseres Dienstes zur Auswahl von Geschenken.
- Du kommunizierst höflich und geschäftsmäßig, ohne Slang und Witze, es sei denn, der Nutzer nutzt sie selbst.

Aufgaben:
- Hilf, Geschenke anhand der angegebenen Parameter auszuwählen (Profil des Empfängers, seine Interessen, Anlass, Budget).
- Erkläre in einfacher, verständlicher Sprache, warum du genau diese Optionen vorschlägst.

Nun legen wir Grenzen und Einschränkungen fest:

Verantwortungsgrenzen:
- Du arbeitest ausschließlich mit unserem Geschenkekatalog und seinen Metadaten.
- Erfinde keine Geschenke, Aktionen und Rabatte, die nicht im Katalog oder in den Tool-Antworten stehen.
- Gib keine medizinischen, juristischen oder finanziellen Ratschläge.
- Übernimm keine Verantwortung für andere Anwendungen oder Websites; wenn der Nutzer danach fragt, sage, dass du nicht helfen kannst.

Fügen wir Regeln für die Arbeit mit Werkzeugen hinzu:

Arbeit mit Werkzeugen:
- Verwende das Tool `profile_to_segments`, wenn eine freie Beschreibung des Empfängers in Interessensegmente überführt werden soll.
- Verwende das Tool `recommend_gifts`, wenn Geschenke nach Nutzerparametern gesucht oder gefiltert werden sollen (Segmente, Budget, Anlass, Locale).
- Verwende das Tool `get_gift`, wenn der Nutzer Details zu einem konkreten Geschenk braucht (Beschreibung, Typ, Preis, Lieferbeschränkungen).
- Kläre vor dem Aufruf von Werkzeugen fehlende Parameter (Alter des Empfängers, Budget, Anlass), wenn das Ergebnis sonst nutzlos wäre.
- Wenn die Anfrage theoretisch ist (z. B. "wie man im Allgemeinen Geschenke zum ersten Hochzeitstag auswählt"), antworte selbst, ohne Tools aufzurufen.

Jetzt – der Block zu Sicherheit und Handlungen im Namen des Nutzers:

Sicherheit:
- Leite keinen Kauf, kein Abo und keinen Versand eines Geschenks ohne ausdrückliche Bestätigung des Nutzers im Chat ein.
- Wenn für ein Tool personenbezogene Daten nötig sind (E‑Mail des Empfängers, Lieferadresse, Name), erkläre zuerst, wozu sie gebraucht werden, und bitte um Bestätigung.
- Übermittle an die Tools nicht mehr Daten als nötig (sende z. B. nicht die gesamte Nachricht, wenn Alter, Interessen und Budget genügen).

Und Ton/übergreifende Regeln:

Allgemeine Regeln:
- Wenn die Tools ein leeres Ergebnis zurückgeben, sage das offen und schlage vor, die Bedingungen zu lockern (Budget, Geschenktyp, Kategorie oder Anlass ändern).
- Wenn der Nutzer bittet, "die Anwendung nicht zu öffnen" oder "auf das Widget zu verzichten", respektiere das und antworte nur mit Text, ohne tools aufzurufen.
- Wenn die Anfrage nichts mit Geschenken oder Einkäufen zu tun hat, antworte wie ein Basis‑ChatGPT und verwende die Tools von GiftGenius nicht.

Am Ende ähnelt diese Konstruktion stark dem Beispiel aus den Zusatzmaterialien: Es gibt die Abschnitte „Rolle“, „Aufgaben“, „Tun/Nicht tun“, „Arbeit mit Werkzeugen“, „Sicherheit“, „Allgemeine Regeln“.

In Next.js können Sie das als separates Modul ablegen:

// app/config/giftGeniusPrompt.ts
export const giftGeniusSystemPrompt = `
Rolle:
- Du bist GiftGenius, der Assistent unseres Dienstes zur Auswahl von Geschenken.
...

Allgemeine Regeln:
- Wenn die Anfrage nichts mit Geschenken zu tun hat, antworte wie ein Basis-ChatGPT und verwende die Tools von GiftGenius nicht.
`;

Und dann diese Konstante in der App‑Konfiguration verwenden (die genaue Vorgehensweise hängt von der Version der Apps SDK ab, aber die Idee ist dieselbe: Dieser Text geht bei der Initialisierung des App‑Dialogs in die Rolle system).

8. Dynamischer Kontext im System‑Prompt

Manchmal muss man dem System‑Prompt etwas Dynamik „untermischen“: aktuelles Datum, Locale, Nutzertyp (Neu-/Bestandskunde), Abo‑Status usw.

Wenn sich z. B. Ihr Geschenkekatalog und Preise je nach Region unterscheiden, können Sie die aktuelle Region in den System‑Prompt übergeben:

export function buildSystemPrompt(locale: string) {
  return `
Rolle:
- Du bist GiftGenius, Assistent zur Geschenkauswahl für die Region ${locale}.

Grenzen:
- Verwende nur die Geschenke und Preise, die in der Region ${locale} verfügbar sind.
...
`;
}

Die Apps SDK kann Ihnen bei der Initialisierung der App _meta["openai/locale"] bereitstellen, und Sie generieren darauf basierend die passende Prompt‑Variante. Detaillierte Lokalisierung behandeln wir später, aber es ist schon jetzt hilfreich zu sehen, dass der System‑Prompt nicht immer statisch sein muss.

Wichtig ist, ihn nicht in „Spaghetti“ aus Bedingungen zu verwandeln. Wenn die Logik zu komplex wird, teilen Sie die App lieber auf oder verlagern Sie Bedingungen in tools (z. B. dass der MCP‑Server selbst die passende Datenquelle je nach Locale wählt), und lassen Sie im System‑Prompt nur die übergeordneten Regeln.

9. Wie der System‑Prompt mit der Beschreibung der tools und UX‑Anweisungen zusammenhängt

Diese Lektion konzentriert sich auf den System‑Prompt, aber in der realen App existiert er nicht isoliert. Es gibt außerdem Tool‑Beschreibungen (description, inputSchema) und Follow‑up‑Beispiele, die Sie in den nächsten Themen definieren. Zusammen bilden sie ein einheitliches Instruktionssystem.

Steuerung des tools-Aufrufs:

• Der System‑Prompt legt die Gesamtausrichtung fest: „Werkzeuge nur für faktische Daten“, „keine Geschenke erfinden“, „nichts kaufen ohne Bestätigung“;
• die Beschreibungen der tools präzisieren, was genau recommend_gifts macht, welche Parameter nötig sind und wann es aufzurufen ist;
• Follow‑up‑Formulierungen bestimmen den Dialogstil nach dem Tool‑Aufruf: wie man ehrlich sagt, dass nichts gefunden wurde, wie man eine Anpassung der Anfrage vorschlägt, wie man Ergebnisse zusammenfasst.

Wenn diese drei Schichten konsistent sind, verhält sich das Modell vorhersagbar:

• es ruft die App dann auf, wenn es wirklich nötig ist;
• es halluziniert keine Geschenke/Artikel außerhalb der Datenbasis;
• es erklärt dem Nutzer nachvollziehbar, was passiert ist (gefunden / nicht gefunden / zusätzliche Informationen nötig).

Wenn nicht – erhalten Sie chaotisches Verhalten und lange Sitzungen des „magischen Prompt‑Tunings“, von denen alle sehr schnell genervt sind.

10. Typische Fehler beim Arbeiten mit dem System‑Prompt der ChatGPT App

Fehler Nr. 1: den System‑Prompt „für die Schönheit“ schreiben statt als Vertrag.
Sehr oft begnügen sich Entwickler mit allgemeinen Floskeln wie „Hilf dem Nutzer, seine Aufgaben zu lösen, so gut du kannst“ und „Sei freundlich“. Dadurch wird dem Modell nicht klarer, wann es die App aufrufen soll, wo die Verantwortungsgrenzen verlaufen, ob es Daten erfinden darf und was bei Tool‑Fehlern zu tun ist. Die Hälfte der Logik verteilt sich dann über Code‑Stacks – und den Kopf des Autors – statt in einem expliziten Vertrag verankert zu sein.

Fehler Nr. 2: eine zu breite Rolle („hilf bei allem“).
Wenn Sie im Rollenabschnitt schreiben „Du bist ein Assistent, der dem Nutzer in allen Fragen hilft“, dann tut das Modell genau das – und denkt nicht immer an Ihre App. Die App wird zur unverbindlichen Option, die kaum verwendet wird, weil das Modell meint, es schafft es ohnehin. Besser ist es, die Nische explizit zu benennen: Geschenkauswahl, Arbeit mit dem Geschenkekatalog, Hilfe in einer konkreten Domäne.

Fehler Nr. 3: keine Regeln, wann Werkzeuge aufzurufen sind.
Formulierungen wie „verwende Tools nach Bedarf“ sind zu vage. Das Modell kann tools entweder völlig ignorieren oder sie selbst dort aufrufen, wo eine Antwort „aus dem Kopf“ genügt hätte. Man muss Szenarien klar trennen: Faktendaten → Tool, Hintergrund‑Erklärungen → Antwort des Modells, ausdrückliche Ablehnung der App durch den Nutzer → nur Text.

Fehler Nr. 4: Halluzinationen mit dem einen Satz „nicht erfinden“ heilen wollen.
Der Satz „nicht halluzinieren“ hilft für sich genommen wenig. Es ist wichtig, explizit zu beschreiben, was genau nicht erfunden werden darf (Artikel/Geschenke außerhalb des Katalogs, Positionen ohne ID, nicht existierende Rabatte) und was bei leerem Ergebnis zu tun ist (ehrlich sagen, dass nichts gefunden wurde). Ohne das versucht das Modell weiterhin, „zu gefallen“, und generiert ausgedachte Optionen. Es braucht den vollständigen Satz: globales Verbot im System‑Prompt, Einschränkungen in den Beschreibungen der tools und Antwortschablonen für „nichts vorhanden“.

Fehler Nr. 5: Sicherheit und Einwilligung des Nutzers ignorieren.
Wenn im System‑Prompt nicht steht, dass Kauf, Buchung oder Änderungen personenbezogener Daten eine ausdrückliche Bestätigung erfordern, könnte das Modell – in „guter Absicht“ – das Tool eigenständig aufrufen. Aus UX‑Sicht ist das eine Katastrophe. Schreiben Sie immer fest, dass jegliche Handlungen mit Finanzen oder Konto nur nach expliziter Zustimmung im Chat erfolgen.

Fehler Nr. 6: die Existenz anderer Apps und Tools nicht berücksichtigen.
In einer Welt, in der ein Konto mehrere Apps und viele tools hat, kann man nicht davon ausgehen, dass das Modell „selbst errät“, welche Anwendung zu verwenden ist. Wenn der System‑Prompt nicht festlegt, dass dies konkret die App für die Geschenkauswahl ist und nur dafür, kann das Modell unvorhersehbar zwischen verschiedenen Apps wechseln oder Tools zweckentfremden.

Fehler Nr. 7: den System‑Prompt „on the fly“ ohne Versionierung und Tests ändern.
Es ist verlockend, in die Konfiguration zu gehen, eine Zeile zu ändern und zu glauben, „es wurde nur besser“. In der Praxis kann jede Prompt‑Anpassung das Verhalten anderer Szenarien brechen. Wenn Sie den System‑Prompt nicht im Repository versionieren, keine Diffs ansehen und keinen Satz von Testanfragen (golden prompt set – dazu kommen wir in diesem Modul) durchlaufen, werden Sie Regressionen wochenlang jagen.