Saubere Prompts: Präzise formulieren, Token sparen

Der Unterschied zwischen einem vagen Prompt und einem präzisen ist der Unterschied zwischen drei Stunden Debugging und einer funktionierenden Lösung. Prompts sind kein Smalltalk — sie sind technische Spezifikationen. Und wie bei jeder Spezifikation gilt: je genauer, desto besser das Ergebnis.

Anatomie eines guten Prompts

Ein guter Prompt hat vier Bestandteile. Erstens den Kontext: Was existiert bereits? Welche Datei, welche Klasse, welche Methode betrifft die Aufgabe? Zweitens die Aufgabe: Was soll konkret passieren? Drittens die Constraints: Was darf nicht passieren? Und viertens das Ausgabeformat: Wie soll das Ergebnis geliefert werden — als komplette Datei, als Diff, als Erklärung mit Codebeispielen?

Die meisten Entwickler schreiben nur den zweiten Teil. „Erstelle eine Funktion, die Benutzerdaten validiert.“ Das ist wie ein Git-Issue ohne Akzeptanzkriterien — technisch machbar, aber das Ergebnis wird nicht das sein, was du dir vorstellst. Kontext und Constraints sind wichtiger als die Aufgabe selbst, weil sie den Lösungsraum eingrenzen. Ohne sie hat die KI unendlich viele Optionen und wählt die statistisch häufigste — nicht die, die zu deinem Projekt passt.

Eine Faustregel, die sich bewährt hat: Wenn dein Prompt kürzer ist als die erwartete Antwort, ist er wahrscheinlich zu vage. Ein Prompt mit drei Wörtern erzeugt eine Antwort mit dreihundert Zeilen — und von denen passen vielleicht zwanzig zu deinem Projekt. Ein Prompt mit dreißig Wörtern erzeugt eine Antwort mit fünfzig Zeilen, von denen fünfundvierzig direkt verwendbar sind. Die Investition in den Prompt zahlt sich immer aus.

Hier ein konkretes Beispiel. Der schlechte Prompt: „Mach die Funktion besser.“ Was heißt besser? Performanter? Lesbarer? Kürzer? Sicherer? Besser getestet? Die KI entscheidet selbst — und ihre Definition von „besser“ deckt sich selten mit deiner. Sie refaktoriert vielleicht die gesamte Klasse, obwohl du nur eine Schleife optimieren wolltest. Der gute Prompt sieht anders aus:

In src/Service/PriceCalculator.php, Methode calculateDiscount():
- Ersetze die foreach-Schleife (Zeile 42-58) durch array_filter + array_map
- Entferne die temporäre Variable $filteredItems
- Return-Type auf float ändern (aktuell mixed)
- Keine weiteren Änderungen an der Klasse

Der zweite Prompt ist fünfmal so lang wie der erste, aber er spart dir eine Stunde Nacharbeit. Die KI weiß exakt, welche Datei, welche Zeilen, welche Transformation, und — entscheidend — was sie nicht anfassen soll. Der letzte Punkt ist der wichtigste: Ohne die explizite Einschränkung „keine weiteren Änderungen“ würde die KI wahrscheinlich auch die benachbarten Methoden „verbessern“, die Variablennamen vereinheitlichen und die PHPDoc-Blöcke umschreiben.

Token sparen — weniger Kontext, bessere Ergebnisse

Der Reflex ist verständlich: je mehr Kontext die KI hat, desto besser versteht sie das Projekt, desto besser der Output. Das stimmt nicht. Mehr Kontext bedeutet mehr Rauschen. Die KI zieht Informationen aus Dateien, die mit deiner Frage nichts zu tun haben, und baut Annahmen darauf auf, die dich in die Irre führen. Ich habe erlebt, wie eine KI den Coding-Style einer Test-Fixture als Vorbild genommen hat, weil die Datei im Kontext war — obwohl sie offensichtlich nicht den Produktionscode-Standard darstellte.

