Vinster:
- Möjlighet att reducera en bugg till den minsta reproducerbara instansen och flytta den till AI med fullt bevis
- Förmåga att testa evidensbaserade hypoteser med den billigaste kontrollen och hitta grundorsaken
- Förmåga att lösa grundorsaken och säkra den med ett regressionstest snarare än att lappa symtomet
Felsökning är processen att ta reda på varför en programvara beter sig oväntat och åtgärda det. Det är det jobb där en utvecklare tillbringar mest tid och blir mest trött; För oftast är misstaget inte där det dyker upp, utan är gömt några steg bakom. AI är en kraftfull tänkande partner som påskyndar denna forskning - men bara om du ger den rätt bevis. Felsökning utan bevis är det område där AI producerar flest hallucinationer.
I den här enheten etablerar vi ett disciplinerat flöde från att generera felet till att komma till grundorsaken: klargöra symtomet, samla bevis (felmeddelande, stackspårning, logg, inmatning), generera en hypotes, testa hypotesen och validera korrigeringen. AI hjälper i varje steg; men det "fixade" beslutet fattas genom att se att buggen faktiskt har försvunnit.
Varför är bevis allt?
En LLM ser inte fel som du gör; Han vet bara vad du säger till honom. En mening som "Applikationen kraschar" ger modellen nästan ingen information, och modellen fyller tomrummet med en förutsägelse - det vill säga en hallucination. I sin tur, det fullständiga felmeddelandet, stack trace — en uppdelning av vilka funktionsanrop felet uppstod genom, ingången som utlöste felet och vad som förväntades, etc. Givet observerat beteende kan modellen rangordna sanna sannolikheter.
Vid felsökning, tänk på AI som en assistent till en detektiv: ju mer bevis du presenterar, desto mer exakt blir hypotesen den genererar. Om det inte finns några bevis kommer assistenten bara gissa och kan leda dig på fel spår.
Tips: Innan du porterar en bugg till AI, reducera den till det minsta reproducerbara exemplet. Den minsta koden och inmatningen som utlöser felet gör det radikalt lättare för både dig och modellen; oftast under denna minskning hittar du själv orsaken.
Steg för steg: Flöde för rotorsaksanalys
- Förtydliga symtomet. "Vad är på gång, vad förväntade du dig skulle hända?" Skriv de två i en mening.
- Samla bevis. Fullständigt felmeddelande, stackspårning, relevanta loggrader, utlösande inmatning, versionsinformation.
- Få hypotesen genererad. Från AI "3 möjliga orsaker som förklarar detta symptom och hur testar jag för varje?" be.
- Testa den billigaste hypotesen först. Lägg till en logg, skriv ut ett värde, kör ett test. Bekräftar bevisen hypotesen?
- Åtgärda grundorsaken, inte symtomet. Istället för att tysta symtomet med ett plåster, ta itu med grundorsaken.
- Validera och lägg till regressionstestning. Se felet försvinna; Skriv sedan ett test som kommer att fånga det felet så att det inte kommer tillbaka.
Tre minifodral
Fall 1 — Stackspårningen ledde till rätt fil. En applikation returnerade ett 500-fel på vissa förfrågningar. Utvecklaren gav hela stackspårningen och utlösande begäran till AI; Modellen antog att felet orsakades av ett None-värde i ett datumanalyslager. Utvecklaren lade till en logg på den raden, verifierade den och löste den på 15 minuter; 2 timmar slösades bort dagen innan med oprövade experiment.
Fall 2 — Hallucination ledde till fel spår. En annan utvecklare skrev helt enkelt "databasanslutningen avbryts". AI anklagade en anslutningspoolinställning utan några bevis; Utvecklaren ägnade 40 minuter åt att mixtra med den här inställningen. Den verkliga orsaken var en timeout på nätverkssidan och avslöjades endast genom att titta på loggarna. Lärdom: en hypotes tagen utan bevis är bara sannolik, inte tillförlitlig.
Fall 3 — Flakigt fel har upptäckts. Det fanns ett test som ibland misslyckades. AI fick testkoden, felmeddelandet och informationen "ibland går det, ibland misslyckas det"; modellen indikerade ett delat tids-/orderberoende för testerna. Granskningen bekräftade att testet baserades på systemets lokala tid. När klockan väl var fixerad (hånad) blev testet stabilt.
Fyra kopieringsbara mallar
Evidensbaserad hypotesgenerering:
Jag felsöker en bugg. Bevis nedan.- Förväntat beteende: {{expected}}- Observerat beteende: {{observed}}- Felmeddelande/stackspårning: {{trace}}- Triggande input: {{input}}- Miljö/version: {{version}}Lista de 3 MEST SANNOLIKA orsakerna som förklarar detta symptom. För varje: hur testar jag (billigaste kontroll) och hur man fixar det om det är sant. Om bevisen är otillräckliga, berätta för mig vilken ytterligare information du behöver.
Tolka stackspåret:
Läs detta stack trace. Skilj mellan vilken rad felet SOM TROR börjar vid (roten) och vilka rader som bara är fortsättningar på kedjan. Föreslå 1-2 ställen att titta först. Relaterad kod:{{code}}Spåra:{{trace}}
Minimal repro subtraktion:
Koden nedan ger ett fel. Minska den till den MINSTA instans som fortfarande utlöser felet men kasserar allt onödigt. Anta inte att varje del du tar bort inte påverkar felet, men lägg till en anteckning som säger "om felet försvinner när du tar bort detta, det är därför".{{code}}
Validering efter korrigering och regressionstestning:
Anta att grundorsaken är {{orsak}} och jag fixar följande: {{fix}}.1) Fixar denna korrigering faktiskt symtomet, kommer det att ha några biverkningar?2) Skriv ett regressionstest som kommer att fånga denna bugg i framtiden.
Svag prompt / Stark prompt
Svag: "Koden fungerar inte, varför?"
Stark: "Nod 20 / Express. POST /orders returnerar 500 när objekt är en tom sträng i kroppen; borde ha returnerat 400. Stack trace: TypeError: Kan inte läsa egenskaperna för odefinierad (läser '0') — bifogad är hela spåret och tillhörande hanterare. Ge mig de 3 mest troliga orsakerna som förklarar detta symptom och hur man testar varje" [trace + kod].
Kraftfull version; Det ger miljön, endpoint, triggeringång, exakt feltyp och förväntat beteende. Modellen kan inte längre göra förutsägelser, utan analys.
steg
AI:s bidrag
din kontroll
samla bevis
Vilka bevis behövs, påminner
Samlar verkligen bevis
hypotesgenerering
Lista möjliga orsaker
Prioriterar med sammanhang
hypotesprövning
Rekommenderar testmetod
Verkar och observerar personligen
korrigering
patch rekommenderar
Löser det grundorsaken? Det är sant.
regression
skriver ett test
Verifierar att testet är brutet
Att lösa grundorsaken, inte symtomet
För det mesta kommer AI:n att föreslå en patch som snabbt tystar symtomet: lägg till ett försök/fång, sätt en nollkontroll, svälj felet. Detta är ibland sant, ofta farligt; eftersom den ursprungliga orsaken finns kvar och bryter ut igen från någon annanstans. Med varje fix, fråga dig själv: "Löser detta orsaken till felet, eller gör det det osynligt?" När du väl hittar grundorsaken är åtgärden vanligtvis mindre, mer robust och permanent.
Varning: Att tyst svälja ett undantag (tom hake) löser inte felet; det bara döljer och omöjliggör framtida diagnoser. Om AI föreslår en sådan "lösning", acceptera den inte utan att ifrågasätta grundorsaken.
Vanliga misstag
- Att ställa frågor utan bevis. Tvetydiga meningar driver modellen till hallucination; Ge fullständigt fel, spår och input.
- Håller fast vid den första hypotesen. AI:s första förslag kanske inte är det mest sannolika; Börja med den billigaste kontrollerbara hypotesen.
- Lappar symtomet och missar grundorsaken. Det tystade felet återkommer.
- Stänger fixen utan att verifiera den. Se i produktionsliknande skick att felet faktiskt försvinner.
- Skriver inte regressionstest. Om inga tester läggs till återkommer samma fel tyst i senare versioner.
Sammanfattningsvis
Vid felsökning är kraften hos AI direkt proportionell mot bevisen du ger den: utan det fullständiga felmeddelandet, stackspårning, triggande input och förväntat beteende spekulerar modellen bara. Disciplinerat flöde – klargör symptom, samla bevis, generera hypoteser, testa med billigaste kontroll, åtgärda grundorsaken, verifiera och lägg till regressionstestning – stänger buggen både snabbt och permanent. AI är en hypotesgenerator; Det är du som bestämmer att felet faktiskt är löst.
Applikationsuppgift
Välj en riktig bugg som du har stött på nyligen (eller återskapa en testbugg). Gör steget "minsta reproduktion" först; Ta bort den minsta koden och inmatningen som utlöser felet. Få sedan 3 möjliga orsaker och testmetoder från AI med mallen "evidensbaserad hypotesgenerering". Testa den billigaste hypotesen själv, hitta grundorsaken, fixa den och skriv slutligen ett regressionstest som kommer att fånga denna bugg i framtiden och verifiera att testet faktiskt är trasigt.
checklista
- [ ] Jag reducerar felet till det minsta reproducerbara provet innan jag flyttar det till AI.
- [ ] Jag lägger till hela felmeddelandet, stackspårning, indata och förväntat beteende i prompten.
- [ ] Jag börjar med den billigaste kontrollerbara, utan att vara låst till en enda hypotes.
- [ ] Jag verifierar att jag har åtgärdat grundorsaken istället för att korrigera symptomet.
- [ ] Jag observerar att korrigeringen faktiskt fixar buggen.
- [ ] Jag lägger till ett regressionstest för varje löst bugg.