Så skriver du en bra buggrapport (för AI eller en utvecklare)

En bra buggrapport gör att någon annan, en utvecklare eller en AI, kan se samma problem som du såg, utan att behöva ställa några frågor till dig. Den behöver en specifik titel, de exakta stegen för att återskapa det, vad du förväntade dig, vad som faktiskt hände, eventuella felmeddelanden kopierade ordagrant och var det hände: vilken sida, webbläsare, enhet och användare. En bugg per rapport, med en skärmbild om det hjälper.

De flesta buggar tar längre tid att förstå än att fixa. En tydlig rapport tar bort förståelsedelen. Det är ännu viktigare med AI-verktyg: en AI kan inte ställa en uppföljningsfråga om vad du menade med "utcheckningen är konstig", så den gissar, och en fel gissning kan förstöra något annat.

Mallen

Kopiera och fyll i:

Titel: [Vad som är fel, var]. T.ex. "Bokningsformuläret avvisar tider efter kl. 18"

Steg för att återskapa:
1. ...
2. ...
3. ...

Förväntat: [vad som borde hända]
Faktiskt: [vad som hände i stället]

Felmeddelande: [exakt text, om något]
Var: [sida/URL, webbläsare, enhet, inloggad som vilken användare]
Hur ofta: [varje gång / ibland / en gång]
Skärmbild eller inspelning: [bifogad]

Resten av den här guiden förklarar varje del.

Steg 1: Återskapa den först

Innan du skriver, försök få buggen att hända igen. Då lär du dig vilka steg som spelar roll, och om det händer varje gång.

Börja från ett rent läge: uppdatera sidan, eller logga ut och in igen.
Notera varje klick och allt du skriver.
Försök hitta den kortaste vägen som utlöser den.
Prova en andra webbläsare eller ett annat konto. Om det bara händer för en användare är det en stor ledtråd.

För mer om detta, se hur du felsöker en AI-byggd app.

Steg 2: Skriv en specifik titel

Titeln ska säga vad som är fel och var, så att någon som skummar en lista förstår vilken bugg det är.

Svag	Stark
Utcheckningen trasig	Köpknappen gör ingenting när varukorgen har en rabattkod
Mobilproblem	Prissättningskorten går utanför skärmen på telefoner under 400 px bredd
Fel vid sparning	Att spara en profil med en emoji i namnet visar "500 Internal Server Error"

Steg 3: Lista de exakta stegen

Numrera dem. Var bokstavlig: vilken sida, vilken knapp, vad du skrev.

Logga in som kund (testkonto: customer@example.com).
Lägg "Starter kit" i varukorgen.
Skriv rabattkoden WELCOME10 och klicka på Apply.
Klicka på Checkout.

"Prova att checka ut med en kod" utelämnar detaljer som ofta spelar roll: vilken användare, vilken produkt, vilken kod och om den tillämpades först.

Steg 4: Förväntat kontra faktiskt

Detta är kärnan i rapporten. Ange båda, eftersom skillnaden är buggen.

Förväntat: utcheckningssidan öppnas med 10 % rabatt synlig i totalen.
Faktiskt: knappen visar en snurrande indikator en sekund, och sedan händer ingenting. Utan rabattkod fungerar utcheckningen.

Utan "förväntat" kanske läsaren inte vet att beteendet är fel. Utan "faktiskt" vet de inte vad de ska leta efter.

Steg 5: Kopiera fel exakt

Felmeddelanden är den snabbaste vägen till orsaken. Kopiera dem som text, ordagrant. Parafrasera inte.

Så hittar du dem:

På skärmen: alla meddelanden appen visar.
Webbläsarens konsol: öppna utvecklarverktygen (F12, eller högerklicka → Inspektera) och titta på fliken Console efter röda rader.
Nätverksfliken: i utvecklarverktygen, hitta den misslyckade förfrågan och notera dess URL och statuskod (till exempel POST /api/checkout → 500).
Serverloggar, om du har åtkomst.

En rad som TypeError: Cannot read properties of undefined (reading 'percent') at checkout.ts:48 pekar ofta direkt på problemet.

Steg 6: Lägg till sammanhang

Var: sidans URL, miljön (förhandsvisning, staging eller live).
Vem: vilken användare eller roll: admin, medlem, utloggad.
Enhet och webbläsare: "Safari på iPhone" kontra "Chrome på Windows" kan spela roll.
Data: allt ovanligt i posten: mycket lång text, specialtecken, ett stort antal objekt.
När det började: "efter gårdagens ändring av rabattkoder" är guld värt.
Hur ofta: varje gång, eller en gång av tio försök.

