Einsteiger-Leitfaden zum Erstellen von Apps mit KI - Prompt Engineering für Builder

Letzten Monat hat eine mir bekannte Operations-Managerin versucht, mit einem KI-Builder eine Onboarding-App für neue Mitarbeiter zu erstellen. Ihr erster Prompt: "Build an onboarding app for new employees." Was sie zurückbekam, war eine generische Landingpage mit einer Willkommensnachricht und einem Formular, das Name, E-Mail und "Abteilung" abfragte. Keine Workflows. Kein Dokumenten-Upload. Keine Aufgaben-Checklisten. Keine Manager-Freigaben. Die nächsten zwei Stunden verbrachte sie damit, Dinge hinzuzufügen, die sie für selbstverständlich gehalten hatte -- und Dinge rückgängig zu machen, die die KI eigenmächtig angenommen hatte.

Beim zweiten Versuch ging sie anders vor. Sie beschrieb, wer die App nutzen würde (neue Mitarbeiter, HR-Koordinatoren und Abteilungsleiter), was jede Person tun muss (Unterlagen ausfüllen, Ausstattung zuweisen, Steuerformulare prüfen), was bei Problemen passiert (fehlende Dokumente lösen eine Erinnerung aus, keinen Blocker) und wie das Ergebnis in jeder Phase aussehen soll. Diese Version funktionierte. Nicht perfekt -- ein paar Überarbeitungsrunden brauchte sie noch -- aber der erste Entwurf war erkennbar die App, die sie im Kopf hatte.

Der Unterschied war kein besseres KI-Modell. Es war ein besserer Prompt.

Dieser Leitfaden behandelt die Lücke zwischen diesen beiden Versuchen. Er erklärt, wie du Prompts schreibst, die Anwendungen produzieren, die deinen Vorstellungen entsprechen -- egal ob du Chattee, Lovable, Bolt.new, Replit oder einen anderen KI-gestützten Builder verwendest. Die Prinzipien sind plattformübergreifend gleich, auch wenn die Details variieren.

Stell dir die KI als schnellen, wörtlich nehmenden Auftragnehmer vor

Das nützlichste Denkmodell für die Arbeit mit KI-Buildern: Stell dir vor, du engagierst einen Entwickler, der zehnmal so schnell arbeitet, Anweisungen buchstabengetreu befolgt und nie nach Klärung fragt. Genau der letzte Punkt ist das Problem. Ein menschlicher Entwickler würde stoppen und sagen: "Moment, was meinst du mit Admin-Kontrollen?" Ein KI-Builder erfindet einfach etwas.

Das bedeutet: Prompts für die App-Entwicklung funktionieren weniger wie Suchanfragen und mehr wie Anforderungsdokumente. Der Prompt definiert Umfang, Verhalten, Berechtigungen und Randfälle -- alles, was normalerweise in einer Spezifikation stehen würde. Lässt du etwas davon weg, füllt die KI die Lücken mit vernünftig klingenden Vermutungen, die für deine Situation völlig falsch sein können.

Eine Studie des MIT Sloan aus dem Jahr 2025 bestätigte das quantitativ: Nur etwa die Hälfte der Leistungsgewinne durch ein besseres KI-Modell kamen vom Modell selbst. Die andere Hälfte kam davon, wie die Menschen ihre Prompts anpassten. In ein leistungsstarkes KI-Tool zu investieren bringt begrenzten Nutzen, wenn du nicht gleichzeitig lernst, es richtig zu steuern.

Prompting-Frameworks, die du kennen solltest

Wenn du noch nie einen strukturierten Prompt geschrieben hast, geben dir Frameworks eine Checkliste, damit du keine wichtigen Bestandteile vergisst. Keines davon ist Magie -- es sind einfach verschiedene Wege, dich daran zu erinnern, welche Informationen die KI braucht.

CO-STAR ist das am weitesten verbreitete Allzweck-Framework. Es steht für Context, Objective, Style, Tone, Audience, Response. Es stammt aus einem GPT-4-Prompt-Engineering-Wettbewerb in Singapur und eignet sich gut für alles, wo Zielgruppe und Tonalität genauso wichtig sind wie der Inhalt. Das "Response"-Element verdient eine Anmerkung: In dedizierten App-Buildern (Chattee, Lovable, Bolt.new) übernimmt die Plattform die Dateierstellung und Projektstruktur eigenständig -- du beschreibst was gebaut werden soll, nicht welchen Dateityp du ausgeben möchtest. Wenn du jedoch Code über eine Allzweck-KI wie ChatGPT generierst und in dein Projekt einfügst, ist die genaue Angabe des Ausgabeformats unerlässlich.

RISEN (Role, Instructions, Steps, End Goal, Narrowing) eignet sich besser für technische Aufgaben. Das "Steps"-Element zwingt dich dazu, deine Anforderungen in eine Sequenz zu zerlegen -- was direkt abbildet, wie Apps gebaut werden. Im "Narrowing"-Element fügst du Einschränkungen hinzu: "keine externen Abhängigkeiten", "Mobile-First", "Supabase für Auth verwenden."

