Промпт для адаптива мобильной версии через AI за один запрос

Мобильную версию чинит один промпт, если в нем есть четыре вещи: проверка meta viewport, поиск горизонтального overflow, набор конкретных breakpoints и правило tap targets от 44px. Такой запрос заставляет нейросеть провести полный аудит адаптивной верстки и вернуть готовые правки по файлам, а не общий совет «сделай отзывчиво». Ниже -> сам промпт, разбор каждого блока и как проверить результат на реальном экране 360 пикселей.

Готовый промпт для адаптива мобильной версии проверяет meta viewport, horizontal overflow, breakpoints и tap targets (минимум 44px по Apple HIG). Один запрос в Cursor или Claude Code -> полный аудит мобильной верстки плюс диф с правками. В статье: сам промпт, таблица брейкпоинтов, стандарты размера кнопок и способ проверки через Playwright MCP.

 Данные по стандартам tap targets и breakpoints актуальны на этот месяц.

Почему AI ломает мобильную версию верстки?

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

Проблема почти всегда не в модели, а в запросе. AI генерит нормальную десктоп-раскладку, а на фразу «сделай адаптивным» отвечает парой медиазапросов наугад. Результат: горизонтальный скролл, кнопки в 20px и текст, который не читается. Точный промпт с брейкпоинтами и размерами убирает 80% этих косяков за один проход.

Разработчики каналов про Cursor формулируют это прямо: вместо «сделай адаптивным» надо просить конкретный макет, например «bento-сетка, которая схлопывается в одну колонку на мобильных». Расплывчатый запрос -> расплывчатый CSS.

Модель не видит твой телефон. Она достраивает мобильную версию из общих паттернов, а твои фиксированные width: 1200px и абсолютное позиционирование в паттерны не входят. Поэтому промпт для адаптива работает не как «магия», а как чек-лист, который ты передаешь исполнителю. Чем точнее чек-лист, тем меньше итераций.

Что должен проверять промпт для адаптива мобильной версии?

Рабочий промпт закрывает четыре зоны: viewport, overflow, breakpoints и tap targets. Пропустишь одну -> получишь либо скролл вбок, либо непопадаемые кнопки.

Мобильная версия ломается в четырех местах, и все четыре легко проверяются одним запросом. Тег viewport включает адаптив вообще. Overflow дает горизонтальный скролл. Breakpoints решают, где сетка схлопывается. Tap targets отвечают за то, попадет ли палец в кнопку. Зашей эти четыре блока в промпт -> и аудит станет системным, а не «на глаз».

Вот что проверяет каждый блок и почему он критичен:

Пятый блок про размер шрифта добавляю почти всегда. На мобильных iOS Safari зумит инпуты со шрифтом меньше 16px, и форма прыгает. Мелочь, а бесит пользователя.

Готовый промпт для адаптива, который можно скопировать

Промпт ниже проводит аудит по четырем блокам и возвращает диф с правками. Вставь фреймворк и файлы, отправь в Cursor или Claude Code, получи список изменений.

Промпт построен по схеме «роль -> контекст -> чек-лист -> формат ответа». Такая структура на порядок точнее общего запроса. Он не просит «улучшить мобилку», он требует пройтись по конкретным пунктам и вернуть код. Проверено на десятках лендингов: с этим промптом responsive-правки заходят с первого-второго раза вместо бесконечного пинг-понга.

Ты senior frontend-разработчик, специализация -> адаптивная верстка.

КОНТЕКСТ:
- Стек: [React + Tailwind / чистый HTML+CSS / Vue, укажи свой]
- Файлы верстки: [пути или "проанализируй всю папку src"]
- Целевые устройства: телефон от 360px, планшет 768px, десктоп от 1024px

ЗАДАЧА: проведи аудит мобильной версии и почини ее. Пройди строго по чек-листу.

1. VIEWPORT
   Проверь наличие <meta name="viewport" content="width=device-width, initial-scale=1">.
   Нет тега -> добавь.

