Slik skriver du en god feilrapport (for KI eller en utvikler)

En god feilrapport gjør at noen andre, en utvikler eller en KI, ser det samme problemet som du så, uten å måtte stille deg noen spørsmål. Den trenger en spesifikk tittel, de nøyaktige stegene for å reprodusere feilen, hva du forventet, hva som faktisk skjedde, eventuelle feilmeldinger kopiert ordrett, og hvor det skjedde: hvilken side, nettleser, enhet og bruker. Én feil per rapport, med et skjermbilde hvis det hjelper.

De fleste feil tar lenger tid å forstå enn å fikse. En klar rapport fjerner forståelsesdelen. Dette betyr enda mer med KI-verktøy: en KI kan ikke stille en oppfølgingsspørsmål om hva du mente med «utsjekken er rar», så den gjetter, og en feil gjetning kan ødelegge noe annet.

Malen

Kopier denne og fyll den ut:

Tittel: [Hva er galt, og hvor] – f.eks. «Bookingskjemaet avviser tidspunkter etter kl. 18»

Steg for å reprodusere:
1. ...
2. ...
3. ...

Forventet: [hva som skulle skjedd]
Faktisk: [hva som skjedde i stedet]

Feilmelding: [nøyaktig tekst, hvis noen]
Hvor: [side/URL, nettleser, enhet, innlogget som hvilken bruker]
Hvor ofte: [hver gang / noen ganger / én gang]
Skjermbilde eller opptak: [vedlagt]

Resten av denne guiden forklarer hver del.

Steg 1: Reproduser den først

Før du skriver, prøv å få feilen til å skje igjen. Da lærer du hvilke steg som betyr noe, og om den skjer hver gang.

Start fra en ren tilstand: last inn siden på nytt, eller logg ut og inn igjen.
Noter hvert klikk og alt du skriver.
Prøv å finne den korteste veien som utløser feilen.
Prøv en annen nettleser eller konto. Hvis det bare skjer for én bruker, er det et stort hint.

For mer om dette, se slik feilsøker du en KI-bygget app.

Steg 2: Skriv en spesifikk tittel

Tittelen bør si hva som er galt og hvor, slik at noen som skanner en liste vet hvilken feil det er.

Svak	Sterk
Utsjekken er ødelagt	Kjøp-knappen gjør ingenting når handlekurven har en rabattkode
Mobilproblem	Prisekortene går utenfor skjermen på telefoner under 400 px bredde
Feil ved lagring	Lagring av en profil med emoji i navnet viser «500 Internal Server Error»

Steg 3: List de nøyaktige stegene

Nummerer dem. Vær bokstavelig: hvilken side, hvilken knapp, hva du skrev.

Logg inn som kunde (testkonto: customer@example.com).
Legg «Startpakke» i handlekurven.
Skriv rabattkoden WELCOME10 og klikk Bruk.
Klikk Til kassen.

«Prøv å sjekke ut med en kode» utelater detaljene som ofte betyr noe: hvilken bruker, hvilket produkt, hvilken kode, og om den ble brukt først.

Steg 4: Forventet mot faktisk

Dette er kjernen i rapporten. Skriv begge, fordi forskjellen er feilen.

Forventet: Kassesiden åpnes med 10 % rabatt vist i totalen.
Faktisk: Knappen viser et lasteikon i et sekund, og så skjer ingenting. Uten rabattkode fungerer kassen.

Uten «forventet» vet ikke leseren kanskje at oppførselen er feil. Uten «faktisk» vet de ikke hva de skal lete etter.

Steg 5: Kopier feilmeldinger nøyaktig

Feilmeldinger er den raskeste veien til årsaken. Kopier dem som tekst, ord for ord, og parafraser ikke.

Slik finner du dem:

På skjermen: en melding appen viser.
Nettleserkonsollen: åpne utviklerverktøyene (F12, eller høyreklikk → Inspiser) og se på Konsoll-fanen for røde linjer.
Nettverksfanen: i utviklerverktøyene finner du den mislykkede forespørselen og noterer URL og statuskode (for eksempel POST /api/checkout → 500).
Serverlogger, hvis du har tilgang.

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

Steg 6: Legg til kontekst

Hvor: side-URL-en, miljøet (forhåndsvisning, staging eller produksjon).
Hvem: hvilken bruker eller rolle: admin, medlem, utlogget.
Enhet og nettleser: «Safari på iPhone» mot «Chrome på Windows» kan være viktig.
Data: alt uvanlig med posten: veldig lang tekst, spesialtegn, et stort antall elementer.
Når det startet: «etter gårsdagens endring av rabattkoder» er gull verdt.
Hvor ofte: hver gang, eller én gang av ti forsøk.

