Sådan skriver du en god fejlrapport (til AI eller en udvikler)

En god fejlrapport lader en anden — en udvikler eller en AI — se det samme problem, som du så, uden at skulle stille dig et eneste spørgsmål. Den har brug for en specifik titel, de præcise trin til at genskabe fejlen, hvad du forventede, hvad der faktisk skete, eventuelle fejlbeskeder kopieret ord for ord, og hvor det skete: hvilken side, browser, enhed og bruger. Én fejl pr. rapport, med et skærmbillede hvis det hjælper.

De fleste fejl tager længere tid at forstå end at rette. En klar rapport fjerner forståelsesdelen. Det betyder endnu mere med AI-værktøjer: en AI kan ikke stille et opfølgende spørgsmål om, hvad du mente med „checkout er underlig“, så den gætter — og et forkert gæt kan ødelægge noget andet.

Skabelonen

Kopiér og udfyld:

Titel: [Hvad der er galt, og hvor] — f.eks. „Bookingformularen afviser tidspunkter efter kl. 18“

Trin til at genskabe:
1. ...
2. ...
3. ...

Forventet: [hvad der burde ske]
Faktisk: [hvad der skete i stedet]

Fejlbesked: [præcis tekst, hvis der er en]
Hvor: [side/URL, browser, enhed, logget ind som hvilken bruger]
Hvor ofte: [hver gang / nogle gange / én gang]
Skærmbillede eller optagelse: [vedhæftet]

Resten af denne guide forklarer hver del.

Trin 1: Genskab den først

Før du skriver, så prøv at få fejlen til at ske igen. Du lærer, hvilke trin der betyder noget, og om den sker hver gang.

Start fra en ren tilstand: genindlæs, eller log ud og ind igen.
Notér hvert klik og alt, du skriver.
Prøv at finde den korteste vej, der udløser den.
Prøv en anden browser eller konto. Hvis det kun sker for én bruger, er det et stort hint.

For mere om dette, se sådan debugger du en app bygget med AI.

Trin 2: Skriv en specifik titel

Titlen bør sige, hvad der er galt og hvor, så nogen der scanner en liste kan se, hvilken fejl det er.

Svag	Stærk
Checkout er i stykker	Checkout-knappen gør ingenting, når kurven har en rabatkode
Mobilproblem	Priskortene går uden for skærmen på telefoner under 400 px bred
Fejl ved gem	Gemning af en profil med emoji i navnet viser „500 Internal Server Error“

Trin 3: List præcise trin

Nummerér dem. Vær bogstavelig: hvilken side, hvilken knap, hvad du skrev.

Log ind som kunde (testkonto: customer@example.com).
Læg „Starter kit“ i kurven.
Indtast rabatkoden WELCOME10 og klik på Anvend.
Klik på Checkout.

„Prøv at checke ud med en kode“ udelader de detaljer, der ofte betyder noget: hvilken bruger, hvilket produkt, hvilken kode, og om den blev anvendt først.

Trin 4: Forventet vs. faktisk

Det er kernen i rapporten. Skriv begge dele, for forskellen er fejlen.

Forventet: Checkout-siden åbnes med 10 % rabat vist i totalen.
Faktisk: Knappen viser en spinner i et sekund, og så sker der ingenting. Uden rabatkode virker checkout.

Uden „forventet“ ved læseren måske ikke, at adfærden er forkert. Uden „faktisk“ ved de ikke, hvad de skal kigge efter.

Trin 5: Kopiér fejl præcist

Fejlbeskeder er den hurtigste vej til årsagen. Kopiér dem som tekst, ord for ord — omskriv dem ikke.

Sådan finder du dem:

På skærmen: enhver besked appen viser.
Browserkonsollen: åbn udviklerværktøjer (F12, eller højreklik → Inspicér) og kig på fanen Console for røde linjer.
Netværksfanen: find den fejlende forespørgsel i udviklerværktøjerne og notér dens URL og statuskode (for eksempel POST /api/checkout → 500).
Serverlogs, hvis du har adgang.

En linje som TypeError: Cannot read properties of undefined (reading 'percent') at checkout.ts:48 peger ofte direkte på problemet.

Trin 6: Tilføj kontekst

Hvor: sidens URL, miljøet (forhåndsvisning, staging eller live).
Hvem: hvilken bruger eller rolle — admin, medlem, ikke logget ind.
Enhed og browser: „Safari på iPhone“ vs. „Chrome på Windows“ kan betyde noget.
Data: alt usædvanligt ved posten — meget lang tekst, specialtegn, et stort antal elementer.
Hvornår det startede: „efter gårsdagens ændring af rabatkoder“ er guld værd.
Hvor ofte: hver gang, eller én gang ud af ti forsøg.

