Как отладить приложение, созданное с ИИ: практический метод

Чтобы отладить приложение, созданное с ИИ, сначала заново вызовите ошибку намеренно, затем соберите доказательства — точные шаги, текст ошибки и то, что показывают консоль браузера и вкладка сети, — и передайте это ИИ в формате «я сделал 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: используйте инструменты разработчика браузера

В каждом настольном браузере есть встроенные инструменты разработчика (developer tools, «devtools»). Они показывают, что страница делает за кулисами. В Chrome, Edge и Firefox щёлкните правой кнопкой в любом месте страницы и выберите Inspect («Просмотреть код»), или нажмите F12 (Cmd+Option+I на Mac). В Safari сначала включите меню «Разработка» в настройках Safari.

Нужны всего три вкладки.

Console

Вкладка Console показывает ошибки и сообщения из кода страницы. Ошибки выделяются красным. Если кнопка ничего не делает при нажатии, в консоли очень часто появляется красная ошибка в момент клика. Скопируйте полный текст ошибки (в большинстве браузеров для этого есть пункт в контекстном меню).

Network

Вкладка Network показывает каждый запрос, который делает страница: загрузка данных, сохранение формы, вход. Откройте её и повторите шаги, которые вызывают ошибку.

• Ищите строки красного цвета или со статусом 400 и выше.
• Щёлкните по упавшей строке и посмотрите Response. Там часто есть сообщение об ошибке сервера, полезнее всего, что видно на экране.
• Запомните URL запроса и код статуса — фраза «POST на /api/bookings вернул 500» очень полезна для ИИ.

Включите Preserve log, если ошибка связана с перезагрузкой страницы или редиректом, чтобы запросы не исчезали.

Elements

Вкладка Elements (или Inspector) показывает структуру страницы и стили. Она особенно полезна для ошибок вёрстки: наведите на элемент, и вы увидите его размер и выделенные отступы. Ничего редактировать не нужно; достаточно сказать: «футер шириной 2000 пикселей на мобильном и сдвигает страницу в сторону».

Шаг 4: проверьте серверные логи

Некоторые ошибки происходят на сервере, где браузер их не видит. Ошибка 500 во вкладке сети — классический признак. Серверные логи — это текстовый вывод вашего бэкенда во время работы — обычно содержат настоящую ошибку со стеком вызовов (списком функций, которые работали, когда произошёл сбой).

Где их найти, зависит от инструмента. В большинстве ИИ-конструкторов можно открыть терминал или просмотр логов проекта, либо просто спросить ИИ: «Проверь серверные логи на ошибки последнего запроса и скажи, что упало».

Шаг 5: опишите ошибку ИИ

Соберите всё в такой вид:

На странице «Записи», вошедший как участник: я нажал Отменить на занятие в 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 в документации.

Вопросы