Multi‑App‑Szenarien und App‑Komposition

1. Was sind Multi‑App‑Szenarien und warum Sie sie brauchen

Bisher haben wir GiftGenius als einzige externe Anwendung in einem konkreten Chat betrachtet: Der Nutzer wählt Ihre App aus der Liste, ChatGPT lädt Ihre Tools, und Sie sind der „Hauptdarsteller“ der Geschichte. Im realen Store ist es anders: Der Nutzer kann mehrere Apps zugleich anschließen, und ChatGPT entscheidet, welche Anwendung auf eine konkrete Anfrage aufgerufen wird.

Zum Beispiel können in einem Chat vorhanden sein:

• eine unternehmensinterne Kalender‑App, die die Geburtstage von Kollegen kennt;
• GiftGenius, das Geschenkideen vorschlägt;
• die Commerce‑App des Unternehmens, die Bestellungen und Bezahlung durchführen kann.

Der Nutzer schreibt: „Erinnere mich an die Geburtstage der Kollegen und schlage gleich vor, was ich schenken und wie ich es kaufen kann.“ Das Modell kann nacheinander drei verschiedene Apps aufrufen: die erste für den Kalender, die zweite für Geschenkideen, die dritte für den Checkout.

Wichtig zu verstehen: Der Nutzer hat keinen Button „Bitte rufe App Nr. 2 auf, hier ist ihr HTTP‑Endpoint“. Er kommuniziert in natürlicher Sprache, und ChatGPT fungiert als Router – es liest die descriptions und Metadaten aller verfügbaren Anwendungen und entscheidet, wen es wann aufruft.

Daraus folgen drei zentrale Gedanken:

• Es gibt Konkurrenz um den Kontext. Ihre App muss unter Dutzenden anderer anhand von Beschreibungen, Namen und Verhalten ausgewählt werden.
• Metadaten werden zu Ihrem „SEO für LLMs“ – sie bestimmen, ob das Modell GiftGenius im richtigen Moment sieht oder ignoriert.
• Denken Sie an Interoperabilität: Ihre Antworten sollten nicht nur dem Menschen im Chat nützen, sondern auch anderen Apps, die denselben Kontext lesen.

Im Kern verwandeln wir eine isolierte ChatGPT‑App in eine Komponente eines größeren Systems.

2. Wie das Modell eine App auswählt: mentale Routing‑Modell

Routing in Multi‑App‑Szenarien funktioniert ungefähr so (stark vereinfacht, aber nützlich für die Entwicklung):

1. ChatGPT hat eine Liste verfügbarer Apps und ihrer Tools mit Metadaten (Name, Beschreibung, JSON‑Schema der Parameter, Annotationen und _meta).
2. Der Nutzer schreibt eine Nachricht.
3. Das Modell bildet eine interne Repräsentation der Absicht (Intent) und macht im Grunde eine semantische Suche über descriptions von Tools und Anwendungen, um zu verstehen, welche Werkzeuge passend sind.
4. Wenn die Kriterien erfüllt sind – ruft es ein Tool auf oder schlägt vor, die App zu öffnen.

Dabei gibt es einen wichtigen Punkt: descriptions müssen ausreichend unterscheidbar (diskriminativ) sein. „Produktsuche“ unterscheidet sich kaum von „Geschenk‑Suche“ oder „Büchersuche“, wohingegen „Geschenkideen‑Suche auf Basis der GiftGenius‑Partnerdatenbank“ die Domäne stark eingrenzt und die Chancen erhöht, dass genau Ihr Tool für Geschenk‑Anfragen ausgewählt wird.

Zweites Detail – vermeiden Sie Namenskollisionen. Ein Tool namens get_data sagt in einer Welt mit Dutzenden Apps gar nichts aus, giftgenius_get_gift_catalog hingegen ist deutlich klarer. Besonders in Kombination mit einer präzisen description.

