Debugging og rodårsagsanalyse

Gevinster:

• Evne til at reducere en fejl til den mindste reproducerbare forekomst og flytte den til AI med fuld bevis
• Evne til at teste evidensbaserede hypoteser med den billigste kontrol og finde den grundlæggende årsag
• Evne til at løse årsagen og sikre den med en regressionstest i stedet for at lappe symptomet

Debugging er processen med at finde ud af, hvorfor en software opfører sig uventet, og rette den. Det er det job, hvor en udvikler bruger mest tid og bliver mest træt; For det meste af tiden er fejlen ikke der, hvor den dukker op, men er gemt et par skridt bagved. AI er en stærk tænkende partner, der accelererer denne forskning - men kun hvis du giver den de rigtige beviser. Fejlretning uden beviser er det område, hvor AI producerer flest hallucinationer.

I denne enhed etablerer vi et disciplineret flow fra generering af fejlen til at komme til hovedårsagen: afklaring af symptomet, indsamling af beviser (fejlmeddelelse, staksporing, log, indtastning), generering af en hypotese, test af hypotesen og validering af rettelsen. AI hjælper på hvert trin; men den "faste" beslutning tages ved at se, at fejlen faktisk er forsvundet.

Hvorfor er beviser alt?

En LLM ser ikke fejl, som du gør; Han ved kun, hvad du fortæller ham. En sætning som "Applikationen går ned" giver næsten ingen information til modellen, og modellen udfylder hullet med en forudsigelse - altså en hallucination. Til gengæld er den fulde fejlmeddelelse, stack trace — en opdeling af hvilke funktionskald fejlen opstod igennem, inputtet, der udløste fejlen, og hvad der var forventet osv. Givet observeret adfærd, kan modellen rangere sande sandsynligheder.

I debugging skal du tænke på AI som en assistent for en detektiv: Jo flere beviser du fremlægger, jo mere nøjagtig er hypotesen den genererer. Hvis der ikke er beviser, vil assistenten kun gætte og kan føre dig på det forkerte spor.

Tip: Før du overfører en fejl til AI, skal du reducere den til det mindste reproducerbare eksempel. Den mindste kode og input, der udløser fejlen, gør tingene radikalt nemmere for både dig og modellen; oftest under denne reduktion finder du selv årsagen.

Trin for trin: Root Cause Analysis Flow

1. Afklar symptomet. "Hvad sker der, hvad forventede du, der ville ske?" Skriv de to i én sætning.
2. Saml beviser. Fuld fejlmeddelelse, staksporing, relevante loglinjer, udløsende indtastning, versionsoplysninger.
3. Få lavet hypotesen. Fra AI "3 mulige årsager, der forklarer dette symptom, og hvordan tester jeg for hver?" spørge.
4. Test den billigste hypotese først. Tilføj en log, udskriv en værdi, kør en test. Bekræfter beviserne hypotesen?
5. Løs årsagen, ikke symptomet. I stedet for at dæmpe symptomet med et plaster, skal du tage fat på den grundlæggende årsag.
6. Valider og tilføj regressionstest. Se fejlen forsvinde; Skriv derefter en test, der vil fange den fejl, så den ikke kommer tilbage.

Tre mini etuier

Tilfælde 1 — staksporingen førte til den korrekte fil. En applikation returnerede en 500-fejl på visse anmodninger. Udvikleren gav fuld stack-sporing og udløsende anmodning til AI; Modellen antog, at fejlen var forårsaget af en None-værdi i et datoparsinglag. Udvikleren tilføjede en log til den linje, verificerede den og løste den på 15 minutter; 2 timer blev spildt dagen før med ubeviste forsøg.

Case 2 — Hallucination førte til forkert spor. En anden udvikler skrev simpelthen "databaseforbindelsen falder". AI anklagede en forbindelsespool-indstilling uden beviser; Udvikleren brugte 40 minutter på at pille ved denne indstilling. Den egentlige årsag var en timeout på netværkssiden og blev kun afsløret ved at se på loggene. Lektion: en hypotese taget uden bevis er kun sandsynlig, ikke pålidelig.

Tilfælde 3 — Flaky fejl fanget. Der var en test, der af og til mislykkedes. AI'en fik testkoden, fejlmeddelelsen og informationen "nogle gange går det, nogle gange fejler det"; modellen indikerede en delt tids-/ordreafhængighed af testene. Gennemgangen bekræftede, at testen var baseret på systemets lokale tid. Når uret var fastgjort (hånet), blev testen stabil.

Fire kopierbare skabeloner

Evidensbaseret hypotesegenerering:

Jeg fejlretter en fejl. Beviser nedenfor.- Forventet adfærd: {{expected}}- Observeret adfærd: {{observeret}}- Fejlmeddelelse/staksporing: {{trace}}- Udløsende input: {{input}}- Miljø/version: {{version}}Angiv de 3 MEST SANDsynlige årsager, der forklarer dette symptom. For hver: hvordan tester jeg (billigst tjek), og hvordan man løser det, hvis det er sandt. Hvis beviserne er utilstrækkelige, så fortæl mig, hvilke yderligere oplysninger du har brug for.

Fortolkning af staksporet:

