Så felsöker du en AI-byggd app: en praktisk metod

För att felsöka en app byggd med AI, får du först buggen att hända igen med avsikt. Samla sedan bevis: de exakta stegen, felmeddelandet och vad webbläsarens konsol och nätverksfliken visar. Ge det till AI:n som "Jag gjorde X, förväntade mig Y, fick Z". Om en rättning gör det värre, återställ till den senaste fungerande versionen i stället för att stapla fler rättningar ovanpå. Du behöver inte läsa koden för att göra något av detta väl.

Den här guiden täcker hela loopen, inklusive en snabb genomgång av webbläsarens utvecklarverktyg för icke-utvecklare.

Felsökningsloopen

Varje buggrättning, oavsett om det är en person eller en AI som gör den, följer samma loop:

1. Återskapa: få buggen att hända på ett pålitligt sätt.
2. Observera: samla felmeddelandet och vad appen gjorde.
3. Beskriv: ge AI:n exakta steg, förväntat resultat och faktiskt resultat.
4. Rätta: låt AI:n ändra en sak.
5. Verifiera: upprepa exakt samma steg och bekräfta att det är löst, och att inget i närheten gick sönder.
6. Återställ vid behov: om det blev värre, ångra och försök igen med bättre underlag.

Den mesta tiden som går förlorad i AI-byggda appar beror på att man hoppar över steg 1, 2 och 5: man säger "det är trasigt", accepterar en ändring utan att testa den och ber sedan om ännu en rättning ovanpå en trasig sådan.

Steg 1: Återskapa buggen

En bugg du kan utlösa på begäran är halvt löst. Försök hitta den kortaste uppsättningen steg som orsakar den.

Fråga dig själv:

• Händer det varje gång? Om det bara händer ibland, vad är annorlunda när det händer? En viss post, en långsam uppkoppling, att du är utloggad?
• Händer det för alla användare? Logga in med ett annat konto. Många buggar syns bara för nya användare utan data, eller för en användare med en annan roll.
• Händer det på alla enheter? Prova en skärm i mobilbredd och en annan webbläsare.
• Började det efter en viss ändring? Om det fungerade igår är de senaste ändringarna de främsta misstänkta.

Skriv ner stegen som en kort numrerad lista. Du klistrar in den i prompten senare.

Steg 2: Läs felmeddelandet

Felmeddelanden ser skrämmande ut, men du behöver bara några delar av dem.

Du behöver inte förstå den; du behöver kopiera den exakt. "Cannot read properties of undefined (reading 'name')" berättar för AI:n att koden väntade sig data (troligen en bokning eller en användare) som inte fanns. En omskrivning som "något odefinierat fel" tappar just den informationen.

Några vanliga, översatta i korthet:

• undefined- / null-fel: koden väntade sig data som inte kom fram. Ofta ett laddningsläge eller en tom lista som koden inte hanterade.
• 404 Not Found: sidan eller API-adressen finns inte. Ofta ett stavfel i en rutt eller en länk till en sida som har bytt namn.
• 401 Unauthorized / 403 Forbidden: förfrågan var inte inloggad, eller användaren får inte göra det.
• 500 Internal Server Error: serverkoden kraschade. Den verkliga orsaken finns i serverloggarna, inte i webbläsaren.
• CORS-fel: webbläsaren blockerade en förfrågan till en annan domän. Vanligtvis ett konfigurationsproblem på serversidan.

Steg 3: Använd webbläsarens utvecklarverktyg

Alla stationära webbläsare har inbyggda utvecklarverktyg ("devtools"). De visar vad sidan gör bakom kulisserna. I Chrome, Edge och Firefox högerklickar du var som helst på sidan och väljer Inspektera, eller trycker F12 (Cmd+Option+I på en Mac). I Safari aktiverar du först menyn Utveckla i Safaris inställningar.

Du behöver bara tre flikar.

Konsol

Fliken Konsol listar fel och meddelanden från sidans kod. Fel visas i rött. Om en knapp inte gör något när du klickar på den visar konsolen mycket ofta ett rött fel precis när du klickar. Kopiera hela feltexten (högerklicka för ett kopieringsalternativ i de flesta webbläsare).

Nätverk

Fliken Nätverk listar varje förfrågan som sidan gör: när den laddar data, sparar ett formulär eller loggar in. Öppna den och upprepa stegen som orsakar buggen.

• Leta efter rader i rött eller med status 400 eller högre.
• Klicka på en misslyckad rad för att se dess svar. Ett serverfel innehåller ofta ett meddelande där som är mer användbart än något på skärmen.
• Notera förfrågans URL och statuskod. "POST till /api/bookings returnerade 500" är en mycket användbar mening att ge AI:n.

Markera Behåll logg om buggen involverar en sidomladdning eller omdirigering, så att förfrågningarna inte försvinner.

Element