Und schließlich stützt sich das Modell auf den Kontext: Wenn im Chat bereits „Geschenke“, „Geburtstage“ und sogar der Name GiftGenius erwähnt wurden, hebt das Ihre App aus Sicht des Routers hervor.

3. Metadaten und Descriptions als LLM‑SEO

Damit Sie Metadaten nicht als „Pflichtformalität in JSON“ behandeln, ist es hilfreich, sie als produktnahe Copywriting‑Arbeit zu sehen. Offizielle Empfehlungen sagen ausdrücklich: treat metadata like product copy und entwerfen Sie „one job per tool“.

Man kann grob mehrere Beschreibungsebenen unterscheiden:

_meta["openai/widgetDescription"]

widgetDescription ist in einer Widget‑Welt besonders wichtig: Das Modell „sieht“ Ihren React‑Code nicht, es weiß nur, welche Props Sie ihm übergeben und wozu. Ein gut ausgefülltes Feld verhindert, dass es Dinge „für Sie erfindet“, und hilft stattdessen, Textantworten an bereits gezeigtes UI anzupassen.

Die Dokumentation zum Apps SDK betont: ChatGPT entscheidet, wann und wie Ihr Connector (App) aufgerufen wird – basierend auf Metadaten. Saubere descriptions und Parameter‑Docs erhöhen den Recall – den Anteil der Situationen, in denen das Modell Ihre App überhaupt in Betracht zieht – und reduzieren Fehlaufrufe.

Mini‑Beispiel: alter vs. neuer Description für GiftGenius

Nehmen wir an, bisher stand dort so etwas wie:

export const appDescription = `
GiftGenius — Helfer für die Suche und den Kauf von Geschenken.
`;

Aus Sicht eines Menschen ist das nicht schlecht, für Routing in einer Multi‑App‑Welt ist es jedoch besser, zu betonen, wann die App zu verwenden ist und was sie nicht tut:

export const appDescription = `
GiftGenius — Assistent für Geschenkideen.
Verwende diese App, wenn der Nutzer um eine Geschenkidee
für eine konkrete Person oder einen Anlass bittet und ein Budget einhalten möchte.
Verwende sie nicht für allgemeines Online‑Shopping oder die Planung persönlicher Finanzen.
`;

Jetzt kann das Modell GiftGenius leichter von einer allgemeinen E‑Commerce‑App oder einem Finanzberater unterscheiden.

4. _meta["openai/widgetDescription"]: wir erklären dem Modell unser UI

In der Tabelle oben haben wir _meta["openai/widgetDescription"] separat erwähnt. Konzentrieren wir uns nun auf diese Ebene: Sie hilft dem Modell, sich Ihr Widget „vorzustellen“ und zu verstehen, welche Teile der Antwort bereits durch das UI abgedeckt sind und was textlich ausgeführt werden sollte.

Angenommen, unser zentrales Tool suggest_gifts liefert eine Liste von Geschenken, und das Widget rendert sie als horizontale Karten‑Karussell. In der Tool‑Beschreibung haben wir bereits erklärt, wann es zu verwenden ist, und in der widgetDescription erklären wir, wie das Ergebnis aussieht.

Beispielfragment eines Tool‑Descriptors (vereinfacht, angelehnt an die Empfehlungen):

const suggestGiftsTool = {
  name: "suggest_gifts",
  description: "Use this to generate gift ideas within user's budget.",
  inputSchema: { /* ... */ },
  _meta: {
    "openai/widgetDescription":
      "Zeigt eine horizontale Liste von Geschenk-Karten mit Preis und dem Button 'Kaufen'. Wiederhole die Geschenk-Namen nicht im Text der Antwort."
  }
};

Damit erreichen wir gleich mehrere Ziele:

• Das Modell weiß, dass das UI bereits Namen und Preise zeigt – in der Textantwort kann es sich also auf Erklärungen und Ratschläge konzentrieren, statt die Liste zu duplizieren.
• Andere Apps (über das Modell) verstehen, dass toolOutput nicht nur ein Absatz Text ist, sondern eine strukturierte Liste, die sie in ihrem Kontext „aufgreifen“ können.

