Si të korrigoni një aplikacion të ndërtuar me AI: një metodë praktike

Për të korrigoni një aplikacion të ndërtuar me AI, së pari bëjeni gabimin të ndodhë përsëri me qëllim, pastaj mblidhni provat — hapat e saktë, mesazhin e gabimit, dhe çfarë tregojnë konsola e shfletuesit dhe skeda e rrjetit — dhe jepini AI-së si „bëra X, prisja Y, mora Z". Nëse një rregullim e përkeqëson gjërat, kthehuni te versioni i fundit që funksionoi, në vend që të grumbulloni rregullime mbi rregullime. Nuk ju duhet të lexoni kodin për ta bërë mirë gjithë këtë.

Ky udhëzues mbulon gjithë ciklin, përfshirë një shikim të shpejtë te veglat e zhvilluesit të shfletuesit për njerëzit që nuk janë zhvillues.

Cikli i korrigjimit

Çdo rregullim gabimi, qoftë nga një person apo nga AI, ndjek të njëjtin cikël:

1. Riprodhoni — bëjeni gabimin të ndodhë me besueshmëri.
2. Vëzhgoni — mblidhni mesazhin e gabimit dhe çfarë po bënte aplikacioni.
3. Përshkruani — jepini AI-së hapa të saktë, rezultatin e pritur dhe rezultatin aktual.
4. Rregulloni — lëreni AI-në të ndryshojë një gjë.
5. Verifikoni — përsëriteni hapat e saktë dhe konfirmoni që është rregulluar, dhe që asgjë pranë nuk u prish.
6. Ktheni mbrapsht nëse nevojitet — nëse u përkeqësua, zhbëjeni dhe provoni përsëri me informacion më të mirë.

Shumica e kohës së humbur te aplikacionet e ndërtuara me AI vjen nga kalimi i hapave 1, 2 dhe 5: thënia „është i prishur", pranimi i një ndryshimi pa e testuar, dhe më pas kërkimi i një rregullimi tjetër mbi një gabim.

Hapi 1: Riprodhoni gabimin

Një gabim që mund ta shkaktoni sipas dëshirës është gjysma e rregulluar. Përpiquni të gjeni grupin më të shkurtër të hapave që e shkakton.

Pyetuni vetes:

• A ndodh çdo herë? Nëse ndodh vetëm ndonjëherë, çfarë është ndryshe kur ndodh — një regjistrim i caktuar, një lidhje e ngadaltë, të qenit i shkyçur?
• A ndodh për çdo përdorues? Hyni me një llogari tjetër. Shumë gabime shfaqen vetëm për përdorues të rinj pa të dhëna, ose për një përdorues me rol tjetër.
• A ndodh në çdo pajisje? Provoni një ekran me gjerësinë e telefonit dhe një shfletues tjetër.
• A filloi pas një ndryshimi të caktuar? Nëse funksiononte dje, ndryshimet e fundit janë të dyshuarit kryesorë.

Shkruajini hapat si një listë të shkurtër të numëruar. Do t'i ngjitni më vonë te kërkesa.

Hapi 2: Lexoni mesazhin e gabimit

Mesazhet e gabimit duken të frikshme, por ju duhen vetëm disa pjesë të tyre.

Nuk ju duhet ta kuptoni; duhet ta kopjoni saktësisht. „Cannot read properties of undefined (reading 'name')" i tregon AI-së se kodi priste disa të dhëna (ndoshta një rezervim ose një përdorues) që nuk ishin aty. Një parafrazim si „një gabim undefined" e humb atë informacion.

Disa të zakonshme, të përkthyera përafërsisht:

• Gabime undefined / null — kodi priste të dhëna që nuk arritën. Shpesh një gjendje ngarkimi ose një listë bosh që kodi nuk e trajtoi.
• 404 Not Found — faqja ose adresa e API-t nuk ekziston. Shpesh një gabim shkrimi në një rrugë ose një lidhje me një faqe që u riemërua.
• 401 Unauthorized / 403 Forbidden — kërkesa nuk ishte e kyçur, ose përdoruesi nuk lejohet ta bëjë atë veprim.
• 500 Internal Server Error — kodi i serverit u rrëzua. Arsyeja e vërtetë është te regjistrat e serverit, jo në shfletues.
• Gabime CORS — shfletuesi bllokoi një kërkesë drejt një domaini tjetër. Zakonisht është një problem konfigurimi në anën e serverit.