Statt dein gesamtes Repository in den Kontext zu laden, verweise auf Dateien. „Die Konfiguration steht in config/services.yaml, Zeile 15-30″ ist besser als die gesamte Datei zu pasten. Die KI kann in den meisten Tools die Datei selbst lesen — du musst ihr nur sagen, wo sie nachschauen soll. Das spart Token für die eigentliche Antwort und hält den Fokus auf dem Problem.

Die 80/20-Regel des Promptings: 20% des möglichen Kontexts liefern 80% der Qualität. Ein Prompt mit der relevanten Methode, dem erwarteten Verhalten und zwei Constraints bringt bessere Ergebnisse als das gesamte Projekt im Kontext. Ich habe das in dutzenden Projekten getestet — fokussierter Kontext gewinnt immer. Bei einem Shopware-Plugin mit 80 Klassen ist es kontraproduktiv, alle 80 als Kontext zu laden, wenn du nur eine einzige Methode ändern willst.

Iterativ arbeiten statt alles auf einmal

Der größte Fehler, den ich bei Entwicklern sehe: Sie versuchen, ein komplettes Feature in einem einzigen Prompt zu generieren. „Erstelle mir ein komplettes User-Management mit Registrierung, Login, Passwort-Reset, Rollenmodell und Admin-Panel.“ Das Ergebnis sind 500 Zeilen Code, die auf den ersten Blick funktionieren und auf den zweiten Blick voller subtiler Fehler stecken — eine Autorisierungsprüfung fehlt hier, eine Race-Condition versteckt sich dort.

Kleine Schritte, häufiges Review. Erst das Datenmodell. Review. Dann die Registrierung. Review. Dann der Login. Review. Jeder Schritt baut auf dem geprüften vorherigen auf. Fehler werden früh erkannt, wenn sie noch billig zu beheben sind — nicht erst, wenn 500 Zeilen aufeinander aufbauen und ein Fehler in Zeile 30 alles danach kaputt macht. Das ist keine KI-spezifische Weisheit, das ist Softwareentwicklung 101 — aber bei KI-generiertem Code vergessen es viele.

Iteratives Arbeiten hat noch einen Vorteil: Du kannst die Qualität jedes Schrittes beurteilen und den nächsten Prompt entsprechend anpassen. Wenn die KI im ersten Schritt einen bestimmten Architekturstil gewählt hat, kannst du im zweiten Prompt darauf aufbauen oder korrigieren. Wenn sie einen Ansatz gewählt hat, der dir nicht gefällt, ist der Preis eines Neustarts niedrig — du wirfst 30 Zeilen weg, nicht 300. Bei einem Monolith-Prompt hast du diese Möglichkeit nicht.

Wann ein langer Prompt trotzdem sinnvoll ist

Es gibt Ausnahmen. Wenn du eine komplexe Datentransformation brauchst — etwa eine Migration von Schema A nach Schema B mit zehn Mapping-Regeln — dann gehört alles in einen Prompt. Die KI muss alle Regeln gleichzeitig kennen, weil sie sich gegenseitig beeinflussen. Hier ist ein langer, detaillierter Prompt besser als fünf kurze, die jeweils nur einen Teil der Regeln kennen.

Dasselbe gilt für Code-Reviews: Wenn du der KI eine Klasse zur Review gibst, braucht sie den gesamten Code, die relevanten Interfaces und den Testcode. Hier den Kontext zu beschneiden wäre kontraproduktiv. Die Faustregel: Generierung braucht fokussierten Kontext, Analyse braucht vollständigen Kontext. Wissen, wann welcher Ansatz passt, ist Teil des Handwerks.

Sprache — präzise wie ein Ticket, nicht wie ein Gespräch

Die KI ist kein Gesprächspartner, dem du vage Wünsche mitteilst. Sie ist ein sehr schneller, sehr literaler Junior-Entwickler. Wenn du sagst „mach das performanter“, optimiert sie vielleicht den Algorithmus, vielleicht das Caching, vielleicht die Datenbankabfragen — du weißt es vorher nicht. Wenn du sagst „ersetze die N+1-Query in getOrderItems() durch einen JOIN“, bekommst du exakt das. Und nur das.

