Förstå innan du fixar. Det vanligaste misslyckandet i AI-felsökning är inte att modellen ger fel svar — det är att den ger ett rimligt svar på en fråga du ställde för tidigt. Sextio sekunders egen undersökning innan du frågar ändrar vilken fråga du ställer, och det ändrar allt.
Slingan som äter tjugo minuter
Mönstret är lätt att känna igen i efterhand och nästan omöjligt att se när man är i det:
Orsaken är att modellen optimerar för en trolig fix, inte för grundorsaken. Den ser bara det du visar. Visar du ett felmeddelande får du den vanligaste förklaringen till det felmeddelandet — vilket ofta inte är din förklaring.
Varje fix i slingan kan dessutom dölja det ursprungliga problemet i stället för att lösa det. Det är därför den fjärde fixen inte hjälper: du felsöker nu konsekvenserna av de tre första.
Läs felmeddelandet själv först
Det låter självklart och görs sällan. De flesta kastar en blick på felet, känner ett stråk av förvirring och sträcker sig direkt efter modellen. En minuts faktisk läsning ändrar vilken fråga du kan ställa.
Ett felmeddelande har nästan alltid fyra delar, även om de inte är utmärkta:
- Feltypen.
TypeError,NullReferenceException,ECONNREFUSED. Den avgränsar kategorin av orsaker kraftigt. - Meddelandet. Läs det bokstavligt. "Cannot read properties of undefined" betyder att något är
undefinedsom du trodde var ett objekt — inget annat. - Stackspåret. Översta raden är där det small. Raderna under visar hur du kom dit. Din egen kod är oftast en av dem — leta efter den.
- Sammanhanget. Statuskod, radnummer, tidsstämpel, vilken förfrågan. Det smalnar av sökrymden innan du läst en enda rad kod.
Ofta räcker den här minuten för att lösa problemet utan att fråga någon. Och när den inte gör det kan du ställa en fråga som handlar om ditt fall i stället för om felmeddelandet i allmänhet.
Undersökning före fråga
Tre uppgifter är nästan alltid värda att ha innan du frågar. De tar några minuter och de avgör svarets kvalitet mer än formuleringen gör.
Felsökningsmallen
När undersökningen är gjord är prompten nästan skriven av sig själv. Det som gör den effektiv är att den innehåller vad du redan uteslutit — annars föreslår modellen det först.
Symtom: vad som händer, och vad du förväntade dig i stället.
Reproduktion: stegen som framkallar felet, eller "inträffar ungefär var tionde gång".
Fel: hela felmeddelandet med stackspår, inte bara sista raden.
Relevant kod: funktionen där det small och den som anropar den.
Redan uteslutet: vad du kontrollerat och vad du vet stämmer.
Miljö: språk- och paketversioner, om det är relevant.
Förklara först vad du tror är grundorsaken och varför. Föreslå fix efter det.
Den sista raden gör mer nytta än den ser ut att göra. Den tvingar fram ett resonemang du kan bedöma, i stället för en kodändring du bara kan acceptera eller förkasta.
Buggar där AI sällan hjälper
Det finns en kategori där modellen konsekvent är svag, och det är värt att känna igen den tidigt så du inte förlorar en timme på fel verktyg.
- Fel som beror på tid eller ordning. Race conditions, saker som bara händer under last, cacher som ligger ur fas. Modellen ser en ögonblicksbild av koden, inte händelseförloppet.
- Fel som bara finns i produktion. Skillnaden ligger nästan alltid i miljön — konfiguration, data, rättigheter — och den syns inte i koden du klistrar in.
- Fel i tredjepartsbeteende. Ett bibliotek som gör något odokumenterat. Här gissar modellen utifrån hur biblioteket brukade fungera.
- Prestandaproblem utan mätning. Utan profilering föreslår modellen den vanligaste optimeringen, som sällan är din flaskhals.
I de här fallen är modellen fortfarande användbar — men som bollplank för hypoteser, inte som källa till fixar. Fråga "vilka tre saker skulle kunna orsaka det här mönstret?" i stället för "hur fixar jag det?".
När du ska starta om
En felsökningssession har en hållbarhet. Efter ett antal förslag som inte fungerat är konversationen full av felaktiga antaganden som modellen nu bygger vidare på. Den upprepar sig, eller föreslår varianter av samma sak.
Två tecken på att det är dags: du har fått samma förslag två gånger, eller du kan inte längre sammanfatta vad ni kommit fram till.
Lösningen är att börja om med en ren konversation och skriva ihop allt du nu vet — inklusive vad som visat sig inte vara orsaken. Det brukar ta tre minuter och lösa det som femton minuters fram och tillbaka inte gjorde.
Felsökning fångar problemen efter att de uppstått. Nästa guide handlar om att fånga dem innan.