TIDD-EC (Task, Instructions, Do, Don't, Examples, Content) ist aus einem Grund wissenswert: der explizite "Don't"-Bereich. KI-Builder neigen dazu, Funktionen hinzuzufügen, die du nicht angefordert hast -- Analytics-Dashboards, Dark-Mode-Schalter, Einstellungs-Panels -- und ihnen zu sagen, was sie nicht bauen sollen, ist überraschend effektiv.

RACE (Role, Action, Context, Expectation) ist das einfachste. Vier Elemente, schnell geschrieben, funktioniert gut für unkomplizierte Anfragen. Wenn du einen Prompt für eine einzelne Komponente oder ein kleines Feature schreibst, reicht das oft aus.

Ein schneller Vergleich, wann welches Framework sinnvoll ist:

Framework	Am besten für	Komplexität	Unterscheidungsmerkmal
CO-STAR	Inhalte, Marketing-Texte, Kommunikation	Niedrig-Mittel	Fokus auf Zielgruppe und Tonalität
RISEN	Mehrstufige technische Aufgaben	Mittel	Explizite Schrittabfolge
TIDD-EC	Aufgaben, bei denen bestimmte Fehler verhindert werden müssen	Mittel	"Do/Don't"-Leitplanken
RACE	Schnelle, fokussierte Anfragen	Niedrig	Minimale Struktur

In der Praxis folgen die meisten erfahrenen Builder keinem einzelnen Framework strikt. Sie entlehnen Elemente aus mehreren -- hier eine Rollenzuweisung, dort explizite Einschränkungen, Beispiele wenn Formatierung wichtig ist. Der Wert liegt nicht im Akronym, sondern in der Gewohnheit, vollständige Informationen bereitzustellen.

Context Engineering: Die Fähigkeit, die wichtiger ist als die Wortwahl im Prompt

2025 ist etwas Wichtiges passiert: Die Branche hörte auf, von "Prompt Engineering" zu sprechen, und begann stattdessen von "Context Engineering" zu reden. Das ist nicht nur ein Begriffswechsel.

Prompt Engineering dreht sich um die Wörter, die du schreibst. Context Engineering dreht sich um die gesamte Informationsumgebung, die das KI-Modell sieht -- Systemanweisungen, Projektdateien, abgerufene Dokumente, Gesprächsverlauf, Tool-Ausgaben und Beispiele. Wie der ehemalige OpenAI-Forscher Andrej Karpathy es ausdrückte: "In every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window with the right information."

Diese Neuausrichtung erklärt etwas Praktisches: warum zwei Personen nahezu identische Prompts schreiben und dramatisch unterschiedliche Ergebnisse erhalten können. Der Unterschied liegt meist am Kontext, nicht an der Formulierung. Eine Person hat ihr bestehendes Datenbankschema bereitgestellt; die andere nicht. Eine hat einen Screenshot ihres Designs beigefügt; die andere hat es in Worten beschrieben. Eine hatte eine Rules-Datei in ihrem Tool konfiguriert; die andere begann jede Sitzung von null.

Für KI-App-Builder bedeutet Context Engineering, über drei Dinge nachzudenken:

Instruktionskontext -- Systemprompts, Regeln und Few-Shot-Beispiele, die der KI sagen, wie sie sich verhalten soll
Wissenskontext -- Domäneninformationen, Dokumentation, bestehende Code-Muster und Projektfakten
Tool-Kontext -- Informationen, die das Modell aus seiner Umgebung sammelt: Code ausführen, Datenbanken abfragen, Dateien lesen

Bevor du also über die Formulierung deines Prompts grübelst, frag dich, ob die KI tatsächlich Zugang zu den Informationen hat, die sie bräuchte, um die Aufgabe gut zu erledigen. Oft hat sie das nicht -- und keine noch so geschickte Formulierung kompensiert fehlenden Kontext.

Was du der KI in jeder Bauphase mitteilen solltest

Einer der häufigsten Fehler mit KI-Buildern ist, alle Anforderungen in einen einzigen Prompt zu packen und auf das Beste zu hoffen. Verschiedene Phasen der App-Entwicklung brauchen unterschiedlichen Kontext. Ein Prompt, der für das Design deines Datenmodells hervorragend funktioniert, liefert unbrauchbare Ergebnisse für den Aufbau deiner UI, wenn der Design-Kontext fehlt.

Hier ist, was in jeder Phase wichtig ist -- und was du einbeziehen solltest.

Beim Aufbau der UI und des Frontends

Die KI muss wissen, wie die Dinge aussehen sollen, nicht nur was sie tun sollen. Ohne visuellen Kontext greift sie auf generische Standardwerte zurück -- und diese Standardwerte könnten Bootstrap anno 2019 sein.

Einbeziehen:

Farbpalette mit spezifischen Hex-Codes (Primär-, Sekundär-, Akzent-, Erfolgs-/Fehler-/Warnfarben)
Typografie -- welche Schriftarten, welche Schriftstärken für Überschriften vs. Fließtext, Zeilenhöhen-Präferenzen
Komponentenbibliothek -- "Verwende shadcn/ui und Tailwind" oder "Verwende Mantine-Komponenten" gibt der KI ein kohärentes Design-Vokabular
Layout-Präferenzen -- Seitenleisten-Navigation vs. obere Navigation, kartenbasierte Layouts, Spaltenanzahl auf Desktop vs. Mobil
Barrierefreiheits-Anforderungen -- WCAG-AA-Konformität, semantisches HTML, Tastatur-Navigation

Ein Prompt, der "Erstelle eine Dashboard-Seite" sagt, ohne diesen Kontext, produziert etwas, das technisch funktioniert, aber nicht im Entferntesten nach deiner Marke aussieht. Sobald du auch nur eine grundlegende Design-Token-Spezifikation mitlieferst -- Farben, Schriften, Abstände -- produziert er etwas, das du tatsächlich ausliefern kannst.

Erstelle eine Dashboard-Seite mit den wichtigsten Kennzahlen für einen HR-Manager.

DESIGN-KONTEXT:
- Komponentenbibliothek: Mantine UI (React)
- Primärfarbe: #2563EB, Sekundär: #7C3AED, neutrale Hintergründe: #F8FAFC
- Typografie: Inter für Überschriften (600 weight), Inter für Fließtext (400 weight)
- Layout: Seitenleisten-Navigation links (240px), Hauptinhaltsbereich mit 24px Padding
- Cards für jede Kennzahl, 8px Rahmenradius, dezenter Schatten (0 1px 3px rgba(0,0,0,0.1))
- Responsiv: Seitenleiste unter den Inhalt stapeln bei Screens unter 768px
- WCAG-AA-Farbkontrast erforderlich

ANZUZEIGENDE KENNZAHLEN:
- Offene Stellen (Anzahl, Trendpfeil vs. Vormonat)
- Durchschnittliche Time-to-Hire (Tage, Balkendiagramm der letzten 6 Monate)
- Mitarbeiter-Fluktuationsrate (Prozent, Liniendiagramm der letzten 12 Monate)
- Ausstehende Onboarding-Aufgaben (Liste der nächsten 5, mit Zuständigem und Fälligkeitsdatum)

Beim Aufbau des Datenmodells

KI-Builder neigen besonders dazu, übermäßig vereinfachte Schemas zu erstellen -- eine einzelne users-Tabelle mit zwanzig Spalten statt ordnungsgemäß normalisierter Entitäten. Die Lösung: Sei pedantisch bei der Struktur. Buchstabiere jede Entität, jeden Feldtyp, jede Einschränkung aus. Benenne deine Namenskonvention (snake_case? camelCase? Singular- oder Plural-Tabellen?). Wenn du eine bestehende Datenbank erweiterst, füge das aktuelle Schema ein -- ohne dieses erfindet die KI Konventionen, die mit dem Bestehenden kollidieren.

Indizierung verdient einen eigenen Abschnitt im Prompt. Die meisten KI-generierten Schemas überspringen Indizes vollständig, was für einen Prototyp in Ordnung und für die Produktion katastrophal ist. Sag der KI, welche Abfragen häufig sein werden, und sie fügt die richtigen Indizes hinzu.

Entwirf eine Datenbank für ein Projektmanagement-Tool.

NAMENSGEBUNG: snake_case für alles, Plural-Tabellennamen.
Jede Tabelle soll erfassen, wann Datensätze erstellt und zuletzt aktualisiert wurden.

ENTITÄTEN UND BEZIEHUNGEN:
- Teams: Name, eindeutiger Slug-Bezeichner
- Users: E-Mail (eindeutig), Anzeigename, gehört zu einem Team
- Projects: Name, gehört zu einem Team, hat einen Besitzer (ein User),
  Status kann active, archived oder draft sein (Standard: draft)
- Tasks: Titel, optionale Beschreibung, gehört zu einem Project,
  kann einem User zugewiesen werden (optional), Status ist einer von
  todo/in_progress/review/done, Priorität ist low/medium/high/critical,
  optionales Fälligkeitsdatum

PERFORMANCE:
- Zusammengesetzter Index auf tasks für project + status (wir filtern
  Aufgabenlisten ständig nach Projekt und dann nach Status)
- Index auf tasks nach assignee (für "Meine Aufgaben"-Ansichten)
- Zusammengesetzter Index auf projects für team + status (für Team-
  Projektlisten)

VALIDIERUNG:
- Fälligkeitsdaten müssen beim ersten Setzen in der Zukunft liegen
- Projektstatus ist bei Erstellung standardmäßig "draft"

Beim Aufbau von Geschäftslogik und Backend-Verhalten

Backend-Prompts scheitern auf andere Weise als UI-Prompts. Statt falsch auszusehen, sehen sie gut aus -- bis du merkst, dass die App Fehler inkonsistent behandelt, die Authentifizierungsprüfung auf einer Seite fehlt oder eine fehlgeschlagene Aktion eine kryptische Fehlermeldung statt einer hilfreichen Nachricht anzeigt.

Was am besten funktioniert: Beschreib, was der Benutzer tut, was im Hintergrund passieren soll, welche Regeln gelten und was der Benutzer sehen soll, wenn etwas schiefgeht. Wenn du zu einer bestehenden App etwas hinzufügst, zeig der KI ein funktionierendes Beispiel aus deiner Codebasis -- sie erfasst Muster schneller durch Beispiele als durch geschriebene Regeln.

Baue ein Task-Zuweisungs-Feature für das Projektmanagement-Tool.

BENUTZERFLUSS:
- Auf der Task-Detailseite sehen Manager und Admins einen "Zuweisen"-Button
- Klick öffnet ein Dropdown mit den Teammitgliedern
- Auswahl einer Person weist den Task dieser Person zu
- Die Seite aktualisiert sich sofort und zeigt den neuen Zuständigen

GESCHÄFTSREGELN:
- Nur Benutzer mit der Rolle Manager oder Admin innerhalb des Projekt-Teams
  können Tasks zuweisen
- Der Zugewiesene muss Mitglied desselben Teams wie das Projekt sein
- Wenn ein Task bereits als "done" markiert ist, kann er nicht neu zugewiesen werden
- Bei Zuweisung wird festgehalten, wer die Änderung wann vorgenommen hat

WAS DER BENUTZER BEI FEHLERN SIEHT:
- Fehlende Berechtigung: "Du hast keine Berechtigung, Tasks
  in diesem Projekt zuzuweisen"
- Task nicht gefunden: "Nicht gefunden"-Seite anzeigen
- Task bereits abgeschlossen: "Dieser Task ist bereits erledigt und kann
  nicht neu zugewiesen werden"
- Ausgewählter Zuständiger nicht im Team: "Diese Person ist kein Mitglied
  des Projekt-Teams"

Beim Aufbau von Integrationen

Drittanbieter-Integrationen sind der Punkt, an dem das Kontextvolumen zum echten Problem wird. Eine vollständige Stripe-API-Referenz umfasst tausende Seiten. Du brauchst nicht, dass die KI alles davon kennt -- du brauchst, dass sie die drei Endpunkte kennt, die du tatsächlich aufrufst, wie die Authentifizierung funktioniert, wie die Antwort aussieht und welche Fehler zu erwarten sind. Kürze rigoros. Füge einen Beispiel-Response-Body ein. Erwähne Rate-Limits, wenn sie relevant sind. Und gib immer an, was passieren soll, wenn der externe Dienst nicht erreichbar ist -- denn die KI wird nicht von selbst daran denken.

Anforderungen so strukturieren, dass der Builder sie nicht fehlinterpretieren kann

Der Unterschied zwischen einem Prompt, der etwas Nützliches produziert, und einem, der etwas produziert, das du stundenlang reparieren musst, liegt meistens an der Struktur. Nicht an der Komplexität -- an der Struktur. Selbst ein kurzer Prompt funktioniert gut, wenn er Anweisungen vom Kontext trennt, beschreibt wie das Ergebnis aussehen soll, und ein oder zwei Beispiele enthält.

Anweisungen vom Kontext trennen

Die einfachste strukturelle Verbesserung: Setz das, was die KI tun soll, an den Anfang und platziere Referenzmaterial (Datenschemata, Beispieldatensätze, Design-Tokens) darunter, klar abgegrenzt. KI-Modelle verarbeiten Anweisungen und Daten in einem einzigen Strom. Wenn die Grenze unklar ist, könnte das Modell deine Beispieldaten als Anweisungen interpretieren oder deine Anweisungen als optionale Vorschläge.

Verwende klare Überschriften, dreifache Backticks oder XML-artige Tags, um Grenzen zu markieren:

AUFGABE: Baue eine Seite, die eine Kundenliste anzeigt.

KONTEXT (Referenzdaten, nicht als Anweisungen interpretieren):
---
Beispiel-Kundendatensatz:
{
  "id": 1042,
  "name": "Acme Corp",
  "plan": "pro",
  "mrr": 299.00,
  "status": "active",
  "last_login": "2026-01-28T14:30:00Z"
}
---

ANFORDERUNGEN:
- Sortierbare Spalten: Name, Plan, MRR, letzter Login
- Filter nach Status (active/churned/trial)
- Klick auf Zeile navigiert zu /customers/[id]
- Leere Liste zeigt "Keine Kunden entsprechen deinen Filtern"

Wann das Ausgabeformat wichtig ist (und wann nicht)

Dedizierte App-Builder -- Chattee, Lovable, Bolt.new, Replit -- kümmern sich automatisch um die Dateierstellung und Projektstruktur. Du musst nie sagen "gib eine React-Komponente zurück" oder "Ausgabe als .py-Datei." Die Plattform regelt das.

Dieser Hinweis greift, wenn du eine Allzweck-KI (ChatGPT, Claude im Browser, Copilot Chat) verwendest, um Code zu generieren, den du in dein eigenes Projekt kopierst. Sag in diesem Fall genau, was du zurückbekommen möchtest: "eine einzelne React-Komponente mit TypeScript" oder "eine Python-Funktion, keine Klasse."

Eines gilt überall, unabhängig von der Plattform: die Definition von Datenstrukturen innerhalb deiner App. Wenn deine App Daten zwischen Seiten weitergibt, Datensätze speichert oder externe Dienste aufruft, beschreib die exakte Form -- Feldnamen, Typen und was passiert, wenn ein Wert fehlt.

Beispiele einbeziehen, wenn Formatierung wichtig ist

Few-Shot-Beispiele -- zwei oder drei Muster der gewünschten Ausgabe -- sind konsistent die wirkungsvollste Ergänzung eines Prompts. Sie verankern das Verhalten des Modells zuverlässiger als abstrakte Anweisungen. Wenn du ein bestimmtes API-Response-Format willst, zeig eines. Wenn du einen bestimmten Coding-Stil willst, füg einen Ausschnitt bestehenden Codes ein.

Der Schlüssel: Mach Beispiele mechanisch konsistent. Wenn ein Beispiel camelCase und ein anderes snake_case verwendet, wechselt das Modell zufällig zwischen beiden.

Eine Vorlage zum Kopieren

Ein Allzweck-Gerüst für KI-App-Builder-Prompts:

TITEL: [Feature- oder App-Name]

ZIEL (ein Satz): [Wie Erfolg aussieht]

NICHT-ZIELE:
- [Was die App NICHT tun darf]
- [Was außerhalb des Umfangs liegt]

BENUTZER:
- [Rolle A] -- [warum sie dieses Feature nutzen]
- [Rolle B] -- [warum sie dieses Feature nutzen]

DATEN:
- Eingaben: [was der Benutzer bereitstellt]
- Quellen: [Datenbanken, APIs, Dateien, aus denen die App liest]
- Verboten: [Daten, auf die die App nicht zugreifen oder die sie nicht anzeigen darf]

WORKFLOWS:
- Happy Path: [Schritt für Schritt]
- Alternative Pfade: [was passiert, wenn X]
- Fehlerpfad: [was passiert, wenn etwas schiefgeht]

REGELN:
- [Regel 1 -- eindeutig, testbar]
- [Regel 2 -- eindeutig, testbar]

AUSGABEFORMAT (weglassen, wenn die Plattform die Dateigenerierung automatisch übernimmt):
- [Struktur, Pflichtfelder, Typen]

AKZEPTANZTESTS:
- Gegeben [Eingabe], erwarte [Ausgabe/Verhalten]

Das ist kein starres Format -- pass es an dein Tool und dein Projekt an. Der Punkt ist, dass jeder Abschnitt eine Entscheidung erzwingt, die du sonst der Vorstellungskraft der KI überlassen würdest.

Rollen und Berechtigungen richtig definieren

Berechtigungsfehler sind die gefährlichste Kategorie von "Fehlkonstruktionen", weil sie Sicherheitslücken schaffen, nicht nur UX-Ärgernisse. Bei KI-generierten Apps ist das Risiko noch größer: Wenn du nicht angibst, wer was tun darf, macht die KI entweder alles für jeden zugänglich oder wendet Berechtigungen inkonsistent an.

Es gibt zwei separate Konzepte, die du auseinanderhalten musst:

Nachrichtenrollen sind die API-Level-Instruktionshierarchie -- System, Developer, User. Diese steuern, welche Anweisungen die KI priorisiert. Deine nicht verhandelbaren Regeln (Sicherheitsgrenzen, Datenzugriffsbeschränkungen) sollten auf der höchstmöglichen Ebene stehen.

App-Benutzerrollen sind die Produktrollen -- Admin, Editor, Betrachter, Kunde. Diese bestimmen, was eine Person in der Anwendung, die du baust, sehen und tun kann.

Ein guter Prompt adressiert beides. Er setzt harte Grenzen in den System-Level-Anweisungen und definiert dann ein konkretes Berechtigungsmodell für die Anwendung.

Das Prinzip, das die meisten Berechtigungsfehler verhindert

Standardmäßig verweigern. Keine Aktion ist erlaubt, es sei denn, sie wurde explizit gewährt. Das ist eine Standard-Sicherheitspraxis (OWASP empfiehlt sie sowohl für traditionelle Webanwendungen als auch für LLM-gestützte), und sie lässt sich direkt darauf übertragen, wie du Prompts schreibst:

Statt so:

Admins können alles verwalten.
Support-Agenten können Kunden helfen.
Kunden können ihr Konto sehen.

Schreib so:

ROLLEN: customer, support_agent, admin

BERECHTIGUNGEN (standardmäßig verweigern -- keine Aktion, sofern nicht hier aufgeführt):

customer:
  DARF: eigenes Profil lesen (außer payment_method-Feld), eigene Tickets erstellen und einsehen,
       öffentliche Wissensdatenbank-Artikel lesen
  DARF NICHT: Daten anderer Benutzer lesen, auf interne KB zugreifen, Daten exportieren, Rollen ändern

support_agent:
  DARF: Tickets lesen, bei denen assigned_to = self, Antworten entwerfen, interne KB lesen
  DARF NICHT: auf Abrechnungsdaten zugreifen, Benutzer löschen, Rollenzuweisungen ändern

admin:
  DARF: KB-Artikel verwalten, Routing-Regeln konfigurieren, Rollenzuweisungen verwalten
  DARF NICHT: Ticket-Nachrichteninhalte einsehen, außer mit expliziter "ticket_audit"-Berechtigung

HOCHRISIKO-AKTIONEN (erfordern menschliche Genehmigung unabhängig von der Rolle):
- Kontolöschung
- Massen-Datenexport
- Rollen-Erhöhung

Die erste Version besteht aus drei Zeilen Deutsch, die fast alles bedeuten könnten. Die zweite Version ist implementierbar -- ein Entwickler (oder eine KI) kann jede Zeile in eine Datenbankprüfung, einen API-Guard oder eine UI-Sichtbarkeitsregel umwandeln.

Welches Zugriffskontrollmodell du beschreiben solltest

Für die meisten App-Builder-Anwendungsfälle ist RBAC (Role-Based Access Control) die richtige Wahl. Es lässt sich sauber auf das "Rolle X darf Y"-Format abbilden, das KI-Modelle gut verarbeiten. Beschreib Rollen, liste erlaubte Aktionen pro Rolle auf und gib den Geltungsbereich jeder Aktion an.

Wenn du feinere Kontrolle brauchst -- "Benutzer können nur Tickets bearbeiten, die sie erstellt haben" oder "Pro-Plan-Benutzer sehen andere Funktionen als Free-Plan-Benutzer" -- bewegst du dich in Richtung ABAC (Attribute-Based Access Control). Drück diese in Prompts als bedingte Regeln aus:

BEDINGTE BERECHTIGUNGEN:
- Ein Benutzer kann ein Ticket bearbeiten, WENN ticket.creator_id = user.id
- Ein Benutzer kann auf das Analytics-Dashboard zugreifen, WENN user.plan IN ('pro', 'enterprise')
- Ein Benutzer kann Gehaltsdaten einsehen, WENN user.department = record.department UND user.role = 'manager'

Fazit: Beschreib Berechtigungen so, dass sie im Code überprüft werden können, nicht so, dass die KI sich Regeln während eines Gesprächs "merken" muss. Nur durch KI durchgesetzte Berechtigungen sind unzuverlässig. Durch Code durchgesetzte Berechtigungen sind testbar.

Bedingte Logik so beschreiben, dass Workflows tatsächlich funktionieren

Hier brechen KI-gebaute Apps am häufigsten zusammen. Der Happy Path sieht großartig aus. Aber sobald ein Benutzer zum ersten Mal ein Formular mit einem fehlenden Feld abschickt, eine Zahlung fehlschlägt oder jemand versucht, auf eine Seite zuzugreifen, die er nicht sehen sollte -- fällt die App auseinander.

Die Ursache: Wenn du nicht beschreibst, was in Nicht-Happy-Path-Szenarien passiert, nimmt die KI an, dass der Happy Path der einzige Pfad ist.

Muster, die in Prompts funktionieren

Guard Clauses verhindern, dass die KI mit unvollständigen Informationen voranprescht:

Wenn Pflichtfelder (order_id, customer_email) fehlen,
den Benutzer bitten, sie anzugeben. Nicht fortfahren oder raten.

Entscheidungstabellen kommunizieren Verzweigungslogik klarer als Prosa:

Bedingung	Aktion	Ausgabe
Benutzer nicht authentifiziert	Anmeldeaufforderung anzeigen, keine Kontodaten laden	Keine API-Aufrufe zu Benutzer-Endpunkten
Authentifiziert, fordert Passwort-Zurücksetzung an	Reset-E-Mail an verifizierte Adresse senden	Bestätigungsnachricht, kein Passwort angezeigt
Authentifiziert, fordert Kontolöschung an	proposed_action für menschliche Prüfung generieren	escalation_needed = true
Suche liefert keine Ergebnisse	"Keine Ergebnisse gefunden" mit Vorschlägen anzeigen	Keinen Fehlerstatus anzeigen
API-Aufruf nach 5 Sekunden Timeout	Retry-Button und entschuldigende Nachricht anzeigen	Timeout-Event mit request_id protokollieren

Zustandsautomaten eignen sich gut für mehrstufige Workflows:

ONBOARDING-WORKFLOW-ZUSTÄNDE:
- invite_sent -> form_incomplete -> form_complete -> documents_pending ->
  manager_review -> approved | rejected

ÜBERGÄNGE:
- invite_sent -> form_incomplete: wenn neuer Mitarbeiter Einladungslink klickt
- form_incomplete -> form_complete: wenn alle Pflichtfelder ausgefüllt
- form_complete -> documents_pending: automatisch, nach bestandener Formularvalidierung
- documents_pending -> manager_review: wenn alle erforderlichen Dokumente hochgeladen
- manager_review -> approved: wenn Manager "Genehmigen" klickt
- manager_review -> rejected: wenn Manager "Ablehnen" klickt (Begründung erforderlich)
- rejected -> form_incomplete: neuer Mitarbeiter kann erneut einreichen

REGELN:
- Kein Zustandsübergang darf einen Schritt überspringen
- Abgelehnte Mitarbeiter können bis zu 2 Mal erneut einreichen, danach Eskalation an HR-Direktor

Vorher und nachher: Bedingte Logik explizit machen

Vorher (der Prompt, der einen fehlerhaften Workflow produziert):

Wenn der Benutzer eine Erstattung will, hilf ihm. Wenn es nicht möglich ist, eskaliere.

Nachher (der Prompt, der einen funktionierenden Workflow produziert):

ERSTATTUNGS-WORKFLOW (Prüfungen in dieser Reihenfolge durchführen):

1. Validierung:
   - Wenn order_id fehlt, fragen: "Wie lautet deine Bestellnummer?"
   - Wenn keine Bestellung für diese ID gefunden wird: "Diese Bestellung
     konnte ich nicht finden. Bitte überprüfe die Nummer."

2. Autorisierung:
   - Wenn user_role = "customer": kann nur anfragen, nicht ausführen.
     Erstattungsantrag für Agent-Prüfung generieren.
   - Wenn user_role = "support_agent": kann initiieren. Weiter zu Schritt 3.

3. Geschäftsregeln:
   - Wenn Kauf älter als 30 Tage: nicht erstattungsfähig.
     Gutschrift oder Eskalation anbieten.
   - Wenn Bestellsumme über 500 USD: an Senior-Agent weiterleiten,
     unabhängig von der Rolle.
   - Wenn Kunde in den letzten 90 Tagen mehr als 3 Erstattungen hatte:
     zur Prüfung markieren.

4. Ausführung:
   - proposed_action generieren: { type: "refund", order_id, amount, reason }
   - escalation_needed = true setzen (alle Erstattungen erfordern menschliche Genehmigung)

Die zweite Version behandelt fehlende Daten, nicht autorisierte Benutzer, Geschäftsregeln und Randfälle. Jede Zeile kann zu einem Testfall werden.

Randfälle: Was in der Produktion wirklich kaputtgeht

KI-Builder optimieren für den Happy Path, sofern du ihnen nichts anderes sagst. Fehlende Eingaben, API-Ausfälle, mehrdeutige Benutzeraktionen und widersprüchliche Regeln -- das sind die Dinge, die echte Probleme verursachen, sobald Menschen die App nutzen.

Ein praktischer Ansatz: Geh für jedes Feature diese Szenarien durch und nimm die Antworten in deinen Prompt auf.

Fehlende oder unvollständige Eingabe. Soll die App um Klärung bitten, einen Validierungsfehler anzeigen oder auf einen Standardwert zurückfallen? Schreib es aus -- die KI trifft nicht die gleiche Wahl wie du.

Externe Dienste fallen aus. Datenbanken haben Timeouts. Zahlungsanbieter lehnen Karten ab. Beschreib, was der Benutzer sieht, wenn etwas kaputtgeht: ob automatisch ein Retry erfolgen soll, eine freundliche Fehlermeldung angezeigt werden soll oder an einen Menschen eskaliert werden soll.

Nicht autorisierte Aktionen sollten immer eine klare, spezifische Meldung erzeugen -- niemals ein stilles Scheitern oder eine rohe Fehlerausgabe. Wenn jemand versucht, auf eine Seite zuzugreifen, die er nicht sehen sollte, sag der KI genau, was sie anzeigen soll.

Widersprüchliche Regeln sind überraschend häufig. "Sei immer hilfreich" kombiniert mit "teile niemals Kontodaten mit unverifizierten Benutzern" erzeugt ein Paradoxon, das die KI allein nicht lösen kann. Gib eine Prioritätsreihenfolge vor: "Sicherheitsregeln übersteuern Hilfsbereitschaftsregeln."

Wenn deine App strukturierte Daten von der KI erwartet, verwende Schema-Erzwingung, wo deine Plattform das unterstützt. Ansonsten gib ein Fallback an: "Wenn die Antwort nicht dem erwarteten Format entspricht, zeige einen generischen Fehler an und protokolliere die fehlerhafte Antwort zum Debugging."

Eine Checkliste, die du in jeden Feature-Prompt einfügen kannst:

RANDFALLBEHANDLUNG:
- Fehlende Pflichtfelder: klärende Fragen stellen; nicht raten oder Standardwerte verwenden
- Externer API-Timeout (über 5s): benutzerfreundlichen Fehler + Retry-Button anzeigen; Event loggen
- Berechtigung verweigert: "Du hast keinen Zugriff auf diese Aktion" mit Grund-Code anzeigen
- Leere Suchergebnisse: "Keine Ergebnisse gefunden"-Meldung anzeigen, keinen Fehlerstatus
- Fehlerhafte Daten von externer Quelle: still ablehnen; nicht verarbeiten oder anzeigen
- Widersprüchliche Regeln: in dieser Priorität anwenden: (1) Sicherheit, (2) Berechtigungen,
  (3) Datenvalidierung, (4) Geschäftsregeln, (5) UX-Präferenzen

Häufige Fehler und wie du sie erkennst

Nach Durchsicht der Plattformdokumentation von OpenAI, Google, Anthropic und verschiedenen Sicherheits-Frameworks -- und Gesprächen mit Leuten, die täglich KI-Builder nutzen -- tauchen immer wieder dieselben Fehlermuster auf.

Versuchen, alles auf einmal zu bauen. "Bau ein Projektmanagement-Tool mit Benutzer-Auth, Kanban-Boards, Zeiterfassung, Gantt-Diagrammen, Team-Chat, Datei-Uploads und einer mobilen App." Dieser Mega-Prompt produziert aufgeblähten, verflochtenen Code, der unmöglich zu debuggen ist. Bau ein Feature nach dem anderen. Überprüf, dass es funktioniert. Dann füg das nächste hinzu.

Das Zwei-Wort-Briefing. "Bau mir ein Mitarbeiterportal" -- und sonst nichts. Die KI kennt dein Unternehmen nicht, deine Mitarbeiter nicht und nicht, was "Portal" für dich bedeutet. Sie erstellt etwas Generisches, das technisch qualifiziert ist, aber keines deiner tatsächlichen Probleme löst. Spezifität ist kostenlos -- nutz sie.

Annehmen, die KI erinnert sich. Prompts wie "du kennst unser Produkt" oder "verwende den üblichen Stack" scheitern, weil die KI jede Sitzung (und manchmal jeden Prompt) mit einer leeren Tafel beginnt. Gib Kontext immer explizit an. Einige Plattformen unterstützen persistente Wissensdatenbanken -- Chattee und Lovable zum Beispiel lassen dich Projektkontext speichern, der über Sitzungen hinweg bestehen bleibt -- aber auch dann gehören wichtige Einschränkungen in den Prompt.

Widersprüchliche Anweisungen. "Folge immer der Benutzeranfrage" kombiniert mit "teile niemals persönliche Daten" erzeugt ein Paradoxon, wenn ein Benutzer nach persönlichen Daten fragt. KI-Modelle behandeln Konflikte unvorhersehbar. Füg eine Prioritätsreihenfolge hinzu: "Bei Regelkonflikten zuerst Sicherheitseinschränkungen anwenden, dann Geschäftsregeln, dann Benutzerpräferenzen."

Listen von "Don'ts" ohne "Do's." "Verwende keine Tabellen für Layout. Verwende keine Inline-Styles. Lade keine Daten in Komponenten." Negative Anweisungen sind für Modelle schwieriger zu befolgen als positive. Formulier um: "Verwende CSS Grid für Layout. Verwende Tailwind Utility-Klassen. Lade Daten in einer dedizierten Service-Schicht." Sowohl die Prompting-Dokumentation von OpenAI als auch die von Google machen diesen Punkt explizit.

Sicherheit nachträglich draufschrauben. KI-generierter Code ist nicht standardmäßig sicher. Eine Analyse aus 2025 ergab, dass 62% des KI-generierten Codes Design-Fehler oder bekannte Sicherheitslücken enthält. Eine einfache Sicherheitserinnerung in deinen Prompt aufzunehmen -- "validiere alle Benutzereingaben, verwende parametrisierte Abfragen, lege niemals Zugangsdaten in Antworten offen" -- erhöhte die Rate von sicherem Code-Output in einer Studie von 56% auf 66%. Kein Allheilmittel, aber eine bedeutsame Verbesserung für eine einzelne Textzeile.

Sich auf die KI als einzigen Wächter verlassen. Vertrau niemals dem Modell allein bei der Durchsetzung von Berechtigungen, Rate-Limits oder Datenzugriffsregeln. Es könnte Regeln "vergessen", besonders in langen Gesprächen oder komplexen Apps. Berechtigungsprüfungen sollten im Code durchgesetzt werden. Behandle alles, was die KI generiert, als ersten Entwurf, der verifiziert werden muss -- insbesondere für sicherheitskritische Pfade.

Der Meta-Prompt: Die KI bitten, bessere Prompts zu schreiben

Eine der am wenigsten genutzten Techniken beim KI-App-Building: Die KI selbst bitten, deinen Prompt zu verbessern, bevor du ihn zum Bauen verwendest.

Der Prozess ist einfach:

Schreib deinen groben Prompt -- auch ein unordentlicher Absatz ist in Ordnung
Bitte die KI: "You are a prompt engineering expert. Review the following app-building prompt and identify what's missing, ambiguous, or likely to produce unexpected results. Then rewrite it."
Beantworte alle klärenden Fragen, die die KI stellt
Verwende den verbesserten Prompt für den tatsächlichen Build

Du kannst das mit einem strukturierten Meta-Prompt weitertreiben:

Du bist Experte für KI-gestützte App-Entwicklung. Ich möchte Folgendes bauen:

"""[deine grobe Idee hier]"""

Stell mir bis zu 10 Fragen, die du beantwortet brauchst, um einen effektiven,
detaillierten Prompt für einen KI-App-Builder zu schreiben. Fokussier dich auf:
- Umfangsgrenzen (was gehört rein, was nicht)
- Benutzerrollen und Berechtigungen
- Datenmodelle und Beziehungen
- Workflows und bedingte Logik
- Randfälle und Fehlerbehandlung
- Design- und UX-Präferenzen

Nachdem ich geantwortet habe, generiere den finalen strukturierten Prompt, den ich verwenden soll.

Das funktioniert, weil KI-Modelle oft besser darin sind zu erkennen, was in einer Spezifikation fehlt, als die richtigen Standardwerte zu erraten. Der Meta-Prompt verwandelt die KI in einen Anforderungsanalysten, bevor sie zum Builder wird.

Testen und Iterieren: Prompts als lebende Dokumente behandeln

Der erste Prompt, der funktioniert, ist selten der beste. Wie Code brauchen Prompts Tests, Versionierung und Verfeinerung.

Ein praktischer Iterationszyklus:

1. Definier, was "korrekt" bedeutet. Bevor du einen Prompt ausführst, notier drei bis fünf konkrete Ergebnisse, die du als erfolgreich akzeptieren würdest. "Die Login-Seite hat E-Mail- und Passwort-Felder, einen 'Passwort vergessen'-Link und zeigt eine spezifische Fehlermeldung bei ungültigen Zugangsdaten."

2. Führ den Prompt aus und notier Fehler. Nicht nur "es funktioniert nicht" -- kategorisier, was schiefgelaufen ist. Fehlendes Feature? Falsches Format? Sicherheitslücke? Falsche Logik? Jeder Fehlertyp hat eine andere Lösung.

3. Reparier jeweils eine Sache. Widersteh dem Drang, den gesamten Prompt nach einem Fehler umzuschreiben. Füg die fehlende Einschränkung hinzu, klär den mehrdeutigen Begriff oder füg ein Beispiel hinzu. Dann führ erneut aus. Zu viele Dinge gleichzeitig zu ändern macht es unmöglich zu wissen, was das Problem behoben hat.

4. Speicher Prompts, die funktionieren. Wenn ein Prompt gute Ergebnisse liefert, speicher ihn als Vorlage. Im Laufe der Zeit sammelst du eine Bibliothek von "goldenen Prompts" für gängige Muster -- Benutzerauthentifizierungs-Flows, CRUD-Oberflächen, Suchfunktionen, Benachrichtigungssysteme.

5. Test erneut beim Modellwechsel. Ein für ein KI-Modell optimierter Prompt kann bei einem anderen anders funktionieren. Wenn du Modelle wechselst (oder deine Plattform ihr Modell aktualisiert), führ deine Tests erneut aus. Die Prompt-Engineering-Community hat wiederholt beobachtet, dass Prompt-Strategien nicht universell zwischen Modellen übertragbar sind -- was für Claude funktioniert, kann bei GPT-4 unterdurchschnittlich abschneiden und umgekehrt.

Einige Teams -- insbesondere Agenturen, die Apps für mehrere Kunden bauen -- verwenden dedizierte Tools für die Prompt-Evaluierung. Promptfoo (Open Source, CLI-basiert) lässt dich Testfälle in YAML definieren und Prompts im Batch dagegen ausführen. DeepEval integriert sich in Python-Test-Suites. Für die meisten einzelnen Builder reicht jedoch ein einfaches Dokument, das "Prompt-Version, Testergebnisse, vorgenommene Änderungen" verfolgt, um auf Kurs zu bleiben.

Plattformspezifische Tipps

Verschiedene KI-Builder handhaben Kontext auf unterschiedliche Weise. Einige Anmerkungen zu den Plattformen, denen du am ehesten begegnen wirst:

Bolt.new gibt der KI die volle Kontrolle über das browserbasierte Dateisystem, Terminal und Server. Leg die Architektur in deinem ersten Prompt fest -- Framework-Wahl, Layout-Struktur, Design-Sprache. Nachfolgende Prompts können dann "im gleichen Stil" referenzieren, ohne alles zu wiederholen. Sei dir bewusst, dass die Kontextbeibehaltung nachlassen kann, sobald Projekte über 15-20 Komponenten hinauswachsen.

Lovable unterstützt eine persistente Knowledge Base mit Kategorien für Projektrichtlinien, Benutzer-Personas, Design-Assets und Codierungskonventionen. Es hat auch ein docs/-Ordner-Memory-System (memory.md, architecture.md usw.), das über Sitzungen hinweg bestehen bleibt. Nutz das, um zu vermeiden, dass du Kontext in jedem Prompt wiederholen musst. Eine Aktion pro Prompt funktioniert tendenziell besser als mehrstufige Anfragen.

Replit Agent bietet einen "Plan-Modus", in dem du die Architektur besprechen kannst, bevor du baust. Nutz ihn. Der "Improve Prompt"-Button ist ebenfalls einen Versuch wert -- er formuliert deinen Prompt spezifischer um. Replits Checkpoint-System lässt dich sicher zurückrollen, sodass du aggressiver experimentieren kannst.

v0 (Vercel) ist auf React/Next.js UI-Generierung spezialisiert. Es versteht shadcn/ui-Komponenten nativ und unterstützt ein Registry-System zum Übergeben von Design-Tokens an das Modell. Wenn du v0 für Frontend-Arbeit verwendest, liefert das Bereitstellen einer tailwind.config und globals.css-Datei bessere Ergebnisse als die Beschreibung von Farben in Prosa.

Cursor verwendet .cursor/rules/-Dateien (mit .mdc-Erweiterung), um der KI persistenten Kontext bereitzustellen. Richte diese ein, bevor du mit dem Bauen beginnst -- sie sind effektiver als die Wiederholung von Anweisungen in jedem Prompt. Starte einen neuen Chat für jede Aufgabe; lange Konversations-Threads verursachen Kontextabweichung.

Chattee verfolgt einen Zweiphasen-Ansatz: zuerst eine Planungsphase, in der die KI einen Implementierungsplan erstellt, dann eine Ausführungsphase, in der sie baut. Dieses Plan-dann-Ausführen-Muster gibt dir einen Prüfpunkt, um das Verständnis der KI zu überprüfen, bevor sie Code schreibt -- Fehlinterpretationen werden erkannt, bevor sie zu fehlkonstruierten Features werden. Die Plattform generiert Full-Stack-Anwendungen (Datenbank, Authentifizierung, Geschäftslogik und UI) aus natürlicher Sprache und kümmert sich um das Deployment auf eigenen Domains.

Alles zusammenführen: Ein echter Prompt, von Anfang bis Ende

Um alles zusammenzuführen, stell dir vor, du bist Operations-Manager bei einem mittelgroßen Unternehmen und brauchst ein internes Tool für die Verwaltung von Gerätewartungsanfragen. Der vollständige Prompting-Prozess könnte etwa so aussehen.

Schritt 1: Grobe Idee (Meta-Prompt)

Ich brauche eine interne Web-App zur Verfolgung von Gerätewartungsanfragen
in unserem Produktionswerk. Etwa 200 Mitarbeiter, 50 größere Geräte.
Aktuell nutzen wir Tabellen und E-Mail -- ein einziges Chaos.

Stell mir die Fragen, die du beantwortet brauchst, um einen detaillierten
Prompt für einen KI-App-Builder zu schreiben.

Die KI könnte fragen: Wer reicht Anfragen ein? Wer genehmigt sie? Welche Informationen werden erfasst? Gibt es Prioritätsstufen? Was passiert, wenn die Wartung abgeschlossen ist? Gibt es ein Benachrichtigungssystem? Was ist mit wiederkehrenden Wartungsplänen?

Schritt 2: Beantworte die Fragen und erhalte einen strukturierten Prompt zurück

Nach der Beantwortung generiert die KI etwas wie dies (das du verfeinerst):

TITEL: Gerätewartungs-Anfragen-Tracker

ZIEL: Tabellenbasierte Wartungsverfolgung durch eine Web-App ersetzen,
mit der Werkspersonal Probleme melden, Wartungsteams triagieren und
beheben, und Manager den Status auf einen Blick sehen können.

BENUTZER:
- Werkspersonal (200 Personen): Anfragen einreichen, Fotos anhängen,
  Status eigener Einreichungen prüfen
- Wartungsteam (12 Personen): Queue einsehen, Anfragen beanspruchen,
  Status aktualisieren, Lösungsnotizen dokumentieren
- Werksleiter (3 Personen): Dashboard-Überblick, kostenintensive
  Reparaturen genehmigen (über 2000 USD), Berichte exportieren

DATENMODELL:
- equipment (id, name, location, type, installation_date, status)
- maintenance_requests (id, equipment_id FK, submitted_by FK,
  priority ENUM(low/medium/high/critical), description, photos[],
  status ENUM(submitted/triaged/in_progress/pending_approval/resolved/closed),
  created_at, resolved_at)
- resolution_notes (id, request_id FK, author_id FK, note_text, created_at)

BERECHTIGUNGEN (standardmäßig verweigern):
- floor_staff: Anfragen erstellen, eigene Anfragen einsehen, Fotos zu
  eigenen Anfragen hochladen
- maintenance_team: alle Anfragen einsehen, beanspruchen (sich selbst
  zuweisen), Status aktualisieren, Lösungsnotizen hinzufügen
- facility_manager: alle maintenance_team-Berechtigungen + kostenintensive
  Reparaturen genehmigen + Dashboard einsehen + CSV exportieren

WORKFLOWS:
- Anfrage einreichen, Priorität automatisch nach Gerätetyp zuweisen,
  Wartungsteam triagiert, beansprucht, bearbeitet, löst
- Wenn geschätzte_kosten über 2000 USD, Status wechselt zu pending_approval,
  Werksleiter genehmigt oder lehnt mit Kommentar ab
- Wenn Anfrage innerhalb von 4 Stunden nicht beansprucht und Priorität = critical,
  Werksleiter benachrichtigen

RANDFÄLLE:
- Foto-Upload schlägt fehl: Retry-Button zeigen, Anfragetexte ohne Fotos speichern
- Doppelte Anfrage für dasselbe Gerät innerhalb von 24 Stunden: Einreicher warnen,
  anbieten, eine Notiz zur bestehenden Anfrage hinzuzufügen
- Gerät nicht im System: "Sonstiges"-Auswahl mit Freitext-Beschreibung erlauben,
  für Admin markieren, um es zur Geräteliste hinzuzufügen

DESIGN:
- Klar, funktional (kein Consumer-Chic -- das ist ein Werkstatt-Tool)
- Große Touch-Bereiche (wird auf Tablets mit Handschuhen benutzt)
- Kontrastreiches Farbschema für Sichtbarkeit in hellen Umgebungen
- Mobile-First für Werkspersonal, Desktop-optimiert für Manager-Dashboard

Schritt 3: Iterativ bauen

Füg nicht diesen gesamten Prompt ein und sag "los." Füttere ihn in Etappen:

Datenmodell und Schema zuerst -- überprüf, ob es sinnvoll ist
Einreichungs-Flow für Werkspersonal -- teste mit dem Happy Path und einem Randfall
Wartungsteam-Queue und Workflow -- überprüf Beanspruchung und Statusaktualisierungen
Manager-Dashboard und Genehmigungsfluss
Benachrichtigungen und Warnungen

Jede Phase bekommt ihren eigenen fokussierten Prompt, mit der Gesamtspezifikation als Kontext.

Kurzreferenz: Prinzipien, die auf jeder Plattform gelten

Anweisungen zuerst, Kontext danach. Setz das, was getan werden soll, an den Anfang. Referenzmaterial kommt darunter, klar abgetrennt.
Sei spezifisch beim Format. Wenn du strukturierte Daten brauchst, zeig die Form. Wenn du eine UI brauchst, nenne die Komponentenbibliothek. Wenn du eine Datenbank brauchst, nenne die Technologie.
Zeigen, nicht nur erzählen. Zwei oder drei Beispiele der gewünschten Ausgabe schlagen einen Absatz abstrakter Anforderungen.
Sag, was zu tun ist, nicht nur was nicht zu tun ist. "Validiere alle Benutzereingaben auf dem Server" funktioniert besser als "vertraue nicht auf clientseitige Daten."
Eine Aufgabe, ein Prompt. Komplexe Features, die Scheibe für Scheibe gebaut werden, erzeugen sauberere, besser debugbare Ergebnisse als Mega-Prompts.
Formulier Sicherheitsanforderungen explizit. Eingabevalidierung, Auth-Prüfungen, Datenzugriffsgrenzen -- nimm nie an, die KI fügt diese von selbst hinzu.
Teste Randfälle, nicht nur Happy Paths. Beschreib für jedes Feature mindestens ein Fehlerszenario: fehlende Eingabe, verweigerte Berechtigung, externer Dienst nicht verfügbar.
Speicher, was funktioniert. Bau eine Bibliothek bewährter Prompts für Muster auf, die du wiederholt verwendest.
Überprüf die Arbeit der KI. Review generierten Code so, wie du die Arbeit eines Auftragnehmers reviewen würdest. Prüf Berechtigungslogik, Datenverarbeitung und Fehlerzustände -- besonders vor dem Deployment für echte Benutzer.

Die Lücke zwischen einer frustrierenden und einer produktiven KI-Builder-Erfahrung liegt fast nie an den Fähigkeiten des Tools. Sie liegt an der Klarheit der Anweisungen, die du ihm gibst. Die gute Nachricht: Anders als Programmieren zu lernen, ist das Erlernen effektiver Prompts etwas, das du an einem Nachmittag bedeutsam verbessern kannst -- und die Rendite steigt mit jedem Projekt, das du baust.