Cum scrii un raport de eroare bun (pentru AI sau un dezvoltator)

Un raport de eroare bun îi permite altcuiva — un dezvoltator sau un AI — să vadă aceeași problemă pe care ai văzut-o tu, fără să te întrebe nimic. Are nevoie de un titlu specific, pașii exacți pentru a o reproduce, ce ai așteptat, ce s-a întâmplat de fapt, orice mesaj de eroare copiat cuvânt cu cuvânt și locul unde a apărut: ce pagină, ce browser, ce dispozitiv și ce utilizator. O eroare pe raport, cu o captură de ecran dacă ajută.

Majoritatea erorilor necesită mai mult timp ca să fie înțelese decât ca să fie reparate. Un raport clar elimină partea de înțelegere. Asta contează și mai mult cu instrumentele AI: un AI nu-ți poate pune o întrebare de clarificare despre ce ai vrut să spui prin „checkout-ul e ciudat”, așa că ghicește — iar o presupunere greșită poate strica altceva.

Șablonul

Copiază-l și completează-l:

Titlu: [Ce nu merge, unde] — de ex. „Formularul de rezervare respinge orele după 18:00”

Pași pentru reproducere:
1. ...
2. ...
3. ...

Așteptat: [ce ar trebui să se întâmple]
Real: [ce s-a întâmplat în schimb]

Mesaj de eroare: [textul exact, dacă există]
Unde: [pagina/URL-ul, browserul, dispozitivul, conectat ca ce utilizator]
Cât de des: [de fiecare dată / uneori / o dată]
Captură de ecran sau înregistrare: [atașată]

Restul acestui ghid explică fiecare parte.

Pasul 1: Reproduce-o mai întâi

Înainte să scrii, încearcă să faci eroarea să apară din nou. Vei afla ce pași contează și dacă apare de fiecare dată.

Pornește dintr-o stare curată: reîmprospătează pagina sau ieși și intră din nou în cont.
Notează fiecare clic și fiecare lucru pe care îl scrii.
Caută cea mai scurtă cale care declanșează eroarea.
Încearcă un al doilea browser sau un alt cont. Dacă apare doar pentru un utilizator, este un indiciu important.

Pentru mai multe despre asta, vezi cum depanezi o aplicație făcută cu AI.

Pasul 2: Scrie un titlu specific

Titlul trebuie să spună ce nu merge și unde, ca cineva care parcurge o listă să știe despre ce eroare e vorba.

Slab	Puternic
Checkout-ul e stricat	Butonul de checkout nu face nimic când coșul are un cod de reducere
Problemă pe mobil	Cardurile de prețuri ies din ecran pe telefoane sub 400px lățime
Eroare la salvare	Salvarea unui profil cu un emoji în nume afișează „500 Internal Server Error”

Pasul 3: Listează pașii exacți

Numerotează-i. Fii literal: ce pagină, ce buton, ce ai scris.

Autentifică-te ca un client (cont de test: customer@example.com).
Adaugă „Kitul de start” în coș.
Introdu codul de reducere WELCOME10 și apasă Aplică.
Apasă Checkout.

„Încearcă să plătești cu un cod” omite detaliile care adesea contează: ce utilizator, ce produs, ce cod, dacă a fost aplicat întâi.

Pasul 4: Așteptat vs real

Aceasta este partea centrală a raportului. Spune amândouă, pentru că diferența este eroarea.

Așteptat: pagina de checkout se deschide cu reducerea de 10% arătată în total.
Real: butonul afișează o rotiță de încărcare o secundă, apoi nu se întâmplă nimic. Fără cod de reducere, checkout-ul funcționează.

Fără „așteptat”, cel care citește s-ar putea să nu știe că un comportament este greșit. Fără „real”, nu știe ce să caute.

Pasul 5: Copiază erorile exact

Mesajele de eroare sunt cea mai rapidă cale către cauză. Copiază-le ca text, cuvânt cu cuvânt — nu le parafraza.

Unde le găsești:

Pe ecran: orice mesaj afișat de aplicație.
Consola browserului: deschide instrumentele pentru dezvoltatori (F12, sau clic dreapta → Inspectează) și uită-te la tabul Console pentru linii roșii.
Tabul Network: în instrumentele pentru dezvoltatori, găsește cererea care eșuează și notează URL-ul și codul de stare (de exemplu POST /api/checkout → 500).
Jurnalele serverului, dacă ai acces la ele.

O linie precum TypeError: Cannot read properties of undefined (reading 'percent') at checkout.ts:48 indică adesea direct problema.

Pasul 6: Adaugă context

Unde: URL-ul paginii, mediul (previzualizare, staging sau live).
Cine: ce utilizator sau rol — admin, membru, neautentificat.
Dispozitiv și browser: „Safari pe iPhone” vs „Chrome pe Windows” pot conta.
Date: orice e neobișnuit la înregistrare — text foarte lung, caractere speciale, un număr mare de elemente.
Când a început: „după schimbarea de ieri a codurilor de reducere” este aur.
Cât de des: de fiecare dată sau o dată din zece încercări.

