Вайб-кодинг для маркетолога: как собрать нужный кусок сайта нейросетью

Что такое вайб-кодинг и что он даёт маркетологу

Вайб-кодинг — это способ получить рабочий код, описывая задачу человеческим языком. Вы объясняете нейросети, что должно появиться на странице и как оно должно себя вести, она выдаёт HTML, CSS и JavaScript, вы копируете результат к себе на сайт. Термин пришёл из английского vibe coding и прижился именно в таком значении: человек задаёт направление и проверяет результат, синтаксис пишет модель.

Для маркетолога ценность здесь простая — время. Раньше мелочь вроде «добавь на лендинг калькулятор доставки» уходила в очередь к разработчику и висела там 3-5 дней: задача маленькая, её всегда двигают вниз списка. Сейчас первый рабочий вариант появляется за 15-20 минут, ещё около часа уходит на доводку и тесты. В моей практике порядок такой: виджет на 150-300 строк — это вечер работы вместе с проверками и правками после первых заявок.

Важная оговорка про границы. Вайб-кодинг закрывает изолированные куски: виджет, блок, форму, скрипт для одной страницы. Как только код лезет в ядро сайта, в оплату, в личные кабинеты или в базу клиентов, нужен разработчик, который понимает последствия. Я держу для себя правило: если сломанный кусок сносится за две минуты и страница после этого остаётся живой, задачу можно отдавать нейросети. Сам вайб-кодинг — одна позиция в наборе AI-инструментов маркетолога, остальной набор я разбирал в обзоре нейросетей для маркетинга.

Какие задачи маркетолога закрывает генерация кода нейросетью

Вот что я собираю таким способом чаще всего:

• Калькуляторы и оценщики — стоимость доставки, расчёт работ, подбор тарифа. Как такие страницы устроены со стороны поиска и что в них считать, разбирал в материале про SEO-калькуляторы на Tilda.
• Квизы — цепочка из 3-5 вопросов, которая подводит человека к персональному предложению. Логика вопросов и сборка оффера — отдельная большая тема, она разобрана в статье про квиз на сайте под оффер.
• Формы заявки — с валидацией, маской телефона, чекбоксом согласия. Сколько полей оставить и как их подписать, смотрите в разборе формы заявки на сайте.
• Мелкие интерфейсные штуки — таблица сравнения тарифов, аккордеон под блок вопросов, таймер акции, липкая кнопка на мобильном, слайдер отзывов.
• Скрипты аналитики — прокидывание UTM в скрытые поля формы, отправка события в Метрику по клику, подмена номера телефона под источник трафика.

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

Есть и обратный список. Правки шаблонов темы, корзина и оплата, интеграции с CRM через API с боевыми ключами, всё, что трогает персональные данные глубже одной формы, — это уже разработка со всеми последствиями. Здесь ошибка измеряется потерянными заказами, и «вроде работает» перестаёт быть достаточной проверкой.

Как поставить задачу нейросети: промпт вместо «сделай виджет»

Промпт «сделай мне калькулятор доставки» даёт ровно то, что заслуживает: абстрактный калькулятор с выдуманными тарифами и чужим дизайном. Задачу приходится описывать так же подробно, как её описывают исполнителю в техзадании. Я держу в голове шесть блоков и прохожу по ним каждый раз.

• Что делает. «Форма расчёта стоимости переезда: три поля ввода, кнопка «Рассчитать», результат появляется под кнопкой без перезагрузки страницы».
• Данные и формула. Конкретные цифры из вашего прайса: базовая ставка, коэффициенты, диапазоны, округление.
• Что на выходе. «Сумма рублями и подпись «Итоговую цену подтверждает менеджер», ниже кнопка «Оставить заявку», она открывает форму».
• Куда уходят данные. На какой адрес, каким способом, какие поля передавать вместе с заявкой.
• Технические рамки. Один самодостаточный блок HTML со встроенными стилями и скриптом, без внешних библиотек, все классы с уникальным префиксом, шрифт наследуется от сайта, адаптив от 360 пикселей.
• Куда вставляется. «Код пойдёт в блок T123 на Тильде» или «в блок «Произвольный HTML» в WordPress» — модель подстроит вёрстку под ограничения площадки.

