Почему AI-сайт работает на компьютере разработчика, но ломается у клиентов

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

Переменные окружения и секреты

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

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

Разработка и production собираются по-разному

Dev-сервер автоматически подставляет маршруты, показывает подробные ошибки и терпит особенности регистра имён файлов. Рабочая сборка оптимизирует код и запускается на другой операционной системе. Импорт `Header` может работать рядом с файлом `header`, а на сервере перестать.

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

Прямые ссылки возвращают 404

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

Проверьте не только главную, а прямое открытие каждой разновидности URL, редиректы и поведение после входа и выхода.

API, CORS и сеть

• Рабочий домен отсутствует в разрешённых источниках API.
• HTTPS-страница обращается к HTTP-ресурсу.
• Cookie имеет неверные SameSite, Secure или Domain.
• Запрос зависит от локального прокси разработчика.
• Сторонний сервис недоступен в регионе клиента.
• Медленная сеть выявляет таймаут и повторную отправку.

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

Реальные данные отличаются от тестовых

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

Особенно опасны даты, часовые пояса, десятичные разделители и кодировки. Тесты должны включать разные локали и границы диапазонов.

Браузеры, устройства и кеш

Новая функция может отсутствовать в старом браузере, наведение мыши — не работать на телефоне, а экранная клавиатура — закрывать кнопку. Старый service worker иногда продолжает раздавать несовместимую версию после релиза.

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

Как диагностировать системно.

1. Получить точный URL, время, устройство и шаги.
2. Найти запрос по идентификатору в журналах.
3. Воспроизвести в чистом профиле и медленной сети.
4. Сравнить переменные и версии окружений.
5. Добавить тест, который воспроизводит ошибку.
6. Исправить причину и проверить соседние сценарии.

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

AI ускоряет анализ логов и подготовку теста, но не заменяет доказательство причины. Случайная серия правок способна скрыть симптом и создать новую несовместимость.

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