Ինչպես վրիպազերծել AI-ով կառուցված հավելված. գործնական մեթոդ

AI-ով կառուցված հավելվածը վրիպազերծելու համար նախ ինքնուրույն վերարտադրեք սխալը, ապա հավաքեք ապացույցներ՝ ճշգրիտ քայլերը, սխալի հաղորդագրությունը և այն, ինչ ցույց են տալիս բրաուզերի կոնսոլը և ցանցային ներդիրը, և այդ ամենը տվեք AI-ին՝ «արեցի X, սպասում էի Y, ստացա Z»։ Եթե շտկումը իրավիճակը վատթարացնում է, վերադարձեք վերջին աշխատող տարբերակին՝ շտկումները մեկը մյուսի վրա չդնելու համար։ Այս ամենը լավ անելու համար կոդը կարդալ պետք չէ։

Այս ուղեցույցը ներառում է ամբողջ ցիկլը, ներառյալ արագ շրջագայություն բրաուզերի մշակողական գործիքներում՝ ոչ տեխնիկական մարդկանց համար։

Վրիպազերծման ցիկլը

Ամեն սխալի շտկում, լինի դա մարդ, թե AI, հետևում է նույն ցիկլին.

1. Վերարտադրել — ստիպեք սխալը հուսալիորեն կրկնվել։
2. Դիտարկել — հավաքեք սխալի հաղորդագրությունը և այն, ինչ հավելվածն անում էր։
3. Նկարագրել — տվեք AI-ին ճշգրիտ քայլեր, ակնկալվող արդյունք և իրական արդյունք։
4. Շտկել — թույլ տվեք AI-ին փոխել մեկ բան։
5. Ստուգել — կրկնեք ճշգրիտ քայլերը և հաստատեք, որ շտկված է, և որ մոտակա բան չի կոտրվել։
6. Վերադառնալ, եթե պետք է — եթե վատացավ, հետ վերցրեք և նորից փորձեք ավելի լավ տեղեկությամբ։

AI-ով կառուցված հավելվածների վրա ժամանակը ամենից շատ կորչում է, երբ բաց են թողնվում 1, 2 և 5 քայլերը. ասում եք «կոտրված է», ընդունում եք փոփոխությունը առանց փորձարկելու, ապա պահանջում եք մեկ այլ շտկում արդեն կոտրվածի վրա։

Քայլ 1. Վերարտադրեք սխալը

Սխալը, որ կարող եք դիտավորյալ առաջացնել, կեսով շտկված է։ Փորձեք գտնել ամենակարճ քայլերը, որոնք այն առաջացնում են։

Հարցրեք ինքներդ ձեզ.

• Միշտ է՞ կրկնվում։ Եթե միայն երբեմն, ի՞նչ է տարբերվում, երբ տեղի է ունենում. մի հատուկ գրառում, դանդաղ կապ, դուրս գալը՞։
• Բոլոր օգտատերերի՞ն է վերաբերում։ Մուտք գործեք որպես այլ հաշիվ։ Շատ սխալներ երևում են միայն նոր օգտատերերի համար՝ առանց տվյալների, կամ մեկ այլ դերով օգտատիրոջ համար։
• Բոլոր սարքերի՞ն է վերաբերում։ Փորձեք հեռախոսի լայնությամբ էկրան և այլ բրաուզեր։
• Մի կոնկրետ փոփոխությունից հետո՞ սկսվեց։ Եթե երեկ աշխատում էր, վերջին մի քանի փոփոխությունները գլխավոր կասկածյալներն են։

Գրեք քայլերը կարճ համարակալված ցուցակով. հետո կպցնեք դրանք հրահանգի մեջ։

Քայլ 2. Կարդացեք սխալի հաղորդագրությունը

Սխալի հաղորդագրությունները սարսափելի են թվում, բայց ձեզ պետք են դրանց մի քանի մասերը միայն։

Պետք չէ հասկանաք այն. պետք է ճշգրիտ պատճենեք։ «Cannot read properties of undefined (reading 'name')»-ը AI-ին ասում է, որ կոդը սպասում էր տվյալների (հավանաբար ամրագրում կամ օգտատեր), որ չեկավ։ «Ինչ-որ undefined սխալ»-ը նման նկարագրությունը կորցնում է։

Մի քանի սովորական, մոտավոր թարգմանությամբ.

• undefined / null սխալներ — կոդը սպասում էր տվյալների, որ չեկան։ Հաճախ բեռնման վիճակ կամ դատարկ ցուցակ, որ կոդը չի մշակում։
• 404 Not Found — էջը կամ API հասցեն գոյություն չունի։ Հաճախ երթուղու սխալ գրություն կամ վերանվանված էջի հղում։
• 401 Unauthorized / 403 Forbidden — հարցումը մուտք գործած չէր, կամ օգտատերը իրավունք չունի այդ գործողության։
• 500 Internal Server Error — սերվերի կողմի կոդը խափանվեց։ Իրական պատճառը սերվերի լոգերում է, ոչ թե բրաուզերում։
• CORS սխալներ — բրաուզերը արգելափակեց հարցումը դեպի այլ դոմեյն։ Սովորաբար սերվերի կողմի կարգավորման խնդիր է։

