Debuggen mit KI: Prompts, die die Ursache finden

Debuggen mit KI funktioniert am besten, wenn du dem Modell gibst, was du einem Kollegen an deinem Schreibtisch geben würdest: den ganzen Fehler, den Code, der ihn ausgelöst hat, was du erwartet hast, was stattdessen passiert ist und was du schon ausgeschlossen hast. Das Modell kann dein Programm nicht ausführen und deine Daten nicht sehen, also stammt alles, was es über den Bug weiß, aus dem, was du einfügst. Die nützlichste einzelne Gewohnheit: nach der Ursache fragen, bevor du nach der Korrektur fragst.

Füg alles ein, nicht nur den Fehler

Die beiden Tabs unten beschreiben denselben Bug. Ein Skript liest eine aus Excel exportierte CSV-Datei und stürzt mit KeyError: 'email' ab, obwohl die Datei eindeutig eine Spalte email hat.

Korrigier das: KeyError: 'email'

Try it

Example replyReplies vary between models and runs.

Ein KeyError bedeutet, dass das Dictionary keinen Schlüssel namens 'email' hat. Du kannst den Fehler vermeiden, indem du .get() verwendest, das None zurückgibt, statt einen Fehler auszulösen:

email = row.get("email")

Oder prüf vorher:

if "email" in row:
    email = row["email"]

Die erste Antwort erklärt korrekt, was ein KeyError ist, und ihr Rat ist hier schädlich. Mit row.get("email") verschwindet der Absturz, und jede E-Mail wird None. Das Modell hat die häufigste Variante des Fehlers beantwortet, weil der Prompt nur diese beschrieben hat.

Der vollständige Bericht hat wegen zweier Zeilen funktioniert. "Nur die erste Spalte scheitert" und "aus Excel als CSV UTF-8 gespeichert" sind die Hinweise, die auf die Byte Order Mark zeigen, und keiner davon steht in der Fehlermeldung. Du weißt selten, welches deiner Details der Hinweis ist, und deshalb fügst du alle ein.

Die fünf Dinge, die hineingehören

Der vollständige Fehler. Der ganze Traceback oder die ganze Konsolenausgabe, keine Umschreibung. Die Zeilennummern und die Aufrufkette zeigen, wo der Fehler begann, und das liegt oft ein paar Ebenen von der Stelle entfernt, an der er sichtbar wurde.
Der Code, der ihn ausgelöst hat. Die scheiternde Funktion und der Code, der sie aufruft. Wenn der Fehler eine Zeile nennt, sorg dafür, dass diese Zeile in dem steht, was du einfügst.
Erwartet gegen tatsächlich. Jeweils ein Satz. Bei Bugs ganz ohne Fehlermeldung (falsche Ausgabe, eine leere Seite, eine langsame Abfrage) ist das der ganze Bug-Report.
Deine Umgebung. Sprachversion, Betriebssystem, Framework- und Bibliotheksversionen, wenn sie eine Rolle spielen könnten. Bugs mit Kodierungen, Pfaden und Datumsangaben hängen oft von der Plattform ab.
Was du schon probiert hast. Das hält das Modell davon ab, es noch einmal vorzuschlagen, und das Ergebnis jedes Versuchs ist ein Beleg. "Ohne den Teil mit email funktioniert es" hat den CSV-Bug auf eine Spalte eingegrenzt.

Frag nach der Ursache vor der Korrektur

Eine Bitte um Korrektur lädt das Modell ein, Code zu ändern, bis der Fehler verschwindet. Eine Frage nach der Ursache bittet es, darüber nachzudenken, warum der Fehler passiert, und die Korrektur ergibt sich daraus. Bitte um eine kurze, geordnete Liste von Ursachen mit einer Prüfung für jede, und führ die Prüfungen dann selbst aus. Diese Vorlage macht genau das:

Ursachen ordnen, noch keine Korrektur

Fill inSpracheerwartettatsächlich

Parts

Hilf mir, die Ursache eines Bugs in meinem JavaScript-Code zu finden. Schreib noch keine Korrektur.

Erwartet: die Liste der User erscheint, wenn die Seite lädt Tatsächlich: leere Seite, und dieser Fehler in der Browserkonsole

TypeError: Cannot read properties of undefined (reading 'map')

function UserList() {
  const [users, setUsers] = useState();

  useEffect(() => {
    fetch("/api/users")
      .then((res) => res.json())
      .then((data) => setUsers(data));
  }, []);

  return (
    <ul>
      {users.map((u) => (
        <li key={u.id}>{u.name}</li>
      ))}
    </ul>
  );
}

Liste bis zu drei wahrscheinliche Ursachen auf, die wahrscheinlichste zuerst. Gib für jede eine einzeilige Prüfung an, mit der ich sie bestätigen oder ausschließen kann.

Try it

Example replyReplies vary between models and runs.

Die Komponente rendert, bevor Daten existieren. useState() startet mit undefined, und React rendert die Komponente einmal, bevor der Effect läuft, also wird users.map auf undefined aufgerufen. Das allein erzeugt genau deinen Fehler, bei jedem Laden. Prüfung: Füg direkt vor return ein console.log(users) ein. Wenn es undefined ausgibt und der Fehler sofort folgt, ist es das.
Die API liefert etwas anderes als ein Array. Würde sie ein Objekt wie { users: [...] } liefern, wäre der Fehler ein anderer (users.map is not a function), also ist das nicht der Fehler, den du eingefügt hast. Es kann trotzdem das nächste Problem sein, sobald Ursache 1 behoben ist. Prüfung: console.log(data) im zweiten .then.
Die Anfrage schlägt fehl. Noch nicht beteiligt: Weil schon das erste Rendern einen Fehler wirft, führt React den Effect nie aus, die Anfrage wird also gar nicht erst gesendet. Prüfung: Der Netzwerk-Tab zeigt keine Anfrage an /api/users, und das bestätigt zugleich Ursache 1.

