Lovable или Bolt застрял в цикле исправления багов? Как довести MVP до конца

Вы просите конструктор починить вход. Вход работает, но дашборд теперь пустой. Следующий промпт возвращает дашборд и снова ломает вход. Если Lovable или Bolt раз за разом чинит одни и те же баги, полезный следующий шаг — собрать больше фактов об одном конкретном сбое. Больше изменений — не значит больше прогресса.

Почему ИИ-приложение застревает в цикле исправлений?

Цикл исправлений возникает, когда изменения устраняют видимый симптом, а исходную причину никто не установил и не проверил. Один и тот же экран могут вызвать несколько разных неисправностей, поэтому общий запрос даёт конструктору слишком много правдоподобных вариантов того, что можно поменять.

Пустой дашборд может означать неудачный запрос, политику доступа, не ту базу данных или действительно отсутствующие данные. Изменение компонента может скрыть сообщение, а неудачный запрос так и останется неудачным. Ваша цель — определить, на какой границе произошёл сбой: в браузере, на сервере, у провайдера аутентификации, в базе данных или во внешней интеграции.

Задайте себе практическое правило остановки: если тот же симптом возвращается после сфокусированной попытки исправления, перестаньте повторять промпт и соберите доказательства другого рода. Это рабочая привычка, а не задокументированное ограничение платформы. Она защищает небольшой проект от накопления несвязанных изменений, пока никто не может объяснить, что именно ломается.

Сломан предпросмотр в конструкторе или ваше приложение?

Прежде чем переписывать код, проверьте окружение конструктора отдельно от приложения. Инцидент на платформе или проблема с подключением предпросмотра — не доказательство того, что архитектуру продукта нужно менять.

Актуальное руководство Bolt по проблемам с предпросмотром рекомендует проверить статус сервиса, собрать ошибки из консоли браузера, попробовать продакшен-сборку и проверить, не отсутствуют ли переменные окружения. Там также объясняется, что повторная отправка одного и того же промпта на починку предпросмотра вряд ли поможет после первой неудачной попытки.

Используйте эту таблицу, чтобы выбрать следующее направление проверки, а не чтобы ставить диагноз. Неудачный сетевой запрос всё равно может быть вызван кодом приложения, а у пустого экрана бывает несколько причин. Зафиксируйте первую содержательную ошибку, пока её не похоронили последующие сбои.

Что сохранить перед следующей попыткой исправления?

Сохраните последнее полезное состояние кода и определите, какие данные может затронуть исправление. История кода и резервные копии базы данных решают разные задачи восстановления.

Документация Lovable по истории версий описывает предпросмотр, добавление в закладки и откат версий кода. В ней прямо сказано, что откат кода не откатывает данные в базе. Прежде чем восстанавливать версию, проверьте, не изменила ли последующая работа записи, права доступа или схему, на которую рассчитывает старый код.

1. Обозначьте последнее состояние, в котором основной сценарий работал, — с отметкой времени или идентификатором коммита.
2. Зафиксируйте текущий сбой и сохраните полезную незакоммиченную работу через поддерживаемый в вашем проекте процесс.
3. Перед работой, которая меняет данные или схему, создайте подходящую резервную копию базы или безопасную тестовую копию.
4. Запишите, в каком проекте и окружении находятся живые пользователи, чтобы тестировать исправление в стороне от них.

Как выглядит полезный промпт на исправление?

Полезный промпт на исправление называет один воспроизводимый сбой, содержит относящиеся к нему доказательства и ограничивает предлагаемое изменение. Попросите объяснить причину, прежде чем разрешать реализацию, которую вы не можете оценить.

Investigate one issue: a signed-in customer cannot save a booking.
Steps: create a fresh customer account, open /bookings/new, choose a date, and select Save.
Expected: one booking is saved and appears after refresh.
Actual: the request returns 403 and no booking is saved.
Evidence: [sanitized error, request path, and timestamp].
First explain the likely cause and the files or policies involved.
Do not change roles, remove access checks, redesign screens, or rewrite unrelated features.
Propose the smallest fix and how to test it with two ordinary accounts.

Этот пример гипотетический. Замените детали тем, что вы действительно наблюдали. Ответ 403 — подсказка о сбое доступа, а не разрешение убрать авторизацию. Не включайте в промпты и скриншоты пароли, токены, строки подключения и записи клиентов.

Для проектов на Lovable руководство по логам бэкенда объясняет, как просматривать запросы и ошибки в сервисах, доступных вашему проекту. Сопоставляйте ошибку со временем действия и окружением. Одна относящаяся к делу запись без конфиденциальных данных полезнее, чем большой неотфильтрованный дамп логов.

Как понять, что исправление действительно сработало?

Исправление работает, когда исходные шаги дают ожидаемый результат, а важные соседние сценарии по-прежнему ведут себя правильно. Проверяйте сохранённое состояние после обновления страницы, а не только временное сообщение об успехе.

1. Повторите исходный сбой с новым аккаунтом и теми же входными данными.
2. Обновите страницу или заново откройте приложение и убедитесь, что результат сохранён корректно.
3. Повторите со вторым обычным аккаунтом и проверьте, что границы владения данными соблюдаются так, как задумано.
4. В безопасном тестовом окружении попробуйте один сценарий сбоя — например, некорректный ввод или прерванный запрос.
5. Проверьте соседние сценарии, использующие изменённый код, затем запустите соответствующие проверки проекта и продакшен-сборку.

Когда стоит привлечь разработчика?

Привлекайте разработчика, когда не можете уверенно объяснить или проверить изменение в критическом сценарии или когда сфокусированное расследование так и не позволяет выделить причину. Особой осторожности требуют доступ к платежам, утечка данных между аккаунтами и повторяющиеся изменения базы данных.

Ограниченный по объёму аудит может ответить, в чём проблема: в конфигурации, в небольшом дефекте реализации или в более серьёзном изъяне архитектуры. Попросите диагноз, список файлов или сервисов, которые предлагается изменить, критерии приёмки и план отката. Такой аудит можно заказать до того, как соглашаться на переписывание.

Хорошая передача задачи включает URL приложения, доступ к проекту или репозиторию через поддерживаемый механизм, шаги воспроизведения, короткую запись экрана, ошибку без конфиденциальных данных и последнюю рабочую версию. Добавьте ближайшую веху для клиентов и функции, которые трогать нельзя. Передавайте учётные данные только через подходящий сервис для обмена секретами или процесс предоставления доступа к аккаунту.

Что должно войти в следующий релиз?

Следующий релиз должен закрыть небольшой измеримый набор сломанных сценариев. Держите запросы на новые функции отдельно, пока эти сценарии не будут проверены в опубликованном приложении.

После исправления воспользуйтесь планом запуска MVP из 12 проверок, чтобы найти смежные пробелы. Если приложение работает в предпросмотре, но ломается после публикации на Replit, используйте чек-лист деплоя на Replit. Если нужна практическая помощь, выберите отправную точку на странице Lovable или Bolt и запишитесь на звонок. Приходите со сбойным сценарием: первый разговор должен помочь определить полезный следующий шаг.