2. HORIZONTAL OVERFLOW
   Найди все элементы, вызывающие скролл вбок на 360px:
   фиксированные width в px, картинки без max-width: 100%,
   длинные строки без переноса, отрицательные margin, min-width на контейнерах.
   Замени фиксированные ширины на относительные или max-width.

3. BREAKPOINTS
   Проверь медиазапросы. Сетка должна схлопываться:
   3 колонки -> 2 на планшете (768px) -> 1 на телефоне (480px и ниже).
   Flex и grid не должны выходить за экран. Добавь недостающие брейкпоинты.

4. TAP TARGETS
   Все кликабельные элементы (кнопки, ссылки-кнопки, иконки, поля):
   минимум 44x44px по Apple HIG. Между соседними целями отступ от 8px.
   Мелкие иконки увеличь за счет padding, не меняя визуальный размер.

5. ЧИТАБЕЛЬНОСТЬ
   Базовый шрифт от 16px (иначе iOS зумит инпуты).
   Проверь контраст и длину строки на узком экране.

ФОРМАТ ОТВЕТА:
- Сначала список найденных проблем по блокам.
- Затем готовый диф с правками по каждому файлу.
- Не трогай десктопную раскладку, правь только мобильные состояния.

Квадратные скобки замени своими данными. Если работаешь в Cursor или Claude Code, агент сам пройдет по файлам и внесет правки. Для одиночного лендинга хватит и обычного чата с моделью посильнее.

Как AI находит горизонтальный overflow на мобильной версии?

Horizontal overflow -> это когда элемент шире экрана и появляется скролл вбок. AI ищет фиксированные ширины, картинки без max-width и отрицательные отступы.

Горизонтальный скролл на телефоне -> симптом номер один сломанной адаптивной верстки. Причина почти всегда одна из пяти: width в пикселях больше вьюпорта, картинка без max-width: 100%, min-width на контейнере, длинное слово без переноса или отрицательный margin. Промпт заставляет AI перебрать эти пять причин, а не гадать. На экране 360px каждая из них дает ту самую полосу прокрутки.

Самый частый виновник -> картинки и эмбеды. Автор верстает под десктоп, ставит width: 800px на изображение, и на телефоне оно вылезает за край. Правило max-width: 100%; height: auto закрывает большинство случаев.

Второй по частоте -> таблицы и код-блоки. Их приходится заворачивать в контейнер с overflow-x: auto, чтобы скроллилась только таблица, а не вся страница. Это как раз тот нюанс, который нейросеть пропускает без прямого указания в промпте.

По факту overflow ловится за секунды: открой DevTools в режиме Device Mode, поставь 360px и посмотри, есть ли нижняя горизонтальная полоса. Если есть -> отдай скрин или описание AI, и он найдет источник.

Какие breakpoints задавать в промпте для адаптива?

Три-четыре брейкпоинта закрывают 95% устройств: 480px телефон, 768px планшет, 1024px десктоп, 1280px+ широкий экран. Больше -> редко нужно.

Не надо десять брейкпоинтов под каждую модель айфона. Рабочий минимум -> три точки, где раскладка реально меняется. Мобильный старт до 480px, планшет 768px, десктоп от 1024px. Внутри этих границ сетка схлопывается с трех колонок в одну. Указывай конкретные значения в промпте: AI разложит медиазапросы по ним, а не выдумает свои случайные 600px и 900px.

Подход mobile-first экономит время: базовые стили пишутся под телефон, а через min-width добавляются десктопные. Так меньше переопределений и чище CSS. В промпте достаточно дописать «используй mobile-first, медиазапросы через min-width», и модель Claude Sonnet 4.6 или Opus 4.8 разложит все аккуратно.

Одна честная оговорка. Если у тебя сложный дашборд с таблицами и графиками, тремя брейкпоинтами не обойдешься. Там появляются промежуточные состояния, и это нормально -> просто добавляешь их точечно, а не заранее.

Почему tap targets должны быть от 44 пикселей?

