Cum depanezi o aplicație construită cu AI: o metodă practică

Ca să depanezi o aplicație construită cu AI, întâi provoacă din nou eroarea intenționat, apoi strânge dovezi — pașii exacți, mesajul de eroare și ce arată consola browserului și tabul de rețea — și dă-le AI-ului sub forma „am făcut X, mă așteptam la Y, am primit Z”. Dacă o reparație înrăutățește lucrurile, revino la ultima versiune funcțională în loc să adaugi reparații peste ea. Nu trebuie să citești codul ca să faci bine toate acestea.

Acest ghid acoperă întregul ciclu, inclusiv un tur rapid al uneltelor pentru dezvoltatori din browser, pentru persoanele fără cunoștințe tehnice.

Ciclul de depanare

Orice reparație de eroare, fie că o face o persoană sau un AI, urmează același ciclu:

1. Reproduce — fă eroarea să apară în mod previzibil.
2. Observă — strânge mesajul de eroare și ce făcea aplicația.
3. Descrie — dă AI-ului pași precisi, rezultatul așteptat și rezultatul real.
4. Repară — lasă AI-ul să schimbe un singur lucru.
5. Verifică — repetă exact pașii și confirmă că e reparat și că nimic din apropiere nu s-a stricat.
6. Revino dacă e nevoie — dacă a devenit mai rău, anulează și încearcă din nou cu informații mai bune.

Cea mai mare parte a timpului pierdut la aplicațiile construite cu AI vine din sărirea peste pașii 1, 2 și 5: spui „e stricat”, accepți o schimbare fără s-o testezi și apoi ceri o altă reparație peste una defectă.

Pasul 1: Reproduce eroarea

O eroare pe care o poți declanșa la cerere este pe jumătate reparată. Încearcă să găsești cel mai scurt set de pași care o provoacă.

Întreabă-te:

• Se întâmplă de fiecare dată? Dacă doar uneori, ce este diferit când apare — o anumită înregistrare, o conexiune lentă, faptul că ești deconectat?
• Se întâmplă pentru fiecare utilizator? Autentifică-te cu un alt cont. Multe erori apar doar pentru utilizatorii noi, fără date, sau pentru un utilizator cu alt rol.
• Se întâmplă pe fiecare dispozitiv? Încearcă un ecran de lățimea telefonului și un alt browser.
• A apărut după o modificare anume? Dacă funcționa ieri, ultimele modificări sunt principalii suspecți.

Notează pașii ca o listă scurtă, numerotată. O vei lipi în prompt mai târziu.

Pasul 2: Citește mesajul de eroare

Mesajele de eroare par intimidante, dar ai nevoie doar de câteva părți din ele.

Nu trebuie să-l înțelegi; trebuie să-l copiezi exact. „Cannot read properties of undefined (reading 'name')” îi spune AI-ului că prin cod se aștepta la niște date (probabil o rezervare sau un utilizator) care nu au ajuns. O parafrază de tipul „o eroare nedefinită” pierde asta.

Câteva erori frecvente, traduse aproximativ:

• Erori undefined / null — codul se aștepta la date care nu au sosit. Adesea o stare de încărcare sau o listă goală pe care codul nu o trata.
• 404 Not Found — pagina sau adresa API-ului nu există. Adesea o greșeală de scriere într-o rută sau un link spre o pagină redenumită.
• 401 Unauthorized / 403 Forbidden — cererea nu era autentificată sau utilizatorul nu are voie să facă asta.
• 500 Internal Server Error — codul de pe server s-a blocat. Motivul real este în jurnalele serverului, nu în browser.
• Erori CORS — browserul a blocat o cerere către un alt domeniu. De obicei o problemă de configurare pe server.

Pasul 3: Folosește uneltele pentru dezvoltatori din browser

Fiecare browser desktop are unelte integrate pentru dezvoltatori („devtools”). Ele arată ce face pagina în culise. În Chrome, Edge și Firefox, fă clic dreapta oriunde pe pagină și alege Inspect, sau apasă F12 (Cmd+Option+I pe Mac). În Safari, activează întâi meniul Develop din setările Safari.

Ai nevoie doar de trei taburi.

Console

Tabul Console listează erorile și mesajele din codul paginii. Erorile apar cu roșu. Dacă un buton nu face nimic când dai clic, consola arată foarte des o eroare roșie chiar în momentul clicului. Copiază textul complet al erorii (fă clic dreapta pe ea pentru opțiunea de copiere, în majoritatea browserelor).

Network

Tabul Network listează fiecare cerere pe care o face pagina — încărcarea datelor, salvarea unui formular, autentificarea. Deschide-l, apoi repetă pașii care provoacă eroarea.

• Caută rânduri roșii sau cu un status de 400 sau mai mare.
• Fă clic pe un rând care eșuează ca să vezi Response. O eroare de server include adesea acolo un mesaj mai util decât orice de pe ecran.
• Notează URL-ul cererii și codul de status — „POST către /api/bookings a întors 500” este o propoziție foarte utilă pentru AI.

Bifează Preserve log dacă eroarea implică o reîncărcare a paginii sau o redirecționare, ca cererile să nu dispară.

Elements

