Wie man bessere KI-Prompts schreibt: Der fehlende Kontext, der KI-Vorschläge wirklich nützlich macht

Bessere KI-Prompts sind nicht unbedingt länger. Sie enthalten den Kontext, den ein Assistent benötigt, um die richtige Entscheidung zu treffen, statt lediglich eine plausibel wirkende Änderung zu erzeugen. Bei der Entwicklungsarbeit bedeutet das in der Regel, den Umfang, die Annahme, das gewünschte Ergebnis, die Einschränkungen und den Grund zu benennen, warum die Änderung wichtig ist.

Das ist der Unterschied zwischen einer Antwort, die kompiliert, und einer Änderung, die dem Produkt hilft.

Ein Assistent kann aus einer kurzen Anweisung gültigen Code schreiben, aber eine kurze Anweisung verschleiert oft die Produktentscheidung. „Entferne die Seitenleiste auf Mobilgeräten“ sagt dem Assistenten, was er ändern soll. Es sagt ihm nicht, ob das Desktop-Verhalten unverändert bleiben muss, warum das aktuelle Verhalten Menschen beeinträchtigt oder woran Erfolg zu erkennen ist.

Wenn dieser Kontext fehlt, muss der Assistent raten. Er kann eine technisch saubere Änderung vornehmen, die einen nützlichen Desktop-Ablauf entfernt, ein nicht zusammenhängendes Layout verändert oder ein Symptom statt des Problems löst.

Verwende einen Prompt als kompaktes Engineering-Briefing, nicht als Befehl.

Beginne mit diesen sechs Informationen:

1. Umfang: Welche Ansicht, Dateien, welcher Ablauf oder welches Verhalten gehört zum Umfang?
2. Problem: Was ist für eine Person, die das Produkt nutzt, schwierig, fehlerhaft, langsam oder verwirrend?
3. Annahme: Was glaubst du, verursacht das Problem?
4. Gewünschtes Ergebnis: Was sollte nach Abschluss der Arbeit zutreffen?
5. Einschränkungen: Was muss unverändert bleiben, und welche Ansätze sind ausgeschlossen?
6. Bitte um Belege: Bitte den Assistenten, die Annahme zu hinterfragen und zu erklären, was er zuerst prüfen würde.

Du brauchst nicht jeden Punkt für eine Ein-Zeilen-Frage. Du brauchst sie, wenn der Assistent in deinem Namen eine Produkt- oder Architekturentscheidung treffen könnte.

Hier ist ein schwacher Prompt:

Gestalte die mobile Navigation einheitlicher und entferne die Seitenleiste.

Er enthält eine Aktion, aber keine Entscheidungsgrenze. Der Assistent könnte die Seitenleiste überall entfernen, weil er nicht weiß, dass Desktop-Nutzer davon abhängig sind.

Hier ist ein besserer Prompt:

Problem: Die Desktop-Seitenleiste ist auf Mobilgeräten schwer zu nutzen, weil sie
zu viel horizontalen Platz einnimmt und mit dem Lektionsinhalt konkurriert.

Annahme: Ein mobiles, eigenes Navigationsmuster würde das Wechseln zwischen
Lektionen erleichtern, ohne den Desktop-Ablauf zu verändern.

Ergebnis: Auf kleinen Bildschirmen können Lernende zwischen Lektionen wechseln und
zur aktuellen Übung zurückkehren, ohne den Kontext zu verlieren. Desktop-Nutzer
behalten die bestehende Seitenleiste und den Tastaturablauf.

Einschränkungen: Entferne die Desktop-Seitenleiste nicht. Behalte das bestehende
Routenverhalten, die Barrierefreiheitsbezeichnungen und den Fortschrittsstatus bei.
Vermeide eine zweite Quelle der Wahrheit für die ausgewählte Lektion.

Prüfe vor der Implementierung die aktuelle Zuständigkeit für die Navigation und
hinterfrage die Annahme, falls eine kleinere Layoutänderung das Problem lösen würde.

Der bessere Prompt gibt dem Assistenten Spielraum für Untersuchungen, macht aber die wichtigen Grenzen explizit: Mobilgeräte sind der Umfang, das Desktop-Verhalten ist geschützt, und ein einziger Zustandsbesitzer ist nicht verhandelbar.

Eine Bitte um Platzierung kann dasselbe Problem haben:

Verschiebe die Themen-Schaltfläche in die Seitenleiste und sorge dafür, dass sie passt.

Diese Anweisung behandelt das bestehende Layout als Dekoration. Sie erklärt nicht, warum der Themenwechsel woanders hingehört oder wie Nutzer ihn nach dem Verschieben finden sollen.

Versuche stattdessen Folgendes:

Problem: Der Themenumschalter in der Navigationsleiste konkurriert mit der globalen
Navigation, wird aber verwendet, während Personen Lektionen im aktuellen Kurs vergleichen.