Steg 7: Vis det

Et skjermbilde med problemet markert, eller en kort skjermopptak, fjerner tvetydighet, særlig for layoutfeil. Hvis KI-verktøyet ditt tar imot bilder, legg ved ett. Klipp bort alt privat, inkludert nøkler og andres data.

Å skrive feilrapporter til en KI-byggeren

Samme struktur fungerer som et prompt. To tillegg hjelper:

Si hva som ikke må endres, slik at rettelsen ikke skaper et nytt problem.
Be den verifisere rettelsen, ikke bare skrive den.

Innlogget som kunde, med «Startpakke» i handlekurven og koden WELCOME10 brukt, gjør et klikk på Til kassen ingenting. Forventet: kassesiden åpnes med 10 % av totalen. Faktisk: et kort lasteikon, og så ingenting. Nettverksfanen viser at POST /api/checkout returnerte 500. Kasse uten kode fungerer. Finn årsaken og fiks den uten å endre hvordan priser beregnes for ordrer uten kode. Sjekk deretter kassen med en prosentrabattkode, en kode med fast beløp og uten kode.

Hvis du er usikker på årsaken, be om en diagnose først:

Ikke endre kode ennå. Hva er basert på denne rapporten de sannsynlige årsakene, og hva ville bekreftet hver av dem?

Vanlige feil

«Det er ødelagt.» Ingen steg, ingen forventet resultat, ingenting å handle på.
Flere feil i én rapport. Noen blir rettet, andre går tapt.
Parafraserte feilmeldinger. «Noe udefinert» skjuler den nyttige delen.
Å glemme bruker eller rolle. Mange feil rammer bare admin, eller bare nye brukere.
Å bare beskrive rettelsen du vil ha («legg til en null-sjekk») i stedet for problemet.
Å dele hemmeligheter i skjermbilder eller innlimte logger.

Sjekkliste

Jeg reproduserte feilen og fant de korteste stegene.
Tittelen sier hva som er galt og hvor.
Stegene er nummerert og bokstavelige.
Både forventet og faktisk er oppgitt.
Feilmeldinger er kopiert nøyaktig, med eventuell mislykket forespørsel og statuskode.
Side, miljø, bruker, enhet og nettleser er med.
Jeg har oppgitt hvor ofte det skjer og når det startet.
Et skjermbilde eller en opptak er vedlagt, med private data fjernet.
Én feil per rapport.

Rapportere feil til Mythex-agenten

I et Mythex-prosjekt er rapporten selve promptet. Noen funksjoner hjelper:

Legg ved et skjermbilde av forhåndsvisningen eller feilskjermen. Opptil 5 filer per melding.
/fix fokuserer agenten på å fikse en feil, og Plan-modus lar den undersøke før den endrer noe.
/test får agenten til å reprodusere flytene i selve forhåndsvisningen og rapportere hva den ser.
Gå tilbake til dette punktet angrer en rettelse som gjorde ting verre.

Dokumentasjonens side om feilsøking med prompter bruker samme steg, forventet og faktisk-struktur. For løkken med retting og kontroll rundt den, se slik itererer du på en KI-bygget app.

Spørsmål

Hva bør en feilrapport inneholde?

En spesifikk tittel, de nøyaktige stegene for å reprodusere problemet, hva du forventet, hva som faktisk skjedde, eventuelle feilmeldinger ordrett, hvor det skjedde (side, nettleser, enhet, bruker), og et skjermbilde eller en opptak hvis det hjelper.

Hvordan skriver jeg en feilrapport til en KI-appbygger?

Bruk samme struktur som for en utvikler: steg, forventet, faktisk og den nøyaktige feilmeldingen. Legg til hva som ikke må endres, og be KI-en både rette og verifisere rettelsen. Vage prompter som «det er ødelagt» fører til gjetting.

Hva hvis jeg ikke klarer å reprodusere feilen?

Rapporter den likevel, men si fra om at du ikke får den til å skje igjen. Ta med hva du holdt på med, tidspunktet, brukerkontoen og eventuelle feil du så. Noter hvor ofte det skjer, for eksempel én gang av ti forsøk, siden sporadiske feil ofte peker mot timing- eller datakonflikter.

Bør jeg ta flere feil i samme rapport?

Nei. Én feil per rapport, slik at hver kan rettes, testes og lukkes for seg. Hvis du tror to problemer henger sammen, si det i begge rapportene.