Промпты для создания сайта и лендинга: от брифа до проверки

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

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

Что подготовить перед первым промптом

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

Различайте три результата:

• Макет показывает расположение и оформление блоков
• Прототип позволяет проверить переходы, ввод данных и отдельные сценарии
• Опубликованный сайт доступен по адресу; для приёма заявок ему ещё нужны настроенная обработка и проверенная доставка

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

Мы выбрали вымышленную студию «Тихий стол». Все учебные факты задали сами: двухчасовой очный мастер-класс по уходу за комнатными растениями, взрослые начинающие, группа до шести человек, цена 2400 ₽, материалы включены. Город, дата, преподаватель и отзывы не заданы. В программе — свет, влажность грунта и пересадка на демонстрационном образце. Форма предназначена только для вымышленных имени и email.

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

Шаг 1. Превратить факты в проверяемый бриф

Начните с исходников, а не с выбора модного стиля. Поля в квадратных скобках замените своими данными. Для незаполненных пунктов прямо напишите «не задано».

Помоги подготовить одностраничный сайт.
Проект: [название и суть].
Посетитель: [кто он и зачем пришёл].
Главное действие: [одно действие].
Подтверждённые факты: [услуга, состав, цена, сроки, ограничения].
Пока неизвестно: [список].
Запрещено придумывать: отзывы, клиентов, адреса, гарантии, скидки и доступность.

Составь короткий бриф: цель страницы, аудитория, факты, пробелы, запреты и критерии готовности. Если для цели не хватает важного факта, задай вопрос. Не заполняй пробел догадкой. Код и рекламный текст пока не пиши.

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

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

Шаг 2. Собрать структуру вокруг вопросов посетителя

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

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

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

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

Шаг 3. Написать тексты без новых обещаний

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

Напиши тексты по принятой структуре: [структура].
Единственный источник фактов: [подтверждённые сведения].
Нужны один H1, короткий лид, тексты блоков, подписи полей и кнопок.
Тон: понятный, спокойный, конкретный. Не добавляй обещаний, отзывов и чисел сверх исходника.
Для каждого действия укажи, что действительно произойдёт после нажатия.

Режим формы: учебная демонстрация. Только вымышленные имя и email, без отправки и сохранения.
Кнопка: «Проверить демоформу».
Успех: «Демо проверено. Данные никуда не отправлены».
Сначала выдай тексты, затем отдельно перечисли места, где нужны дополнительные факты. Код не пиши.

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

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

Сохраните принятую версию текста. Дальше просите менять оформление без переписывания условий: так легче заметить пропавшую оговорку или новую скидку.

Шаг 4. Задать интерфейс и его состояния

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

Спроектируй интерфейс для этих окончательных текстов: [тексты].
Стиль: [фон, акцент, настроение]. Используй читаемый системный шрифт.
На широком экране [например, три карточки в ряд], на узком — одна колонка.
Одна основная кнопка ведёт к [цель].
У полей постоянные видимые подписи. Клавиатурный фокус заметен.
Опиши состояния формы: до ввода, при пустых обязательных полях, при неверном email, после корректной проверки, после изменения уже проверенных данных.
Не добавляй новые блоки, факты и внешние ресурсы. Пока дай описание интерфейса без кода.

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

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

W3C рекомендует связывать подпись с соответствующим полем. Подсказка внутри пустого поля исчезает при вводе и не всегда может заменить такую подпись. Поэтому просите постоянные названия полей, а не только красивый placeholder.

Шаг 5. Получить исходный файл с ограниченной логикой

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

Реализуй принятые тексты и интерфейс: [вставьте оба результата].
Верни один полный index.html с HTML, CSS и небольшим JavaScript внутри, без пропусков.
Не подключай внешние библиотеки, шрифты, изображения, аналитику, сеть, сервер и хранилища.
Добавь lang=ru, charset, viewport, title и description.
Страница должна помещаться в ширины 320, 390, 430 и 1280 CSS-пикселей без горизонтальной прокрутки.
Кнопка первого экрана ведёт якорем к форме.

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

