Paano Mag-debug ng AI-Built na App: Praktikal na Paraan

Para mag-debug ng app na ginawa gamit ang AI, i-reproduce muna ang bug nang sinasadya, saka mangolekta ng ebidensya: ang eksaktong hakbang, ang error message, at kung ano ang ipinapakita ng browser console at network tab. Ibigay ito sa AI bilang "ginawa ko ang X, inaasahan ko ang Y, pero Z ang nakuha ko". Kung lumala ang lagay pagkatapos ng fix, mag-rollback sa huling gumaganang bersyon sa halip na magdagdag pa ng fix sa ibabaw nito. Hindi mo kailangang basahin ang code para magawa ito nang maayos.

Sakop ng gabay na ito ang buong ikot, kasama ang mabilisang pagtingin sa browser developer tools para sa mga hindi developer.

Ang ikot ng debugging

Sinusunod ng bawat pag-aayos ng bug, tao man o AI ang gumagawa, ang parehong ikot:

1. I-reproduce: pagpapaulit ng bug nang maaasahan.
2. Obserbahan: kunin ang error message at kung ano ang ginagawa ng app.
3. Ilarawan: bigyan ang AI ng tiyak na hakbang, inaasahang resulta at aktuwal na resulta.
4. Ayusin: hayaang baguhin ng AI ang isang bagay.
5. I-verify: ulitin ang eksaktong hakbang at kumpirmahing naayos na, at walang ibang nasira sa paligid.
6. Mag-rollback kung kailangan: kung lumala, i-undo at subukan ulit nang may mas magandang impormasyon.

Karamihan ng nasasayang na oras sa mga app na gawa ng AI ay galing sa paglaktaw sa mga hakbang 1, 2 at 5: pagsasabing "sira ito", pagtanggap ng pagbabagong hindi nasubukan, at saka paghingi ng isa pang fix sa ibabaw ng sira na.

Hakbang 1: I-reproduce ang bug

Kalahating naayos na ang bug na kaya mong i-trigger kapag gusto mo. Subukang hanapin ang pinakamaikling hanay ng hakbang na nagdudulot nito.

Tanungin ang sarili:

• Nangyayari ba ito sa bawat pagkakataon? Kung minsan lang, ano ang iba kapag nangyayari ito: isang partikular na record, mabagal na koneksyon, o naka-log out?
• Nangyayari ba ito sa bawat user? Mag-log in gamit ibang account. Maraming bug ang lumalabas lang sa mga bagong user na walang data, o sa user na may ibang role.
• Nangyayari ba ito sa bawat device? Subukan ang screen na kasing-lapad ng telepono at ibang browser.
• Nagsimula ba ito pagkatapos ng partikular na pagbabago? Kung gumana ito kahapon, ang huling ilang pagbabago ang pangunahing suspek.

Isulat ang mga hakbang bilang maikling may-numerong listahan. I-paste mo ito sa prompt mamaya.

Hakbang 2: Basahin ang error message

Mukhang nakatatakot ang mga error message, pero kakaunting bahagi lang ang kailangan mo.

Hindi mo kailangang maintindihan ito; kailangan mo itong kopyahin nang eksakto. Sinasabi ng "Cannot read properties of undefined (reading 'name')" sa AI na may inaasahang data ang code (malamang booking o user) na wala roon. Mawawala ang kahulugang iyon kapag inilarawan mo lang bilang "some undefined error".

Ilan sa mga karaniwan, halos isinalin:

• Mga error na undefined / null: inaasahan ng code ang data na hindi dumating. Kadalasan ito ay loading state o walang lamang listahan na hindi hinawakan ng code.
• 404 Not Found: hindi umiiral ang page o API address. Kadalasan ay typo sa route o link sa page na napalitan ang pangalan.
• 401 Unauthorized / 403 Forbidden: hindi naka-log in ang request, o hindi pinapayagan ang user na gawin iyon.
• 500 Internal Server Error: nag-crash ang server-side code. Nasa server logs ang totoong dahilan, hindi sa browser.
• Mga error sa CORS: hinarang ng browser ang request papunta sa ibang domain. Kadalasan ay problema sa configuration sa panig ng server.