Пункт про уникальный префикс классов экономит больше всего нервов. Стоит его пропустить, и нейросеть спокойно выдаст глобальные стили вида button { background: #000 }. После вставки на сайт перекрасятся все кнопки, включая меню и корзину, а диагноз ставится через полчаса поисков. Я ловил такое трижды на разных проектах, поэтому формулирую прямо: «все селекторы только внутри .mv-calc, глобальные теги не трогай».

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

Итерации промпта: как довести код от «почти» до рабочего

Первый ответ модели обычно рабочий процентов на 70-80. Дальше идут итерации, и здесь у новичков ломается процесс: они пишут «всё плохо, переделай» и получают новый вариант, где сломано что-то другое. Правило, которое сокращает путь: одна правка за итерацию, максимально конкретная.

Нормальный цикл на реальной задаче выглядит так:

• Итерация 1. «Кнопка «Рассчитать» уезжает за край на мобильном. Сделай её на всю ширину контейнера при ширине экрана меньше 480 пикселей».
• Итерация 2. «При пустом поле «Метраж» результат показывает NaN. Добавь проверку: пока поля пустые, кнопка остаётся неактивной».
• Итерация 3. «Вот ошибка из консоли: Uncaught TypeError: Cannot read properties of null. Скрипт стартует раньше, чем на странице появляются элементы».
• Итерация 4. «Добавь отправку цели в Метрику по клику на «Оставить заявку»: счётчик 12345678, идентификатор цели calc_lead».

Три приёма, которые я использую постоянно. Первый — отдавать модели точный текст ошибки из консоли браузера (F12, вкладка Console): это ускоряет диагностику в разы по сравнению с описанием «у меня всё сломалось». Второй — просить возвращать код целиком одним куском, потому что склейка фрагментов руками отнимает время и рождает опечатки. Третий — скриншот: когда виджет визуально разъезжается, картинка объясняет проблему быстрее трёх абзацев текста.

Если после 5-6 итераций код ходит по кругу, я закрываю ветку и начинаю новую с обновлённым описанием задачи, куда сразу вписываю все всплывшие требования. Длинный диалог захламляет контекст: модель тащит за собой отменённые варианты и возвращает уже исправленные баги. Отдельная ветка под каждую задачу — привычка, которую стоит завести с первого дня.

Куда вставлять готовый код на Тильде

На Тильде для своего кода есть три места, и выбор между ними определяет половину будущих проблем.

• Блок T123 «HTML-код» — основной вариант. Ставится в любое место страницы, внутрь идёт весь виджет целиком: стили, разметка, скрипт. Для 200-300 строк это правильный выбор.
• Элемент HTML внутри Zero Block — когда виджет должен встать в конкретную точку дизайнерского блока. Здесь следите за высотой: содержимое, которое растёт после расчёта, вылезает за границы контейнера и наезжает на соседний блок.
• Настройки сайта → Ещё → HTML-код для вставки внутрь head или body — только для того, что должно работать на всех страницах: счётчики, подмена номера, общие скрипты. Виджету одной страницы здесь делать нечего.

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

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

Куда вставлять код в WordPress без правки темы

В WordPress точек входа тоже несколько, и правило простое: чем дальше от файлов темы, тем безопаснее.

• Блок «Произвольный HTML» в редакторе Gutenberg — для виджета внутри конкретной записи или страницы. Всё лежит в контенте и откатывается через ревизии записи.
• Плагин для сниппетов вроде Code Snippets — когда код должен работать на группе страниц или подключаться по условию. Каждый сниппет включается и выключается тумблером, это удобно при отладке.
• functions.php дочерней темы — для шорткодов и подключения файлов. Правки в родительской теме затираются при первом же обновлении, это классические грабли.

Что ломается на WordPress чаще всего. Классический редактор в визуальном режиме вырезает теги script и портит разметку при переключении вкладок, поэтому работайте во вкладке «Текст» либо в блоке «Произвольный HTML». Плагины кэширования с включённой минификацией и объединением JS склеивают инлайновый скрипт с остальными и роняют его — для страницы с виджетом оптимизацию стоит исключить в настройках плагина. Темы задают глобальные стили для форм и кнопок, из-за чего виджет приезжает с чужими отступами и цветами: лечится тем же уникальным префиксом классов.

Перед вставкой — бэкап. Даже если код уходит только в контент записи, полчаса на восстановление сайта из копии стоят дороже пяти минут на выгрузку. У большинства хостингов в РФ автоматическая копия делается раз в сутки, и этого хватает при одном условии: вы помните, в какой момент вносили правку.

Что ломается в сгенерированном коде и как это проверять

Код от нейросети ломается предсказуемо. Вот список того, что я прохожу перед публикацией каждый раз:

• Консоль браузера. F12, вкладка Console на странице с виджетом. Красные ошибки означают, что часть логики уже отвалилась, даже когда внешне всё нарисовалось правильно.
• Мобильная ширина. Режим устройства в браузере, ширина 360 пикселей. Горизонтальный скролл и уехавшие кнопки — самая частая беда сгенерированной вёрстки.
• Дошла ли заявка. Отправляю тестовую заявку и смотрю вкладку Network: ушёл ли запрос и каким кодом ответил сервер. Модель охотно рисует красивое «Спасибо, заявка отправлена» поверх запроса, который никуда не улетает. Самая дорогая ошибка из всех.
• Цели в Метрике. Проверяю через отчёт по конверсиям или Вебвизор, что событие долетело до счётчика. Виджет без цели — слепая зона в аналитике.
• Соседние блоки. Прокликиваю остальную страницу и меню: как себя чувствуют шрифты, отступы, кнопки. Глобальные селекторы дают эффект именно там, куда вы смотреть не собирались.
• Вес и скорость. Один виджет добавляет обычно 10-40 КБ. Если ради одной анимации подтянулась внешняя библиотека на 200 КБ, прошу переписать без неё.

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

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

Главное

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