Gewünschtes Ergebnis: Platziere den Themenwechsel neben der Kursnavigation, damit sein
Zweck klar ist und er beim Durchsehen einer Lektion leicht erreichbar bleibt.

Einschränkungen: Behalte die Aktionen der globalen Navigationsleiste unverändert bei,
bewahre das ausgewählte Thema beim Navigieren und mache die Seitenleiste auf schmalen
Bildschirmen nicht zum einzigen Weg, Themen zu wechseln.

Prüfe zuerst das aktuelle Routen- und Zustandsmodell. Erkläre, ob die Seitenleiste
das richtige Ziel ist, bevor du das Layout änderst.

Die zentrale Änderung ist nicht „mehr Details“. Es ist eine bessere Definition von Erfolg.

KI ist dann am nützlichsten, wenn sie auf eine falsche Prämisse hinweisen kann, bevor sie einen Patch schreibt. Füge eine direkte Frage hinzu:

Welche Belege würden diese Annahme widerlegen, und welche kleinere Änderung sollten
wir zuerst erwägen?

Bei einem Bug frage nach Reproduktionsschritten und konkurrierenden Hypothesen. Bei einem Refactoring frage, welches Verhalten regressieren könnte. Bei einer Architekturänderung frage, welcher bestehende Besitzer, welche Grenze oder welcher Vertrag dupliziert würde.

Das verschiebt die Arbeit von „sofort Code erzeugen“ zu „eine fundierte Entscheidung treffen und dann implementieren“.

Verwende diese Vorlage, wenn eine Aufgabe Produkt- und technischen Kontext braucht:

Aufgabe: [Beschreibe die Änderung in einem Satz.]

Problem: [Wer ist betroffen und was läuft schief?]
Umfang: [Dateien, Ansichten, Ablauf oder Subsystem im Umfang.]
Annahme: [Was du für die Ursache hältst oder welche Lösung helfen könnte.]
Gewünschtes Ergebnis: [Beobachtbares Ergebnis für Nutzer und System.]
Einschränkungen: [Zu bewahrendes Verhalten, Kompatibilität, Leistung, Barrierefreiheit,
Sicherheit, Rollout und Nicht-Ziele.]
Relevanter Kontext: [Architektur, Datenfluss, kürzliche Änderungen, Protokolle oder Beispiele.]
Akzeptanzkriterien: [Woran wir erkennen, dass die Arbeit abgeschlossen ist.]
Validierung: [Auszuführende Tests, manuelle Prüfungen oder Messungen.]

Bevor du Code änderst, prüfe den relevanten Bereich. Hinterfrage die Annahme, wenn
die Belege eine sicherere oder kleinere Lösung nahelegen.

Die Vorlage erleichtert auch die Überprüfung: Ein Teammitglied kann das beabsichtigte Ergebnis sehen und entscheiden, ob die vorgeschlagene Implementierung es erfüllt.

Relevanter Kontext ist selektiv. Füge einen fehlschlagenden Test, eine Fehlermeldung, die aktuelle Komponentengrenze, einen Request-Payload oder einen kurzen Nutzerweg hinzu. Kopiere nicht Tausende nicht zusammenhängende Zeilen und hoffe, dass der Assistent den wichtigen Teil findet.

Für einen fokussierten Coding-Workflow siehe wie man ChatGPT fürs Programmieren promptet. Für wiederverwendbare Muster bei Implementierung, Debugging und Review lies Prompt Engineering für Entwickler.

Nutze einen toolspezifischen Leitfaden, wenn Repository-Kontext den Prompt verändert: Cursor AI prompten, bewährte Praktiken für GitHub-Copilot-Prompts oder bessere Ergebnisse mit Claude Code erzielen.

Nutze einen aufgabenspezifischen Leitfaden, wenn du sofort anpassbare Formulierungen brauchst: Prompt-Engineering-Beispiele für Softwareentwickler, Prompt-Vorlagen zum Refaktorieren von Code oder Prompt-Vorlagen zum Debuggen von Produktionsproblemen.

Nutze einen Entscheidungsleitfaden, wenn das Risiko im Prozess statt in der Syntax liegt: Fehler von KI-Coding-Assistenten und wie du sie vermeidest und wie erfahrene Entwickler KI anders einsetzen.

Die gleichen Gewohnheiten, die KI-Prompts nützlich machen, machen Tickets, Pull Requests und Incident-Notizen klarer: Erkläre das Problem, definiere das Ergebnis, bewahre wichtiges Verhalten und validiere das Resultat.

Wenn eine Aufgabe einen Shell-Befehl oder eine Terminalausgabe betrifft, mache das Verhalten konkret, bevor du einen Assistenten bittest, es zu ändern. Übe Kommandozeilen-Workflows im Browser, damit du die Eingabe, Ausgabe und den Fehlermodus erkennst, die deine Implementierung behandeln soll.