Как создать сайт с помощью ИИ и не застрять на красивом прототипе

Вы описываете будущий лендинг обычными словами. Через несколько минут справа уже открывается аккуратный экран: заголовок, карточки, кнопка, форма. Хочется нажать «Опубликовать» и считать задачу закрытой.

Но экран в браузере ещё не означает, что сайт готов. Форма может никуда не отправлять заявку. Мобильная версия — расползаться. Секретный ключ — лежать прямо в коде. А после первой неудачной правки может выясниться, что вернуться к рабочей версии некуда.

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

Начинать лучше не со слов «хочу современный сайт», а с ответа на вопрос: что человек должен сделать после просмотра страницы?

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

Затем ограничьте первую версию. Например:

• одна страница;

• описание услуги и три примера;

• форма с именем и контактом;

• подтверждение успешной отправки;

• уведомление владельцу сайта.

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

Хорошее задание для ИИ описывает не только блоки, но и критерий готовности: «После тестовой отправки заявка появляется в указанном канале, а пользователь видит подтверждение». Такой критерий можно проверить. «Сделай красиво и удобно» — нельзя.

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

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

Перед первой большой правкой попросите агента:

1. создать репозиторий, если его ещё нет;

2. показать, какие файлы войдут в изменение;

3. сделать первый коммит с понятным названием;

4. объяснить, как вернуться к нему.

Не просите просто «настроить Git». Вам нужен наблюдаемый результат: в истории есть контрольная точка, а текущие изменения видны отдельно. Если агент не может показать разницу между версиями, вы пока управляете проектом вслепую.

Большой промпт создаёт впечатляющий первый результат, но плохо подходит для следующих итераций. Если за один раз попросить новый дизайн, форму, оплату, личный кабинет и аналитику, после ошибки будет трудно понять, какая часть её вызвала.

Безопаснее менять проект небольшими порциями:

1. собрать структуру страницы;

2. проверить навигацию и кнопки;

3. добавить одну форму;

4. подключить место, куда попадают данные;

5. проверить успешный и неуспешный сценарии;

6. сохранить рабочую версию.

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

Если изменение не получилось, не наращивайте поверх него ещё пять просьб. Вернитесь к последней контрольной точке, уточните критерий и повторите один шаг. Так диалог с ИИ остаётся управляемым, а проект не превращается в стопку случайных исправлений.

Форма — первая часть сайта, где красивого интерфейса недостаточно. Нужно проверить не только кнопку, но и весь путь данных.

Минимальный сценарий выглядит так:

• обязательные поля нельзя отправить пустыми;

• пользователь понимает, где ошибся;

• корректные данные доходят до сервера;

• сервер возвращает реальный успех или ошибку;

• повторный клик не создаёт несколько одинаковых заявок;

• владелец получает уведомление;

• в интерфейсе нет тестовых адресов и выдуманных фактов.

Встроенная проверка полей в браузере полезна, но это только первая линия. Руководство MDN по валидации форм отдельно разбирает HTML- и JavaScript-проверки. Если сайт сохраняет данные, сервер всё равно должен проверять вход самостоятельно: поведение браузера можно обойти.

Отдельный разговор — ключи к почте, базе, платёжному или Telegram API. Их нельзя вставлять в страницу или отправлять в публичный репозиторий. OWASP относит API-ключи, пароли и токены к секретам и рекомендует ограничивать доступ, хранить их отдельно от исходного кода и предусматривать замену или отзыв. OWASP Secrets Management Cheat Sheet.

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

Сначала проверьте страницу на телефоне и компьютере. Адаптивный дизайн нужен не ради отдельной «мобильной версии», а чтобы один интерфейс оставался читаемым и управляемым на разных экранах. Это базовая цель responsive design в руководстве MDN.

Затем пройдите три сценария:

1. Нормальный: пользователь читает страницу, нажимает главную кнопку и успешно завершает действие.

2. Ошибочный: пропускает поле, вводит неверные данные или теряет соединение.

3. Повторный: возвращается назад, обновляет страницу или нажимает кнопку дважды.

Не откладывайте такую проверку на самый конец. MDN рекомендует тестировать небольшие части по мере работы и включать реальные мобильные устройства в набор проверок. Introduction to cross-browser testing.

Записывайте найденную проблему как наблюдение, а не оценку: «на экране шириной 375 пикселей кнопка выходит за край» полезнее, чем «мобильная версия плохая». Чем точнее вход, тем меньше агенту приходится угадывать.

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

Лучше, если публикация оформлена как воспроизводимый процесс, а не как набор ручных действий, который помнит только текущий чат. GitHub Actions, например, позволяет описать сборку и деплой как последовательность шагов и хранить историю запусков. Deploying with GitHub Actions.

Перед публикацией выясните:

• какая ветка или версия уходит на сайт;

• где посмотреть журнал неудачного деплоя;

• как вернуть предыдущую рабочую версию;

• где хранятся переменные окружения;

• кто управляет доменом и DNS;

• включён ли HTTPS.

Если вы используете собственный домен, его подключение становится отдельной настройкой. Нужно связать домен с хостингом через DNS, проверить адрес и защищённое соединение. В инструкции GitHub Pages эти действия тоже разделены: сначала домен добавляется к сайту, затем настраиваются записи у DNS-провайдера и HTTPS.

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

На курсе «Вайбкодинг на максималках» этот цикл разбирается на собственном проекте: от устройства разработки и Git до базы данных, сервера и деплоя. Это имеет смысл, если вам нужен не ещё один красивый прототип, а проект, который вы сможете менять после первой публикации.

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

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

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

Сайт можно считать готовым к первому реальному трафику, если:

1. у него есть одно понятное целевое действие;

2. рабочая версия сохранена в Git;

3. функции добавлялись и проверялись небольшими шагами;

4. формы передают данные, а ключи не попадают в код браузера;

5. основной и ошибочный сценарии пройдены на телефоне и компьютере;

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

7. целевое действие видно в аналитике.

ИИ может подготовить файлы, помочь с проверкой и настроить часть деплоя. Но управляемый результат появляется не из одного удачного промпта, а из последовательности проверок.