Prompts für KI-App-Builder schreiben: Mit Vorher-Nachher-Beispielen

Sehen Sie zwei Personen zu, die denselben KI-App-Builder eine Stunde lang benutzen. Eine hat eine funktionierende App; die andere hat ein Chaos und die Meinung, „KI-Coding ist überbewertet". Das Tool war identisch. Die Prompts waren es nicht.

Einen App-Builder zu prompten ist eine andere Fähigkeit als einen Chatbot zu prompten. Sie stellen keine Fragen — Sie erteilen Arbeitsaufträge an einen Agenten, der Dutzende Entscheidungen auf Basis dessen trifft, was Sie gesagt und nicht gesagt haben. Hier ist, was wirklich funktioniert — mit Vorher-Nachher-Beispielen durchgehend.

Der erste Prompt: Entscheidungen vorn bündeln, Implementierung weglassen

Ihr Eröffnungs-Prompt legt das Fundament des Projekts. Der Agent füllt jede Lücke, die Sie lassen, mit einer Vermutung — und auch wenn gute Agenten vernünftig raten, ist jede Vermutung ein Münzwurf darauf, ob sie Ihre Absicht trifft.

Vorher:

Mach mir eine Fitness-App.

Nachher:

Baue einen Workout-Tracker für Kraftsportler. Daten: Workouts haben ein Datum; jedes Workout hat Einträge mit Übungsname, Sätzen, Wiederholungen und Gewicht. Screens: (1) das heutige Protokoll mit Schnellerfassung, (2) Verlauf nach Wochen gruppiert, (3) ein Fortschrittsdiagramm pro Übung. Ein Nutzer, kein Login nötig. Dunkles, minimalistisches Design.

Die „Nachher"-Version entscheidet Zielgruppe, Datenmodell, Screens, Auth-Umfang und visuelle Richtung — die fünf Entscheidungen, die später teuer zu ändern sind. Beachten Sie, was sie nicht enthält: keinen Tech-Stack, keine Datenbankwahl, keine Komponentenbibliotheken. Eine gute Plattform trifft diese Entscheidungen besser, als ein Prompt es kann, und das Briefing mit halbverstandenen Fachbegriffen vollzustopfen schadet aktiv („nimm MongoDB", wenn die Plattform um Postgres herum gebaut ist, erzeugt nur Reibung).

Eine Struktur, die konsistent funktioniert:

1. Was es ist, in einem Satz, mit der Zielgruppe.
2. Die Daten, als schlichte Substantive und Felder.
3. Die Screens, durchnummeriert.
4. Explizite Ausschlüsse — „kein Login", „keine Zahlungen". Ausschlüsse verhindern Umfang, den der Agent sonst hilfsbereit erfinden würde.

Iterations-Prompts: eine Änderung, an einem Ort verankert

Nach dem ersten Build ändern Ihre Prompts den Charakter: von Architektur zu Chirurgie. Zwei Regeln leisten den Großteil der Arbeit.

Eine Änderung pro Nachricht. Gebündelte Anfragen scheitern als Einheit — wenn eine von fünf Änderungen danebengeht, müssen Sie um die anderen vier herum nachbessern.

Verankern Sie jede Änderung an einem Ort.

Vorher:

Die Daten sehen falsch aus.

Nachher:

Auf der Verlaufsseite zeigen die Wochen-Überschriften „Woche 32". Zeige stattdessen einen Datumsbereich, etwa „4. Aug. – 10. Aug.".

Benennen Sie den Screen, zitieren Sie den falschen Text, beschreiben Sie den richtigen. Der Agent findet die exakte Stelle, statt zu suchen — weniger Fehlgriffe, weniger Credits.

Ergebnisse beschreiben, nicht Implementierungen

Sie werden versucht sein, wie ein Entwickler zu reden. Widerstehen Sie — es sei denn, Sie sind einer.

Vorher:

Füge ein useEffect hinzu, das beim Mount neu lädt, und memoisiere das Listen-Rendering.

Nachher:

Wenn ich nach dem Hinzufügen einer Ausgabe zum Dashboard zurückkomme, zeigt die Summe noch die alte Zahl, bis ich neu lade. Sie sollte aktuell sein.

Die erste Version legt den Agenten auf Ihre Diagnose fest, die falsch sein kann. Die zweite gibt ihm den tatsächlichen Defekt — das, dessen Sie sich sicher sind — und lässt ihn die Ursache finden. Beschreiben Sie Symptome mit der Gewissheit eines Nutzers; überlassen Sie Diagnosen dem, was den Code lesen kann.

Nutzen Sie Referenzen — sie schlagen Adjektive

„Modern und clean" bedeutet nichts; jedes Design seit 2010 behauptet das von sich. Referenzen transportieren um Größenordnungen mehr Information:

Lass die Preissektion wie Linears Preisseite wirken: viel Weißraum, dünne Rahmen, eine Akzentfarbe.

Noch besser: Hängen Sie einen Screenshot an — von einer App, die Ihnen gefällt, von einer Handskizze, vom konkreten kaputten Layout, das Sie beschreiben. Plattformen, die Bildanhänge akzeptieren (Massvai tut das), lösen visuelle Mehrdeutigkeit aus einem Bild weit schneller auf als aus Prosa. Ein Screenshot des Bugs mit einer einzeiligen Bildunterschrift ist das wertvollste Prompt-Format, das es gibt.

Wenn es schiefgeht: Hören Sie auf zu graben

Der teuerste Prompting-Fehler ist kein schlechter Prompt — es ist der vierte Versuch in Folge, eine Richtung zu flicken, die grundsätzlich falsch ist.

Wenn zwei Anläufe für denselben Fix nicht funktioniert haben, wechseln Sie die Strategie:

• Rollen Sie zurück. Stellen Sie den Checkpoint vor dem Schlamassel wieder her (Massvai sichert jede Generierung) und nähern Sie sich mit einer anderen Beschreibung neu an. Rückwärtsgehen fühlt sich wie ein Verlust an; meist ist es der schnellste Weg nach vorn.
• Zoomen Sie heraus. Statt den Fix neu zu beschreiben, beschreiben Sie das Ziel: „Vergiss die bisherigen Anweisungen zum Filter-Dropdown. Das will ich Nutzern ermöglichen: …" Agenten kommen mit frischen Zielen besser zurecht als mit angehäuften Flick-Anweisungen.

Ein Spickzettel

Nichts davon ist exotisch. Es ist dieselbe Klarheit, die Sie einem menschlichen Auftragnehmer schulden würden — nur dass dieser Auftragnehmer sorgfältig liest, sich nie über Details ärgert und in Sekunden mit der Arbeit beginnt. Geben Sie ihm ein Briefing, das dessen würdig ist.