Мобильная версия сайта после вайбкодинга: что проверить до публикации

Когда ИИ-агент вносит правки в сайт, первое, что ломается незаметно — мобильная версия. Десктоп выглядит красиво, а на телефоне кнопка уходит за экран или текст накладывается на изображение. В этой статье — конкретный чек-лист: что проверить в мобильной версии до того, как нажать «опубликовать», каким инструментом пользоваться и где чаще всего прячутся ошибки после вайбкодинга.

Почему мобильная верстка ломается после правок ИИ-агента?

Вайбкодинг ускоряет разработку, но ИИ видит код, а не экраны реальных пользователей. Агент может переписать CSS-блок так, что на 1920 пикселях всё идеально, а на 390 пикселях iPhone кнопка «Заказать» уходит под нижний край или перекрывается меню. Проблема не в том, что ИИ плохо работает, — он просто не тестирует результат на физическом устройстве.

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

Чем проверить адаптивность без реального телефона?

Быстрый старт — DevTools в браузере. В Chrome нажмите F12, затем Ctrl+Shift+M, и вы увидите страницу в режиме мобильного экрана. Можно выбрать конкретное устройство из списка: iPhone SE, Samsung Galaxy S23, iPad. Это не замена реальному тесту, но позволяет поймать грубые ошибки за три минуты.

Дальше — Google PageSpeed Insights и Google Search Console. В Search Console есть раздел «Удобство для мобильных»: он покажет страницы, на которых роботы Google зафиксировали проблемы. Это ценно, потому что Search Console проверяет ваш сайт так, как его видит поисковик, а не как вы его видите у себя на мониторе.

Для более детальной проверки подойдёт сервис BrowserStack или Responsively App. BrowserStack запускает страницу на реальных устройствах в облаке — можно кликать, листать, вводить текст. Responsively — бесплатный десктопный инструмент, который показывает сайт сразу на нескольких разрешениях одновременно.

Что именно проверять на мобильном экране?

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

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

Дальше — формы. Поле ввода на телефоне должно автоматически вызывать клавиатуру правильного типа: для email — с символом @, для телефона — цифровую. Если ИИ менял атрибуты полей, тип клавиатуры мог сбиться. Кнопка отправки должна быть достаточно большой — минимум 44×44 пикселя по рекомендации Apple.

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

Как проверить на реальных телефонах без больших затрат?

Самый дешёвый способ — попросить кого-то из знакомых открыть сайт на своём телефоне с другой ОС. Если вы разрабатываете на ноутбуке с iPhone под рукой, попросите коллегу с Android, и наоборот. Разные версии браузеров на iOS и Android ведут себя по-разному, особенно в части CSS-grid и flexbox.

Если нужно проверить конкретный сценарий — например, заполнение формы заказа или оплату — делайте это на реальном устройстве, а не в эмуляторе. Прокрутка, тап, свайп в DevTools ведут себя иначе, чем настоящие пальцы на стекле.

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

Типичные ошибки мобильной версии после вайбкодинга

• Фиксированная ширина блока в пикселях — ИИ скопировал десктопные стили, не добавив медиазапрос.
• Текст выходит за границу контейнера — чаще всего длинные слова без переноса или заголовок в одну строку с большим шрифтом.
• Кнопки слишком маленькие или расположены вплотную друг к другу — попасть пальцем сложно, пользователь уходит.
• Изображения не масштабируются — агент убрал max-width: 100% или заменил его фиксированным размером.
• Всплывающие окна (pop-up, модалки) перекрывают весь экран без кнопки закрытия — на мобильном это критично.
• Горизонтальный скролл на странице — один из элементов шире viewport, что Google считает ошибкой удобства для мобильных.

Что делать, если ошибок много?

Если после проверки выяснилось, что мобильная версия сломана в нескольких местах, не стоит пускать ИИ-агент переделывать всё заново без чёткого задания. Сначала составьте список конкретных проблем: «на странице /услуги кнопка уходит за правый край на устройствах шириной до 400px». Чем точнее задание, тем меньше агент сломает по пути к исправлению.

Хорошая практика — фиксировать скриншоты с указанием устройства и размера экрана. Это и для агента полезно, и для себя: когда правок накопилось много, легко потерять понимание, что было и что стало. Если сайт написан на PHP или другом серверном языке, дополнительно проверьте безопасность после правок: как защитить PHP-проект после вайбкодинга от уязвимостей.