Рабочий процесс с использованием ИИ для размещения небольшого веб-сайта на Cloudflare
Повторяемый рабочий процесс и шаблоны запросов для проектирования, улучшения и развертывания небольшого сайта с помощью ИИ-ассистента для программирования, бесплатных тарифов GitHub и Cloudflare.
Небольшому информационному сайту больше не требуется длительная разработка. Благодаря ИИ-ассистенту по программированию, который выполняет значительную часть работы, один человек может превратить первоначальную идею в исходный код на GitHub, осуществить автоматическую развертку через Cloudflare и получить рабочий домен под собственным именем примерно за полдня интенсивной работы. Сложность смещается от написания кода к определению желаемого результата и предоставлению точных замечаний по полученному продукту. В этом руководстве пошагово описан этот процесс, приведены шаблоны запросов, которые можно адаптировать для этапов дизайна, создания логотипа, проверки и улучшения, а также четко указано, в каких случаях этот подход становится нецелесообразным.
Начинайте с цели, а не с фреймворка
Первый естественный вопрос у разработчика — какой фреймворк выбрать: React, Next.js, генератор статических сайтов или что-то ещё. Когда ассистент может сгенерировать большую часть кода, этот вопрос становится гораздо менее важным по сравнению с более простым: что на самом деле должен делать сайт?
Для первой версии личного или консалтингового сайта ответ может быть кратким. Посетители должны понимать, зачем существует сайт, иметь возможность найти его статьи и аналитику, а также знать, как связаться с владельцем. Это уже полный спектр требований. Если сначала записать их, у вас и у модели будет чёткий критерий для всех последующих решений, и первая версия не превратится в проект полной переработки.
Когда у вас нет конкретного дизайна
Многие начинают без технического задания, и это нормально. Вместо макетов опишите желаемый опыт использования: например, профессиональный, современный, чистый, просторный и ориентированный на технологии, но без излишнего футуристичного стиля. Ассистент преобразует этот описания в первый визуальный черновик.
Как только что-то появляется на экране, получение обратной связи становится проще, поскольку вы реагируете на конкретный элемент, а не просто представляете его:
- Логотип не соответствует бренду.
- Изображение баннера обрезано.
- Один из разделов кажется перегруженным.
- Часть страницы следует пока скрыть.
Последовательность подобных реакций и составляет процесс дизайна. Вам не нужен специальный дизайнерский словарь — достаточно умения замечать то, что кажется неправильным, и выразить это словами.
Цикл обратной связи важнее первоначального запроса
Не существует единственного идеального запроса. Первый результат предназначен лишь для того, чтобы у вас был объект для ответа. Последующие указания становятся более узкими и конкретными: исправить логотип, скорректировать кадрирование баннера, скрыть незавершённые разделы, переименовать элементы навигации, протестировать ссылки, проверить мобильную верстку.
Качество достигается за счёт множества коротких, конкретных этапов, а не одного огромного запроса. Короткие этапы также позволяют легче заметить, когда модель изменила что-то, чего вы не просили.
Универсальный запрос для первой версии
Полезный начальный запрос описывает проект, затем просит модель предложить дизайн и обосновать его перед генерацией кода. Шаблон может включать следующие элементы:
- Название бренда, компании или проекта.
- Цель: что должен помочь вам сделать сайт.
- Целевая аудитория: для кого он предназначен.
Затем попросите модель предложить варианты на основе цели и аудитории:
- Палитру цветов.
- Стиль шрифтов.
- Структуру главной страницы.
- Концепцию раздела с главным контентом.
- Навигацию.
- Рекомендуемые разделы контента.
- Призывы к действию.
- Общий визуальный стиль.
В заключение попросите его объяснить предложенный дизайн и причины, по которым он подходит аудитории, прежде чем писать любой код, и сгенерировать первую рабочую версию только после того, как вы одобрите этот подход. Разделение предложения и реализации — ключевой шаг: гораздо дешевле отклонить палитру в текстовом виде, чем удалять её из сгенерированного CSS.
Рассматривайте логотип как отдельную задачу
Логотип должен работать и вне веб-сайта: на социальных профилях, в презентациях и документах. Если объединять его с требованиями к сайту, скорее всего получится что-то, подходящее только для заголовка, поэтому выделяйте разработку бренда в отдельную задачу.
Попросите простую концепцию логотипа, который будет выглядеть минималистично, современно, профессионально и узнаваемо даже в малом размере. Укажите, где он должен использоваться: на веб-сайтах, аватарах в социальных сетях, в презентациях, документах, а также на светлом и темном фоне. Кратко опишите идею, которую представляет бренд, затем запросите:
- Визуальную концепцию.
- Подход к типографике.
- Палитру цветов.
- Идею для иконки или монограммы.
- Версию для светлого фона.
- Версию для темного фона.
- Обоснование того, почему дизайн подходит бренду.
Укажите четкое ограничение, запрещающее использование сложных иллюстраций или символов, требующих тонких деталей, поскольку они становятся нечитаемыми при малом размере фавикона.
Позвольте ассистенту заняться реализацией, сохраняя при этом фокус на поставленной цели
Как только направление работы определено, помощник для кодирования (ChatGPT и Codex — в том сценарии, откуда берется этот рабочий процесс) может взять на себя большую часть реализации. Преимущество заключается в том, что инструкции остаются на уровне желаемого результата, а не указаний на конкретный файл и строку кода:
- Баннер разделен пополам.
- Пока что отключите комментариями эти разделы.
- Переименуйте эту кнопку.
- Сделайте так, чтобы эта кнопка прокручивала код к соответствующему разделу.
- Сделайте логотип идентичным оригинальному изображению.
Вы по-прежнему проверяете каждый результат, но вам больше не нужно самостоятельно искать изменения в кодовой базе для каждой мелкой правки.
Зарегистрируйте домен заранее и продолжайте разрабатывать локально
Регистрация домена занимает немного времени: поиск, проверка доступности, регистрация и оплата. Однако сделать его полностью готовым к использованию может потребоваться больше времени. В описанном здесь случае всё было решено в течение примерно 24 часов, как и ожидалось; продолжительность задержки зависит от регистратора и процесса распространения DNS.
Это ожидание не обязательно должно мешать разработке. Продолжайте работать и тестировать в локальной среде с использованием цикла «изменить, просмотреть, проверить, исправить, снова протестировать». Работа локально также гарантирует, что незавершённые эксперименты никогда не станут общедоступными, а описание изменений на более высоком уровне избавляет от необходимости искать конкретные строки во множестве файлов.
Используйте модель в качестве инструмента для проверки, а не только для создания
Как только появится первая версия, попросите ассистента её проанализировать. В запросе на обзор необходимо указать его роль, ограничить возможность полной переработки и потребовать приоритетных, практических рекомендаций.
Попросите его взглянуть на скриншот как опытного дизайнера интерфейса и пользовательского опыта и, без ненужной переработки, выявить наиболее важные направления для улучшения:
- Макет: расстояния между элементами, выравнивание и общее визуальное балансирование.
- Иерархия и типографика: насколько четко направлен взгляд пользователя, выбор шрифтов и удобочитаемость.
- Целостность дизайна: цвета и элементы бренда на всей странице.
- Адаптивность на меньших экранах.
- Призывы к действию: насколько они очевидны и четко сформулированы.
Попросите оценить каждое замечание по степени важности, чтобы в каждом указывалось, что считается слабым местом, почему это важно и что именно нужно изменить. Ограничьте список только теми изменениями, которые существенно улучшают профессионализм и удобство использования. Именно это предложение предотвращает превращение отзыва в простой список косметических пожеланий.
Итерации — вот где происходит основная работа
После первоначального дизайна почти не требуется создавать что-то совершенно новое. Практически вся работа сводится к улучшению уже существующего, и здесь наилучше подходят краткие и четкие указания. Надежный шаблон для итераций выглядит так:
- Нумерованный список конкретных изменений, по одному на строку.
- Четкое указание не перерабатывать нерелевантные разделы и сохранять все, что уже работает корректно.
Необходимо уделять особое внимание инструкции по сохранению оригинала. Ассистенты склонны «улучшать» соседний код в процессе исправления того, о чем вы просили, и четкое ограничение снижает такую тенденцию. Чек-лист самопроверки не заменяет ваш собственный анализ, но помогает выявить очевидные откаты до того, как вы их заметите.
Как только сайт будет работать локально, загрузите его исходный код в репозиторий GitHub. GitHub предоставляет историю версий и безопасный способ отката любых изменений, внесенных ассистентом.
Далее подключите этот репозиторий к Cloudflare, чтобы каждое добавление в репозиторий запускало автоматическую сборку и развертывание. С этого момента публикация заключается просто в коммите и пуше. Для небольшого информационного сайта в данном случае хватило бесплатного тарифа Cloudflare; проверьте текущие лимиты планов под ваши нужды.
Когда домен активен и его DNS-записи настроены, привяжите пользовательский домен к развернутому проекту. После этого ввод домена в браузер покажет живой сайт.
Сколько это стоит и когда это не подходит
Для такого проекта расходы на эксплуатацию невелики:
- Регистрация домена: примерно 12 долларов в год в данном случае.
- GitHub: бесплатно.
- Cloudflare: бесплатный тариф оказался достаточным.
- Инструменты ИИ: стоимость подписки на ChatGPT или другого ассистента.
Помимо подписки на ассистента, домен фактически является единственной стоимостью инфраструктуры.
Такой подход не подходит для всех приложений. Любые системы, связанные с оплатами, конфиденциальными персональными данными, сложной аутентификацией, базами данных или регулируемыми средами, требуют тщательной инженерной проработки: моделирования угроз, проверки кода специалистом, понимающим каждую строку, тестирования и оперативного мониторинга. Однако для портфолио, лендинг-страниц, консалтинговых сайтов, прототипов и простых сайтов с контентом барьер входа значительно ниже, чем раньше.
Что решает ассистент, а что — нет
Ассистент берет на себя большую часть операций: написание и редактирование кода, преобразование отзывов по дизайну в соответствующие изменения, устранение визуальных ошибок и объяснение незнакомых технических процедур. Некоторые решения по-прежнему остаются за человеком:
- Что должен представлять сайт.
Это устраняет узкое место. Ограничивающий фактор больше не связан с технической возможностью создания сайта, а с способностью четко определить желаемое решение. Барьеры реализации снижаются, но потребность в принятии решений остается.
Основные выводы
- Определите цель, аудиторию и основное сообщение перед тем, как выбирать технологии.
- Попросите модель предложить и обосновать дизайн перед написанием кода, а затем явно одобрите выбранное направление.
- Обрабатывайте логотип отдельно, чтобы он корректно выглядел во всех форматах, а не только в заголовке сайта.
- Используйте короткие, конкретные этапы итераций с ограничением «сохранить всё остальное» и списком самопроверки.
- Используйте помощника как критика, так и сопровождающего при разработке, получая приоритизированные и практические рекомендации.
- Загрузите код на GitHub и позвольте Cloudflare развертывать его при каждом обновлении, чтобы контроль версий и хостинг происходили автоматически.
- Используйте этот легковесный подход только для сайтов с низким уровнем риска. Основная ценность заключается в том, как все элементы объединяются в единый рабочий процесс: вы контролируете цели, принимаете решения и утверждаете изменения, помощник занимается выполнением задач, GitHub хранит историю изменений, а Cloudflare осуществляет публикацию.