Und ja, Hand aufs Herz: Solche Beschreibungen zu schreiben ist langweiliger als zu coden, aber genau sie sparen Ihnen später Stunden beim Debuggen merkwürdigen Modellverhaltens.

5. Tool‑Annotationen: readOnlyHint, destructiveHint, openWorldHint

In der Multi‑App‑Welt ist nicht nur „wann aufrufen“ wichtig, sondern auch wie sicher der Aufruf eines konkreten Tools ist. Dafür führt das Apps SDK einen Satz von Annotationen in Tool‑Deskriptoren ein.

Die Idee: Annotationen sind weiche Hinweise für das Modell auf den Charakter der Operation. Sie ersetzen keine Server‑Autorisierung, beeinflussen aber deutlich, wie ChatGPT sich in Ketten verhält.

Kurze Zusammenfassung (konzeptionell):

readOnlyHint

destructiveHint / isConsequential

openWorldHint

Annotationen (readOnlyHint, destructiveHint, openWorldHint) sind Teil der standardmäßigen Tool‑Beschreibung und können nicht nur von ChatGPT genutzt werden. Das Feld _meta["openai/isConsequential"] ist ein engerer, ChatGPT‑spezifischer Hinweis, der dem Modell zusätzlich hilft, „sichere“ und „konsequente“ Aufrufe zu unterscheiden.

Schauen wir uns zwei Tools von GiftGenius an:

• suggest_gifts – Katalog lesen, sicher.
• create_checkout_session – Checkout erstellen, eine Aktion mit Side‑Effects.

Beispiel für die Beschreibung des Tools suggest_gifts

const suggestGiftsTool = {
  name: "suggest_gifts",
  description:
    "Use this when the user asks for gift ideas for a person or occasion.",
  inputSchema: { /* ... */ },
  annotations: {
    readOnlyHint: true
  },
  _meta: {
    "openai/widgetDescription": "Geschenk-Karussell mit Preis und Link.",
    "openai/isConsequential": false
  }
};

Ein solches Tool kann das Modell mehrfach hintereinander aufrufen, auch „präventiv“, um im Voraus Varianten vorzubereiten, ohne den Nutzer zu jeder Aktion zu befragen.

Beispiel für die Beschreibung des Tools create_checkout_session

const createCheckoutTool = {
  name: "create_checkout_session",
  description:
    "Finalize purchase of selected gifts via Instant Checkout.",
  inputSchema: { /* ... */ },
  annotations: {
    destructiveHint: true
  },
  _meta: {
    "openai/isConsequential": true
  }
};

Hier signalisieren wir explizit: Das ist eine Write‑Operation mit Konsequenzen (Geld wird abgebucht, Bestellung erstellt). Das Modell soll vor dem Aufruf die Bestätigung des Nutzers einholen – besonders in langen Ketten mit mehreren Apps.

Überschätzen Sie die Magie nicht: Selbst mit destructiveHint müssen Sie serverseitig Eingabedaten, Tokens und Rechte prüfen, wie wir es in den Modulen zu Sicherheit und Autorisierung besprochen haben. Für Multi‑App‑Orchestrierung helfen Annotationen dem Modell jedoch, solche Tools nicht „unnötig abzufeuern“.

6. Isolierte App vs. Ökosystem: die Grenzen von GiftGenius schärfen

Als GiftGenius die einzige App im Chat war, konnte der Scope recht breit sein: Geschenk‑Auswahl, Tipps zur Verpackung, Erinnerungen an Feiertage, sogar kurze Glückwunschtexte. Das Modell ruft ohnehin nur Ihre Tools auf.

In einem Multi‑App‑Szenario beginnt ein „ich kann alles“‑Ansatz zu schaden:

• Der Router unterscheidet schlechter, wann Sie der ideale Kandidat sind und wann besser eine andere App genutzt wird;
• Sie überschneiden sich mit Kalender, allgemeinem Task‑Manager, Finanz‑Planer etc.;
• Bei gemeinsamer Nutzung mehrerer Apps kann das Modell den „falschen“ Ausführer wählen und Tools verwechseln.

Der bessere Ansatz – die Verantwortungszone klar abgrenzen:

• GiftGenius: nur Geschenkideen + Hilfe beim Kauf über ACP/Checkout;
• CalendarApp: Ereignisse und Erinnerungen;
• Finance‑App: Nutzerbudget insgesamt, persönlicher Finanzplan.

In App‑ und Tool‑Beschreibungen ist es hilfreich, nicht nur „Use this when…“, sondern auch „Do not use when…“ explizit zu schreiben. Genau das empfiehlt das offizielle Discovery‑Playbook.

Mini‑Beispiel einer Tool‑Beschreibung:

description: `
Use this tool when the user explicitly asks for gift suggestions.
Do not use for generic product discovery or price comparison.
`

Solche Einschränkungen helfen nicht nur beim Routing, sondern machen das Verhalten Ihrer App für Produkt und QA vorhersagbarer.

7. Muster der App‑Komposition: pipeline, handoff, shared context

In Multi‑App‑Szenarien tauchen in der Praxis drei verbundene Ideen auf:

• pipeline – mehrere Apps arbeiten nacheinander (Kalender → Geschenke → Commerce), jede erledigt ihren Schritt;
• handoff – die Ausgabe einer App wird zum Eingang der nächsten;
• shared context – die Übergabe erfolgt über den gemeinsamen Textkontext des Chats, ohne direkte HTTP‑Aufrufe zwischen Anwendungen.

Wie bereits angedeutet, ist ein Multi‑App‑Szenario keine Magie à la „App A ruft App B via HTTP auf“. In der aktuellen Umsetzung von ChatGPT Apps ist die Isolation recht streng: Anwendungen rufen einander nicht direkt auf, die Kommunikation läuft über den gemeinsamen Textkontext.

Das grundlegende Muster lässt sich so formulieren:

1. App A gibt Text oder JSON in den Chat zurück (oft innerhalb von structuredContent/Widget).
2. Das Modell liest diese Ausgabe.
3. Im nächsten Zug kann es App B aufrufen und Details aus der Antwort von A in die Argumente ihrer Tools einsetzen.

Das nennt man text/context handoff: „Ausgabe von App A → Modell → Eingang App B“.

Beispiel: CalendarApp + GiftGenius + CommerceApp

Schauen wir uns ein konkretes Szenario an.

Nutzer: „Mein Chef hat morgen Geburtstag, schlage ein Geschenk vor und schließe den Kauf gleich ab.“

Schritt für Schritt:

1. Das Modell versteht, dass zuerst Datum und Person zu klären sind. Es ruft das Tool der Kalender‑App auf, etwa corporate_calendar.list_upcoming_birthdays, und erhält eine Struktur:

   [
     { "name": "Aleksey Bykov", "date": "2025-11-22", "relation": "manager" }
   ]
   

2. Danach entscheidet das Modell, GiftGenius zu rufen. Es ruft Ihr suggest_gifts mit Argumenten auf, die aus dem Kalender stammen:

   {
     "recipientName": "Aleksey",
     "occasion": "birthday",
     "budget": 150,
     "relationship": "manager"
   }
   

   Das GiftGenius‑Widget zeigt ein Geschenk‑Karussell, und die Textantwort erklärt, warum diese Ideen passend sind.

3. Der Nutzer wählt ein bis zwei Varianten aus (per Button im Widget → widgetState), und das Modell ruft anschließend das Tool der Commerce‑App auf, z. B. corp_checkout.create_gift_order, mit den IDs der ausgewählten SKUs und der Lieferadresse.