Steg 7: Visa det

En skärmbild med problemet markerat, eller en kort skärminspelning, tar bort tvetydighet, särskilt för layoutbuggar. Om ditt AI-verktyg tar emot bilder, bifoga en. Beskär bort allt privat, inklusive nycklar och andra personers data.

Skriva buggrapporter till en AI-byggare

Samma struktur fungerar som en prompt. Två tillägg hjälper:

Säg vad som inte får ändras, så att fixen inte orsakar ett nytt problem.
Be den verifiera fixen, inte bara skriva den.

Inloggad som kund, med "Starter kit" i varukorgen och koden WELCOME10 tillämpad, gör ett klick på Checkout ingenting. Förväntat: utcheckningssidan öppnas med 10 % rabatt på totalen. Faktiskt: en kort snurrande indikator, sedan ingenting. Nätverksfliken visar att POST /api/checkout returnerade 500. Utcheckning utan kod fungerar. Hitta orsaken och åtgärda den utan att ändra hur priser beräknas för beställningar utan kod. Kontrollera sedan utcheckningen med en procentkod, en kod med fast belopp och utan kod.

Om du är osäker på orsaken, be om en diagnos först:

Ändra ingen kod ännu. Vilka är de troliga orsakerna utifrån den här rapporten, och vad skulle bekräfta var och en?

Vanliga misstag

"Det är trasigt." Inga steg, inget förväntat resultat, inget att agera på.
Flera buggar i en rapport. Vissa fixas, andra försvinner.
Parafraserade fel. "Någon odefinierad sak" döljer den användbara delen.
Att utelämna användaren eller rollen. Många buggar drabbar bara admin, eller bara nya användare.
Att bara beskriva den fix du vill ha ("lägg till en null-kontroll") i stället för problemet.
Att dela hemligheter i skärmbilder eller inklistrade loggar.

Checklista

Jag återskapade buggen och hittade de kortaste stegen.
Titeln säger vad som är fel och var.
Stegen är numrerade och bokstavliga.
Både förväntat och faktiskt är angivna.
Felmeddelanden är kopierade exakt, med eventuell misslyckad förfrågan och statuskod.
Sida, miljö, användare, enhet och webbläsare är med.
Jag har angett hur ofta det händer och när det började.
En skärmbild eller inspelning är bifogad, med privata data borttagen.
En bugg per rapport.

Rapportera buggar till Mythex-agenten

I ett Mythex-projekt är rapporten prompten. Några funktioner hjälper:

Bifoga en skärmbild av förhandsvisningen eller felskärmen, upp till 5 filer per meddelande.
/fix fokuserar agenten på att fixa en bugg; Plan-läget låter den undersöka innan den redigerar.
/test låter agenten återskapa flöden i förhandsvisningen och rapportera vad den ser.
Återgå till den här punkten ångrar en fix som gjorde saker sämre.

Dokumentationens sida felsökning med prompter använder samma steg, förväntat och faktiskt-struktur. För loopen med att fixa och kontrollera runt det, se hur du itererar på en AI-byggd app.

Frågor

Vad ska en buggrapport innehålla?

En specifik titel, de exakta stegen för att återskapa problemet, vad du förväntade dig, vad som faktiskt hände, eventuella felmeddelanden ordagrant, var det hände (sida, webbläsare, enhet, användare) och en skärmbild eller inspelning om det hjälper.

Hur skriver jag en buggrapport till en AI-appbyggare?

Använd samma struktur som för en utvecklare: steg, förväntat, faktiskt och det exakta felet. Lägg till vad som inte får ändras, och be den att fixa och sedan verifiera fixen. Vaga prompter som 'det är trasigt' leder till gissningar.

Vad gör jag om jag inte kan återskapa buggen?

Rapportera den ändå, men säg det. Ta med vad du gjorde, tidpunkten, användarkontot och eventuellt fel du såg. Notera hur ofta det händer, till exempel en gång av tio försök, eftersom sporadiska buggar ofta pekar på tidsproblem eller datafel.

Ska jag lägga flera buggar i en och samma rapport?

Nej. En bugg per rapport, så att var och en kan fixas, testas och stängas för sig. Om du tror att två problem hänger ihop, skriv det i båda rapporterna.