Як налагодити застосунок, створений ШІ: практичний метод

Щоб налагодити застосунок, створений за допомогою ШІ, спершу відтворіть помилку навмисно, потім зберіть докази — точні кроки, текст повідомлення про помилку і те, що показують консоль браузера та вкладка мережі, — і передайте їх ШІ у форматі «я зробив X, очікував Y, отримав Z». Якщо виправлення погіршує ситуацію, відкотіться до останньої робочої версії замість того, щоб накладати виправлення одне на одне. Щоб робити це добре, не обов'язково читати код.

Цей гід охоплює весь цикл, зокрема короткий огляд інструментів розробника браузера для непрограмістів.

Цикл налагодження

Кожне виправлення помилки, незалежно від того, хто його робить — людина чи ШІ, — проходить той самий цикл:

1. Відтворити — зробити так, щоб помилка стабільно виникала.
2. Спостерігати — зібрати повідомлення про помилку і те, що робив застосунок.
3. Описати — дати ШІ точні кроки, очікуваний результат і фактичний результат.
4. Виправити — дозволити ШІ змінити одну річ.
5. Перевірити — повторити ті самі кроки і переконатися, що помилку усунено й сусідні функції не зламалися.
6. Відкотитися за потреби — якщо стало гірше, скасуйте зміну і спробуйте знову з кращою інформацією.

Більшість часу, витраченого на застосунки, створені ШІ, йде на пропущені кроки 1, 2 і 5: казати «воно зламалося», приймати зміну без перевірки, а потім просити ще одне виправлення поверх зламаного.

Крок 1: Відтворіть помилку

Помилку, яку можна викликати на вимогу, вже наполовину виправлено. Спробуйте знайти найкоротший набір кроків, що її викликає.

Запитайте себе:

• Чи відбувається це щоразу? Якщо лише інколи, що відрізняється, коли це стається, — певний запис, повільне з'єднання, вихід з акаунта?
• Чи відбувається це для кожного користувача? Увійдіть під іншим акаунтом. Багато помилок видно лише новим користувачам без даних або користувачам з іншою роллю.
• Чи відбувається це на кожному пристрої? Спробуйте екран шириною з телефон і інший браузер.
• Чи почалося це після конкретної зміни? Якщо це працювало вчора, останні кілька змін — головні підозрювані.

Запишіть кроки у вигляді короткого нумерованого списку. Пізніше ви вставите його в промпт.

Крок 2: Прочитайте повідомлення про помилку

Повідомлення про помилки лякають, але вам потрібні лише кілька частин.

Не обов'язково розуміти її; потрібно точно скопіювати. «Cannot read properties of undefined (reading 'name')» каже ШІ, що код очікував дані (імовірно, бронювання або користувача), яких не було. Переказ на кшталт «якась помилка 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» дуже корисне для ШІ.

Увімкніть Preserve log, якщо помилка пов'язана з перезавантаженням сторінки або перенаправленням, щоб запити не зникали.

Elements

Вкладка Elements (або Inspector) показує структуру сторінки і стилі. Вона найкорисніша для помилок розмітки: наведіть курсор на елемент, щоб побачити його розмір і відступи. Редагувати тут нічого не потрібно; достатньо сказати: «підвал має ширину 2 000 пікселів на мобільному і зсуває сторінку вбік».

Крок 4: Перевірте серверні логи

Деякі помилки виникають на сервері, куди браузер не бачить. Класична ознака — помилка 500 у вкладці мережі. Серверні логи — текстовий вивід вашого бекенда під час роботи — зазвичай містять справжню помилку зі стеком викликів (список функцій, які працювали, коли все впало).

Що саме і де шукати, залежить від інструмента. У більшості конструкторів застосунків на основі ШІ можна відкрити термінал або перегляд логів проєкту, або просто попросити ШІ: «Перевір серверні логи на помилки від останнього запиту і скажи, що не спрацювало».

Крок 5: Опишіть помилку ШІ

Складіть зібрані дані в таку форму:

На сторінці бронювань, увійшовши як учасник: я натиснув Cancel на заняття о 9:00 завтра. Очікував: бронювання зникає, а на занятті стає на одне вільне місце більше. Фактично: на екрані нічого не змінилося. Консоль показує TypeError: Cannot read properties of undefined (reading 'id') у BookingCard.tsx:31, а вкладка мережі показує, що DELETE /api/bookings/123 повернув 500. Знайди причину, виправ її і перевір, що скасування працює для учасника з одним бронюванням і з кількома.

Чому важлива кожна частина:

• Де і під яким користувачем звужує пошук до одного екрана і однієї ролі.
• Точні кроки дозволяють ШІ відтворити помилку.
• Очікуване і фактичне визначає, що означає «виправлено».
• Текст помилки і невдалий запит вказують прямо на причину.
• «Перевір, що…» просить ШІ не лише редагувати, а й перевірити.

Якщо ШІ двічі спробував виправити й не вийшло, попросіть його пояснити, перш ніж щось змінювати:

Поки не змінюй код. Що, на твою думку, спричиняє цю помилку і які докази це підтверджують?

Хибну гіпотезу легко помітити, коли її записано, і її набагато дешевше виправити, ніж хибне виправлення.

Крок 6: Перевірте й подивіться на сусідні частини

Коли ШІ каже, що все виправлено, повторіть точні кроки з кроку 1. Потім перевірте речі навколо:

• Ту саму дію для іншої ролі користувача
• Ту саму дію без даних і з великою кількістю даних
• Сторінки, що використовують ті самі компоненти, що й виправлена
• Екран шириною з телефон, якщо виправлення торкнулося розмітки

Зміни ШІ іноді виправляють один шлях і тихо ламають інший. Двохвилинна перевірка зараз заощадить годину розгубленості потім.

Крок 7: Відкотіться, а не накопичуйте

Якщо виправлення погіршило справи або ви втретє пройшли кола без прогресу, поверніться назад. Відкат до останньої робочої версії та переформулювання з кращими доказами майже завжди краще, ніж просити четверте виправлення поверх трьох хибних. Кожна невдала спроба залишає код, який заплутує наступну.

Корисні звички, що роблять відкат простим:

• Тестуйте після кожної зміни, щоб знати, яка саме зміна щось зламала.
• Тримайте зміни невеликими — одна функція або одне виправлення в повідомленні.
• Запам'ятовуйте останню робочу версію перед ризикованою дією.
• Якщо код у Git, робіть коміти робочих версій, щоб можна було до них повернутися.

Типові шаблони помилок у застосунках, створених ШІ

Коли проблема не в помилці

Деякі «помилки» — це ШІ зробив саме те, що йому сказали, а опис був неоднозначним. Якщо виправлення, яке ви просите, насправді означає зміну поведінки, скажіть це прямо: «Зміни так, щоб…». Якщо ви не впевнені, яка поведінка правильна, спершу вирішіть це. Наш гід з написання промптів для конструкторів застосунків на основі ШІ розповідає, як чітко задавати правила. А якщо ви готуєте застосунок для реальних користувачів, як перевести прототип ШІ у продакшен описує перевірки, які варто зробити перед запуском.

Налагодження в Mythex

У Mythex є інструменти для кожного кроку циклу:

• Прев'ю, щоб відтворити помилку, зокрема з рамкою розміром з телефон.
• /test: агент проходить ваше живе прев'ю, як користувач, і звітує про зламані сценарії.
• /fix спрямовує агента саме на поламане.
• Режим Plan дозволяє агенту дослідити ситуацію і пояснити її, перш ніж щось редагувати.
• Code → terminal показує серверні логи вашого застосунку.
• Revert to this point для будь-якої відповіді відкочує проєкт до цієї контрольної точки.

Якщо публікація не вдалася, у діалозі публікації зазвичай є кнопка Fix with AI, яка читає вивід збірки або логи застосунку. Див. Debug your app і Publish troubleshooting у документації.

Запитання