Aus Sicht von ChatGPT sind das drei verschiedene Anwendungen, für den Nutzer jedoch ein einziges Gespräch. Der Schlüssel, damit das funktioniert:

• klare descriptions der Tools jeder App;
• saubere Namen (corporate_calendar.list_upcoming_birthdays statt schlicht list_events);
• ein abgestimmtes Format strukturierter Daten (sodass eine Geschenkidee so beschrieben ist, dass die Commerce‑App sie verstehen kann).

Visuelles Schema

Man kann diese Pipeline so darstellen:

sequenceDiagram
    participant U as Benutzer
    participant C as ChatGPT (Router)
    participant Cal as CalendarApp
    participant G as GiftGenius
    participant Com as CommerceApp

    U->>C: Mein Chef hat morgen Geburtstag, such etwas aus und kaufe es
    C->>Cal: tools.call(list_upcoming_birthdays)
    Cal-->>C: [{ name, date, relation }]
    C->>G: tools.call(suggest_gifts, { recipient, occasion, budget })
    G-->>C: gift suggestions (+ widget)
    C-->>U: Erläuterungen + GiftGenius-Widget
    U->>C: Variante #2 gefällt mir, kaufe sie
    C->>Com: tools.call(create_gift_order, { skuId, address })
    Com-->>C: Order confirmation
    C-->>U: Fertig, Bestellung abgeschlossen

Ihre Aufgabe als Entwickler von GiftGenius ist es, dafür zu sorgen, dass Ihre Stimme in diesem Chor klar und zweckmäßig klingt und andere nicht stört.

8. Interoperabilität: Antworten für andere Apps brauchbar machen

In der Multi‑App‑Welt reicht es nicht, „nur schön dem Nutzer zu antworten“. Idealerweise sollte Ihr toolOutput auch maschinenlesbar für andere Anwendungen sein: Commerce‑App, Analyse‑Agent, Workflow‑Orchestrator usw.

Das bedeutet praktisch:

• strukturierte JSON‑Antworten der Tools statt serialisierten „menschenlesbaren“ Fließtext;
• möglichst stabile, verständliche Felder.

Man kann z. B. das Ergebnis von suggest_gifts so typisieren:

export type GiftSuggestion = {
  id: string;
  title: string;
  description: string;
  price: number;
  currency: string;
  forPerson: string;
  occasion: string;
  purchaseUrl: string;
};

Und in der Tool‑Antwort ein Array solcher Objekte zurückgeben:

{
  "gifts": [
    {
      "id": "sku_123",
      "title": "Tisch-Planetarium",
      "description": "Mini-Projektor des Sternenhimmels...",
      "price": 89.99,
      "currency": "USD",
      "forPerson": "Aleksey",
      "occasion": "birthday",
      "purchaseUrl": "https://shop.example.com/sku_123"
    }
  ]
}

Das GiftGenius‑Widget nimmt dies als Props und rendert schöne Karten, und die Commerce‑App kann, wenn sie dieses JSON im Kontext sieht, id und purchaseUrl für den weiteren Checkout übernehmen.

Die Praxis von Multi‑App‑Szenarien zeigt: Eine gute App liefert Daten so, dass sie eine andere App „verdauen“ kann – nicht nur die Augen eines Menschen.

9. Praktisches Refactoring von GiftGenius für Multi‑App

Fassen wir alles in ein paar konkrete Änderungen an unserer Übungs‑App zusammen.

Manifest‑Description präzisieren

Stellen wir uns vor, wir haben eine openai-app.json (oder das Äquivalent im Next.js‑Template) mit folgender Beschreibung:

{
  "name": "GiftGenius",
  "description": "Gift assistant for finding and buying presents."
}

Machen wir sie für Routing expliziter:

{
  "name": "GiftGenius",
  "description": "Assistant for gift ideas and purchase flows. Use this app when the user asks what to gift a specific person or for a specific occasion within a budget. Do not use for generic online shopping or personal finance planning."
}