Tabul Elements (sau Inspector) arată structura și stilurile paginii. Este cel mai util pentru erorile de aspect: treci cu mouse-ul peste un element ca să vezi dimensiunea și spațiul evidențiate. Nu trebuie să editezi nimic aici; ajunge să spui „footer-ul are 2.000 de pixeli lățime pe mobil și împinge pagina lateral”.

Pasul 4: Verifică jurnalele serverului

Unele erori apar pe server, unde browserul nu le vede. O eroare 500 în tabul de rețea este semnul clasic. Jurnalele serverului — ieșirea text a backend-ului în timp ce rulează — conțin de obicei eroarea reală, cu o urmă de stivă (o listă a funcțiilor care rulau când a eșuat).

Unde le găsești depinde de unealta ta. În majoritatea constructoarelor de aplicații cu AI poți deschide un terminal sau o vedere a jurnalelor pentru proiect sau pur și simplu poți întreba AI-ul: „Verifică jurnalele serverului pentru erori de la ultima cerere și spune-mi ce a eșuat.”

Pasul 5: Descrie eroarea către AI

Pune ce ai strâns în această formă:

Pe pagina Rezervări, autentificat ca membru: am dat clic pe Cancel la clasa de mâine de la 9:00. Mă așteptam: rezervarea dispare și clasa arată un loc liber în plus. Real: nimic nu se schimbă pe ecran. Consola arată TypeError: Cannot read properties of undefined (reading 'id') la BookingCard.tsx:31, iar tabul de rețea arată că DELETE /api/bookings/123 a întors 500. Găsește cauza, repar-o și verifică dacă anularea funcționează pentru un membru cu o rezervare și pentru unul cu mai multe.

De ce contează fiecare parte:

• Unde și în ce calitate restrânge problema la un ecran și un rol.
• Pașii exacți îi permit AI-ului să reproducă eroarea.
• Așteptat vs real definește ce înseamnă „reparat”.
• Textul erorii și cererea care a eșuat indică direct spre cauză.
• „Verifică că…” cere AI-ului să verifice, nu doar să modifice.

Dacă AI-ul a încercat o reparație de două ori și a eșuat, cere-i să explice înainte să schimbe ceva:

Nu schimba codul încă. Ce crezi că provoacă asta și ce dovezi susțin părerea?

O teorie greșită se observă ușor când este scrisă, și este mult mai ieftin să o corectezi decât o reparație greșită.

Pasul 6: Verifică, apoi verifică zona din jur

Când AI-ul spune că este reparat, repetă pașii exacți din Pasul 1. Apoi verifică lucrurile din jur:

• Aceeași acțiune pentru un alt rol de utilizator
• Aceeași acțiune fără date și cu foarte multe date
• Paginile care împart componente cu cea pe care ai reparat-o
• Un ecran de lățimea telefonului, dacă reparația a atins aspectul

Modificările AI uneori repară o cale și strică în tăcere alta. O verificare de două minute acum economisește o oră confuză mai târziu.

Pasul 7: Revino în loc să adaugi peste

Dacă o reparație a făcut lucrurile mai rele, sau ai trecut prin trei runde fără progres, întoarce-te. Revenirea la ultima versiune funcțională și reformularea cu dovezi mai bune bate aproape mereu cererea unei a patra reparații peste trei greșite. Fiecare încercare eșuată lasă cod în urmă, iar acel cod încurcă următoarea încercare.

Obiceiuri bune care fac revenirea ușoară:

• Testează după fiecare modificare, ca să știi care schimbare a stricat lucrurile.
• Păstrează modificările mici — o funcție sau o reparație pe mesaj.
• Notează ultima versiune bună înainte să începi ceva riscant.
• Dacă codul este în Git, fă commit versiunilor funcționale ca să te poți întoarce la ele.

Tipare frecvente de erori la aplicațiile construite cu AI

Când problema nu este o eroare

Unele „erori” sunt AI-ul care construiește exact ce i s-a cerut, iar descrierea a fost ambiguă. Dacă reparația pe care o ceri este de fapt o schimbare de comportament, spune-o clar: „Schimbă-l astfel încât…”. Dacă nu ești sigur care este comportamentul corect, decide mai întâi asta. Ghidul nostru despre cum scrii prompturi pentru constructorii de aplicații cu AI acoperă cum specifici clar regulile. Iar dacă pregătești o aplicație pentru utilizatori reali, cum duci un prototip AI în producție acoperă verificările care merită făcute înainte de lansare.

Depanarea în Mythex

Mythex are unelte pentru fiecare pas al ciclului:

• Previzualizarea ca să reproduci eroarea, inclusiv un cadru de dimensiunea telefonului.
• /test face ca agentul să parcurgă previzualizarea live ca un utilizator și să raporteze fluxurile defecte.
• /fix îndreaptă agentul spre defectele concrete.
• Modul Plan îl lasă pe agent să investigheze și să explice înainte să modifice ceva.
• Code → terminal arată jurnalele serverului aplicației tale.
• Revert to this point pe orice răspuns readuce proiectul la acel checkpoint.

Dacă o publicare eșuează, dialogul de publicare oferă de obicei Fix with AI, care citește ieșirea build-ului sau jurnalele aplicației. Vezi Depanează-ți aplicația și Depanarea publicării în documentație.

Întrebări