Hakbang 3: Gamitin ang browser developer tools

May built-in na developer tools ("devtools") ang bawat desktop browser. Ipinapakita nito ang ginagawa ng page sa likod ng eksena. Sa Chrome, Edge at Firefox, i-right-click kahit saan sa page at piliin ang Inspect, o pindutin ang F12 (Cmd+Option+I sa Mac). Sa Safari, i-on muna ang Develop menu sa settings ng Safari.

Tatlong tab lang ang kailangan mo.

Console

Nakalista sa Console tab ang mga error at mensahe mula sa code ng page. Pulang kulay ang mga error. Kapag walang nangyayari pagkapindot mo sa button, kadalasang may pulang error na lalabas mismo sa sandaling pinindot mo. Kopyahin ang buong teksto ng error (i-right-click ito para sa copy option sa karamihan ng browser).

Network

Nakalista sa Network tab ang bawat request na ginagawa ng page: pagkuha ng data, pag-save ng form, pag-log in. Buksan ito, saka ulitin ang mga hakbang na nagdudulot ng bug.

• Hanapin ang mga row na pula o may status na 400 pataas.
• I-click ang pumalyang row para makita ang Response nito. Madalas may mensahe roon ang server error na mas kapaki-pakinabang kaysa anumang nasa screen.
• Itala ang URL at status code ng request. Ang pangungusap na "Pumalya ang POST sa /api/bookings na may 500" ay napakahalagang ibigay sa AI.

I-tick ang Preserve log kung ang bug ay may kinalaman sa pag-reload o redirect ng page, para hindi mawala ang mga request.

Elements

Ipinapakita ng Elements (o Inspector) tab ang istruktura at style ng page. Pinakamakatulong ito sa mga layout bug: i-hover ang isang element para makita ang laki at spacing nito na naka-highlight. Hindi mo kailangang mag-edit dito; sapat nang sabihing "ang footer ay 2,000 pixel ang lapad sa mobile at itinutulak ang page patagilid".

Hakbang 4: Tingnan ang server logs

May ilang bug na nangyayari sa server, kung saan hindi nakikita ng browser. Ang 500 error sa network tab ang klasikong senyales. Karaniwang naglalaman ang server logs, na ang text output ng backend habang tumatakbo, ng totoong error kasama ang stack trace (listahan ng mga function na tumatakbo nang pumalya ito).

Nakadepende kung saan mo ito makikita sa tool na gamit mo. Sa karamihan ng AI app builder, puwede kang magbukas ng terminal o log view para sa project, o simpleng itanong sa AI: "Tingnan ang server logs para sa mga error mula sa huling request at sabihin sa akin kung ano ang pumalya."

Hakbang 5: Ilarawan ang bug sa AI

Ilagay ang nakalap mo sa ganitong anyo:

Sa Bookings page, naka-log in bilang member: in-click ko ang Cancel sa 9:00 class bukas. Inaasahan: mawawala ang booking at madadagdagan ng isang bakanteng puwesto ang class. Aktuwal: walang nagbago sa screen. Ipinapakita ng console ang TypeError: Cannot read properties of undefined (reading 'id') sa BookingCard.tsx:31, at ipinapakita ng network tab na ang DELETE /api/bookings/123 ay nagbalik ng 500. Hanapin ang sanhi, ayusin ito, at tiyaking gumagana ang pagkansela para sa member na may isang booking at para sa may ilang booking.

Bakit mahalaga ang bawat bahagi:

• Saan at bilang sino ang nagpapaliit sa isang screen at isang role.
• Eksaktong mga hakbang ang nagpapahintulot sa AI na i-reproduce ito.
• Inaasahan kumpara sa aktuwal ang nagtatakda kung ano ang "naayos na".
• Ang teksto ng error at ang pumalyang request ang tumuturo nang diretso sa sanhi.
• "Tiyaking gumagana ang…" ang nagpapahiling sa AI na mag-verify, hindi lang mag-edit.

