Како да дебагирате апликација направена со 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: Користете ги алатките за програмери во прелистувачот

Секој десктоп прелистувач има вградени алатки за програмери („devtools“). Тие покажуваат што прави страницата зад сцената. Во Chrome, Edge и Firefox, кликнете десно каде било на страницата и изберете Inspect, или притиснете F12 (Cmd+Option+I на Mac). Во Safari, прво вклучете го менито Develop во поставките на Safari.

Треба да ви се три табови.

Console

Табот Console ги наведува грешките и пораките од кодот на страницата. Грешките се прикажуваат црвено. Ако копче не прави ништо кога ќе кликнете на него, конзолата многу често покажува црвена грешка во моментот на кликнувањето. Копирајте го целиот текст на грешката (во повеќето прелистувачи кликнете десно за опција за копирање).

Network

Табот Network ги наведува сите барања што страницата ги прави — вчитување податоци, зачувување формулар, најава. Отворете го, па повторете ги чекорите што ја предизвикуваат грешката.

• Барајте редови во црвено или со статус 400 или повисок.
• Кликнете на неуспешен ред за да го видите неговиот Response. Серверската грешка често содржи порака таму што е покорисна од сè на екранот.
• Запишете ја URL адресата и статус кодот на барањето — „POST до /api/bookings врати 500“ е многу корисна реченица за AI.

Означете Preserve log ако грешката вклучува презимување на страницата или пренасочување, за барањата да не исчезнат.

Elements

Табот Elements (или Inspector) ја покажува структурата и стиловите на страницата. Најкорисен е за грешки во распоредот: задржете глушецот над елемент за да видите истакнати димензии и размаци. Не треба да уредувате ништо тука; доволно е да кажете „футерот е 2.000 пиксели широк на мобилен и ја турка страницата настрана“.

Чекор 4: Проверете ги серверските дневници

Некои грешки се случуваат на серверот, каде прелистувачот не може да ги види. Грешката 500 во мрежниот таб е класичен знак. Серверските дневници — текстуалниот излез на вашиот бекенд додека работи — обично ја содржат вистинската грешка со stack trace (список на функции што работеле кога се урнало).

Каде ги наоѓате зависи од алатката. Во повеќето градители на апликации можете да отворите терминал или приказ на дневници за проектот, или едноставно да го прашате AI: „Проверете ги серверските дневници за грешки од последното барање и кажете ми што не успеало.“

Чекор 5: Опишете ја грешката на AI

Ставете го она што го собравте во оваа форма:

На страницата Bookings, најавен како член: кликнав Cancel на утрешниот час од 9:00. Очекувано: резервацијата исчезнува и часот покажува едно слободно место повеќе. Вистински: на екран нема промена. Конзолата покажува TypeError: Cannot read properties of undefined (reading 'id') на BookingCard.tsx:31, а мрежниот таб покажува дека DELETE /api/bookings/123 врати 500. Најди ја причината, поправи ја и провери дека откажувањето функционира за член со една резервација и за член со повеќе.

Зошто секој дел е важен:

• Каде и како кој го стеснува на еден екран и една улога.
• Точните чекори му овозможуваат на AI да ја репродуцира.
• Очекувано наспроти вистинско го дефинира значењето на „поправено“.
• Текстот на грешката и неуспешното барање укажуваат директно на причината.
• „Провери дека…“ го бара од AI да верифицира, не само да уредува.

Ако AI два пати се обидел да поправи и не успеал, замолете го да објасни пред да менува нешто:

Не менувај код уште. Што мислиш дека ја предизвикува оваа грешка и какви докази ја поддржуваат таа претпоставка?

Погрешна теорија лесно се забележува кога е напишана, и многу поевтино е да се исправи отколку погрешна поправка.

Чекор 6: Верифицирајте, па проверете ги соседните работи

Кога AI вели дека е поправено, повторете ги точните чекори од Чекор 1. Потоа проверете ги работите околу неа:

• Истата акција за друга корисничка улога
• Истата акција без податоци и со многу податоци
• Страници што ги делат компонентите со оној што го поправивте
• Екран со ширина на телефон, ако поправката го допре распоредот

Промените на AI понекогаш поправаат една патека и тивко расипуваат друга. Двеминутна проверка сега штеди збунет час подоцна.

Чекор 7: Вратете се наназад наместо да ставате уште

Ако поправката влошила нешто, или сте поминале три рунди без напредок, вратете се. Враќањето на последната работна верзија и преформулирањето со подобри докази скоро секогаш е подобро од барање четврта поправка врз три погрешни. Секој неуспешен обид остава код зад себе, и тој код ја збунува следната обид.

Добри навики што го прават враќањето лесно:

• Тестирајте по секоја промена, за да знаете која промена расипала нешто.
• Држете ги промените мали — една функција или поправка по порака.
• Забележете ја последната добра верзија пред нешто ризично.
• Ако кодот е во Git, комитирајте ги работните верзии за да се вратите на нив.

Вообичаени обрасци на грешки кај апликации направени со AI

Кога проблемот не е грешка

Некои „грешки“ се AI што го прави точно она што му било кажано, а описот бил двосмислен. Ако поправката што ја бараш всушност е промена на однесувањето, кажи го јасно: „Промени го така што…“. Ако сте неизвесни какво е точното однесување, прво одлучете го тоа. Нашиот водич за пишување промпти за AI градители на апликации опфаќа како јасно да се специфицираат правилата. А ако подготвувате апликација за вистински корисници, однесување на AI прототип во продукција ги опфаќа проверките што вреди да се направат пред лансирање.

Дебагирање во Mythex

Mythex има алатки за секој чекор од циклусот:

• Preview за репродукција на грешката, вклучително и рамка со големина на телефон.
• /test го натера агентот да кликне низ вашиот жив преглед како корисник и да пријави расипани текови.
• /fix го насочува агентот конкретно кон расипаното.
• Plan режимот му дозволува на агентот да истражи и објасни пред да уредува нешто.
• Code → terminal ги покажува серверските дневници на вашата апликација.
• Revert to this point на секој одговор ја враќа проектот на таа контролна точка.

Ако објавувањето не успее, дијалогот за објавување обично нуди Fix with AI, кој ги чита излезот од build-от или дневниците на апликацијата. Видете Debug your app и Publish troubleshooting во документацијата.

Прашања