AI ဖြင့် တည်ဆောက်ထားသော App ကို Debug လုပ်နည်း: လက်တွေ့နည်းလမ်း

AI ဖြင့် တည်ဆောက်ထားသော app ကို debug လုပ်ရန် ဦးစွာ bug ကို ရည်ရွယ်ချက်ရှိရှိ ထပ်ဖြစ်အောင် လုပ်ပါ၊ ထို့နောက် အထောက်အထား စုဆောင်းပါ — အဆင့်အတိအကျများ၊ error message နှင့် browser console နှင့် network tab တွင် ပေါ်သည်များ — ပြီးလျှင် AI ကို "ကျွန်ုပ် X ကို လုပ်ခဲ့သည်၊ Y ကို မျှော်လင့်ခဲ့သည်၊ Z ကို ရရှိခဲ့သည်" ဟု ပေးပါ။ ပြင်ဆင်ချက်တစ်ခုက ပိုဆိုးစေလျှင် နောက်ဆုံး အလုပ်ဖြစ်ခဲ့သော ဗားရှင်းသို့ rollback လုပ်ပါ၊ အပေါ်တွင် ပြင်ဆင်ချက် ဆက်မပုံပါနှင့်။ Code ကို ဖတ်ရန် မလိုအပ်ပါ။

ဤလမ်းညွှန်သည် loop တစ်ခုလုံးကို ဖုံးလွှမ်းပြီး နည်းပညာမသုံးတတ်သူများအတွက် browser developer tool များကို အတိုချုံ့ မိတ်ဆက်ပေးပါတယ်။

Debugging loop

Bug ပြင်ဆင်ချက်တိုင်း၊ လူ သို့မဟုတ် AI ဖြစ်စေ၊ တူညီသော loop ကို လိုက်ပါတယ်:

1. ပြန်ဖြစ်အောင်လုပ်ပါ — bug ကို ယုံကြည်ရစွာ ဖြစ်စေပါ။
2. သတိပြုပါ — error message နှင့် app က ဘာလုပ်နေသလဲ ကို စုဆောင်းပါ။
3. ဖော်ပြပါ — AI ကို အဆင့်တိကျများ၊ မျှော်လင့်ရလဒ်နှင့် တကယ်ရလဒ်ကို ပေးပါ။
4. ပြင်ပါ — AI က အရာတစ်ခုတည်းကို ပြောင်းစေပါ။
5. အတည်ပြုပါ — အဆင့်တိကျအတိုင်း ပြန်လုပ်ပြီး ပြင်ပြီးကြောင်းနှင့် အနီးရှိ တစ်စုံတစ်ခုမျှ မပျက်ကြောင်း အတည်ပြုပါ။
6. လိုအပ်လျှင် rollback လုပ်ပါ — ပိုဆိုးလာလျှင် ပြန်ဖျက်ပြီး ပိုကောင်းသော အချက်အလက်ဖြင့် ပြန်ကြိုးစားပါ။

AI-built app များတွင် အချိန်ဖြုန်းမှု အများစုသည် ၁၊ ၂ နှင့် ၅ အဆင့်များကို ကျော်ခြင်းမှ ဖြစ်ပါတယ်: "ပျက်နေတယ်" ဟု ပြောခြင်း၊ ပြောင်းလဲမှုကို စမ်းသပ်မလုပ်ဘဲ လက်ခံခြင်း၊ ထို့နောက် ပျက်နေသော ပြင်ဆင်ချက်ပေါ်တွင် နောက်ထပ် ပြင်ဆင်ချက် တောင်းခြင်း။

အဆင့် ၁: Bug ကို ပြန်ဖြစ်အောင် လုပ်ပါ

သင်ဖြစ်စေနိုင်သော bug သည် ဝက်ဝက်ပြင်ပြီးသားဖြစ်သည်။ အတိုဆုံး အဆင့်အစုံကို ရှာပါ။

သင့်ကိုယ်သင် မေးပါ:

• အမြဲဖြစ်ပါသလား? တစ်ခါတစ်ရံသာဖြစ်ပါက ဖြစ်သည့်အခါ ဘာကွဲပြားနေသလဲ — တစ်ခုခု record၊ နှေးကွေးသော connection၊ logout ဖြစ်နေခြင်း?
• အသုံးပြုသူတိုင်းအတွက် ဖြစ်ပါသလား? အကောင့်မတူညီသည်ဖြင့် login ဝင်ကြည့်ပါ။ Bug အများအပြားသည် data မရှိသော အသစ်အသုံးပြုသူများ သို့မဟုတ် role မတူသော အသုံးပြုသူများအတွက်သာ ပေါ်လာတတ်ပါတယ်။
• စက်တိုင်းတွင် ဖြစ်ပါသလား? ဖုန်းအကျယ်ရှိ စခရင်နှင့် browser မတူညီသည်ကို စမ်းကြည့်ပါ။
• ပြောင်းလဲမှု တစ်ခုအပြီးတွင် စတင်ခဲ့သလား? အရင်နေ့က အလုပ်လုပ်ခဲ့လျှင် နောက်ဆုံး ပြောင်းလဲမှု အနည်းငယ်သည် အဓိက သံသယ ဖြစ်ပါတယ်။

အဆင့်များကို နံပါတ်စဉ် စာရင်းအဖြစ် ရေးပါ။ နောက်ပိုင်း prompt ထဲ ကူးထည့်ပါမည်။

အဆင့် ၂: Error message ကို ဖတ်ပါ

Error message များသည် ကြောက်စရာကောင်းဟု ထင်ရသော်လည်း အပိုင်းအနည်းငယ်သာ လိုအပ်ပါတယ်။

နားလည်ရန် မလိုပါ၊ အတိအကျ ကူးယူရန် လိုသည်။ "Cannot read properties of undefined (reading 'name')" သည် code က data တစ်ခု (များသောအားဖြင့် booking သို့မဟုတ် user) ကို မျှော်လင့်ခဲ့သော်လည်း ရောက်မလာခဲ့ကြောင်း AI ကို ပြောပြပါတယ်။ "some undefined error" ဟု ပြန်ပြောလျှင် ထိုအချက်ကို ဆုံးရှုံးပါသည်။

အဖြစ်များသော အချို့ (ခြုံငုံ ဘာသာပြန်ထား):

• undefined / null error များ — code က မျှော်လင့်ထားသော data မရောက်ခဲ့ပါ။ Loading အခြေအနေ သို့မဟုတ် code က မကိုင်တွယ်ထားသော ဗလာ list ဖြစ်လေ့ရှိပါတယ်။
• 404 Not Found — စာမျက်နှာ သို့မဟုတ် API လိပ်စာ မရှိပါ။ Route တွင် typo သို့မဟုတ် အမည်ပြောင်းသွားသော စာမျက်နှာသို့ link ဖြစ်လေ့ရှိပါတယ်။
• 401 Unauthorized / 403 Forbidden — request က login မဝင်ထားခြင်း၊ သို့မဟုတ် အသုံးပြုသူ၌ ထိုလုပ်ဆောင်ခွင့် မရှိခြင်း။
• 500 Internal Server Error — Server-side code ပျက်သွားခြင်း။ အမှန်အကြောင်းရင်းသည် browser တွင် မဟုတ်ဘဲ server log များတွင် ရှိပါတယ်။
• CORS error များ — Browser က အခြား domain သို့ request ကို ပိတ်ဆို့ခဲ့သည်။ များသောအားဖြင့် server ဘက်ရှိ configuration ပြဿနာ။

အဆင့် ၃: Browser developer tool များကို သုံးပါ

Desktop browser တိုင်းတွင် built-in developer tool များ ("devtools") ရှိပါတယ်။ ၎င်းတို့သည် စာမျက်နှာသည် နောက်ကွယ်တွင် ဘာလုပ်နေသလဲ ပြပါတယ်။ Chrome၊ Edge နှင့် Firefox တွင် စာမျက်နှာ မည်သည့်နေရာမဆို right-click နှိပ်ပြီး Inspect ကို ရွေးပါ၊ သို့မဟုတ် F12 နှိပ်ပါ (Mac တွင် Cmd+Option+I)။ Safari တွင် ဦးစွာ Safari settings တွင် Develop menu ကို ဖွင့်ပါ။

သင်သုံးရမည့် tab သုံးခုသာ ရှိပါတယ်။

Console

