Как создать сайт с помощью ИИ: от запроса до публикации

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

С этого и стоит начинать работу с ИИ. Когда вы просите «сделай современный сайт мастерской», агенту приходится самому решать, что на нём будет. Он может добавить историю компании, преимущества и большую кнопку «Начать путешествие», хотя посетителю хотелось уточнить время ремонта. Дайте агенту больше конкретики: кому предназначена страница, с какой задачей человек придёт и что должен суметь сделать после прочтения.

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

Заодно договоримся, что означает отправленная форма. Пока сотрудник сам уточняет время, после отправки уместно написать: «Заявка получена. Мы свяжемся с вами и договоримся о визите». Если сайт сообщает «Вы записаны на 15:00», человек вправе рассчитывать, что это время уже занято за ним. Тогда понадобится расписание и правило, которое не позволит двум людям одновременно забрать одно место. Лучше разобраться с этим до создания формы: от ответа зависит и её текст, и устройство приложения.

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

Допустим, услуга называется «Настройка тормозов». Человеку без опыта это название мало что объясняет, поэтому рядом можно описать знакомые ему признаки: ручка проваливается, колесо задевает колодку, торможение стало слабее. Попросите ИИ помочь с формулировкой и отдайте её на проверку мастеру. Он уточнит, когда достаточно настройки, а когда нужен осмотр или замена детали. Так текст будет полезным и не пообещает ремонт, который по одному описанию подтвердить нельзя.

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

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

Когда материалы готовы, структура обычно становится понятнее. На первом экране стоит назвать услугу и место, чтобы человек сразу понял, куда попал. Например, «Ремонт велосипедов в [название района]» с коротким пояснением и кнопкой «Оставить заявку». Район и обещание под кнопкой возьмите из реальных условий работы. Если сотрудник отвечает только в рабочие часы, лучше сообщить об этом рядом с формой: посетитель, который написал поздно вечером, будет понимать, когда ждать звонка.

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

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

В задачу для агента добавьте название вкладки браузера, основной заголовок страницы и понятные заголовки разделов. Текст желательно отдавать в HTML уже при открытии, чтобы посетителю и поисковому роботу не приходилось ждать отдельной загрузки всего содержания. Если выбранный инструмент собирает страницу в браузере с помощью JavaScript, проверьте, видит ли поисковик итоговый текст. Это особенно полезно выяснить до публикации десятков страниц по одному шаблону.

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

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

Проверим форму на собственном контакте и добавим узнаваемое описание, например «Проверка формы: настройка тормозов». После отправки найдите эту заявку в хранилище и в списке сотрудника. Обновите страницу, выйдите из кабинета и войдите снова. Данные должны остаться на месте и совпасть с тем, что вы вводили. Если запись исчезла после обновления, стоит проверить, не хранилась ли она только в памяти открытой страницы.

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

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

Но есть более неприятный случай. Сервер сохранил телефон, а подтверждение не дошло до браузера из-за обрыва связи. Человек видит ошибку и повторяет отправку. Если сервер воспринимает её как совершенно новое обращение, сотрудник получит две одинаковые заявки. При этом написать «Ваша заявка не создана» тоже нельзя: браузер сейчас просто не знает, что произошло на сервере.

Для таких повторов используют идемпотентность. У одной отправки есть свой идентификатор; при повторной попытке браузер передаёт его снова, и сервер может узнать уже выполненное действие и вернуть прежний результат. Это поведение нужно реализовать на сервере, договорившись также, как долго он помнит идентификаторы. Если на каждое нажатие генерировать новый ключ или только добавить заголовок Idempotency-Key без обработки, дубликаты от этого не исчезнут.

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

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

У каждого поля оставьте видимую подпись. Если слово «Телефон» написано только внутри пустого поля, оно исчезнет при вводе, и человеку придётся вспоминать, что именно он заполняет. Для ошибки тоже нужен текст: красная рамка вокруг телефона не объясняет, чего не хватает. На компьютере пройдите форму клавишей Tab и посмотрите, удобно ли перемещаться между полями и отправить её без мыши.

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

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

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

Чтобы сайт мог попасть в поиск, поисковому роботу нужны доступная страница и её содержание. Проверьте, не остался ли после разработки запрет обхода в robots.txt или запрет индексации noindex. Основной адрес укажите в canonical, который помогает поисковику разобраться с дублями, и в sitemap, списке страниц сайта. Затем откройте Яндекс Вебмастер или Google Search Console, проверьте URL и отправьте его на переобход. Робот посещает и оценивает страницы отдельно от вашей публикации, поэтому отправка запроса не гарантирует ни немедленного появления, ни включения в поиск.

Если вам нужна только страница с услугами и телефоном, её можно собрать в конструкторе сайтов. В нашем примере есть ещё сохранение заявок и рабочий список сотрудника, поэтому понадобится место для данных, серверных действий и входа в кабинет. В Agnostic это можно связать в одном проекте: приложение отвечает за сайт, Data хранит обращения, App Auth помогает организовать вход сотрудников. Внешний агент получает доступ к выбранному проекту через MCP.

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

Подготовь сайт веломастерской с заявкой на связь в Agnostic.

Сначала прочитай контекст и назови выбранные проект, окружение
и доступные действия. Во внешнем редакторе проверь Agnostic MCP.
Если подключения нет, помоги выбрать проект и окружение,
получить инструкцию из меню MCP, покажи план настройки
и продолжи после авторизации в браузере.
Инструкция: https://agn0.ru/blog/connect-cursor/.
Для кода используй workspace проекта, полученный через Agnostic CLI;
если его нет, помоги получить. Если стартового App ещё нет,
объясни создание в Live отдельно от его публикации.

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

Сохраняй заявки в Data Agnostic через сервер приложения
с текущим Runtime SDK. Runtime-токен остаётся на сервере.
Сотрудник входит через App Auth; сервер проверяет права
на каждое чтение и изменение. Посетитель не читает общий список.
Проверь поля, доступ, двойной клик и потерянный ответ сервера.
Объясни реализованную защиту от повторов и её ограничения.

Подготовь Preview существующего App в согласованной среде,
дай адрес и результаты проверок с тестовыми контактами.
Покажи, где сотрудник найдёт сохранённую заявку.
Публикацию в Live выполним отдельным решением.

В Agnostic стартовый App создаётся в Live, а затем для существующего приложения можно подготовить Preview. Само создание App ещё не публикует сайт. Когда предварительная версия проверена, при выпуске сверяйте выбранное приложение, окружение и этапы операции. Записи Data и публикации разделены по окружениям, поэтому контрольную заявку после выпуска ищите в той среде, куда вы выпустили сайт.

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