Die Antwort macht etwas, das eine Antwort mit Korrektur zuerst überspringt: Sie schließt Ursachen aus, weil der Fehler, den sie erzeugen würden, sich von dem unterscheidet, den du eingefügt hast, oder weil der Code nie weit genug kommt, damit sie eintreten. Auch deshalb zählt der genaue Text des Fehlers. Das Modell zuerst Ursachen auflisten zu lassen, ist eine leichte Form von Chain-of-Thought-Prompting: Das Nachdenken kommt zuerst, und die Schlussfolgerung baut darauf auf.

Bau eine minimale Reproduktion

Eine minimale Reproduktion ist das kleinste Programm, das den Bug noch zeigt: fest eingetragene Daten statt eines Datenbankaufrufs, eine Funktion statt des ganzen Moduls. Beim Bauen findest du den Bug oft schon, bevor du jemanden fragst, weil jedes Stück, das du entfernst, den Bug entweder behält (es war nicht beteiligt) oder verschwinden lässt (es war beteiligt). Wenn nicht, ist die Reproduktion der ideale Prompt: kurz genug, dass das Modell jede Zeile liest, und frei von fremdem Code, der es auf die falsche Spur schicken könnte.

Wenn der Bug von Daten abhängt, füg ein paar Zeilen ein, die ihn auslösen. Über [{"id": 1, "name": null}] kann ein Modell nachdenken; über "ein paar Zeilen in Produktion" nicht.

Wenn die Korrekturen nicht mehr helfen

Wenn die dritte Korrektur des Modells auf dieselbe Weise scheitert, wird eine vierte Bitte um Korrektur kaum besser ausfallen. Zwei Dinge helfen mehr:

Gib ihm neue Belege. Füg eine print- oder Log-Zeile ein, die die tatsächlichen Werte an der Fehlerstelle zeigt, führ sie aus und füg die Ausgabe ein. Belege, die der Theorie des Modells widersprechen, sind der schnellste Weg zu einer besseren.
Beginne ein neues Gespräch. Lange Debugging-Verläufe füllen sich mit verworfenen Theorien und alten Versionen des Codes, und das Modell baut vielleicht weiter darauf auf. Ein neuer Chat mit dem aktuellen Code, dem Fehler, den Belegen und einer Zeile "schon ausgeschlossen: X und Y" kommt in einer Antwort oft weiter.

Sei vorsichtig bei selbstsicheren Antworten über das Verhalten von Bibliotheken. Ein Modell kann eine Option oder Funktion beschreiben, die es nicht gibt; unter KI-Halluzinationen steht, wie du das prüfst. Wenn der Code nicht kaputt ist, du aber nicht verstehst, warum er tut, was er tut, ist ein Prompt zum Code erklären das bessere Werkzeug.

Häufig gestellte Fragen

Wie bitte ich ChatGPT oder Claude, meinen Code zu korrigieren?

Füg die vollständige Fehlermeldung und den Code ein, der sie ausgelöst hat, und ergänze drei kurze Zeilen: was du erwartet hast, was stattdessen passiert ist und was du schon probiert hast. Frag nach der wahrscheinlichsten Ursache und wie du sie bestätigen kannst, bevor du um eine Korrektur bittest. Ein bloßes "korrigier das" bringt eine Korrektur für die häufigste Variante des Fehlers, und die ist vielleicht nicht deine.

Soll ich mein ganzes Projekt in die KI einfügen?

Nein. Füg die Funktion ein, in der der Fehler passiert, den Code, der sie aufruft, und ein Beispiel der Daten, die sie bekommt. Noch besser: Reduzier das Problem auf das kleinste Programm, das es noch zeigt. Fremde Dateien machen die Antwort langsamer und geben dem Modell mehr Stellen, an denen es nach einem Problem sucht, das dort gar nicht ist.

Warum verschwindet der Fehler mit der Korrektur der KI, aber das Programm funktioniert trotzdem nicht?

Die Korrektur hat das Symptom behandelt. Wenn du zum Beispiel row["email"] durch row.get("email") ersetzt, verschwindet ein KeyError, aber wenn der Schlüssel wegen eines Bugs weiter vorne fehlt, ist jetzt jede E-Mail stillschweigend None. Wer zuerst nach der Ursache fragt und nach einem Weg, sie zu bestätigen, vermeidet Korrekturen, die das Problem nur verstecken.

Was, wenn die KI immer wieder Korrekturen vorschlägt, die nicht funktionieren?

Hör auf, nach Korrekturen zu fragen, und gib ihr stattdessen Belege. Berichte, was jeder Versuch verändert hat, füg eine print- oder Log-Zeile ein, die die tatsächlichen Werte zeigt, und füg diese Ausgabe ein. Wenn das Gespräch lang ist, beginne ein neues mit einer sauberen Zusammenfassung: Code, Fehler, Belege und die schon ausgeschlossenen Korrekturen.

Verwandte Konzepte