Die vier Regeln, die jeden Prompt unten funktionieren lassen
Vor den Prompts die Regeln, die sie alle teilen. Sie zu jedem Coding-Prompt hinzuzufügen, verbessert die Ausgabe mehr als ein Modellwechsel.
Nenne deine Version. Trainingsdaten sind zu der Major-Version verzerrt, über die am meisten geschrieben wurde, was oft nicht die ist, die du nutzt. Wir nutzen [Framework] [Version], [Sprache] [Version] verhindert die meisten veralteten Antworten.
Grenze den Diff ein. Bitte um einen Fix und du bekommst oft ein Refactoring. Ändere so wenig wie möglich, erhalte die bestehende Struktur und Benennung, und liste jede geänderte Zeile mit einem Ein-Zeilen-Grund auf ist der nützlichste Satz in diesem Dokument.
Frage vor Lösungen nach Hypothesen. Ein Modell, das gefragt wird, was falsch ist, liefert dir eine Vermutung als Schlussfolgerung verpackt. Ein Modell, das nach eingestuften Ursachen und günstigen Checks gefragt wird, liefert dir einen Debugging-Plan.
Fordere den Fehlermodus ein. Was könnte das kaputt machen, und behebt das die Ursache oder das Symptom? fängt die teuerste Klasse von KI-Unterstützung ab: eine Änderung, die das Symptom verschwinden lässt, während der Defekt bleibt.
Debugging
1. Eingestufte Hypothesen
Hier ist der Fehler, der relevante Code und was ich bereits ausgeschlossen habe. Gib mir noch keinen Fix. Liste die vier wahrscheinlichsten Ursachen nach Wahrscheinlichkeit sortiert, und für jede den günstigsten Check, der sie bestätigen oder ausschließen würde. Fehler: [einfügen]. Code: [einfügen]. Bereits ausgeschlossen: [Liste]. Stack: [Sprache, Framework, Versionen].
2. Der sporadische Bug
Das schlägt sporadisch fehl, ungefähr [Häufigkeit], unter [Bedingungen]. Zähle die Kategorien sporadischer Fehler auf, die dieses spezifische Symptom erzeugen könnten: Timing, Reihenfolge, Ressourcenerschöpfung, eine externe Abhängigkeit, Zustand, der zwischen Läufen leckt, Uhrzeit oder Zeitzone, Caching. Sage für jede, was im Code dafür oder dagegen spricht, und was ich genau loggen sollte, um sie zu unterscheiden. Code: [einfügen].
3. Es funktioniert lokal
Das funktioniert lokal und schlägt in [Umgebung] fehl. Liste jede Kategorie von Umgebungsunterschieden auf, die dieses spezifische Symptom verursachen könnte: Konfiguration, Umgebungsvariablen, Versionen, Dateisystem und Groß-/Kleinschreibung, Zeitzone und Locale, Netzwerk und DNS, Berechtigungen, Ressourcenlimits und Build- oder Bundling-Unterschiede. Ordne nach Wahrscheinlichkeit anhand des Symptoms, und gib mir den Diagnosebefehl für jede.
4. Erkläre den Fix, bevor ich ihn übernehme
Erkläre, warum dieser Fix funktioniert, was er nicht behebt und was er kaputt machen könnte. Wenn die eigentliche Ursache woanders liegt und das hier ein Symptom-Patch ist, sag das direkt.
Code-Review
5. Einen Diff reviewen
Reviewe diesen Diff wie ein anspruchsvoller Reviewer. Kategorien in Prioritätsreihenfolge: Korrektheitsfehler, Sicherheitsprobleme, unbehandelte Fehlermodi, Race Conditions, dann Stil. Gib für jeden Befund Schweregrad, die konkrete Zeile und warum es in dieser Codebasis wichtig ist, nicht allgemein. Kommentiere nicht die Formatierung. Wenn der Diff solide ist, sag das, statt Befunde zu erfinden. Konventionen: [beschreiben]. Diff: [einfügen].
6. Der Sicherheits-Check
Prüfe diesen Code speziell auf Sicherheitsprobleme: Injection, Lücken bei Authentifizierung und Autorisierung, unsichere Deserialisierung, Secrets in Code oder Logs, unvalidierte Eingaben, die einen sensiblen Vorgang erreichen, und Abhängigkeitsrisiken. Gib für jedes den Angriffspfad konkret an, statt nur die Kategorie zu nennen. Sage klar, was du ohne Einblick in [Deployment, Auth-Schicht, Datensensibilität] nicht einschätzen kannst.
7. Der Fehlermodus-Audit
Gib für jeden externen Aufruf in diesem Code an, was passiert, wenn er langsam ist, wenn er fehlschlägt, wenn er unerwartete Daten zurückgibt und wenn er teilweise erfolgreich ist. Welche davon sind aktuell unbehandelt, und welche wären still?
Der letzte findet mehr echte Produktionsprobleme als ein allgemeines Review, weil er nach den Pfaden fragt, für die niemand einen Test geschrieben hat.
Refactoring und Architektur
8. Der Refactoring-Plan
Schlage einen sequenzierten Plan vor, um [Beschreibung] zu refaktorieren. Bedingungen: die öffentliche API von [x] darf sich nicht ändern, wir deployen kontinuierlich, also muss jeder Schritt eigenständig ausrollbar sein, und Tests müssen nach jedem Schritt bestehen. Gib für jeden Schritt die Änderung, das Risiko, wie man ihn verifiziert und wie man ihn zurückrollt. Ordne nach Risiko, niedrigstes zuerst. Schreibe den Code noch nicht.
9. Argumentiere die andere Seite
Ich wähle [Ansatz A] statt [Ansatz B] für [Kontext und Bedingungen]. Mach das stärkste Argument für B. Was müsste über unsere Bedingungen wahr sein, damit B richtig ist, und trifft davon etwas hier zu? Schließe nicht, dass beide gültig sind.
10. Verstehe, was du geerbt hast
Hier sind die wichtigsten Quelldateien. Erstelle: die Einstiegspunkte, den Datenfluss von Request zu Response, den geteilten Zustand und wo er mutiert wird, externe Abhängigkeiten und was passiert, wenn jede nicht verfügbar ist, und die drei Bereiche, die basierend auf Komplexität und Kopplung am wahrscheinlichsten Bugs enthalten. Sage explizit, was du aus dem Gegebenen nicht bestimmen kannst.
Diese letzte Anweisung ist wichtig. Modelle beschreiben das Verhalten einer Datei, die du nicht eingefügt hast, abgeleitet aus ihrem Namen. Eine explizite Liste von Unbekannten zu erzwingen, sagt dir, was du noch lesen musst.
Tests
11. Die Tests, die du nicht geschrieben hättest
Schreibe Testfälle für diese Funktion, mit Fokus auf Eingaben, die ich wahrscheinlich nicht bedacht habe: Grenzwerte, leer und null, Unicode, sehr große Werte, gleichzeitige Aufrufe und jede implizite Annahme in der Implementierung. Sage für jeden Test, welche Annahme er prüft. Funktion: [einfügen].
12. Teste die Testsuite
Hier ist eine Funktion und ihre bestehenden Tests. Welches Verhalten ist nicht abgedeckt? Konkret: Fehlerpfade, Grenzwerte, Interaktionen zwischen Parametern und alles, was die Implementierung tut, das kein Test prüft. Schreibe die bestehenden Tests nicht um.
Der zweite ist der wertvollere Prompt, und er wird selten genutzt. Coverage-Prozentsätze sagen dir, welche Zeilen ausgeführt wurden, nicht welches Verhalten tatsächlich abgesichert ist, und in der Lücke zwischen beiden leben die Regressionen.
Das Zweitmeinungs-Muster
Die wertvollste Gewohnheit in diesem ganzen Paket, und die einzige, die mehr als ein Modell erfordert.
Hol dir eine Antwort von einem Modell. Wechsle dann und gib sie weiter:
Ein anderer Entwickler hat diese Lösung für dieses Problem vorgeschlagen. Finde, was daran falsch ist: Korrektheit bei Grenzfällen, Nebenläufigkeit, Fehlerbehandlung, Performance bei [Skala], oder ein einfacherer Ansatz, der übersehen wurde. Wenn sie wirklich solide ist, sag das klar, statt Einwände zu erfinden. Problem: [einfügen]. Vorgeschlagene Lösung: [einfügen].
Zwei Ergebnisse, und beide sind nützlich. Entweder findet das zweite Modell eine echte Lücke, was du jetzt vor dem Merge weißt, oder es stimmt zu, obwohl es zum Widerspruch gedrängt wurde, was eine sinnvolle Bestätigung ist. Mit demselben Modell zu iterieren, bringt dir keins von beidem, weil ein Modell, das seine eigene Ausgabe reviewt, meist sich selbst zustimmt.
Nutze es bei Entscheidungen, die teuer wären, falsch zu treffen: eine Schema-Änderung, ein Nebenläufigkeits-Fix, alles, was Auth oder Geld betrifft. Nicht bei Routinearbeit. Siehe Modelle direkt vergleichen, Modelle mitten im Gespräch wechseln und Code mit mehreren Modellen schreiben und debuggen für den gesamten Workflow an einem Ort.
Worauf du achten solltest
Erfundene APIs. Selbstsichere Methodennamen, Parameter und Config-Keys, die nicht existieren, besonders bei kürzlich geänderten Bibliotheken. Die Signatur sieht richtig aus. Prüfe die echte Dokumentation, bevor du auf etwas Unbekanntem aufbaust.
Kein Vertrauenssignal. Ein korrekter Fix und ein subtil falscher kommen mit identischer Sicherheit daher. Der Ton sagt dir nichts.
Stiller Scope Creep. Dafür existiert Regel zwei.
Sicherheitstheater. Schwachstellenklassen in deinem Code zu benennen, ist ein nützlicher erster Durchgang. Es ist kein Audit, und das Modell kennt dein Bedrohungsmodell, Deployment oder deine Datensensibilität nicht.
Bewahre die Prompts, die du wöchentlich nutzt, irgendwo auf, von wo du sie einfügen kannst, und lege dauerhafte Regeln in die Anweisungen eines Projekts, damit sie automatisch für jeden Chat in diesem Projekt gelten.
- Nenne Sprache, Framework und Version in jedem Coding-Prompt
- Füge den Diff-eingrenzen-Satz zu jedem Prompt hinzu, der Code erzeugt
- Frage vor einem Fix nach eingestuften Hypothesen und günstigen Checks
- Frage immer, was ein Fix kaputt machen könnte und ob er das Symptom behandelt
- Wende das Zweitmeinungs-Muster bei allem an, das teuer wäre, falsch zu machen
- Frage, was die bestehende Testsuite nicht abdeckt, nicht nur nach mehr Tests
- Verifiziere unbekannte APIs gegen die echte Dokumentation
- Bewahre die Prompts, die du wöchentlich nutzt, dort auf, wo du sie einfügen kannst
Häufige Fragen
Funktionieren diese Prompts nur mit Claude?
Nein. Sie sind für den Long-Context-, sorgfältig-argumentierenden Stil geschrieben, in dem Claude gut ist, und funktionieren direkt auch mit GPT und Gemini. Tatsächlich sind mehrere über Modelle hinweg besser einsetzbar: Der Zweitmeinungs-Prompt braucht zwei, und der "argumentiere die andere Seite"-Prompt ist nützlicher, wenn das argumentierende Modell nicht die ursprüngliche Wahl getroffen hat.
Welches Modell sollte ich für welchen Prompt nutzen?
Als Ausgangspunkt: Claude für subtiles Schlussfolgern, unbekannte Architekturen und das Erklären, warum sich etwas so verhält; GPT für schnelle Implementierung auf gut ausgetretenem Terrain und strikte strukturierte Ausgaben; ein Large-Context-Modell, wenn die Frage mehr Code umfasst, als bequem in einen normalen Prompt passt. Überschreibe das dann mit einer Woche eigener Vergleiche, denn die richtige Antwort hängt mehr von deinem Stack ab als von jedem Benchmark.
Ist das ein Ersatz für ein agentisches Coding-Tool?
Nein, sie lösen unterschiedliche Probleme. Ein Agent lebt in deinem Repository und bearbeitet Dateien. Diese Prompts sind für die Reasoning-Schicht: einen Fehler verstehen, einen Diff reviewen, ein Refactoring planen, über einen Ansatz argumentieren. Die meisten Entwickler nutzen beides, und die Modellwahl ist hier wichtiger, weil du das Reasoning bewertest, nicht den entstandenen Diff.
Wie stoppe ich es dabei, Code umzuschreiben, den ich nicht angefragt habe?
Füge dem Prompt hinzu: ändere so wenig wie möglich, erhalte die bestehende Struktur und Benennung, und liste jede geänderte Zeile mit einem Ein-Zeilen-Grund auf. Ungefragtes Refactoring ist der Hauptgrund, warum KI-Vorschläge unüberprüfbar werden, und den Diff einzugrenzen ist der Unterschied zwischen einer Änderung, über die du nachdenken kannst, und einer, die du von Grund auf neu lesen musst.
Kann ich proprietären Code einfügen?
Whizi trainiert nicht mit deinen Unterhaltungen, und die Datenrichtlinie jedes Anbieters ist einsehbar, bevor du dieses Modell aktivierst, aber die Richtlinie deines Arbeitgebers ist die bindende Bedingung, und die variiert stark. Wo Einschränkungen gelten, ist es meist sowohl erlaubt als auch der bessere Prompt, das Problem als minimales Beispiel zu reproduzieren, das die Struktur erhält und die Geschäftslogik weglässt, weil das die Details entfernt, die um Aufmerksamkeit konkurrierten.