Sådan debugger du en AI-bygget app: en praktisk metode

For at debugge en app bygget med AI skal du først få fejlen til at ske igen med vilje, derefter indsamle beviser — de præcise trin, fejlbeskeden, og hvad browserens konsol og netværksfane viser — og give det til AI'en som «Jeg gjorde X, forventede Y, fik Z». Hvis en rettelse gør tingene værre, så rul tilbage til den sidste fungerende version i stedet for at stable flere rettelser oven på. Du behøver ikke læse koden for at gøre alt dette godt.

Denne guide dækker hele loopet, inklusive en hurtig rundtur i browserens udviklerværktøjer for ikke-udviklere.

Debug-loopet

Hver fejlrettelse, uanset om det er en person eller en AI, der laver den, følger det samme loop:

1. Genskab — få fejlen til at ske pålideligt.
2. Observér — indsaml fejlbeskeden og hvad appen lavede.
3. Beskriv — giv AI'en præcise trin, det forventede resultat og det faktiske resultat.
4. Ret — lad AI'en ændre én ting.
5. Verificér — gentag de præcise trin og bekræft, at det er rettet, og at intet i nærheden gik i stykker.
6. Rul tilbage, hvis nødvendigt — hvis det blev værre, så fortryd og prøv igen med bedre information.

De fleste af de timer, der spildes på AI-byggede apps, kommer af, at man springer trin 1, 2 og 5 over: siger «det er i stykker», accepterer en ændring uden at teste den, og beder så om endnu en rettelse oven på en i stykker.

Trin 1: Genskab fejlen

En fejl, du kan udløse efter behov, er halvt rettet. Prøv at finde det korteste sæt trin, der forårsager den.

Spørg dig selv:

• Sker det hver gang? Hvis kun nogle gange, hvad er så anderledes, når det sker — en bestemt post, en langsom forbindelse, at du er logget ud?
• Sker det for alle brugere? Log ind med en anden konto. Mange fejl viser sig kun for nye brugere uden data, eller for en bruger med en anden rolle.
• Sker det på alle enheder? Prøv en skærm i telefonbredde og en anden browser.
• Begyndte det efter en bestemt ændring? Hvis det virkede i går, er de sidste par ændringer de oplagte mistænkte.

Skriv trinene ned som en kort nummereret liste. Du indsætter den i prompten senere.

Trin 2: Læs fejlbeskeden

Fejlbeskeder ser skræmmende ud, men du behøver kun nogle få dele af dem.

Du behøver ikke forstå den; du skal kopiere den præcist. «Cannot read properties of undefined (reading 'name')» fortæller AI'en, at koden forventede nogle data (sandsynligvis en booking eller en bruger), som ikke var der. En omskrivning som «en undefined-fejl» mister den information.

Nogle almindelige, groft oversat:

• undefined- / null-fejl — koden forventede data, der ikke kom frem. Ofte en indlæsningstilstand eller en tom liste, koden ikke håndterede.
• 404 Not Found — siden eller API-adressen findes ikke. Ofte en tastefejl i en rute eller et link til en side, der blev omdøbt.
• 401 Unauthorized / 403 Forbidden — forespørgslen var ikke logget ind, eller brugeren har ikke lov til det.
• 500 Internal Server Error — server-koden gik ned. Den egentlige grund står i serverlogs, ikke i browseren.
• CORS-fejl — browseren blokerede en forespørgsel til et andet domæne. Normalt et konfigurationsproblem på serversiden.

Trin 3: Brug browserens udviklerværktøjer

Alle desktopbrowsere har indbyggede udviklerværktøjer («devtools»). De viser, hvad siden laver bag kulisserne. I Chrome, Edge og Firefox skal du højreklikke hvor som helst på siden og vælge Inspect, eller trykke F12 (Cmd+Option+I på en Mac). I Safari skal du først slå menuen Develop til i Safaris indstillinger.

Du har kun brug for tre faner.

Console

Fanen Console lister fejl og beskeder fra sidens kode. Fejl vises med rødt. Hvis en knap ikke gør noget, når du klikker på den, vil konsollen meget ofte vise en rød fejl i det øjeblik, du klikker. Kopiér hele fejlteksten (højreklik for en kopieringsmulighed i de fleste browsere).

Network

Fanen Network lister alle forespørgsler siden laver — indlæsning af data, gemning af en formular, login. Åbn den, og gentag trinene, der forårsager fejlen.

• Kig efter rækker i rødt eller med en status på 400 eller højere.
• Klik på en fejlende række for at se dens Response. En serverfejl indeholder ofte en besked dér, der er mere nyttig end noget på skærmen.
• Notér forespørgslens URL og statuskode — «POST til /api/bookings returnerede 500» er en meget nyttig sætning at give AI'en.

Sæt kryds i Preserve log, hvis fejlen involverer en sideindlæsning eller omdirigering, så forespørgslerne ikke forsvinder.

Elements