Hapi 3: Përdorni veglat e zhvilluesit të shfletuesit

Çdo shfletues desktop ka vegla të integruara zhvilluesi („devtools"). Ato tregojnë çfarë po bën faqja në sfond. Në Chrome, Edge dhe Firefox, klikoni me të djathtën kudo në faqe dhe zgjidhni Inspect, ose shtypni F12 (Cmd+Option+I në Mac). Në Safari, aktivizoni menunë Develop te cilësimet e Safari-t së pari.

Ju duhen vetëm tri skeda.

Console

Skeda Console liston gabimet dhe mesazhet nga kodi i faqes. Gabimet shfaqen me të kuqe. Nëse një buton nuk bën asgjë kur klikoni, konsola shpesh do të shfaqë një gabim të kuq në momentin e klikimit. Kopjoni tekstin e plotë të gabimit (klikoni me të djathtën për opsionin e kopjimit në shumicën e shfletuesve).

Network

Skeda Network liston çdo kërkesë që bën faqja — ngarkimi i të dhënave, ruajtja e një formulari, hyrja. Hapeni, pastaj përsëriteni hapat që shkaktojnë gabimin.

• Kërkoni rreshta me të kuqe ose me status 400 e lart.
• Klikoni një rresht që dështon për të parë Response. Një gabim serveri shpesh përfshin atje një mesazh më të dobishëm se çdo gjë në ekran.
• Shënoni URL-në e kërkesës dhe kodin e statusit — „POST te /api/bookings ktheu 500" është një fjali shumë e dobishme për t'i dhënë AI-së.

Shenjoni Preserve log nëse gabimi përfshin rifreskim faqeje ose ridrejtim, që kërkesat të mos zhduken.

Elements

Skeda Elements (ose Inspector) tregon strukturën dhe stilet e faqes. Është më e dobishme për gabimet e pamjes: kaloni miun mbi një element për të parë madhësinë dhe hapësirën e theksuar. Nuk ju duhet të ndryshoni asgjë këtu; mjafton të thoni „footer-i është 2,000 pikselë i gjerë në telefon dhe e shtyn faqen anash".

Hapi 4: Kontrolloni regjistrat e serverit

Disa gabime ndodhin në server, ku shfletuesi nuk i sheh. Një 500 në skedën e rrjetit është shenja klasike. Regjistrat e serverit — daljet me tekst të backend-it tuaj ndërsa punon — zakonisht përmbajnë gabimin e vërtetë me një stack trace (listën e funksioneve që ishin në punë kur dështoi).

Ku i gjeni varet nga mjeti juaj. Në shumicën e ndërtuesve të aplikacioneve me AI mund të hapni një terminal ose pamje regjistrash për projektin, ose thjesht t'i kërkoni AI-së: „Kontrollo regjistrat e serverit për gabime nga kërkesa e fundit dhe më trego çfarë dështoi."

Hapi 5: Përshkruajeni gabimin për AI-në

Vendoseni atë që keni mbledhur në këtë formë:

Te faqja e Rezervimeve, i kyçur si anëtar: klikova Cancel te klasa e nesërme e orës 9:00. Pritur: rezervimi zhduket dhe klasa tregon një vend të lirë më shumë. Aktuale: asgjë nuk ndryshon në ekran. Konsola tregon TypeError: Cannot read properties of undefined (reading 'id') te BookingCard.tsx:31, dhe skeda e rrjetit tregon se DELETE /api/bookings/123 ktheu 500. Gjej shkakun, rregulloje dhe kontrollo që anulimi punon për një anëtar me një rezervim dhe për një me disa.

Pse ka rëndësi secila pjesë:

• Ku dhe si kë e ngushton në një ekran dhe një rol.
• Hapat e saktë i lejojnë AI-së të riprodhojë gabimin.
• Pritur kundrejt aktuales përcakton çfarë do të thotë „e rregulluar".
• Teksti i gabimit dhe kërkesa që dështoi tregojnë drejt e te shkaku.
• „Kontrollo që…" i kërkon AI-së të verifikojë, jo vetëm të ndryshojë.

Nëse AI ka provuar dy herë një rregullim dhe ka dështuar, kërkojini të shpjegojë përpara se të ndryshojë diçka:

Mos e ndrysho kodin ende. Çfarë mendon se e shkakton këtë, dhe çfarë provash e mbështesin?

Një teori e gabuar lehtë dallohet kur shkruhet, dhe kushton shumë më pak të korrigjohet sesa një rregullim i gabuar.

Hapi 6: Verifikoni, pastaj kontrolloni pranë

Kur AI thotë se është rregulluar, përsëritni hapat e saktë nga Hapi 1. Pastaj kontrolloni gjërat përreth:

• Veprimi i njëjtë për një rol tjetër përdoruesi
• Veprimi i njëjtë pa të dhëna, dhe me shumë të dhëna
• Faqet që ndajnë komponentë me atë që rregulluat
• Një ekran me gjerësinë e telefonit, nëse rregullimi preku pamjen

Ndryshimet e AI ndonjëherë rregullojnë një rrugë dhe prishin heshtazi një tjetër. Një kontroll dy-minutësh tani kursen një orë të konfuzë më vonë.

Hapi 7: Ktheni mbrapsht në vend që të grumbulloni

Nëse një rregullim e përkeqësoi gjërat, ose keni kaluar tri raunde pa përparim, kthehuni mbrapsht. Kthimi te versioni i fundit që funksionoi dhe riformulimi me prova më të mira pothuajse gjithmonë është më mirë sesa kërkimi i një rregullimi të katërt mbi tre të gabuarit. Çdo përpjekje e dështuar lë kod pas, dhe ai kod e ngatërron përpjekjen e radhës.

Zakone të mira që e bëjnë kthimin të lehtë:

• Testoni pas çdo ndryshimi, që të dini cili ndryshim prishi gjërat.
• Mbajini ndryshimet të vogla — një veçori ose rregullim për mesazh.
• Shënoni versionin e fundit të mirë përpara se të filloni diçka të rrezikshme.
• Nëse kodi është në Git, bëni commit versionet që funksionojnë, që të mund t'uktheheni.

Modele të zakonshme gabimesh në aplikacionet e ndërtuara me AI

Kur problemi nuk është gabim

Disa „gabime" janë AI që ndërton pikërisht atë që i u tha, dhe përshkrimi ishte i paqartë. Nëse rregullimi që kërkoni është në të vërtetë një ndryshim sjelljeje, thojeni qartë: „Ndryshoje në mënyrë që…". Nëse e gjeni veten të paqartë se cila është sjellja e saktë, vendoseni atë fillimisht. Udhëzuesi ynë për shkrimin e kërkesave për ndërtuesit e aplikacioneve me AI mbulon si të specifikoni rregulla qartë. Dhe nëse po e përgatitni një aplikacion për përdorues real, si ta çoni një prototip AI në prodhim mbulon kontrollet që vlen t'i bëni para lansimit.

Korrigjimi në Mythex

Mythex ka vegla për çdo hap të ciklit:

• Preview për të riprodhuar gabimin, përfshirë një pamje me madhësinë e telefonit.
• /test e ka agjentin të klikojë nëpër pamjen tuaj paraprake live si një përdorues dhe të raportojë rrjedhat e prishura.
• /fix e drejton agjentin specifikisht drejt prishjeve.
• Modaliteti Plan e lë agjentin të hetojë dhe shpjegojë përpara se të ndryshojë diçka.
• Code → terminal shfaq regjistrat e serverit të aplikacionit tuaj.
• Revert to this point në çdo përgjigje e kthen projektin te ai checkpoint.

Nëse një publikim dështon, dialogu i publikimit zakonisht ofron Fix with AI, që lexon daljen e build-it ose regjistrat e aplikacionit. Shihni Debug your app dhe Publish troubleshooting në dokumentacion.

Pyetje