Prompt zum Debuggen: Hypothese statt Raten
Debuggen mit Hypothesen statt Ausprobieren: vollständige Fehlermeldung, Reproduktion und die wahrscheinlichste Ursache zuerst.
Du bist Support-Engineer/in und debuggst über Hypothesen, nicht über Ausprobieren. FEHLER - Was ich erwarte: [ERWARTETES VERHALTEN] - Was passiert: [TATSÄCHLICHES VERHALTEN] - Vollständige Fehlermeldung: [STACKTRACE] - Umgebung: [SPRACHE, VERSION, SYSTEM, BROWSER] - Letzte Änderungen: [WAS VORHER GEÄNDERT WURDE] CODE [RELEVANTER CODE] VORGEHEN 1) ZUSAMMENFASSUNG — was die Fehlermeldung aussagt, in einem Satz ohne Fachjargon dazwischen. 2) HYPOTHESEN — maximal 3, sortiert nach Wahrscheinlichkeit, jede mit der Zeile oder Bedingung, die sie stützt. 3) PRÜFUNG — wie ich jede Hypothese in unter zwei Minuten bestätige oder ausschließe. 4) URSACHE — die wahrscheinlichste Ursache mit Erklärung. 5) FIX — minimale Änderung, die den Fehler behebt, ohne anderes zu brechen. 6) WIE ES DAZU KAM — was im Design oder in der Annahme falsch war. REGELN - Wenn die Fehlermeldung unvollständig ist, sag, welche Zeile du brauchst, statt zu raten. - Kein Refactoring nebenbei: erst reparieren, dann verbessern. - Wenn zwei Ursachen möglich sind, gib für beide einen Fix.
Ein Fehler hat eine Ursache. Wenn du drei Fixes gleichzeitig ausprobierst, hast du keine.
02 — Variablen
Eckige Klammern füllen
Die hervorgehobenen Felder sind die Stellen für deine Angaben. Du musst nicht alle füllen: Was leer bleibt, ergänzt das Modell nach eigenem Ermessen.
[ERWARTETES VERHALTEN]
[TATSÄCHLICHES VERHALTEN]
[STACKTRACE]
[SPRACHE, VERSION, SYSTEM, BROWSER]
[WAS VORHER GEÄNDERT WURDE]
[RELEVANTER CODE]
03 — Anwendung
So gehst du Schritt für Schritt vor
- 01
Füge den kompletten Stacktrace ein: die erste Zeile im eigenen Code ist die interessante, nicht die letzte.
- 02
Lass dir Prüfschritte geben, nicht nur die Lösung: so lernst du, den Fehler beim nächsten Mal selbst zu isolieren.
- 03
„Kein Refactoring nebenbei“ ist die wichtigste Regel: sonst kannst du nicht sagen, welche Änderung geholfen hat.
04 — Varianten
Derselbe Prompt, anderes Ergebnis
Ein Prompt deckt nicht jeden Fall ab. Diese Varianten verlangen dieselbe Arbeit in anderem Ton, anderer Länge oder anderem Format: nimm die, die passt.
Produktionsfehler
Gleiche Struktur für einen Live-Fehler: Priorität, Auswirkung, Sofortmaßnahme, Ursache, dauerhafte Lösung, Vermeidung.
Performance
Gleiche Struktur für ein Performance-Problem: Messung, Engstelle, Hypothese, Änderung, Gegenmessung.
05 — Tipps
Hinweise, die das Ergebnis eine Stufe heben
- Die Ursache steht fast immer in der ersten Zeile des Stacktraces, die auf eigenen Code zeigt.
- Ohne Reproduktion ist Debugging Raten: erst den Fall zuverlässig erzeugen, dann analysieren.
06 — Fragen
Häufige Fragen zu Programmierung
Warum liegt das Modell oft daneben?
Weil der Kontext fehlt: Version, letzte Änderung, vollständige Meldung. Drei Angaben mehr lösen die meisten Fehldiagnosen.
Sollte ich den ganzen Code einfügen?
Nur die betroffene Funktion und die Aufrufkette. Riesige Dateien verwässern die Analyse.
Weiter
Das könnte dir auch helfen
Prompt für wartbaren Code
Code, den jemand in sechs Monaten warten kann: Versionen, Randfälle, Fehlerbehandlung und Tests von Anfang an.
Fortgeschritten ChatGPTClaudeRefactoring-Prompt: Verhalten bleibt gleich
Refactoring ohne Regressionsrisiko: öffentlicher Vertrag bleibt, Tests zuerst, jeder Schritt einzeln prüfbar.
Profi ChatGPTClaudePython-Code-Prompt mit Tests
Python, das läuft: Version, Typen, Fehlerbehandlung, Beispielaufruf und Tests statt Snippet ohne Kontext.
Fortgeschritten ChatGPTClaudeLandingpage mit HTML und CSS
Eine Seite, die auf dem Handy genauso gut aussieht wie am Desktop: semantisches HTML, ein System, kein Framework-Zwang.
FortgeschrittenDiese Seite hat das CopyPromt-Redaktionsteam erstellt; sie wurde erstmals am 25 Oktober 2026 veröffentlicht. Die Prompts sind für den Einsatz in mehreren Modellen geschrieben; Markennamen werden nur zur Kennzeichnung genannt.