Jetzt ist bereits aus dem Text ersichtlich, dass es sich nicht um allgemeines Shopping, keinen Finanzberater und keinen Kalender handelt.

Descriptions der Tools umschreiben

Tool für die Geschenk‑Suche:

const suggestGiftsTool = {
  name: "giftgenius_suggest_gifts",
  description: `
Use this when the user asks for gift ideas for a specific person or group,
optionally with a budget or occasion.
Do not use for non-gift product recommendations or travel booking.
`
};

Tool, das SKU‑Details aus Ihrem Katalog nachlädt (read‑only):

const getGiftDetailsTool = {
  name: "giftgenius_get_gift_details",
  description: `
Use this to fetch more details for a gift suggested earlier by GiftGenius,
for example when the user asks “tell me more about option #2”.
`,
  annotations: { readOnlyHint: true }
};

Das Einkaufs‑Tool – mit destructiveHint, wie bereits gezeigt.

_meta["openai/widgetDescription"] aktualisieren

Angenommen, unser Widget enthält bereits Karten mit dem CTA „Kaufen“. Geben wir das dem Modell mit:

const giftWidgetMeta = {
  _meta: {
    "openai/widgetDescription": `
Zeigt eine Liste von Geschenk-Karten mit Beschreibung, Preis und dem Button 'Kaufen'.
Das Modell soll die vollständige Liste nicht im Text wiederholen, sondern die Auswahl kommentieren und bei der Entscheidung helfen.
`
  }
};

Dann wird das Modell seltener zehn Geschenke als Text im Chat ausschreiben, wenn sie ohnehin im Widget sichtbar sind, und sich auf Erklärungen und Logik konzentrieren – gut für UX und Token‑Kosten.

10. Multi‑App‑Denken für Ihr zukünftiges Produkt

Wichtig ist der mentale Wechsel vom Modus „Wie besiege ich alle Konkurrenten und werde die einzige App des Nutzers?“ in den Modus „Wie mache ich meine App zum idealen Modul in einem großen Ökosystem“.

Dieser Ansatz bringt mehrere praktische Vorteile:

• Sie können dem Nutzer und den Store‑Reviewern leichter erklären, wofür Ihre App da ist und wann sie passend ist;
• dem Modell fällt die Routing‑Entscheidung leichter: weniger Verwirrung, weniger „falsche“ Aufrufe;
• Sie können Kompositionen gezielt entwerfen: heute mit Kalender und Commerce, morgen mit einem HR‑Bot oder einer internen CRM.

Die offiziellen Discovery‑Guides betonen: Entwerfen Sie „one job per tool“, und betrachten Sie Metadaten als lebendiges Artefakt, das getestet und aktualisiert werden muss – nicht als statischen Text aus dem ersten Commit.

Dabei hilft sehr, was Sie bereits in den vorigen Themen des Moduls 20 getan haben: Golden‑Cases, LLM‑Evals, CI‑Runs. Sie können den Fall‑Satz um Szenarien „im Chat sind GiftGenius und CalendarApp“ erweitern und verfolgen, wie Änderungen in Beschreibungen die App‑Auswahl und die Antwortqualität beeinflussen.

11. Typische Fehler bei Multi‑App und Komposition

Fehler №1: App‑Beschreibung „Ich kann alles“.
Wenn Sie in der Manifest‑Description etwas wie „smarter Assistent für alle Aufgaben“ schreiben, konkurrieren Sie nicht nur mit anderen Apps, sondern auch mit dem Basis‑ChatGPT. Dem Router fällt es schwer zu verstehen, wann er genau Sie rufen soll und wann die eingebauten Möglichkeiten ausreichen. In der Multi‑App‑Welt gewinnen Anwendungen mit klarer, enger Bestimmung: „Geschenk‑Auswahl“, „Kalender‑Verwaltung“, „Log‑Analyse“.

