Gevinster:
- Evne til å redusere en feil til den minste reproduserbare forekomsten og flytte den til AI med fullstendig bevis
- Evne til å teste evidensbaserte hypoteser med den billigste kontrollen og finne rotårsaken
- Evne til å løse årsaken og sikre den med en regresjonstest i stedet for å lappe symptomet
Feilsøking er prosessen med å finne ut hvorfor en programvare oppfører seg uventet og fikse det. Det er jobben der en utvikler bruker mest tid og blir mest sliten; For det meste av tiden er feilen ikke der den dukker opp, men er skjult noen få skritt bak. AI er en kraftig tenkende partner som akselererer denne forskningen - men bare hvis du gir det riktig bevis. Feilsøking uten bevis er området der AI produserer flest hallusinasjoner.
I denne enheten etablerer vi en disiplinert flyt fra å generere feilen til å komme til grunnårsaken: klargjøre symptomet, samle bevis (feilmelding, stabelsporing, logg, oppføring), generere en hypotese, teste hypotesen og validere rettelsen. AI hjelper på hvert trinn; men den "fikse" avgjørelsen tas ved å se at feilen faktisk har forsvunnet.
Hvorfor er bevis alt?
En LLM ser ikke feil slik du gjør; Han vet bare hva du forteller ham. En setning som "Applikasjonen krasjer" gir modellen nesten ingen informasjon, og modellen fyller gapet med en prediksjon - det vil si en hallusinasjon. I sin tur, hele feilmeldingen, stack trace — en sammenbrudd av hvilke funksjonskall feilen oppstod gjennom, input som utløste feilen, og hva som var forventet, etc. Gitt observert atferd, kan modellen rangere sanne sannsynligheter.
Ved feilsøking, tenk på AI som en assistent for en detektiv: jo mer bevis du presenterer, desto mer nøyaktig blir hypotesen den genererer. Hvis det ikke er bevis, vil assistenten bare gjette og kan lede deg på feil spor.
Tips: Før du porterer en feil til AI, reduser den til det minste reproduserbare eksempelet. Den minste koden og inngangen som utløser feilen gjør ting radikalt enklere for både deg og modellen; oftest under denne reduksjonen finner du årsaken selv.
Trinn for trinn: Root Cause Analysis Flow
- Forklar symptomet. "Hva skjer, hva forventet du skulle skje?" Skriv de to i én setning.
- Samle bevis. Full feilmelding, stabelsporing, relevante logglinjer, utløsende oppføring, versjonsinformasjon.
- Få hypotesen generert. Fra AI "3 mulige årsaker som forklarer dette symptomet og hvordan tester jeg for hver?" spørre.
- Test den billigste hypotesen først. Legg til en logg, skriv ut en verdi, kjør en test. Bekrefter bevisene hypotesen?
- Rett opp årsaken, ikke symptomet. I stedet for å dempe symptomet med et plaster, ta opp grunnårsaken.
- Valider og legg til regresjonstesting. Se feilen forsvinne; Skriv deretter en test som vil fange opp feilen slik at den ikke kommer tilbake.
Tre minivesker
Tilfelle 1 — Stabelsporingen førte til riktig fil. En applikasjon returnerte en 500-feil på visse forespørsler. Utvikleren ga full stabelsporing og utløsende forespørsel til AI; Modellen antok at feilen var forårsaket av en Ingen-verdi i et datoparsingslag. Utvikleren la til en logg på den linjen, bekreftet den og løste den på 15 minutter; 2 timer ble kastet bort dagen før med uprøvde forsøk.
Tilfelle 2 - Hallusinasjon førte til feil spor. En annen utvikler skrev ganske enkelt "databaseforbindelsen faller". AI anklaget en tilkoblingsbassenginnstilling uten bevis; Utvikleren brukte 40 minutter på å fikle med denne innstillingen. Den virkelige årsaken var en timeout på nettverkssiden og ble bare avslørt ved å se på loggene. Leksjon: en hypotese tatt uten bevis er bare sannsynlig, ikke pålitelig.
Tilfelle 3 - Flaky feil fanget. Det var en test som av og til feilet. AI fikk testkoden, feilmeldingen og informasjonen "noen ganger går det, noen ganger mislykkes det"; modellen indikerte en delt tid/ordreavhengighet av testene. Gjennomgangen bekreftet at testen var basert på systemets lokale tid. Når klokken var fikset (hånet), ble testen stabil.
Fire kopierbare maler
Generering av evidensbasert hypotese:
Jeg feilsøker en feil. Bevis nedenfor.- Forventet atferd: {{expected}}- Observert atferd: {{observert}}- Feilmelding/stakksporing: {{trace}}- Utløsende input: {{input}}- Miljø/versjon: {{version}}List opp de 3 MEST SANsynlige grunnårsakene som forklarer dette symptomet. For hver: hvordan tester jeg (billigste sjekk) og hvordan fikser det hvis det er sant. Hvis bevisene er utilstrekkelige, fortell meg hvilken tilleggsinformasjon du trenger.
Tolking av stabelsporet:
Les dette stabelsporet. Skille mellom hvilken linje feilen SANsynligvis starter ved (roten) og hvilke linjer som bare er fortsettelser av kjeden. Foreslå 1-2 steder å se først. Beslektet kode:{{code}}Trace:{{trace}}
Minimal repro subtraksjon:
Koden nedenfor gir en feil. Reduser den til den MINSTE forekomsten som fortsatt utløser feilen, men forkaster alt som er unødvendig. Ikke anta at hver del du fjerner ikke påvirker feilen, men legg til en merknad som sier "hvis feilen forsvinner når du fjerner dette, er det derfor".{{code}}
Post-korreksjonsvalidering og regresjonstesting:
Anta at rotårsaken er {{cause}} og jeg gjør følgende rettelse: {{fix}}.1) Løser denne rettelsen faktisk symptomet, vil det ha noen bivirkninger?2) Skriv en regresjonstest som vil fange opp denne feilen i fremtiden.
Svak forespørsel / Sterk forespørsel
Svak: "Koden fungerer ikke, hvorfor?"
Strong: "Node 20 / Express. POST /orders returnerer 500 når varer er en tom streng i kroppen; burde ha returnert 400. Stack trace: TypeError: Kan ikke lese egenskapene til undefined (leser '0') — vedlagt er hele sporet og tilhørende behandler. Gi meg de 3 mest sannsynlige årsakene som forklarer dette symptomet og hvordan man tester hvert" [trace + kode].
Kraftig versjon; Det gir miljøet, endepunkt, triggerinngang, eksakt feiltype og forventet oppførsel. Modellen kan ikke lenger gi spådommer, men analyser.
trinn
AI sitt bidrag
din kontroll
samle bevis
Hvilke bevis trengs, minner om
Samler virkelig bevis
hypotese generering
List opp mulige årsaker
Prioriterer med kontekst
hypotesetesting
Anbefaler testmetode
Opererer og observerer personlig
korrigering
patch anbefaler
Løser det grunnårsaken? Det er sant.
regresjon
skriver en test
Verifiserer at testen er ødelagt
Løse grunnårsaken, ikke symptomet
Mesteparten av tiden vil AI foreslå en oppdatering som raskt demper symptomet: legg til et forsøk/fangst, sett en nullsjekk, svelg feilen. Dette er noen ganger sant, ofte farlig; fordi den opprinnelige årsaken forblir på plass og bryter ut igjen fra et annet sted. Med hver reparasjon, spør deg selv: "Løser dette årsaken til feilen, eller gjør det den usynlig?" Når du finner årsaken, er løsningen vanligvis mindre, mer robust og permanent.
Forsiktig: Stille svelging av et unntak (tom fangst) løser ikke feilen; det skjuler bare og gjør fremtidig diagnose umulig. Hvis AI foreslår en slik "løsning", ikke aksepter den uten å stille spørsmål ved grunnårsaken.
Vanlige feil
- Stille spørsmål uten bevis. Tvetydige setninger presser modellen inn i hallusinasjoner; Gi fullstendig feil, spor og input.
- Holder fast på den første hypotesen. AIs første forslag er kanskje ikke det mest sannsynlige; Start med den billigste kontrollerbare hypotesen.
- Lapper på symptomet og mangler grunnårsaken. Den lydløse feilen kommer tilbake.
- Lukker rettelsen uten å bekrefte den. Se i produksjonslignende tilstand at feilen faktisk forsvinner.
- Skriver ikke regresjonstester. Hvis ingen tester legges til, vil den samme feilen stille tilbake i senere versjoner.
Oppsummert
Ved feilsøking er kraften til AI direkte proporsjonal med bevisene du gir den: uten fullstendig feilmelding, stabelsporing, utløsende input og forventet oppførsel, spekulerer modellen bare. Disiplinert flyt – klargjør symptom, samle bevis, generer hypoteser, test med billigste kontroll, fiks rotårsak, verifiser og legg til regresjonstesting – lukker feilen både raskt og permanent. AI er en hypotesegenerator; Du er den som bestemmer at feilen faktisk er løst.
Søknadsoppgave
Velg en ekte feil du har støtt på nylig (eller reproduser en testfeil). Gjør trinnet "minimum reproduksjon" først; Fjern den minste koden og inngangen som utløser feilen. Få deretter 3 mulige årsaker og testmetoder fra AI med malen "evidensbasert hypotesegenerering". Test den billigste hypotesen selv, finn rotårsaken, fiks den, og skriv til slutt en regresjonstest som vil fange opp denne feilen i fremtiden og verifisere at testen faktisk er ødelagt.
sjekkliste
- [ ] Jeg reduserer feilen til den minste reproduserbare prøven før jeg flytter den til AI.
- [ ] Jeg legger til hele feilmeldingen, stabelsporing, inndata og forventet oppførsel i ledeteksten.
- [ ] Jeg starter med den billigste kontrollerbare, uten å være låst til en eneste hypotese.
- [ ] Jeg bekrefter at jeg har løst årsaken i stedet for å lappe symptomet.
- [ ] Jeg observerer at rettelsen faktisk fikser feilen.
- [ ] Jeg legger til en regresjonstest for hver løst feil.