Палец накрывает 8–10 мм экрана, это примерно 44 пикселя. Кнопки меньше -> постоянные промахи. 44px это стандарт Apple, 48dp у Android, 24px минимум WCAG.

Размер кликабельной зоны -> не вкусовщина, а исследованная величина. Средний кончик пальца по данным лаборатории MIT Touch Lab -> 16–20 мм, и в мелкую кнопку он не попадает. Apple HIG требует 44 на 44 пункта, Google Material -> 48dp, а WCAG 2.2 задает юридический минимум 24 на 24 пикселя для уровня AA. Для веба безопасный ориентир -> 44px, он совпадает с усиленным уровнем WCAG 2.5.5.

Разберем стандарты, чтобы не путаться в цифрах:

Хитрость, которую стоит прописать в промпте: визуальный размер иконки и размер зоны клика -> разные вещи. Иконка может выглядеть на 24px, а тап-зона за счет padding расширяться до 48px. Так дизайн остается минималистичным, а палец попадает. Именно эту технику AI применяет, если ему прямо сказать «увеличь tap target через padding, не меняя визуальный размер».

Отдельно про отступы. Две кнопки по 44px, стоящие вплотную, все равно дают промахи. WCAG рекомендует зазор от 8px между соседними целями, а для опасных действий вроде «Удалить» -> от 16px. Это тоже пункт для промпта.

Как проверить результат промпта на реальном экране?

Проверяй на 360px в DevTools Device Mode. Для автопроверки подключи Playwright MCP -> AI сам откроет страницу, померит элементы и вернет отчет.

Аудит без проверки -> половина работы. Самый быстрый способ -> DevTools в режиме устройства на ширине 360px, где ловятся overflow и наложения. Продвинутый вариант -> Playwright MCP: нейросеть открывает страницу в браузере, меняет размер окна, проверяет tap targets и генерирует HTML-отчет со скриншотами. Так проверка мобильной версии идет без ручных кликов.

Playwright MCP -> это мост, через который модель управляет реальным браузером. По урокам с YouTube-каналов про Claude AI setup выглядит так: ставишь Node.js, добавляешь конфиг MCP-сервера в настройки Claude Desktop через File -> Settings -> Developer, перезапускаешь приложение. Дальше просишь: «открой страницу на 360px, найди горизонтальный скролл и кнопки меньше 44px, сделай скриншоты».

Лайфхак из тех же разборов: если AI не находит нужный элемент, добавь в промпт HTML-подсказку -> data-test-id, id или CSS-селектор. Точность распознавания сразу растет. И ставь разрешения аккуратно: «allow once» для незнакомого действия, «allow always» -> только когда уверен.

Ручная проверка все равно нужна. Открой сайт на своем телефоне, а не только в эмуляторе. Эмулятор не покажет, как ведет себя палец, инерция скролла и клавиатура, наезжающая на форму.

Цитата от Максима

Максим: «Веб-версию GoBanana я собрал за 3 часа после выхода модели. 6-8 часов на весь продукт, который принес 12 млн рублей. Но пока не вылизал мобильную версию, толку было мало. Люди заходят с телефона, и если у тебя там все разъезжается -> они просто уходят. Сделал адаптив нормально -> получил цифру».

Частые ошибки при работе с промптом для адаптива

Три ошибки убивают результат: правки ломают десктоп, нет проверки на реальном устройстве и слишком общий запрос без брейкпоинтов.

Промпт для адаптива дает осечку по трем причинам. Первая: AI чинит мобилку и попутно ломает десктоп, если в запросе не сказано «не трогай десктопные состояния». Вторая: правки не проверили на телефоне, а эмулятор соврал. Третья: запрос был общим, без конкретных breakpoints, и модель разложила случайные значения. Все три лечатся точностью формулировки.

Четвертая, менее очевидная -> доверие цифрам вместо глаз. Модель отчитывается «все кнопки теперь 44px», а визуально две из них слиплись. Всегда сверяй отчет с картинкой на узком экране.

