Как да отстраните грешки в приложение, създадено с 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) показва структурата и стиловете на страницата. Най-полезен е за грешки в оформлението: задръжте курсора върху елемент, за да видите очертания му размер и разстояния. Тук не е нужно да редактирате нищо; достатъчно е да кажете „футърът е 2000 пиксела широк на мобилно и избутва страницата встрани“.

Стъпка 4: Проверете сървърните логове

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

Къде ги намирате, зависи от инструмента. В повечето инструменти за създаване на приложения с AI можете да отворите терминал или изглед на логовете за проекта или просто да попитате AI: „Провери сървърните логове за грешки от последната заявка и кажи какво се е провалило.“

Стъпка 5: Опишете грешката на AI

Съберете каквото сте открили във видов формат:

В страницата Bookings, влязъл като член: кликнах 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 има инструменти за всяка стъпка от цикъла:

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

Ако публикуването се провали, диалогът за публикуване обикновено предлага Fix with AI, който чете изхода от билда или логовете на приложението. Вижте Отстраняване на грешки в приложението ви и Отстраняване на проблеми при публикуване в документацията.

Въпроси