Քայլ 3. Օգտագործեք բրաուզերի մշակողական գործիքները

Յուրաքանչյուր desktop բրաուզեր ունի ներկառուցված մշակողական գործիքներ («devtools»)։ Դրանք ցույց են տալիս, թե էջը ինչ է անում ծածկույթի ետևում։ Chrome-ում, Edge-ում և Firefox-ում աջ սեղմեք էջի ցանկացած տեղ և ընտրեք Inspect, կամ սեղմեք F12 (Mac-ում՝ Cmd+Option+I)։ Safari-ում նախ միացրեք Develop մենյուն Safari-ի կարգավորումներում։

Միայն երեք ներդիր է պետք։

Console

Console ներդիրը ցույց է տալիս էջի կոդի սխալներն ու հաղորդագրությունները։ Սխալները կարմիրով են։ Եթե կոճակը ոչինչ չի անում, երբ սեղմում եք, կոնսոլը շատ հաճախ կարմիր սխալ է ցույց տալիս հենց սեղմման պահին։ Պատճենեք սխալի ամբողջական տեքստը (աջ սեղմեք դրա վրա՝ մեծ մասը բրաուզերներում պատճենելու տարբերակը ստանալու համար)։

Network

Network ներդիրը ցույց է տալիս էջի կատարած յուրաքանչյուր հարցում՝ տվյալների բեռնում, ձևի պահում, մուտք։ Բացեք այն, ապա կրկնեք այն քայլերը, որ առաջացնում են սխալը.

• Փնտրեք կարմիր կամ 400 և բարձր կարգավիճակով տողեր։
• Սեղմեք ձախողված տողի վրա՝ տեսնելու Response-ը։ Սերվերի սխալը հաճախ այնտեղ ունի հաղորդագրություն, որ ավելի օգտակար է, քան էկրանի ցանկացած բան։
• Նշեք հարցման URL-ը և կարգավիճակի կոդը. «POST /api/bookings-ը վերադարձրեց 500» շատ օգտակար նախադասություն է AI-ին։

Նշեք Preserve log-ը, եթե սխալը ներառում է էջի վերաբեռնում կամ վերահղում, որպեսզի հարցումները չանհետանան։

Elements

Elements (կամ Inspector) ներդիրը ցույց է տալիս էջի կառուցվածքը և ոճերը։ Ամենից օգտակարն է դասավորության սխալների համար. վրան սավառնելով տեսնում եք տարրի չափը և տարածությունը։ Այստեղ որևէ բան խմբագրելու կարիք չկա. բավական է ասել՝ «ստորին մասը հեռախոսում 2000 պիքսել լայն է և էջը կողքի է մղում»։

Քայլ 4. Ստուգեք սերվերի լոգերը

Որոշ սխալներ տեղի են ունենում սերվերում, որտեղ բրաուզերը չի տեսնում դրանք։ Network-ում 500 սխալը դրա դասական նշանն է։ Սերվերի լոգերը՝ backend-ի տեքստային արտածումը, երբ այն աշխատում է, սովորաբար պարունակում են իրական սխալը stack trace-ով (ցուցակ այն ֆունկցիաների, որոնք աշխատում էին, երբ խափանվեց)։

Դրանց գտնելու տեղը կախված է գործիքից։ Շատ AI հավելվածների կառուցիչներում կարող եք բացել տերմինալ կամ լոգերի տեսք նախագծի համար, կամ պարզապես հարցնել AI-ին. «Ստուգիր սերվերի լոգերը վերջին հարցման սխալների համար և ասա, թե ինչն է ձախողվել»։

Քայլ 5. Նկարագրեք սխալը AI-ին

Դրանից հավաքածը դրեք այս ձևի մեջ.

Ամրագրումների էջում՝ մուտք գործած որպես անդամ. սեղմեցի Cancel վաղվա 9:00 դասի վրա։ Սպասում էի՝ ամրագրումը կանհետանա, իսկ դասը մեկ ազատ տեղ կունենա։ Իրականում՝ էկրանին ոչինչ չփոխվեց։ Կոնսոլը ցույց է տալիս TypeError: Cannot read properties of undefined (reading 'id') BookingCard.tsx:31-ում, իսկ network ներդիրը ցույց է տալիս, որ DELETE /api/bookings/123-ը վերադարձրեց 500։ Գտիր պատճառը, շտկիր և ստուգիր, որ չեղարկումը աշխատում է անդամի համար մեկ ամրագրումով և մի քանիսով։

Ինչու յուրաքանչյուր մաս կարևոր է.

• Որտեղ և որպես ով նեղացնում է այն մեկ էկրանի և մեկ դերի։
• Ճշգրիտ քայլերը թույլ են տալիս AI-ին վերարտադրել այն։
• Ակնկալվող և իրական սահմանում են, թե ինչ է նշանակում «շտկված»։
• Սխալի տեքստը և ձախողված հարցումը ուղղակիորեն ցույց են տալիս պատճառը։
• «Ստուգիր, որ…» AI-ին խնդրում է ստուգել, ոչ միայն խմբագրել։