Fanen Elements (eller Inspector) viser sidens struktur og stilarter. Den er mest nyttig til layoutfejl: hold musen over et element for at se dets størrelse og mellemrum fremhævet. Du behøver ikke redigere noget her; det er nok at sige «footeren er 2.000 pixels bred på mobil og skubber siden til siden».

Trin 4: Tjek serverlogs

Nogle fejl sker på serveren, hvor browseren ikke kan se dem. En 500-fejl i netværksfanen er det klassiske tegn. Serverlogs — tekstoutputtet fra din backend, mens den kører — indeholder typisk den egentlige fejl med en stack trace (en liste over de funktioner, der kørte, da det fejlede).

Hvor du finder dem, afhænger af dit værktøj. I de fleste AI-app-builders kan du åbne en terminal eller logvisning for projektet, eller blot bede AI'en: «Tjek serverlogs for fejl fra den sidste forespørgsel og fortæl mig, hvad der fejlede.»

Trin 5: Beskriv fejlen til AI'en

Sæt det, du har indsamlet, i denne form:

På bookingsiden, logget ind som medlem: Jeg klikkede på Cancel for morgendagens 9:00-hold. Forventet: bookingen forsvinder, og holdet viser én ledig plads mere. Faktisk: intet ændrer sig på skærmen. Konsollen viser TypeError: Cannot read properties of undefined (reading 'id') i BookingCard.tsx:31, og netværksfanen viser at DELETE /api/bookings/123 returnerede 500. Find årsagen, ret den, og tjek at annullering virker for et medlem med én booking og for et med flere.

Hvorfor hver del betyder noget:

• Hvor og som hvem indsnævrer det til én skærm og én rolle.
• Præcise trin lader AI'en genskabe fejlen.
• Forventet vs. faktisk definerer, hvad «rettet» betyder.
• Fejlteksten og den fejlende forespørgsel peger direkte på årsagen.
• «Tjek at…» beder AI'en om at verificere, ikke bare ændre.

Hvis AI'en har forsøgt en rettelse to gange uden held, så bed den forklare, før den ændrer noget:

Ændr endnu ikke koden. Hvad tror du forårsager dette, og hvilket bevis understøtter det?

En forkert teori er let at spotte, når den er skrevet ud, og meget billigere at korrigere end en forkert rettelse.

Trin 6: Verificér, og tjek omkringliggende

Når AI'en siger, at den er rettet, så gentag de præcise trin fra Trin 1. Tjek derefter det omkring det:

• Den samme handling for en anden brugerrolle
• Den samme handling uden data og med meget data
• Sider, der deler komponenter med den, du rettede
• En skærm i telefonbredde, hvis rettelsen rørte layoutet

AI-ændringer retter nogle gange én vej og ødelægger stille en anden. Et to-minutters tjek nu sparer en forvirret time senere.

Trin 7: Rul tilbage i stedet for at stable oven på

Hvis en rettelse gjorde tingene værre, eller du er gået tre runder uden fremskridt, så gå tilbage. At rulle tilbage til den sidste version, der virkede, og omformulere med bedre beviser, slår næsten altid at bede om en fjerde rettelse oven på tre forkerte. Hvert mislykket forsøg efterlader kode, og den kode forvirrer næste forsøg.

Gode vaner, der gør tilbagerulning nem:

• Test efter hver ændring, så du ved, hvilken ændring der ødelagde noget.
• Hold ændringerne små — én funktion eller rettelse pr. besked.
• Notér den sidste gode version før du begynder noget risikabelt.
• Hvis koden ligger i Git, så commit fungerende versioner, så du kan vende tilbage til dem.

Almindelige fejlmønstre i AI-byggede apps

Når problemet ikke er en fejl

Nogle «fejl» er AI'en, der bygger præcis det, den fik besked på, og beskrivelsen var tvetydig. Hvis den rettelse du beder om egentlig er en ændring i adfærd, så sig det klart: «Ændr det, så at…». Hvis du opdager, at du ikke er sikker på, hvad den korrekte adfærd overhovedet er, så beslut det først. Vores guide om at skrive prompts til AI-app-builders dækker, hvordan du specificerer regler tydeligt. Og hvis du forbereder en app til rigtige brugere, dækker fra AI-prototype til produktion de tjek, der er værd at lave før lancering.

Debugging i Mythex

Mythex har værktøjer til hvert trin i loopet:

• Preview til at genskabe fejlen, inklusive en ramme i telefonstørrelse.
• /test får agenten til at klikke sig gennem din live-forhåndsvisning som en bruger og rapportere ødelagte flows.
• /fix peger agenten specifikt mod ødelæggelser.
• Plan-tilstand lader agenten undersøge og forklare, før den redigerer noget.
• Code → terminal viser din apps serverlogs.
• Revert to this point på et hvilket som helst svar ruller projektet tilbage til det checkpoint.

Hvis en publicering fejler, tilbyder publiceringsdialogen normalt Fix with AI, som læser build-outputtet eller appens logs. Se Debug your app og Publish troubleshooting i dokumentationen.

Spørgsmål