Мы в VibeCoderz гоняем адаптив-промпт как обязательный шаг перед публикацией любого лендинга. Сначала Cursor правит по чек-листу, потом смотрим глазами на 360px, потом на живом телефоне. Три прохода, минут пятнадцать. Дешевле, чем терять пользователей на кривой мобилке.

Глоссарий

Адаптивная верстка -> раскладка, которая подстраивается под ширину экрана. Одна страница нормально выглядит и на телефоне, и на десктопе.

Breakpoint (брейкпоинт) -> точка ширины экрана, на которой меняется раскладка. Например, на 768px три колонки превращаются в две.

Horizontal overflow -> ситуация, когда элемент шире экрана и появляется горизонтальная прокрутка. Главный симптом сломанной мобильной версии.

Tap target -> кликабельная зона элемента: кнопки, ссылки, иконки. Минимум для веба -> 44 на 44 пикселя.

Meta viewport -> тег в HTML, который включает адаптив. Без него телефон показывает уменьшенную десктоп-версию.

Mobile-first -> подход, где базовые стили пишутся под телефон, а десктопные добавляются сверху через медиазапросы.

Playwright MCP -> сервер, через который AI управляет реальным браузером: открывает страницы, меняет размер окна, делает скриншоты.

WCAG -> международный стандарт доступности веба. Задает в том числе минимальные размеры кликабельных элементов.

FAQ

Почему AI ломает мобильную версию сайта? Нейросеть верстает по десктопному макету, а мобилку достраивает по остаточному принципу. Фиксированные ширины и мелкие кнопки на телефоне разъезжаются. Промпт с конкретными breakpoints и правилами tap targets убирает это за один проход.

Какой минимальный размер кнопки на мобильной версии? Безопасный ориентир для веба -> 44 на 44 пикселя. Это правило Apple HIG и усиленный уровень WCAG 2.5.5. Юридический минимум по WCAG 2.2 -> 24px, Android Material требует 48dp. Для основных действий бери 44px и выше.

Как найти горизонтальный скролл на мобильной версии? Проси AI найти элементы шире вьюпорта: фиксированные width в пикселях, картинки без max-width, длинные строки, отрицательные margin. В браузере overflow видно через DevTools -> Device Mode на 360px, где появляется полоса прокрутки.

В каком инструменте запускать промпт для адаптива? Cursor и Claude Code видят весь проект и правят CSS прямо в файлах. Для лендинга на одном файле подойдет любой чат с моделью посильнее. Хочешь, чтобы AI сам открыл страницу на 360px -> подключай Playwright MCP.

Достаточно ли одного промпта, чтобы починить адаптив? Один запрос дает полный аудит и первую пачку правок. Сложную сетку с 3-4 брейкпоинтами доводишь за 2-3 итерации: запустил, проверил на телефоне, вернул список косяков. Это рабочий цикл, а не провал.

Нужно ли добавлять meta viewport вручную? Без строки meta viewport мобильная версия вообще не включится, браузер покажет уменьшенный десктоп. Проверку тега стоит зашить в промпт первым пунктом. AI часто забывает его в самодельных HTML-страницах.

Работает ли промпт для адаптива на Tailwind? Да, и даже лучше. В Tailwind брейкпоинты уже заданы префиксами (sm, md, lg), и AI просто расставляет их по классам. В промпте достаточно указать стек, и модель разложит адаптив через утилиты, а не через отдельный CSS.

Что дальше

Скопируй промпт, подставь свой стек и прогони мобильную версию через Cursor, Claude Code или Windsurf. Разбор инструментов и их сильных сторон -> в каталоге AI-инструментов на VibeCoderz.

Если хочешь не просто починить адаптив, а собрать продукт с нуля и вывести его в органику -> запишись на консультацию к Максиму. Разберет твою задачу и покажет, где вайбкодинг сэкономит недели.

Материал команды VibeCoderz. Обновлено: июль 2026. Стандарты tap targets и breakpoints сверены с WCAG 2.2, Apple HIG и Google Material 3.