Fehler №2: verwaschene Tool‑Descriptions und Namenskollisionen.
Tools mit Namen wie get_data, process_request und der Erklärung „verarbeitet Nutzerdaten“ eignen sich hervorragend, um das Modell zu verwirren. In einer Welt mehrerer Apps gerät man leicht in die Lage, dass Ihr Tool dort aufgerufen wird, wo es um eine völlig andere Domäne geht. Der richtige Weg – Domäne und Aktion verbinden (giftgenius_get_gift_catalog, calendar.list_birthdays) und „Use this when… / Do not use when…“ explizit beschreiben.

Fehler №3: Ignorieren von _meta["openai/widgetDescription"].
Entwickler füllen oft nur die description aus und denken bei _meta höchstens an die Lokalisierung. Dadurch versteht das Modell nicht, was das Widget zeigt, und beginnt entweder, das UI textlich zu duplizieren, oder verspricht dem Nutzer „eine Preistabelle“, die Ihr Widget gar nicht hat. Ein paar Zeilen in widgetDescription ersparen viele Missverständnisse.

Fehler №4: fehlende Annotationen readOnlyHint/destructiveHint.
Wenn all Ihre Tools gleich „neutral“ wirken, unterscheidet das Modell nicht, welche davon man häufig und sicher aufrufen kann und welche eine Nutzerbestätigung erfordern. In mehrstufigen Szenarien mit mehreren Apps ist das besonders kritisch: Man kann versehentlich mehrere Write‑Operationen nacheinander ausführen – ohne explizite Beteiligung des Menschen. Vergessen Sie nicht, Read‑Only‑Tools zu kennzeichnen und konsequente/destruktive Aktionen deutlich hervorzuheben.

Fehler №5: Antworten, die nur für Menschen, nicht für andere Apps gedacht sind.
Aus einem Tool einfach „eine Liste von Geschenken“ als eine Textzeile zurückzugeben, ist verlockend, aber dann fällt es jeder anderen App schwerer, dieses Ergebnis zu nutzen. Strukturierte JSON‑Daten mit klaren Feldern (id, price, currency, purchaseUrl, occasion) bringen Vorteile für UI und Komposition: Das Modell kann diese Daten in Argumente anderer Tools einsetzen, ohne natürliche Sprache zu parsen.

Fehler №6: Der Versuch, innerhalb einer App alles zu implementieren, was der Nutzer eventuell brauchen könnte.
Manchmal ist die Versuchung groß: „Wenn ich GiftGenius schon gebaut habe, soll es auch den Kalender führen, E‑Mails an Kollegen verschicken und das Budget planen.“ In einer isolierten Welt ist das noch erträglich, im Multi‑App‑Kontext werden Sie zum Alleskönner, der mit anderen scharf fokussierten Apps kollidiert. Besser ist der Vertrag mit sich selbst: Meine App macht X – und das perfekt; der Rest ist fremde Verantwortung. Ein solcher Entwurf vereinfacht UX und die Entwicklung des Ökosystems erheblich.

Fehler №7: Kein Testen des Verhaltens im Umfeld anderer Apps.
Entwickler testen ihre Anwendung häufig im Dev Mode in einem „leeren“ Chat ohne andere Apps. Im Store hingegen kann der Nutzer leicht ein Dutzend verbundene Anwendungen haben, von denen sich einige konzeptionell mit Ihrer überschneiden. Legen Sie einen Testszenario‑Satz an, in dem benachbarte Apps (Kalender, allgemeines Shopping, Finanzen) im Chat vorhanden sind, und führen Sie Golden‑Cases durch: Wählt das Modell GiftGenius bei Geschenk‑Anfragen korrekt und verwechselt es ihn nicht mit anderen Teilnehmern?

1

Umfrage/Quiz

LLM-Apps: die neue Generation, Level 20, Lektion 4

Nicht verfügbar

LLM-Apps: die neue Generation

LLM-Apps: die neue Generation

Öffnen