Kung dalawang beses nang sinubukan ng AI ang fix at pumalya, hilingin sa kanyang magpaliwanag bago magbago ng kahit ano:

Huwag ka munang magbago ng code. Ano sa tingin mo ang sanhi nito, at anong ebidensya ang sumusuporta rito?

Madaling makita ang maling teorya kapag naisulat na, at mas mura itong itama kaysa maling fix.

Hakbang 6: I-verify, saka tingnan ang mga kalapit

Kapag sinabi ng AI na naayos na, ulitin ang eksaktong hakbang mula sa Hakbang 1. Pagkatapos, tingnan ang mga nasa paligid nito:

• Ang parehong aksyon para sa ibang user role
• Ang parehong aksyon na walang data, at na may maraming data
• Mga page na nagbabahagi ng component sa inayos mo
• Screen na kasing-lapad ng telepono, kung ginalaw ng fix ang layout

Minsan, naaayos ng pagbabago ng AI ang isang landas at tahimik na nasisira ang isa pa. Ang dalawang minutong pagsusuri ngayon ay nakakatipid ng isang oras na pagkalito mamaya.

Hakbang 7: Mag-rollback sa halip na magdagdag pa

Kung lumala ang lagay pagkatapos ng fix, o tatlong ikot na ang lumipas nang walang progreso, bumalik. Ang pag-rollback sa huling gumaganang bersyon at muling pagsasabi ng problema na may mas magandang ebidensya ay halos palaging mas mainam kaysa humingi ng ikaapat na fix sa ibabaw ng tatlong maling fix. Nag-iiwan ang bawat nabigong subok ng code, at nalilito nito ang susunod na subok.

Mga magandang ugali na nagpapadali ng rollback:

• Subukan pagkatapos ng bawat pagbabago, para malaman mo kung aling pagbabago ang nagpasira.
• Panatilihing maliit ang mga pagbabago: isang feature o fix kada mensahe.
• Itala ang huling gumaganang bersyon bago magsimula ng delikadong bagay.
• Kung nasa Git ang code, mag-commit ng mga gumaganang bersyon para makabalik ka sa mga ito.

Mga karaniwang pattern ng bug sa mga app na gawa ng AI

Kapag hindi bug ang problema

May ilang "bug" na ang AI ay gumagawa lang nang eksakto ayon sa sinabi sa kanya, at malabo lang ang paglalarawan. Kung ang hinihingi mong fix ay talagang pagbabago sa behaviour, sabihin ito nang tahasan: "Baguhin ito para…". Kung hindi ka sigurado kung ano mismo ang tamang behaviour, pagpasyahan muna iyon. Sakop ng aming gabay sa pagsusulat ng prompt para sa AI app builder kung paano malinaw na ilalarawan ang mga panuntunan. At kung naghahanda ka ng app para sa totoong user, sakop ng paglipat ng AI prototype sa production ang mga check na sulit gawin bago ilunsad.

Pag-debug sa Mythex

May mga tool ang Mythex para sa bawat hakbang ng ikot:

• Preview para i-reproduce ang bug, kasama ang frame na kasing-laki ng telepono.
• /test pinapa-click ng agent ang live preview mo na parang user at iniuulat ang mga sirang daloy.
• /fix itinuturo ng agent ang sira nang partikular.
• Plan mode hinahayaan ang agent na mag-imbestiga at magpaliwanag bago mag-edit ng kahit ano.
• Code → terminal ipinapakita ang server logs ng app mo.
• Revert to this point sa anumang reply ay nagba-balik ng project sa checkpoint na iyon.

Kapag pumalya ang publish, karaniwang nag-aalok ang publish dialog ng Fix with AI, na binabasa ang build output o logs ng app. Tingnan ang Debug your app at Publish troubleshooting sa docs.

Mga tanong