Eine App mit KI zu bauen hat die Notwendigkeit beseitigt, Code Zeile für Zeile zu schreiben, nicht aber die Notwendigkeit, klar zu denken. Der Flaschenhals hat sich verschoben: Statt Syntax zu tippen, schreibst du ein Briefing. Ein vager Prompt erzeugt eine vage App (generische Screens, erfundene Funktionen, fehlende Randfälle). Ein präziser kommt schon beim ersten Versuch erstaunlich nah ran. Dieser Leitfaden zeigt, wie man Prompts schreibt, um eine App zu bauen: eine wiederverwendbare Anatomie, schlechte vs. gute Beispiele und ein Iterationsrhythmus, der nicht kaputtmacht, was schon funktioniert.
Dieselben Prinzipien finden sich in der offiziellen Modell-Dokumentation. OpenAIs Prompt-Engineering-Guide betont klare Anweisungen und iteratives Testen. Für AI-App-Builder heißt das: Ergebnisse beschreiben, die Nutzer sehen können, nicht React-Muster, die das Modell für dich erfinden soll.
Die 7-teilige Anatomie eines guten App-Prompts
Behandle deinen ersten Prompt wie ein Briefing für einen freiberuflichen Entwickler, der dich nie getroffen hat und vor dem Start keine Rückfragen stellen kann. Je mehr der folgenden Punkte er von allein beantwortet, desto weniger muss die KI raten, und desto weniger korrigierst du später.
- Kontext, wer und was: für wen die App ist und welches Problem sie löst, in ein bis zwei Sätzen.
- Ziel: die eine Hauptsache, die jemand erledigen muss, eine Dienstleistung verkaufen, Projekte verfolgen, eine Warteliste verwalten.
- Nutzer: Einzelperson, kleines internes Team, externe Kunden oder mehrere Rollen mit unterschiedlichem Zugriff.
- Wichtigste Screens: die vier bis sechs Seiten, die am meisten zählen, explizit benannt, Dashboard, Kundenliste, Rechnungsdetail, Einstellungen.
- Datenentitäten: die Substantive deiner App und wie sie zusammenhängen, ein Kunde hat viele Projekte; ein Projekt hat viele Rechnungen.
- Rahmenbedingungen: Nichtverhandelbares, Login erforderlich, Zahlungen, Mobile-First, eine bestimmte Integration.
- Ton und Marke: Farben, Stilreferenzen, formell vs. verspielt, „minimal wie Stripe“ schlägt „mach es modern“.
Schlechter Prompt vs. guter Prompt
Der Abstand zwischen einer mittelmäßigen App und einer nützlichen liegt selten am Modell. Fast immer liegt er am Prompt. Hier dieselbe Idee, zweimal geschrieben.
Schlecht
"Bau mir eine App, um meine Kunden zu verwalten."
Gut
"Ich leite eine kleine Design-Agentur mit zwei weiteren Freelancern. Bau ein Kundenportal, in dem wir Kunden, Projekte pro Kunde und Rechnungen pro Projekt sehen. Ich brauche ein Dashboard der aktiven Projekte, eine Kundenliste mit Kontakten und eine Projektseite mit Aufgaben und Rechnungsstatus (Entwurf, versendet, bezahlt). Kunden loggen sich ein und sehen nur ihre eigenen Daten. Klares, minimalistisches UI in Blau und Weiß."
Die schlechte Version zwingt die KI, Kontext, Screens, Daten und Zugriffsregeln zu erfinden. Die gute liefert Agentur-Kontext, das Ziel, Entitäten und Beziehungen (Kunde → Projekt → Rechnung), benannte Screens, eine harte Rahmenbedingung (rollenbasierter Zugriff) und einen visuellen Ton. Fast nichts bleibt dem Raten überlassen.
Merke
Wenn ein Kollege mit kaum Kontext aus deinem Prompt nicht wüsste, was zu bauen ist, weiß es das Modell auch nicht. Anthropics Prompting-Leitfaden nutzt denselben Test: Klarheit für eine scharfe Neueinstellung ist Klarheit für die KI.
Zum zugrunde liegenden Prinzip, explizit sein, Kontext geben, vage Adjektive vermeiden, siehe Anthropics Claude-Prompting-Best-Practices.
Fang breit an, dann verfeinere Screen für Screen
Jedes Feld und jede Regel in einen riesigen Prompt zu packen geht meist schief: Das Modell jongliert zu viel und lässt die Hälfte fallen. Ein besserer Rhythmus entspricht dem, wie echte Produkte entstehen, zuerst das Gerüst, dann die Tiefe. So bleibt auch Vibe Coding produktiv: zuerst die Absicht, dann enge Feedback-Schleifen.
- Erster Prompt: Zweck, Nutzer und die Handvoll Screens, damit die KI das Gesamtgerüst bauen kann.
- Zweite Runde: einen Screen wählen, „In der Kundenliste Suche und einen Statusfilter hinzufügen.“
- Dritte Runde: erst zum nächsten Screen, wenn der vorherige stimmt.
- Feinschliff: Texte, Abstände, Leerzustände und Randfälle, sobald die Struktur hält.
App-Builder-Guides wie Knacks AI-Prompt-Patterns machen denselben Punkt: mit wenigen Entitäten und klaren Beziehungen starten, dann erweitern. Widerstehe dem Drang, das gesamte Produkt in Nachricht eins zu spezifizieren.
Neu prompten vs. Mikro-Patches
Nicht jede Anfrage verdient dieselbe Formulierung. Strukturelle Änderungen brauchen einen volleren Prompt, der den Kontext für diesen App-Teil neu setzt. Winzige Tweaks funktionieren besser als kurze, chirurgische Nachrichten.
| Situation | Nutzen | Beispiel-Formulierung |
|---|---|---|
| Neue Entität, neue Rolle oder umgebaute Navigation | Neu prompten | "Rechnungen hinzufügen, die an jedes Projekt gebunden sind. Status: Entwurf, versendet, bezahlt. Auf der Projektseite anzeigen." |
| Label, Farbe, Sortierung, einzelnes Feld | Mikro-Patch | "Auf der Rechnungsdetailseite das Badge Bezahlt grün machen." |
| KI hat einen Screen vermasselt | Diesen Screen neu prompten | Nochmal sagen, was der Screen tun muss; nennen, was anderswo unverändert bleiben soll. |
Auch bei Mikro-Patches: Screen und Element benennen. „Mach es schöner“ ist kein Prompt, es ist eine Hoffnung.
Fehler, die deine Prompts sabotieren
- Zu vage sein. „Modern und professionell“ ist nicht umsetzbar. Nenne eine Referenz, eine Farbe oder ein Layout.
- Zu viele Features auf einmal verlangen. Auth + Zahlungen + Dashboard + Benachrichtigungen in einer Nachricht zwingt zu dünner Aufmerksamkeit überall.
- Implementierung statt Ergebnis beschreiben. Lass „nutze einen useEffect und einen Reducer“ weg. Sag, was der Nutzer sehen und tun soll.
- Randfälle vergessen. Leere Listen, fehlgeschlagene Zahlungen, ein Kunde ohne Projekte, früh benennen.
Tipps, die mit jedem AI-App-Builder funktionieren
- Den Screen benennen. „Auf dem Dashboard…“ beseitigt Unklarheit darüber, wo eine Änderung greift.
- Echte Beispiele geben. Echte Plannamen und Preise einfügen statt „eine Preistabelle hinzufügen“.
- Jeweils nur eine Sache ändern. Eine klare Absicht pro Nachricht macht sichtbar, was funktioniert hat.
- Sagen, was gleich bleiben muss. Beim Verfeinern eines Screens den Rest der App ausdrücklich schützen.
- Früh mit realitätsnahen Daten testen. Drei Beispielzeilen können Layout-Brüche verbergen, die bei fünfzig sichtbar werden.
Sobald das Prompten sitzt, zählt die Tool-Wahl für Ownership und sicheres Iterieren, starte mit unserem Vergleich der besten AI-App-Builder.
Dieselbe Anatomie für Sites, Web-Apps und Mobile
Das Framework ändert sich nicht nach Produkttyp, nur die Gewichtung.
| Produkt | Im Prompt betonen |
|---|---|
| Showcase-Site | Ton, Marke und Abschnitts-Texte (Hero, Leistungen, Social Proof, Kontakt). |
| Web-App / MVP | Entitäten, Beziehungen, Rollen und den Kern-Job-to-be-done. |
| Mobile App | Navigationsmuster, daumenfreundliche Aktionen, Offline-Bedarf, Layout für kleine Screens. |
Für den Mobile-Pfad siehe wie man eine Mobile App erstellt. Um eine Produktidee mit derselben Prompt-Disziplin zu validieren, kombiniere diesen Leitfaden mit wie man ein Startup-MVP baut.
Den Rahmen in die Praxis umsetzen
Anatomie, Iterationsrhythmus und Re-Prompting-Gewohnheiten aus diesem Leitfaden gelten für jeden KI-App-Builder. Starten Sie mit einem breiten Brief zu Zweck, Nutzern und wichtigen Screens; verfeinern Sie Screen für Screen; unterscheiden Sie strukturelle Änderungen von Mikro-Anpassungen.
Goldene Regel
Ein Prompt = eine Änderung. Kurze, fokussierte Nachrichten schlagen lange Anfragen, die die Hälfte des Produkts auf einmal umbauen wollen.
Bevor Sie generieren, prüfen Sie Ihren Prompt mit demselben Test wie für einen neuen, kompetenten Mitarbeiter: Könnte jemand mit fast keinem Kontext allein aus diesem Brief die richtige erste Version liefern? Wenn ja, sind Sie bereit, Screen für Screen zu iterieren, bis jeder Screen dem entspricht, was Sie im Kopf hatten.