Console tab သည် စာမျက်နှာ၏ code မှ error များနှင့် message များကို စာရင်းပြုစုပါတယ်။ Error များကို အနီရောင်ဖြင့် ပြပါတယ်။ ခလုတ်တစ်ခု နှိပ်သော်လည်း ဘာမှမဖြစ်ပါက၊ နှိပ်ချိန်တွင် အနီရောင် error တစ်ခု ပေါ်လေ့ရှိပါတယ်။ Error ၏ စာသားအပြည့်အစုံကို ကူးယူပါ (အများ browser များတွင် right-click နှိပ်ပြီး copy ရွေးချယ်ခွင့် ရှိပါတယ်)။

Network

Network tab သည် စာမျက်နှာ လုပ်ဆောင်သော request တိုင်းကို စာရင်းပြုစုပါတယ် — data ဖတ်ခြင်း၊ form သိမ်းခြင်း၊ login ဝင်ခြင်း။ ဖွင့်ပြီး bug ဖြစ်စေသော အဆင့်များကို ပြန်လုပ်ပါ။

• အနီရောင် သို့မဟုတ် status 400 နှင့် အထက်ရှိ row များကို ရှာပါ။
• ပျက်ကွက်သော row ကို နှိပ်ပြီး Response ကို ကြည့်ပါ။ Server error တွင် မျက်နှာပြင်ပေါ်ရှိသည်ထက် ပိုအသုံးဝင်သော message ပါတတ်ပါတယ်။
• Request ၏ URL နှင့် status code ကို မှတ်ပါ — "POST /api/bookings သည် 500 ပြန်ပါသည်" ဆိုသော စာကြောင်းသည် AI ကို အလွန်အသုံးဝင်ပါတယ်။

Bug တွင် page reload သို့မဟုတ် redirect ပါဝင်ပါက Preserve log ကို ခြစ်ထားပါ၊ request များ ပျောက်မသွားစေရန်။

Elements

Elements (သို့မဟုတ် Inspector) tab သည် စာမျက်နှာ၏ structure နှင့် style များကို ပြပါတယ်။ Layout bug များအတွက် အထူးအသုံးဝင်ပါတယ်: element ပေါ် hover လုပ်လျှင် ၎င်း၏ အရွယ်အစားနှင့် spacing ကို highlight လုပ်ပြပါတယ်။ ဤနေရာတွင် ဘာမျှ ပြင်ရန်မလို၊ "footer သည် မိုဘိုင်းတွင် 2,000 pixel ကျယ်ပြီး စာမျက်နှာကို ဘေးသို့ တွန်းနေသည်" ဟု ပြောရုံ လုံလောက်ပါတယ်။

အဆင့် ၄: Server log များကို စစ်ပါ

အချို့ bug များသည် browser မမြင်နိုင်သော server ပေါ်တွင် ဖြစ်ပါတယ်။ Network tab ထဲမှ 500 error သည် ဂန္ထဝင် လက္ခဏာဖြစ်ပါတယ်။ Server log — backend ၏ run နေစဉ် စာသား output — တွင် stack trace (ပျက်ကွက်သည့်အချိန်တွင် run နေသော function များ၏ စာရင်း) ပါသော အမှန်တကယ် error ပါလေ့ရှိပါတယ်။

ဘယ်မှာ ရှာရမည်ဆိုသည်မှာ သင့် tool အပေါ် မူတည်ပါတယ်။ AI app builder အများစုတွင် project အတွက် terminal သို့မဟုတ် log view ကို ဖွင့်နိုင်ပါတယ်၊ သို့မဟုတ် AI ကို ရိုးရိုးပြောနိုင်ပါတယ်: "နောက်ဆုံး request မှ server log ထဲ error များကို စစ်ပြီး ဘာပျက်ကွက်သလဲ ပြောပါ။"

အဆင့် ၅: AI ကို bug ကို ဖော်ပြပါ

ရရှိထားသည်များကို ဤပုံစံသို့ ထည့်ပါ:

Bookings စာမျက်နှာတွင်၊ member အဖြစ် login ဝင်ထားပြီး: မနက်ဖြန် 9:00 class ၏ Cancel ကို နှိပ်ခဲ့သည်။ မျှော်လင့်ချက်: booking ပျောက်သွားပြီး class တွင် နေရာ တစ်ခု ပိုလွတ်သွားရမည်။ တကယ်ဖြစ်သည်: စခရင်ပေါ်တွင် ဘာမျှ မပြောင်းလဲပါ။ Console တွင် TypeError: Cannot read properties of undefined (reading 'id') ကို BookingCard.tsx:31 တွင် ပြသပြီး network tab တွင် DELETE /api/bookings/123 သည် 500 ပြန်ခဲ့သည်။ အကြောင်းရင်းကို ရှာပြီး ပြင်ပါ၊ နှင့် member တစ်ယောက်တည်း booking ရှိသော်လည်းကောင်း၊ အများအပြား ရှိသော်လည်းကောင်း cancel လုပ်ခြင်း အလုပ်လုပ်ကြောင်း စစ်ပါ။

အစိတ်အပိုင်းတစ်ခုချင်းစီ အရေးကြီးပုံ:

• ဘယ်မှာနှင့် ဘယ်သူအဖြစ် က စာမျက်နှာတစ်ခုနှင့် role တစ်ခုသို့ ကျဉ်းစေသည်။
• အဆင့်အတိအကျများ က AI ကို ပြန်ဖြစ်အောင် လုပ်ခွင့်ပေးသည်။
• မျှော်လင့်ချက်နှင့် တကယ်ဖြစ်သည် က "ပြင်ပြီး" ဆိုသည်ကို သတ်မှတ်သည်။
• Error စာသားနှင့် ပျက်ကွက်သော request က အကြောင်းရင်းကို တိုက်ရိုက် ညွှန်ပြသည်။
• "စစ်ဆေးပါ…" က AI ကို ပြင်ရုံသာမက အတည်ပြုရန် တောင်းဆိုသည်။

AI က နှစ်ကြိမ် ပြင်ရန် ကြိုးစားပြီး ကျရှုံးပါက အရာတစ်ခုမျှ မပြင်မီ ရှင်းပြရန် ဤသို့ မေးပါ:

Code မပြောင်းသေးပါနှင့်။ ဘာကြောင့် ဖြစ်တယ်လို့ ထင်သလဲ၊ ဘယ်အထောက်အထားက ထောက်ခံသလဲ?

မှားသော သီအိုရီကို ရေးထုတ်လိုက်သောအခါ အလွယ်တကူ တွေ့နိုင်ပြီး၊ မှားသော ပြင်ဆင်ချက်ထက် ပြင်ရန် ပိုသက်သာပါတယ်။

အဆင့် ၆: အတည်ပြုပြီး ဘေးပတ်ဝန်းကျင် စစ်ပါ

AI က ပြင်ပြီးဟု ပြောသောအခါ အဆင့် ၁ မှ အတိအကျ အဆင့်များကို ပြန်လုပ်ပါ။ ထို့နောက် ပတ်ဝန်းကျင်ကို စစ်ပါ:

• အခြား user role အတွက် လုပ်ဆောင်ချက်တူတူ
• Data မရှိသော်လည်းကောင်း၊ data အများအပြား ရှိသော်လည်းကောင်း လုပ်ဆောင်ချက်တူတူ
• ပြင်ထားသော အရာနှင့် component များ မျှဝေသော စာမျက်နှာများ
• Layout ပြင်ခဲ့လျှင် ဖုန်းအကျယ် စခရင်

AI ပြောင်းလဲမှုများက တစ်လမ်းကို ပြင်ပေးပြီး တခြားတစ်လမ်းကို တိတ်တဆိတ် ဖျက်ဆီးနိုင်ပါတယ်။ ယခု နာရီဝက်ခန့် စစ်ဆေးခြင်းက နောက်မှ ရှုပ်ထွေးသော နာရီတစ်ခုကို ရှောင်စေပါတယ်။

အဆင့် ၇: ပြင်ဆင်ချက် ဆက်မပုံမဲ့ rollback လုပ်ပါ

