So schreiben Sie Prompts für KI-App-Builder (mit Vorher-Nachher-Beispielen)

Ein guter Prompt für einen KI-App-Builder beschreibt das Produkt, nicht den Code: wer es nutzt, was die Nutzer Schritt für Schritt tun, welche Daten gespeichert werden und wer was sehen darf. Nachdem die erste Version existiert, bitten Sie pro Nachricht um eine konkrete Änderung, sagen, was gleich bleiben muss, und beschreiben Probleme als „Ich habe X gemacht, erwartet hatte ich Y, bekommen habe ich Z“. Diese drei Gewohnheiten beheben die meisten enttäuschenden Ergebnisse.

Der Rest dieses Leitfadens zeigt die Muster im Detail, mit Vorher-Nachher-Beispielen, die Sie anpassen können.

Warum das Prompten eines App-Builders anders ist als ein Chat mit einer KI

Wenn Sie einen Chat-Assistenten etwas fragen, bekommen Sie bei einem vagen Prompt eine vage Antwort, und Sie machen weiter. Wenn Sie einen KI-App-Builder prompten, ist die Antwort ein laufendes Programm. Jede Lücke in Ihrer Beschreibung wird mit einer Vermutung gefüllt, und diese Vermutungen werden zu Code, Datenbanktabellen und Bildschirmen, mit denen Sie dann leben oder die Sie rückgängig machen müssen.

Das Ziel eines Prompts ist deshalb nicht, klug zu klingen. Es geht darum, weniger wichtige Entscheidungen dem Zufall zu überlassen. Dafür brauchen Sie keine Fachsprache. Sie müssen nur konkret sein bei den Dingen, die nur Sie wissen: Ihre Nutzer, Ihr Ablauf und Ihre Regeln.

Was in einen ersten Prompt gehört

Beantworten Sie diese Fragen, bevor Sie etwas schreiben. Jede schließt eine Lücke, die die KI sonst raten würde.

Angeben	Warum es wichtig ist	Beispiel
Das Produkt in einem Satz	Gibt den Rahmen für alle späteren Entscheidungen vor	„Eine Buchungsseite für einen Friseursalon mit zwei Plätzen“
Wer es nutzt	Bestimmt die Bildschirme und den Ton	„Laufkundschaft am Handy, und der Inhaber am Laptop“
Der Hauptablauf, Schritt für Schritt	Das, was zuerst funktionieren muss	„Leistung wählen, Termin wählen, Name und Telefonnummer eingeben, Bestätigung erhalten“
Die gespeicherten Daten	Wird zum Datenbankdesign	„Leistungen, Buchungen, Kunden“
Wer was sehen oder ändern darf	Bestimmt Anmeldung und Berechtigungen	„Nur der Inhaber sieht alle Buchungen“
Look and Feel, kurz	Vermeidet einen generischen Standardstil	„Dunkel, schlicht, große Buttons“
Was vorerst wegfällt	Hält die erste Version klein	„Noch keine Zahlungen oder Bewertungen“

Die letzte Zeile wird oft unterschätzt. Wenn Sie sagen, was Sie nicht wollen, verhindern Sie, dass die KI einen Blog, eine Preisseite und eine Newsletter-Anmeldung hinzufügt, die Sie nie angefragt haben.

Vorher und nachher: der erste Prompt

Vorher:

Mach mir eine App für mein Fitnessstudio.

Der Builder muss alles raten: Mitglieder oder Personal? Kurse oder Personal Training? Zahlungen? Sie bekommen etwas, das wie eine Fitnessstudio-Website aussieht und nichts von dem tut, was Sie brauchen.

Nachher:

Baue eine Kursbuchungs-App für ein kleines Yoga-Studio. Mitglieder sehen die Kurse dieser Woche (Name, Lehrer, Uhrzeit, freie Plätze), buchen einen Platz und können bis zwei Stunden vorher stornieren. Mitglieder melden sich mit E-Mail und Passwort an. Der Studioinhaber meldet sich an, um Kurse anzulegen, zu sehen, wer gebucht hat, und die Anwesenheit zu markieren. Speichere Kurse, Mitglieder und Buchungen in einer Datenbank. Ruhiges, helles Design, das auf dem Handy gut funktioniert. Noch keine Zahlungen.