Fliken Element (eller Inspektören) visar sidans struktur och stilar. Den är mest användbar för layoutbuggar: håll musen över ett element för att se dess storlek och avstånd markerade. Du behöver inte ändra något här. Det räcker att säga "sidfoten är 2 000 pixlar bred i mobilvy och skjuter sidan åt sidan".

Steg 4: Kontrollera serverloggarna

Vissa buggar uppstår på servern, där webbläsaren inte kan se dem. Ett 500-fel i nätverksfliken är det klassiska tecknet. Serverloggar, alltså textutdata från din backend när den körs, innehåller oftast det verkliga felet med en stack trace (en lista över funktionerna som kördes när det kraschade).

Var du hittar dem beror på verktyget. I de flesta AI-appbyggare kan du öppna en terminal eller loggvy för projektet, eller helt enkelt fråga AI:n: "Kontrollera serverloggarna för fel från den senaste förfrågan och berätta vad som misslyckades."

Steg 5: Beskriv buggen för AI:n

Lägg det du samlat i den här formen:

På bokningssidan, inloggad som medlem: jag klickade på Avboka för imorgons 9:00-lektion. Förväntat: bokningen försvinner och lektionen visar en ledig plats till. Faktiskt: inget ändras på skärmen. Konsolen visar TypeError: Cannot read properties of undefined (reading 'id') i BookingCard.tsx:31, och nätverksfliken visar att DELETE /api/bookings/123 returnerade 500. Hitta orsaken, rätta den och kontrollera att avbokning fungerar för en medlem med en bokning och för en med flera.

Varför varje del spelar roll:

• Var och som vem avgränsar det till en skärm och en roll.
• Exakta steg gör att AI:n kan återskapa buggen.
• Förväntat kontra faktiskt definierar vad "löst" betyder.
• Felmeddelandets text och den misslyckade förfrågan pekar direkt på orsaken.
• "Kontrollera att…" ber AI:n att verifiera, inte bara ändra.

Om AI:n har försökt rätta två gånger utan framgång, be den förklara innan den ändrar något:

Ändra ingen kod ännu. Vad tror du orsakar detta, och vilka belägg stöder det?

En felaktig teori är lätt att upptäcka när den skrivs ut, och mycket billigare att korrigera än en felaktig rättning.

Steg 6: Verifiera och kontrollera närliggande delar

När AI:n säger att det är fixat, upprepa de exakta stegen från steg 1. Kontrollera sedan sådant som ligger runt omkring:

• Samma handling för en annan användarroll
• Samma handling utan data och med mycket data
• Sidor som delar komponenter med den du rättade
• En skärm i mobilbredd, om rättningen rörde layouten

Ändringar gjorda av AI fixar ibland en väg och bryter tyst en annan. En kontroll på två minuter nu sparar en förvirrad timme senare.

Steg 7: Återställ i stället för att lägga på

Om en rättning gjorde saker sämre, eller du har gått tre varv utan framsteg, gå tillbaka. Att återställa till den senaste fungerande versionen och formulera om med bättre underlag slår nästan alltid att be om en fjärde rättning ovanpå tre felaktiga. Varje misslyckat försök lämnar kod efter sig, och den koden förvirrar nästa försök.

Bra vanor som gör återställning enkel:

• Testa efter varje ändring, så att du vet vilken ändring som förstörde något.
• Håll ändringarna små: en funktion eller rättning per meddelande.
• Notera den senaste fungerande versionen innan du gör något riskabelt.
• Om koden ligger i Git, committa fungerande versioner så att du kan återgå till dem.

Vanliga felmönster i AI-byggda appar

När problemet inte är en bugg

Vissa "buggar" är att AI:n bygger exakt det den fick i uppdrag, och beskrivningen var tvetydig. Om rättningen du ber om egentligen är en beteendeförändring, säg det tydligt: "Ändra så att…". Om du märker att du inte själv vet vilket det korrekta beteendet är, bestäm det först. Vår guide om hur du skriver prompter till AI-appbyggare går igenom hur man specificerar regler tydligt. Och om du förbereder en app för riktiga användare täcker hur du tar en AI-prototyp till produktion kontrollerna som är värda att göra före lansering.

Felsökning i Mythex

Mythex har verktyg för varje steg i loopen:

• Förhandsvisning för att återskapa buggen, inklusive en ram i telefonstorlek.
• /test låter agenten klicka igenom din live-förhandsvisning som en användare och rapportera trasiga flöden.
• /fix riktar agenten mot just sådana brister.
• Planläge låter agenten undersöka och förklara innan den redigerar något.
• Kod → terminal visar din apps serverloggar.
• Återställ till den här punkten på valfritt svar återställer projektet till den checkpointen.

Om en publicering misslyckas, erbjuder publiceringsdialogen oftast Fixa med AI, som läser byggutdatan eller appens loggar. Se Felsök din app och Felsök publicering i dokumentationen.

Frågor