Læs dette stakspor. Skelne mellem hvilken linje fejlen MULIGVIS starter ved (roden), og hvilke linjer der blot er fortsættelser af kæden. Foreslå 1-2 steder at se først. Relateret kode:{{code}}Spor:{{trace}}

Minimal repro subtraktion:

Koden nedenfor giver en fejl. Reducer det til den MINDSTE instans, der stadig udløser fejlen, men kasserer alt unødvendigt. Gå ikke ud fra, at hver brik, du fjerner, ikke påvirker fejlen, men tilføj en note, der siger "hvis fejlen forsvinder, når du fjerner dette, er det derfor".{{code}}

Postkorrektionsvalidering og regressionstest:

Antag, at grundårsagen er {{cause}}, og jeg laver følgende rettelse: {{fix}}.1) Løser denne rettelse rent faktisk symptomet, vil det have nogen bivirkninger?2) Skriv en regressionstest, der vil fange denne fejl i fremtiden.

Svag prompt / Stærk prompt

Svag: "Koden virker ikke, hvorfor?"

Stærk: "Node 20 / Express. POST /ordrer returnerer 500, når varer er en tom streng i kroppen; burde have returneret 400. Stack trace: TypeError: Kan ikke læse egenskaber for undefined (læser '0') — vedhæftet er det fulde spor og tilhørende handler. Giv mig de 3 mest sandsynlige årsager, der forklarer dette symptom, og hvordan man tester hver enkelt" [trace + kode].

Kraftig version; Det giver miljøet, endepunkt, triggerinput, nøjagtig fejltype og forventet adfærd. Modellen kan ikke længere lave forudsigelser, men analysere.

trin

AI's bidrag

din kontrol

indsamling af beviser

Hvilke beviser er nødvendige, minder

Samler virkelig beviser

hypotesegenerering

Angiv mulige årsager

Prioriterer med kontekst

hypotesetestning

Anbefaler testmetode

Betjener og observerer personligt

rettelse

patch anbefaler

Løser det årsagen? Det er sandt.

regression

skriver en test

Bekræfter, at testen er brudt

Løsning af hovedårsagen, ikke symptomet

Det meste af tiden vil AI foreslå en patch, der hurtigt dæmper symptomet: tilføj et forsøg/fang, sæt et nul-tjek, sluk fejlen. Dette er nogle gange sandt, ofte farligt; fordi den oprindelige årsag forbliver på plads og bryder ud igen fra et andet sted. Med hver rettelse skal du spørge dig selv: "Løser dette årsagen til fejlen, eller gør det den usynlig?" Når du først har fundet årsagen, er rettelsen normalt mindre, mere robust og permanent.

Forsigtig: Stille synkning af en undtagelse (tom fangst) løser ikke fejlen; det skjuler blot og gør fremtidig diagnose umulig. Hvis AI foreslår en sådan "løsning", skal du ikke acceptere den uden at stille spørgsmålstegn ved den grundlæggende årsag.

Almindelige fejl

• At stille spørgsmål uden beviser. Tvetydige sætninger skubber modellen til hallucination; Giv fuld fejl, spor og input.
• Holder fast i den første hypotese. AI's første forslag er måske ikke det mest sandsynlige; Start med den billigste kontrollerbare hypotese.
• Lapper symptomet og mangler den grundlæggende årsag. Den stillede fejl vender tilbage.
• Lukning af rettelsen uden at bekræfte den. Se i produktionslignende stand, at fejlen faktisk forsvinder.
• Skriver ikke regressionstest. Hvis der ikke tilføjes nogen test, vil den samme fejl stille vende tilbage i senere versioner.

Sammenfattende

Ved debugging er AI-kraften direkte proportional med de beviser, du giver den: Uden den fulde fejlmeddelelse, staksporing, udløsende input og forventet adfærd, spekulerer modellen bare. Disciplineret flow – klargør symptom, indsaml beviser, generér hypoteser, test med den billigste kontrol, ret rodårsagen, verificer og tilføj regressionstestning – lukker fejlen både hurtigt og permanent. AI er en hypotesegenerator; Det er dig, der beslutter, at fejlen rent faktisk er løst.

Ansøgningsopgave

Vælg en rigtig fejl, du har stødt på for nylig (eller genskab en testfejl). Udfør "minimum reproduktion" trin først; Fjern den mindste kode og input, der udløser fejlen. Så få 3 mulige årsager og testmetoder fra AI med skabelonen "evidensbaseret hypotesegenerering". Test selv den billigste hypotese, find den grundlæggende årsag, ret den, og skriv endelig en regressionstest, der vil fange denne fejl i fremtiden og verificere, at testen faktisk er brudt.

tjekliste

• [ ] Jeg reducerer fejlen til den mindste reproducerbare prøve, før jeg flytter den til AI.
• [ ] Jeg tilføjer den fulde fejlmeddelelse, staksporing, input og forventet adfærd til prompten.
• [ ] Jeg starter med den billigste kontrollerbare, uden at være fastlåst i en eneste hypotese.
• [ ] Jeg bekræfter, at jeg har løst hovedårsagen i stedet for at lappe symptomet.
• [ ] Jeg bemærker, at rettelsen faktisk retter fejlen.
• [ ] Jeg tilføjer en regressionstest for hver løst fejl.