Die zweite Version ist immer noch kurz. Sie beantwortet einfach die Fragen aus der Tabelle oben.

Verhalten beschreiben, nicht die Umsetzung

Oft erzielen Sie bessere Ergebnisse, wenn Sie beschreiben, was passieren soll, statt wie es gebaut werden soll.

Vorher:

Füge einen useEffect hinzu, der Buchungen lädt, und eine Modal-Komponente zum Bearbeiten.

Nachher:

Wenn der Inhaber eine Buchung anklickt, öffnet sich ein Panel, in dem er die Uhrzeit ändern oder die Buchung stornieren kann. Änderungen sollen sofort in der Liste erscheinen.

Der erste Prompt legt die KI auf eine bestimmte Technik fest, die vielleicht nicht zu der bereits gebauten App passt. Der zweite nennt das gewünschte Ergebnis und überlässt es der KI, den richtigen Ansatz für den vorhandenen Code zu wählen. Wenn Sie Entwickler sind und eine klare Vorliebe haben, sagen Sie sie – aber verbinden Sie sie mit dem Ergebnis.

Geschäftsregeln konkret machen

Geschäftsregeln sind der Bereich, in dem KI-gebaute Apps am häufigsten schiefgehen, weil sie für Sie offensichtlich und für die KI unsichtbar sind. Formulieren Sie sie ausdrücklich.

Grenzen: „Ein Mitglied kann höchstens drei künftige Buchungen haben.“
Zeitpunkte: „Stornierungen schließen zwei Stunden vor Kursbeginn.“
Randfälle: „Ist ein Kurs voll, zeige einen Warteliste-Button statt Buchen.“
Berechtigungen: „Lehrer sehen die Anwesenheit ihrer eigenen Kurse, aber nicht die anderer Lehrer.“

Jede dieser Regeln ist ein Satz. Fehlt eine davon, setzt die App sie entweder nicht durch oder erfindet eine eigene Version.

Nach der ersten Version: eine Änderung pro Nachricht

Sobald etwas in der Vorschau läuft, wechseln Sie von der Beschreibung des ganzen Produkts zu kleinen, überprüfbaren Änderungen.

Vorher:

Das Design passt nicht, die Buchung funktioniert nicht richtig, und ich möchte eine Kalenderansicht und E-Mails.

Nachher (als vier getrennte Nachrichten):

Wenn ich den letzten Platz in einem Kurs buche, steht bei dem Kurs noch „1 Platz frei“. Es sollte „Ausgebucht“ stehen und der Buchen-Button ausgeblendet werden.

Füge auf der Terminseite eine Wochenkalender-Ansicht hinzu, eine Spalte pro Tag. Behalte die aktuelle Listenansicht als Option.

Mache die Kurskarten auf Handys kompakter: kleinere Abstände, Name des Lehrers in derselben Zeile wie die Uhrzeit.

Sende dem Mitglied nach der Buchung eine Bestätigungs-E-Mail.

Warum das funktioniert:

Jede Änderung ist klein genug, dass die KI sie in einem Durchgang richtig umsetzen kann.
Sie können jede einzelne testen, bevor Sie weitergehen.
Wenn eine Änderung schiefgeht, können Sie nur diesen Schritt zurücknehmen, ohne die anderen zu verlieren.

Sagen, was bleiben soll

Wenn Sie um eine Änderung an etwas bitten, das bereits funktioniert, sagen Sie der KI, was sich nicht ändern darf. Das ist der einfachste Weg, Regressionen zu verhindern (Dinge, die früher funktionierten und nach einer Bearbeitung kaputtgehen).

Gestalte den Hero-Bereich der Startseite neu mit einer größeren Überschrift und einem Foto rechts. Behalte die Navigation, die Farben und alles unterhalb des Hero-Bereichs genau so, wie es ist.