Verben sind wichtig. „Erstelle“ bedeutet eine neue Datei. „Ändere“ bedeutet eine bestehende Datei. „Entferne“ bedeutet Löschen. „Refaktoriere“ bedeutet gleiche Funktionalität, andere Struktur. Jedes Verb löst bei der KI ein anderes Verhalten aus — wähle es bewusst. „Überarbeite die Klasse“ ist nicht dasselbe wie „Ändere die Methode calculateTotal“. Das erste gibt der KI Carte blanche über die gesamte Datei, das zweite fokussiert auf einen einzigen Punkt.

Negationen sind mächtig. „Keine zusätzlichen Methoden“, „kein neues Interface“, „keine Änderungen an bestehenden Tests“ — solche Constraints verhindern, dass die KI über das Ziel hinausschießt. Ohne sie neigt sie dazu, alles zu verbessern, was sie sieht, auch wenn du nur eine einzige Zeile ändern wolltest. In meinen Prompts stehen fast immer mehr Dinge, die die KI nicht tun soll, als Dinge, die sie tun soll. Das klingt paradox, liefert aber die besten Ergebnisse.

Denk an Prompts wie an Git–Commit-Messages: kurz, präzise, auf den Punkt. Kein Smalltalk, keine Höflichkeitsfloskeln, keine Erklärung warum du die Frage stellst. Die KI braucht das nicht — sie braucht klare Anweisungen, klare Constraints und ein klares Ausgabeformat. Alles andere ist verschwendete Token, die du besser für den eigentlichen Code verwendest.

Prompt-Templates für wiederkehrende Aufgaben

Wenn du feststellst, dass du denselben Prompt-Typ immer wieder schreibst, lohnt sich ein Template. Ein Code-Review-Prompt hat immer die gleiche Struktur: „Prüfe [Datei] auf [Kriterien]. Achte besonders auf [Schwerpunkte]. Ignoriere [Ausnahmen].“ Ein Refactoring-Prompt ebenfalls: „In [Datei], Methode [Name]: [Transformation]. Keine weiteren Änderungen.“ Solche Templates sparst du dir als Snippets und passt sie pro Aufgabe an.

Das spart nicht nur Tipparbeit, sondern erzwingt die Struktur, die gute Prompts auszeichnet. Wenn du ein Template mit vier Feldern hast — Kontext, Aufgabe, Constraints, Format — vergisst du keines davon. Das Template ist dein Qualitätssiegel für Prompts, genau wie ein Ticket-Template dein Qualitätssiegel für Anforderungen ist.

In meinen Projekten habe ich fünf Standard-Templates: Feature-Implementierung, Refactoring, Bug-Fix, Code-Review, Test-Generierung. Jedes hat eine andere Struktur, weil jede Aufgabe andere Informationen erfordert. Ein Bug-Fix-Prompt braucht die Fehlerbeschreibung und die Reproduktionsschritte, ein Feature-Prompt braucht die Akzeptanzkriterien. Templates erzwingen diese Unterscheidung und verhindern, dass du aus Gewohnheit immer den gleichen vagen Prompt schreibst.

Prompts sind eine Fähigkeit, die du trainieren kannst. Je mehr du darüber nachdenkst, was du willst, bevor du tippst, desto besser wird das Ergebnis. Das klingt trivial, aber die meisten Entwickler tippen los, drücken Enter und beschweren sich dann über den Output. Die Lösung liegt fast immer im Prompt, nicht im Modell.

Alle Teile dieser Serie

Teil 1: Projekt vorbereiten — Dateien, Struktur, Kontext
Teil 2: Gute Regeln schreiben — der KI Grenzen setzen
Teil 3: Saubere Prompts — präzise formulieren, Token sparen
Teil 4: Modelle und Tools — Stärken, Schwächen, Einsatzgebiete
Teil 5: Sicherheit — was nicht in den Prompt gehört
Teil 6: Reviews — warum der Mensch das letzte Wort haben muss
Teil 7: Wann KI nicht nutzen — die Grenzen kennen
Glossar: Begriffe für Entwickler