Pasul 7: Arată-o

O captură de ecran cu problema încercuită sau o scurtă înregistrare de ecran elimină ambiguitatea — mai ales pentru erorile de aspect. Dacă instrumentul tău AI acceptă imagini, atașează una. Taie din captură tot ce e privat, inclusiv chei și datele altor persoane.

Scrierea rapoartelor de eroare pentru un builder AI

Aceeași structură funcționează ca prompt. Două adăugiri ajută:

Spune ce nu trebuie să se schimbe, ca reparația să nu creeze o problemă nouă.
Cere-i să verifice reparația, nu doar să o scrie.

Autentificat ca client, cu „Kitul de start” în coș și codul WELCOME10 aplicat, apăsarea pe Checkout nu face nimic. Așteptat: pagina de checkout se deschide cu 10% reducere din total. Real: o rotiță scurtă, apoi nimic. Tabul network arată că POST /api/checkout a returnat 500. Checkout-ul fără cod funcționează. Găsește cauza și repar-o fără să schimbi felul în care se calculează prețurile pentru comenzile fără cod. Apoi verifică checkout-ul cu un cod procentual, cu un cod de sumă fixă și fără cod.

Dacă nu ești sigur de cauză, cere mai întâi un diagnostic:

Nu schimba încă nimic în cod. Pe baza acestui raport, care sunt cauzele probabile și ce ar confirma fiecare dintre ele?

Greșeli frecvente

„E stricat.” Fără pași, fără rezultat așteptat, nimic de care să te poți apuca.
Mai multe erori într-un singur raport. Unele se repară, altele se pierd.
Erori parafrazate. „Un lucru undefined” ascunde partea utilă.
Lipsa utilizatorului sau a rolului. Multe erori apar doar pentru admini sau doar pentru utilizatorii noi.
Descrierea doar a reparației dorite („adaugă o verificare null”) în loc de problemă.
Partajarea de secrete în capturi de ecran sau în jurnale lipite.

Listă de verificare

Am reprodus eroarea și am găsit cei mai scurți pași.
Titlul spune ce nu merge și unde.
Pașii sunt numerotați și literali.
Sunt scrise atât rezultatul așteptat, cât și cel real.
Mesajele de eroare sunt copiate exact, cu cererea care eșuează și codul de stare.
Sunt incluse pagina, mediul, utilizatorul, dispozitivul și browserul.
Am spus cât de des apare și când a început.
O captură de ecran sau o înregistrare este atașată, cu datele private eliminate.
Un singur bug pe raport.

Raportarea erorilor către agentul Mythex

Într-un proiect Mythex, raportul este promptul. Câteva funcții ajută:

Atașează o captură de ecran a previzualizării sau a ecranului de eroare — până la 5 fișiere per mesaj.
/fix concentrează agentul pe repararea unei erori; modul Plan îi permite să investigheze înainte să modifice.
/test îi cere agentului să reproducă fluxurile direct în previzualizare și să raporteze ce vede.
Revino la acest punct anulează o reparație care a înrăutățit lucrurile.

Pagina depanarea cu prompturi din documentație folosește aceeași structură pași / așteptat / real. Pentru bucla de reparare și verificare din jurul ei, vezi cum iterezi o aplicație făcută cu AI.

Întrebări

Ce ar trebui să includă un raport de eroare?

Un titlu specific, pașii exacți pentru reproducerea problemei, ce ai așteptat, ce s-a întâmplat de fapt, orice mesaj de eroare copiat cuvânt cu cuvânt, unde a apărut (pagina, browserul, dispozitivul, utilizatorul) și o captură de ecran sau o înregistrare, dacă ajută.

Cum scriu un raport de eroare pentru un builder de aplicații cu AI?

Folosește aceeași structură ca pentru un dezvoltator: pași, rezultat așteptat, rezultat real și eroarea exactă. Adaugă ce nu trebuie să se schimbe și cere-i să repare și apoi să verifice reparația. Prompturile vagi, de tipul „e stricat”, duc la ghicit.

Ce fac dacă nu pot reproduce eroarea?

Raportează-o oricum, dar spune că nu ai reușit să o reproduci. Include ce făceai, ora la care s-a întâmplat, contul utilizatorului și orice eroare ai văzut. Notează cât de des apare, de exemplu o dată din zece încercări, pentru că erorile intermitente indică adesea probleme de timp sau de date.

Ar trebui să pun mai multe erori într-un singur raport?

Nu. O eroare pe raport, ca fiecare să poată fi reparată, testată și închisă separat. Dacă crezi că două probleme sunt legate, spune asta în fiecare raport.