Եթե AI-ը երկու անգամ փորձել է շտկել և ձախողվել, խնդրեք բացատրել, նախքան որևէ բան փոխելը.

Առայժմ կոդ մի փոխիր։ Ինչ կարծիքի ես, ինչն է առաջացնում այս խնդիրը, և ինչ ապացույցներ են դա հաստատում։

Առանց սխալ տեսության գրված՝ հեշտ է նկատել, և շատ ավելի էժան է ուղղել, քան սխալ շտկումը։

Քայլ 6. Ստուգեք, ապա նայեք մոտակա բաներին

Երբ AI-ն ասում է, որ շտկված է, կրկնեք Քայլ 1-ի ճշգրիտ քայլերը։ Հետո ստուգեք շրջապատը.

• Նույն գործողությունը մեկ այլ օգտատիրոջ դերով
• Նույն գործողությունը առանց տվյալների և շատ տվյալներով
• Էջեր, որոնք կիսում են շտկված հատվածի բաղադրիչները
• Հեռախոսի լայնությամբ էկրան, եթե շտկումը դիպել է դասավորությանը

AI-ի փոփոխությունները երբեմն շտկում են մեկ ուղին և անհետևողական կերպով կոտրում մյուսը։ Երկու րոպեանոց ստուգումը հիմա խնայում է շփոթված մեկ ժամ հետո։

Քայլ 7. Վերադարձեք, այլ ոչ թե շերտավորեք

Եթե շտկումը վատացրեց իրավիճակը, կամ երեք փուլ անցել է առանց առաջընթացի, հետ վերադարձեք։ Վերադառնալը վերջին աշխատող տարբերակին և պատճառների ավելի լավ ապացույցներով վերաձևակերպելը գրեթե միշտ ավելի լավ է, քան չորրորդ շտկում պահանջելը երեք սխալ շտկումների վրա։ Յուրաքանչյուր անհաջող փորձ թողնում է կոդ, և այդ կոդը շփոթեցնում է հաջորդ փորձը։

Հետ վերադառնալը հեշտացնող լավ սովորություններ.

• Փորձարկեք յուրաքանչյուր փոփոխությունից հետո, որ իմանաք, թե որ փոփոխությունն է կոտրել բաները։
• Պահեք փոքր փոփոխություններ — մեկ գործառույթ կամ շտկում մեկ հաղորդագրության մեջ։
• Նշեք վերջին լավ տարբերակը նախքան ռիսկային բան սկսելը։
• Եթե կոդը Git-ում է, պահեք աշխատող տարբերակները, որ կարողանաք վերադառնալ դրանց։

Սովորական սխալների օրինաչափություններ AI-ով կառուցված հավելվածներում

Երբ խնդիրը սխալ չէ

Որոշ «սխալներ» այն են, որ AI-ը ճիշտ այն է կառուցում, ինչ ասված էր, և նկարագրությունը անորոշ էր։ Եթե շտկումը, որ խնդրում եք, իրականում վարքագծի փոփոխություն է, ասեք հստակ. «Փոխիր այնպես, որ…»։ Եթե անորոշ եք, թե ճիշտ վարքագիծը ինչ է, առաջին հերթին որոշեք դա։ Մեր ուղեցույցը հրահանգներ գրելու մասին AI հավելվածների կառուցիչների համար ցույց է տալիս, թե ինչպես հստակ նշել կանոնները։ Իսկ եթե իրական օգտատերերի համար հավելված եք պատրաստում, AI նախատիպը արտադրություն տանելու ուղեցույցը ներառում է թողարկումից առաջ արժեքավոր ստուգումները։

Վրիպազերծում Mythex-ում

Mythex-ն ունի գործիքներ ցիկլի յուրաքանչյուր քայլի համար.

• Նախադիտում սխալը վերարտադրելու համար, ներառյալ հեռախոսի չափի շրջանակը։
• /test-ը գործակալին թույլ է տալիս կտտացնել ձեր կենդանի նախադիտումը օգտատիրոջ պես և հաղորդել կոտրված հոսքերի մասին։
• /fix-ը գործակալին ուղղում է կոնկրետ խզումների վրա։
• Plan ռեժիմը թույլ է տալիս գործակալին հետաքննել և բացատրել, նախքան որևէ բան խմբագրելը։
• Code → terminal ցույց է տալիս ձեր հավելվածի սերվերի լոգերը։
• Revert to this point-ը ցանկացած պատասխանի վրա վերադարձնում է նախագիծը այդ checkpoint-ին։

Եթե հրապարակումը ձախողվում է, հրապարակման երկխոսությունը սովորաբար առաջարկում է Fix with AI, որը կարդում է կառուցման ելքը կամ հավելվածի լոգերը։ Տե՛ս docs-ի Debug your app և Publish troubleshooting բաժինները։

Հարցեր