ပြင်ဆင်ချက်တစ်ခုက ပိုဆိုးစေခဲ့လျှင် သို့မဟုတ် တိုးတက်မှု မရှိဘဲ သုံးကြိမ် ရောက်လာပါက ပြန်သွားပါ။ အလုပ်ဖြစ်ခဲ့သော နောက်ဆုံးဗားရှင်းသို့ rollback လုပ်ပြီး အထောက်အထား ပိုကောင်းဖြင့် ပြန်ရေးခြင်းသည် မှားနေသော ပြင်ဆင်ချက် သုံးခုပေါ်တွင် နောက်တစ်ခု ထပ်တောင်းခြင်းထက် အမြဲတမ်း ပိုကောင်းပါတယ်။ ကျရှုံးတိုင်း code ကို ကျန်ခဲ့ပြီး ၎င်းသည် နောက်ကြိုးစားမှုကို ရှုပ်ထွေးစေပါတယ်။

Rollback ကို လွယ်ကူစေသော အကျင့်ကောင်းများ:

• ပြောင်းလဲမှုတိုင်းပြီးနောက် စမ်းသပ်ပါ၊ ဘယ်ပြောင်းလဲမှုက ပျက်စေသလဲ သိရန်။
• အပြောင်းအလဲ သေးသေးဖြင့်ထားပါ — message တစ်ခုလျှင် feature သို့မဟုတ် ပြင်ဆင်ချက် တစ်ခု။
• အန္တရာယ်ရှိသော အရာမလုပ်မီ နောက်ဆုံး အလုပ်လုပ်သော ဗားရှင်းကို မှတ်ပါ။
• Code သည် Git တွင် ရှိလျှင် အလုပ်လုပ်သော ဗားရှင်းများကို commit လုပ်ပါ၊ ပြန်သွားနိုင်ရန်။

AI-built app များတွင် အဖြစ်များသော bug ပုံစံများ

Bug မဟုတ်သော ပြဿနာများ

အချို့ "bug" များသည် AI က ပြောထားသည့်အတိုင်း တည်ဆောက်ခြင်း ဖြစ်ပြီး ဖော်ပြချက်မှာ ရှုပ်ထွေးနေခြင်း ဖြစ်ပါတယ်။ သင်တောင်းဆိုသော ပြင်ဆင်ချက်သည် အမှန်တကယ် အပြုအမူ ပြောင်းလဲမှု ဖြစ်ပါက ထိုသို့ ရိုးရိုးရှင်းရှင်း ပြောပါ: "ပြောင်းပါ ဤသို့…"။ မှန်ကန်သော အပြုအမူက ဘာလဲ မသေချာပါက ဦးစွာ ဆုံးဖြတ်ပါ။ AI app builder များသို့ prompt ရေးနည်းအတွက် AI app builder များအတွက် prompt ရေးနည်း တွင် စည်းမျဉ်းများကို ရှင်းရှင်းလင်းလင်း သတ်မှတ်နည်းကို ဖုံးလွှမ်းထားပါတယ်။ အသုံးပြုသူ အစစ်များအတွက် app ကို ပြင်ဆင်နေပါက AI prototype ကို production သို့ ယူဆောင်နည်း တွင် launch မတိုင်မီ လုပ်သင့်သော စစ်ဆေးမှုများကို ဖော်ပြထားပါတယ်။

Mythex တွင် debug လုပ်ခြင်း

Mythex တွင် loop ၏ အဆင့်တစ်ခုစီအတွက် ကိရိယာများ ရှိပါတယ်:

• Preview — bug ကို ပြန်ဖြစ်အောင်လုပ်ရန်၊ ဖုန်းအရွယ် frame ပါဝင်သည်။
• /test — agent က သင့် live preview ကို အသုံးပြုသူတစ်ယောက်လို နှိပ်ပြီး ပျက်နေသော flow များကို အစီရင်ခံသည်။
• /fix — agent ကို ပျက်စီးမှုများကို တိကျစွာ ညွှန်ပြသည်။
• Plan mode — agent က ဘာမျှ မပြင်မီ စုံစမ်းပြီး ရှင်းပြနိုင်စေသည်။
• Code → terminal — သင့် app ၏ server log များကို ပြသသည်။
• Revert to this point — မည်သည့် reply ပေါ်တွင်မဆို ထို checkpoint သို့ project ကို rollback လုပ်သည်။

Publish မအောင်မြင်ပါက publish dialog တွင် များသောအားဖြင့် Fix with AI ကို ပေးပြီး build output သို့မဟုတ် app ၏ log များကို ဖတ်ပေးပါတယ်။ Docs တွင် Debug your app နှင့် Publish troubleshooting ကို ကြည့်ပါ။

မေးခွန်းများ