Trin 7: Vis det

Et skærmbillede med problemet markeret, eller en kort skærmoptagelse, fjerner tvetydighed — især ved layoutfejl. Hvis dit AI-værktøj accepterer billeder, så vedhæft et. Beskær alt privat væk, inklusive nøgler og andres data.

Skriv fejlrapporter til et AI-byggeværktøj

Den samme struktur virker som en prompt. To tilføjelser hjælper:

Sig hvad der ikke må ændre sig, så rettelsen ikke skaber et nyt problem.
Bed den verificere rettelsen, ikke bare skrive den.

Logget ind som kunde, med „Starter kit“ i kurven og koden WELCOME10 anvendt, gør et klik på Checkout ingenting. Forventet: checkout-siden åbnes med 10 % rabat på totalen. Faktisk: en kort spinner, og så ingenting. Netværksfanen viser at POST /api/checkout returnerede 500. Checkout uden kode virker. Find årsagen og ret den uden at ændre, hvordan priser beregnes for ordrer uden kode. Tjek derefter checkout med en procentkode, en kode med fast beløb og uden kode.

Hvis du er usikker på årsagen, så bed om en diagnose først:

Ændr ikke kode endnu. Hvad er ud fra denne rapport de sandsynlige årsager, og hvad ville bekræfte hver af dem?

Almindelige fejl

„Det er i stykker.“ Ingen trin, intet forventet resultat, intet at handle på.
Flere fejl i én rapport. Nogle bliver rettet, andre går tabt.
Omskrevne fejlbeskeder. „En eller anden undefined-ting“ skjuler den nyttige del.
Manglende bruger eller rolle. Mange fejl rammer kun admins eller kun nye brugere.
Kun at beskrive den rettelse du ønsker („tilføj en null-kontrol“) i stedet for problemet.
At dele hemmeligheder i skærmbilleder eller indsatte logs.

Tjekliste

Jeg genskabte fejlen og fandt de korteste trin.
Titlen siger hvad der er galt og hvor.
Trin er nummererede og bogstavelige.
Både forventet og faktisk er angivet.
Fejlbeskeder er kopieret præcist, med eventuel fejlende forespørgsel og statuskode.
Side, miljø, bruger, enhed og browser er med.
Jeg har skrevet hvor ofte det sker, og hvornår det startede.
Et skærmbillede eller en optagelse er vedhæftet, med privat data fjernet.
Én fejl pr. rapport.

Rapportering af fejl til Mythex' agent

I et Mythex-projekt er rapporten selve prompten. Nogle funktioner hjælper:

Vedhæft et skærmbillede af forhåndsvisningen eller fejlskærmen — op til 5 filer pr. besked.
/fix fokuserer agenten på at rette en fejl, og Plan-tilstanden lader den undersøge, før den redigerer.
/test får agenten til at genskabe flows i selve forhåndsvisningen og rapportere, hvad den ser.
Gå tilbage til dette punkt fortryder en rettelse, der gjorde tingene værre.

Docs-siden debugging med prompts bruger samme trin, forventet og faktisk-struktur. For fix-og-kontrol-løkken omkring den, se sådan itererer du på en app bygget med AI.

Spørgsmål

Hvad skal en fejlrapport indeholde?

En specifik titel, de præcise trin til at genskabe problemet, hvad du forventede, hvad der faktisk skete, eventuelle fejlbeskeder ord for ord, hvor det skete (side, browser, enhed, bruger), og et skærmbillede eller en optagelse, hvis det hjælper.

Hvordan skriver jeg en fejlrapport til en AI-appbygger?

Brug samme struktur som til en udvikler: trin, forventet, faktisk og den præcise fejl. Tilføj hvad der ikke må ændre sig, og bed den om at rette og derefter verificere rettelsen. Vage prompts som „det er i stykker“ fører til gæt.

Hvad hvis jeg ikke kan genskabe fejlen?

Rapportér den alligevel, men sig det. Inkludér hvad du lavede, tidspunktet, brugerkontoen og eventuelle fejl du så. Notér hvor ofte det sker, for eksempel en gang ud af ti forsøg, da sporadiske fejl ofte peger på timing eller datamæssige problemer.

Skal jeg samle flere fejl i én rapport?

Nej. Én fejl pr. rapport, så hver kan rettes, testes og lukkes for sig selv. Hvis du tror, to problemer hænger sammen, så sig det i hver rapport.