Dasselbe gilt für Daten: „Füge den Mitgliedern ein Telefonnummer-Feld hinzu. Entferne oder benenne keine bestehenden Felder um.“

Screenshots und exakter Text verwenden

Ausdrücke wie „das Ding oben“ sind mehrdeutig. Die meisten KI-App-Builder akzeptieren Bilder, und ein Screenshot mit einer kurzen Notiz ist schneller als ein Absatz Beschreibung.

Hängen Sie einen Screenshot an und schreiben Sie: „Der rot umkreiste Button überlappt auf Handys das Menü.“
Kopieren Sie den exakten Text jeder Fehlermeldung, statt ihn umzuformulieren.
Zitieren Sie Beschriftungen auf dem Bildschirm genau: „der Button Änderungen speichern auf der Einstellungsseite“.

Für Fehler gilt speziell diese Form:

Auf der Buchungsseite habe ich bei einer Buchung für morgen auf Stornieren geklickt. Ich erwartete, dass sie aus meiner Liste verschwindet. Stattdessen passierte nichts, und die Buchung ist nach dem Neuladen immer noch da. Behebe es und prüfe, ob das Stornieren funktioniert.

Unser Leitfaden zu der Fehlersuche in einer KI-gebauten App geht darauf genauer ein.

Bei großen Änderungen zuerst planen

Bei allem, was viele Teile der App betrifft – Benutzerkonten zu einer App ohne Konten hinzufügen, Zahlungen ergänzen, die Datenstruktur ändern –, bitten Sie um einen Plan, bevor sich Code ändert.

Erkläre, bevor du etwas änderst, wie du Team-Konten hinzufügen würdest: welche neuen Tabellen, welche Seiten sich ändern und was mit bestehenden Nutzern passiert. Ändere noch keinen Code.

Lesen Sie den Plan. Wenn er etwas missversteht, ist es viel günstiger, einen Absatz zu korrigieren, als eine fertige Funktion. Viele Builder haben dafür einen eigenen Modus; bei Mythex heißt er Plan, neben Build und Ask.

Was Sie vermeiden sollten

Vermeiden	Warum	Stattdessen
„Mach es besser“ / „Mach es auffälliger“	Kein Ziel, die KI ändert zufällig Dinge	Nennen Sie die Änderung: „mehr Abstand zwischen den Abschnitten, größere Überschriften“
Ein riesiger Prompt mit zehn Funktionen	Fehler häufen sich, schwer zu testen	Eine Funktion pro Nachricht
API-Schlüssel in den Chat einfügen	Schlüssel landen im Chatverlauf	Die Secrets- oder Umgebungseinstellungen des Builders verwenden
Mit einem fehlerhaften Ergebnis diskutieren	Jede Korrektur stapelt sich auf dem Fehler	Zurücksetzen und neu formulieren
Code festlegen, den Sie nicht verstehen	Fixiert eine schlechte Lösung	Beschreiben Sie das gewünschte Verhalten
„Sicherheit auf Unternehmensniveau“ verlangen	Heißt nichts Konkretes	Listen Sie die tatsächlichen Regeln auf: wer was sehen darf

Zu API-Schlüsseln: Wenn Sie einen Zahlungs- oder E-Mail-Dienst brauchen, legen Sie dessen Schlüssel in den Secrets des Projekts ab und nicht im Prompt. Siehe was Umgebungsvariablen und Secrets sind, falls Ihnen das neu ist.

Wiederverwendbare Prompt-Vorlagen

Passen Sie diese an, indem Sie die Platzhalter in eckigen Klammern ersetzen.

Neue App:

Baue eine [Art der App] für [wer]. Sie [Hauptablauf, Schritt für Schritt]. [Zweite Nutzergruppe] meldet sich an, um [was sie tut]. Speichere [Daten] in einer Datenbank. [Look and Feel]. Lass [spätere Dinge] weg.

Neue Funktion:

Füge [Funktion] zur Seite [Seite] hinzu. Wenn [Nutzer] [Handlung] ausführt, soll [was passieren soll]. Nur [wer] darf [das tun]. Lass [bestehende Dinge] unverändert.