13 октября 2026 года в веб-интерфейсе ChatGPT, в режиме Instant, мы получили полный файл с CSS и JavaScript. Точное имя модели интерфейс не показал. Мы сохранили исходник до правок. В нём были один H1, адаптивная сетка, видимые подписи полей и обработчик, который отменял стандартную отправку формы. Внешние библиотеки для этого примера не понадобились.

В некоторых ответах ChatGPT есть кнопка предпросмотра HTML. Официальная справка описывает поддерживаемые предпросмотры и ограничения их среды. Если нужной кнопки нет, сохраните код как index.html в текстовом редакторе и откройте файл в браузере. Проверка должна относиться именно к той версии файла, которую вы собираетесь использовать.

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

Шаг 6. Проверить результат и отправить адресную правку

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

Проверь приложенный HTML против брифа и критериев: [бриф и критерии].
Раздели вывод на три части: что видно из кода; что реально проверено запуском; что ещё нужно проверить руками.
Проверь факты, один H1, подписи полей, якоря, внешние подключения и поведение формы.
Для каждой проблемы укажи: как воспроизвести, ожидаемое поведение, фактическое поведение и минимальное исправление.
Не утверждай, что проверил мобильный экран, сеть или доставку заявки, если у тебя нет инструментов и результатов такой проверки. Сначала отчёт, без переписывания всей страницы.

Минимальная самостоятельная приёмка занимает несколько отдельных сценариев:

1. Открыть страницу на широкой и узкой ширине. Проверить заголовок, карточки, поля и горизонтальную прокрутку
2. Нажать основную кнопку и убедиться, что она приводит к нужной форме
3. Отправить пустую форму, затем ввести неверный email
4. Ввести вымышленные корректные данные и проверить точный текст результата
5. После успеха изменить поле, снова допустить ошибку и повторить проверку
6. Пройти элементы клавишей Tab: должно быть видно, где находится фокус
7. Сверить текст с исходными фактами и проверить, не добавились внешние подключения

В сохранённом коде нашлась конкретная ошибка. После ввода «Демо» и demo@example.com обработчик показывал успех. Если затем заменить email на «ошибка», прежнее зелёное сообщение оставалось до следующего нажатия кнопки. Мы воспроизвели это, исполнив исходный JavaScript в отдельном тестовом окружении с имитацией событий формы. Это проверка логики обработчика, а не полноценный запуск страницы в браузере.

Причина оказалась простой: результат очищался только при новой отправке. Редакционная правка добавила сброс сообщения при редактировании любого поля. Проверка также нашла слишком мягкое правило email: код принимал demo@example..com. Мы уточнили проверку доменной части. Повторный прогон в том же JavaScript-окружении прошёл 18 из 18 заданных сценариев, включая сброс статуса и три ошибочных формата домена. Эти правки внесли мы; ответом ChatGPT они не были. Форматная проверка не подтверждает, что почтовый ящик существует.

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

Для возврата найденной проблемы в нейросеть используйте узкий запрос:

Обнаружено: [точное действие и фактический результат].
Ожидаю: [нужное поведение].
Исправь только связанную с этим логику. Сохрани тексты, стили, структуру, факты и запрет внешних запросов.
Верни полный обновлённый файл и кратко перечисли изменения.
После правки повторно проверь проблемный сценарий и соседние сценарии: [список]. Не объявляй проверку выполненной без запуска.

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

Что нужно сделать до настоящего запуска

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

Не вставляйте пароли, API-ключи и секреты почтового сервиса в HTML: посетитель может получить код страницы. Не считайте сгенерированный текст согласия готовым решением для обработки персональных данных. Правила обработки и документы нужно проверить применительно к вашему проекту до начала сбора.

Отдельно разберитесь с размещением страницы, правами на изображения, аналитикой и резервной копией принятой версии. Если удобнее собирать и размещать страницу в одном сервисе, посмотрите разбор Sites в ChatGPT. Если нужен калькулятор или другой интерактивный элемент, пригодится материал о том, как проверить небольшой инструмент в Claude Artifacts.

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