Was muss tatsächlich in einen Build-Prompt?
Vier Dinge, und das sage ich, nachdem ich zugesehen habe, wie sich etwa zweihundert davon in fertige Websites verwandelt haben: was es ist, für wen es ist, die Must-haves und — optional — eine Stimmung. Alles andere ist Rauschen, das der Builder ohnehin mit Standardwerten füllt — die eigentliche Fähigkeit besteht also nicht darin, mehr zu schreiben, sondern zu erkennen, zu welchem dieser vier Punkte man wirklich eine Meinung hat, und nur das zu sagen.
Beginne mit dem, was es ist, und bleib dabei bei einer Kategorie, nicht bei einer Spezifikation. „Eine Buchungswebsite für ein Yogastudio“ ist besser als „eine Website, auf der Leute Termine sehen und einen Button klicken, um einen Platz zu reservieren und eine Bestätigung zu bekommen“, obwohl der zweite Satz mehr Information enthält. Die Kategorie aktiviert Standardwerte, die der Builder bereits kennt — Zeitpläne sehen wie Zeitpläne aus, Buchungsabläufe wie Buchungsabläufe —, während die Beschreibung ihn dazu zwingt, die Kategorie erst von Grund auf zu rekonstruieren.
Muss ich sagen, für wen es ist?
Man muss nicht, aber das ist der Satz, den Leute überspringen, die es nicht sollten. „Für die bestehenden Kursteilnehmer des Studios“ und „für Leute, die das Studio zum ersten Mal entdecken“ ergeben fast überall dort unterschiedliche Websites, wo es zählt — Tonalität der Texte, ob es einen großen Marketing-Hero gibt oder ein direktes Layout zum Terminplan, ob die Preise vorne stehen (neue Besucher brauchen sie) oder eher versteckt sind (Stammkunden kennen sie schon). Ein Nebensatz hier kann hundert kleine Unklarheiten auflösen, die eine ganze Seite Funktionswünsche nie klären würde. Ist die Zielgruppe wirklich allgemein, lässt man es weg — man sollte keine erfinden, nur um die Lücke zu füllen.
Wie viele Must-haves sollte ich aufführen?
Zwei oder drei. Der Test, den ich anwende: Würde man den ersten Build ablehnen, weil das fehlt? „Kursplan, Online-Zahlungen, Trainer-Profile“ besteht diesen Test für ein Yogastudio — ohne Kursplan ist es keine kleinere Version der Website, sondern eine andere Website. „Eine Newsletter-Anmeldung im Footer“ besteht den Test fast nie; das ist ein Nice-to-have, und Nice-to-haves gehören in den Nachfolgechat, sobald man einen Plan gesehen hat, nicht in den ursprünglichen Prompt hineingequetscht, wo sie mit den wirklich wichtigen Dingen konkurrieren.
Das ist ehrlich gesagt die Zutat, bei der Leute in beide Richtungen am meisten danebenliegen. Null Must-haves, und der Builder rät — manchmal falsch. Acht Must-haves, und der Builder behandelt alle acht als gleich tragend, und was zurückkommt, liest sich wie eine Funktionsliste im Website-Kostüm — keine Hierarchie, kein Raum zum Atmen. Wenn ich mich gegen das Weglassen einer einzigen Zutat wehren müsste, dann gegen diese. Schon ein einziger Nebensatz mit „den zwei Dingen, die das zu meinem Projekt machen“ spart fast immer eine Extrarunde, weil das die einzige Information ist, die der Builder aus der Kategorie allein nicht ableiten kann.
Sollte ich eine Stimmung angeben?
Nur, wenn man eine hat. Viele gute Prompts lassen das komplett weg, und das ist völlig in Ordnung — der Design Director legt sich auf eine Art Gestaltung fest, egal ob man eine vorgibt oder nicht. Eine Stimmung in zwei Worten („warm und handgezeichnet“, „klinisch und schnell“, „wie eine Spielhalle aus den 90ern“) lenkt diese Festlegung nur in eine bestimmte Richtung, statt sie den Standardwerten der Kategorie zu überlassen. Wenn man eine starke Reaktion hat — man weiß, dass man cremefarbene Hintergründe und warme Serifenschrift will, oder man weiß, dass man abgerundete Ecken hasst —, lohnt sich dieser Satz. „Klar und modern“ zählt übrigens nicht dazu. Das ist keine Stimmung, sondern das Fehlen einer solchen, und es lenkt nirgendwohin, kostet aber trotzdem einen Platz.
Warum nicht einfach alles beschreiben, was ich mir vorstelle?
Weil der Builder es umsetzt. Das ist der eigentliche Fehlerfall, und er ist nicht das, was man erwartet — es liegt nicht daran, dass zu viel Information den Builder verwirrt, sondern daran, dass jeder Satz, den man schreibt, als Anweisung gelesen wird, einschließlich der halbfertigen Gedanken, die man beim zweiten Hinschauen bereitwillig verwerfen würde. Ich habe schon miterlebt, wie jemand „vielleicht einen Testimonial-Bereich, bin mir nicht sicher“ geschrieben hat und einen Testimonial-Bereich mit drei Platzhalterzitaten zurückbekam, weil „vielleicht, bin mir nicht sicher“ für einen menschlichen Leser eine Einschränkung ist, für ein System, das einen beim Wort nimmt, aber ein Funktionswunsch.
Das würde keine Rolle spielen, wenn Unterspezifizierung teuer wäre, so wie bei einem menschlichen Entwicklerteam, wo Unklarheit einen zwei Wochen kostet, bevor jemand merkt, dass das Falsche gebaut wurde. Hier ist es nicht teuer. Der Builder plant, bevor er baut — man sieht einen konkreten Vorschlag, bevor überhaupt etwas in Code umgesetzt wird —, also kostet Unterspezifizierung nur eine fünfminütige Korrektur in dem Chat, während Überspezifizierung genau in dem Moment alle schwächsten, halbfertigen Ideen vorne anstellt, in dem man am wenigsten Informationen hat, um zu wissen, welche davon es überhaupt wert sind, behalten zu werden. Zehn Wörter echter Anforderungen schlagen zweihundert Wörter Bewusstseinsstrom, nicht weil mehr Information an sich schlecht wäre, sondern weil in genau dieser Oberfläche jedes zusätzliche Wort eine Verpflichtung ist.
Es gibt noch einen leiseren Nachteil: Es macht die Hierarchie flach. Führt man zwölf Funktionen mit gleicher Betonung auf, hat der Builder kein Signal, welche drei davon einem wirklich wichtig sind, und gibt entweder allen zwölf das gleiche visuelle Gewicht (unübersichtlich) oder rät bei der Priorität (manchmal falsch, und jetzt debuggt man eine Vermutung, statt eine Präferenz geäußert zu haben). Drei klar formulierte Must-haves schützen diese Hierarchie. Zwölf in einem Absatz löschen sie aus.
Wie sieht ein guter Prompt tatsächlich aus?
| Prompt | Warum es funktioniert |
|---|---|
| „Ein Trainingslogbuch für Kletterer — Sessions, Schwierigkeitsgrade, Fortschrittsdiagramme.“ | Was, plus drei Must-haves, insgesamt zehn Wörter an Anforderungen. Kein Hinweis auf die Zielgruppe, weil „Kletterer, die ihr eigenes Training protokollieren“ aus der Kategorie offensichtlich hervorgeht — es lässt korrekterweise genau die eine Zutat weg, die hier keine Wirkung hätte. |
| „Eine Landingpage für meinen Podcast über urbane Landwirtschaft, warm und redaktionell, mit einer Episodenliste und einem Anmeldeformular.“ | Was, Zielgruppe durch „meinen Podcast“ impliziert, Stimmung, zwei Funktionen. Es steht nicht dabei, welcher Player die Episoden einbettet oder wie viele pro Seite angezeigt werden — das sind Fragen für die zweite Runde, nicht für den ursprünglichen Prompt. |
| „Ein Air-Hockey-Spiel für zwei Spieler, echte Physik, eine Tastatur.“ | Bei Spielen wird dieses Muster besonders deutlich: Genre plus die eine Einschränkung, die bestimmt, wie es sich tatsächlich spielt. „Echte Physik“ und „eine Tastatur“ sind weniger Funktionen als vielmehr die zwei Entscheidungen, die darüber bestimmen, ob es sich wie das Spiel im eigenen Kopf anfühlt. Tischfarbe, Puckspuren, Punkteanzeige — das schlägt der Builder vor, man reagiert darauf. |
Was alle drei verbindet, ist nicht Kürze um ihrer selbst willen, sondern dass jedes Wort eine Aufgabe erfüllt. Streicht man „warm und redaktionell“ aus dem Podcast-Prompt, bekommt man eine generische Podcast-Seite; streicht man „urbane Landwirtschaft“, hat das Stimmungswort nichts mehr, worauf es sich beziehen kann. Das ist der eigentliche Test dafür, ob ein Prompt gut formuliert ist — nicht die Wortzahl. Ich würde einen 40-Wörter-Prompt bevorzugen, bei dem sich jeder Nebensatz seinen Platz verdient, gegenüber einem 15-Wörter-Prompt, der nur um der Kürze willen knapp ist und still und leise ein Must-have unterschlägt.
Was, wenn ich bereits Markenfarben oder echte Fotos habe?
Häng sie an. Beschreib sie nicht. Ich habe schon erlebt, wie jemand einen sorgfältigen Absatz schreibt, um eine Markenpalette in hex-naher Sprache zu umreißen – „ein tiefes Waldgrün, eher gedeckt“ –, während die tatsächlichen Markenrichtlinien die ganze Zeit als PDF auf dem Desktop lagen. Eine beschriebene Farbe ist eine Vermutung, die der Builder erst rekonstruieren muss; eine angehängte ist einfach korrekt. Echte Speisekarten, echte Fotos, Markenmaterialien – die Wissens- und Referenzfunktionen spielen sie direkt in den Build ein, und Fakten schlagen Beschreibungen von Fakten jedes Mal.