Designänderung:

Ändere auf der Seite [Seite] das Element [konkretes Element] zu [konkrete Änderung]. Behalte [was bleiben soll]. Prüfe, ob es auf einem Bildschirm in Handybreite richtig aussieht.

Fehler:

Auf der Seite [Seite] habe ich [Schritte]. Ich erwartete [Erwartung]. Stattdessen [tatsächliches Ergebnis, plus exakter Fehlertext]. Behebe es und prüfe, ob der Ablauf funktioniert.

Frage ohne Änderungen:

Ändere keinen Code. Erkläre, wie [Teil der App] funktioniert und wo [Daten] gespeichert werden.

Eine längere Spezifikation schreiben

Bei größeren Projekten kann es helfen, zuerst ein einseitiges Briefing zu schreiben und es als ersten Prompt einzufügen: die Nutzer, die Kernabläufe, die Daten, die Regeln und was nicht dazugehört. Sie können sogar eine KI bitten, den Entwurf zu erstellen – unser Leitfaden zum Schreiben eines Product Requirements Docs mit KI zeigt, wie das geht. Beschränken Sie den ersten Bauauftrag auf den Kernablauf und ergänzen Sie den Rest Schritt für Schritt.

Prompten in Mythex

Alles oben Beschriebene funktioniert in Mythex. Einige Besonderheiten, die helfen:

Modi Build, Plan und Ask. Nutzen Sie Plan für große oder riskante Änderungen und Ask, wenn Sie eine Erklärung ohne Bearbeitung möchten.
Checkpoints. Nach jeder erfolgreichen Änderung speichert Mythex einen Checkpoint, und Zu diesem Punkt zurückkehren bei einer Antwort setzt das Projekt zurück. Sie können auch eine frühere Nachricht bearbeiten und erneut senden, um von dort aus einen anderen Prompt zu testen.
Secrets-Karte. Braucht der Agent einen API-Schlüssel, fragt er über eine Karte im Chat danach. So wird der Wert als Projekt-Secret gespeichert und nicht in Ihre Nachricht geschrieben.
Bilder. Hängen Sie Screenshots oder Mockups an, und der Agent sieht sie sich an.

Die Dokumentation hat eine kurze Seite zu wirksamen Prompts und eine zum Iterieren ohne Neubau. Wenn Sie bei null anfangen, zeigt wie Sie eine App mit KI bauen ein komplettes Projekt, und wie Sie mit KI eine gut aussehende App gestalten behandelt Prompts für die visuelle Feinarbeit.

Fragen

Wie lang sollte ein Prompt für einen KI-App-Builder sein?

Für die erste Version reicht meist ein kurzer Absatz mit vier bis acht Sätzen: wer die App nutzt, der Hauptablauf, die gespeicherten Daten und wer was sehen darf. Danach funktionieren kürzere Prompts besser, die jeweils nur eine Änderung verlangen, als lange.

Soll ich der KI sagen, welches Framework oder welche Sprache sie verwenden soll?

Nur wenn es einen Grund dafür gibt, etwa einen Entwickler, der den Code später übernimmt, oder einen Dienst, der nur mit einem bestimmten Stack funktioniert. Ansonsten beschreiben Sie das Produkt und lassen den Builder sinnvolle Standards wählen.

Warum ändert die KI Dinge, die ich nicht ändern wollte?

Meist, weil der Prompt zu allgemein war („mach es besser“) oder nicht gesagt hat, was bleiben soll. Nennen Sie genau das, was geändert werden soll, sagen Sie, was gleich bleiben muss, und bitten Sie um eine Änderung pro Nachricht.

Ist es besser, ein schlechtes Ergebnis mit weiteren Prompts zu korrigieren oder neu anzufangen?

Wenn die letzte Änderung die Sache verschlechtert hat, setzen Sie auf die Version davor zurück und formulieren Sie neu, statt Korrekturen auf Korrekturen zu stapeln. Ein neues Projekt starten Sie nur, wenn sich die Idee selbst geändert hat.