Rubber-Duck-Debugging für ein Problem, das Sie nicht knacken
Der klassische Trick — den Bug laut erklären, bis die Antwort auftaucht — funktioniert noch besser, wenn die Ente zurückredet. Debugging ist eine der häufigsten KI-Aufgaben, fast die Hälfte der Entwickler nutzt KI dafür zumindest teilweise. Aber das Ziel hier ist ein Denkpartner, der Ihnen hilft, Hypothesen zu bilden und zu prüfen — kein Werkzeug, das einen Patch ausspuckt, den Sie blind einfügen: 45% der Entwickler sagen, das Reparieren von KI-geschriebenem Code koste mehr Zeit, als es einspart.
Sie sind ein ruhiger Senior Engineer, der mir hilft, durch Nachdenken zu debuggen, nicht durch das Aushändigen eines Patches. Agieren Sie als Debugging-Partner: Helfen Sie mir, die Ursache zu finden, und lassen Sie mich den Fix umsetzen. Was ich erwartet habe: {{expected}} Was tatsächlich passiert (genauer Fehler, Stack Trace oder falscher Output): {{actual}} Relevanter Code und Umgebung: {{context}} Was ich bereits versucht habe: {{tried}} Tun Sie Folgendes: 1. Formulieren Sie das Problem in Ihren eigenen Worten neu, damit ich bestätigen kann, dass Sie es verstanden haben. 2. Listen Sie die wahrscheinlichsten Ursachen auf, priorisiert, jeweils mit der Begründung und einem konkreten Check, den ich ausführen kann, um sie zu bestätigen oder auszuschließen. 3. Schlagen Sie den einzelnen nächsten Diagnoseschritt vor — eine Log-Zeile, einen Breakpoint oder ein minimales Experiment —, bevor Sie einen Fix vorschlagen. 4. Erst wenn wir die Ursache eingegrenzt haben, schlagen Sie einen Fix vor und erklären, warum er die Grundursache statt des Symptoms behebt. Regeln: - Raten Sie nicht an einem Fix, bevor die Ursache identifiziert ist. Wenn meine Informationen nicht ausreichen, sagen Sie mir genau, was ich sammeln soll. - Stützen Sie Hypothesen auf den Fehler und den Code, die ich bereitgestellt habe; erfinden Sie kein Framework-Verhalten, keine Konfiguration und keine Zeilennummern. Sagen Sie klar, wenn Sie spekulieren. - Bevorzugen Sie die kleinstmögliche Änderung, die die Grundursache behebt, gegenüber einem großen Umbau.
Tragen Sie Ihre Angaben ein — der Prompt aktualisiert sich live. Dann kopieren.
Neu formuliert: Ihr Endpunkt liefert unter Last sporadisch 500er mit einem Connection-Pool-Erschöpfungsfehler, funktioniert aber lokal. Wahrscheinlichste Ursachen, priorisiert: 1. Verbindungen werden im Fehlerpfad nicht freigegeben — prüfen, ob ein fehlgeschlagener Query den Release-/Close-Aufruf überspringt. Reproduzieren und aktive Verbindungen beobachten. 2. Pool zu klein für die reale Nebenläufigkeit — Checkout- und Check-in-Zähler pro Anfrage loggen. 3. Eine langsame Query hält Verbindungen offen — den Slow-Query-Log der Datenbank prüfen. Nächster Diagnoseschritt: Log bei jedem Acquire und Release ergänzen, dann mit etwa 20 gleichzeitigen Anfragen reproduzieren, bevor irgendeine Konfiguration geändert wird. Ich spekuliere bei Ursache 1, bis die Logs sie bestätigen.
Der komplette Arbeitsablauf
- Sammeln Sie den genauen Fehler, den Stack Trace und eine minimale Reproduktion, bevor Sie beginnen
- Fügen Sie bereinigten Code und Logs ein — entfernen Sie Geheimnisse, Tokens und interne Hostnamen
- Arbeiten Sie die priorisierten Hypothesen durch und führen Sie jeden vorgeschlagenen Check selbst aus
- Setzen Sie den Fix von Hand um und ergänzen Sie einen Test, der den ursprünglichen Bug reproduziert
Worauf Sie achten sollten
Logs und Stack Traces enthalten häufig Geheimnisse, Tokens, interne URLs und Kundendaten — bereinigen Sie sie vor dem Einfügen, und nutzen Sie für alles Proprietäre ein freigegebenes Tool statt eines Consumer-Kontos.
Ein selbstbewusster Fix, der auf die falsche Grundursache zielt, ist schlimmer als kein Fix. Lassen Sie das Modell die Ursache mit Belegen eingrenzen, bevor Sie etwas ändern, und reproduzieren Sie den Bug dann mit einem Test, damit Sie wissen, dass er wirklich gelöst ist.
Modelle erfinden plausibles Framework-Verhalten und Konfigurationsoptionen. Prüfen Sie jede referenzierte API, jedes Flag oder jede Einstellung gegen die echte Dokumentation.
Woher das stammt
Jeder Anwendungsfall auf dieser Website beruht auf echten Berichten, die Softwareentwickler aus der Praxis geteilt haben — nichts davon ist von uns erfunden.