Робочий процес з використанням ШІ для розгортання невеликого веб-сайту на Cloudflare

Невеликий інформаційний веб-сайт більше не потребує тривалої розробки. Завдяки AI-асистенту з програмування, який виконує більшу частину роботи, одна людина може перейти від первинної ідеї до вихідного коду на GitHub, автоматичної розгортки через Cloudflare та живого користувацького домену приблизно за півдня зосередженої роботи. Важка частина переміщується від написання коду до прийняття рішення про те, що ви хочете, та надання точних відгуків щодо отриманого результату. Цей посібник описує цей процес крок за кроком, містить шаблони запитів, які можна адаптувати для етапів дизайну, логотипу, перегляду та ітерацій, а також чітко вказує, де цей підхід більше не є доцільним.

Починайте з мети, а не з фреймворку

Природним першим запитанням у розробника є те, яку технологічну стек використовувати: React, Next.js, генератор статичних сайтів чи щось інше. Коли асистент може створити більшу частину коду, це запитання стає значно менш важливим порівняно з простішим: що саме має робити сайт?

Для першої версії особистого чи консультаційного сайту відповідь може бути короткою. Відвідувачі повинні зрозуміти, що означає сайт, мати змогу знайти його статті та аналізи, а також знати, як зв’язатися з авторами. Це і є повний спектр функцій. Спочатку записавши це, ви та модель матимете чіткі критерії для кожного подальшого рішення, а також уникнете того, що перше випускання перетвориться на проєкт повної переробки.

Коли у вас немає конкретного дизайну

Багато людей починають без технічних вимог до дизайну, і це нормально. Замість макетів описайте бажаний досвід користування: наприклад, професійний, сучасний, чистий, просторий та орієнтований на технології, але без зайвої футуристичності. Асистент перетворює цей опис на перший візуальний чернеток.

Як тільки щось з’являється на екрані, надання відгуків стає простішим, адже ви реагуєте на конкретну річ, а не уявляєте її:

• Логотип не відповідає бренду.
• Зображення-банер обрізане.
• Одна з частин сторінки здається переповненою.
• Частину сторінки потрібно наразі приховати.

Послідовність таких реакцій і є процесом дизайну. Вам не потрібна спеціальна термінологія — достатньо здатності помічати те, що виглядає неправильно, та сказати про це.

Цикл відгуків важливіший за початкове завдання

Не існує єдиного ідеального запиту. Перший результат створюється для того, щоб у вас було на що відповісти. Подальші інструкції стають все більш конкретними: виправити логотип, скоригувати зображення банера, приховати незавершені частини, змінити назви елементів навігації, перевірити посилання, переглянути мобільну верстку.

Якість досягається завдяки багатьом коротким, конкретним етапам, а не одному величезному запиту. Короткі етапи також допомагають швидше помітити, коли модель змінила щось, про що ви не просили.

Ідеальний запит для першої версії

Корисний початковий запит описує проект, а потім просить модель запропонувати дизайн та обґрунтувати його перед створенням коду. Шаблон може включати такі елементи:

• Назва бренду, компанії чи проекту.
• Мета: що має допомогти вам сайт.
• Цільова аудиторія: для кого цей сайт.

Основне послання, яке відвідувач має засвоїти протягом перших 15–20 секунд.

Візуальний стиль: професійний, мінімалістичний, преміум-класу, креативний чи орієнтований на технології, а також вибір світлого, темного чи нейтрального фону.

Базові вимоги: чистий шрифт, достатньо простору між елементами, чітка візуальна ієрархія та макет, який підходить для телефонів.

Чесне зазначення про те, що кольори, шрифти чи структура сторінки ще не обрані.

Потім попросіть модель запропонувати, враховуючи мету та аудиторію:

1. Палітру кольорів.
2. Стиль шрифтів.
3. Структуру головної сторінки.
4. Концепцію розділу «Герой».
5. Навігацію.
6. Рекомендовані розділи контенту.
7. Заклики до дії.
8. Загальний візуальний стиль.

Завершіть процес, доручивши системі пояснити запропонований дизайн та причини, чому він підходить аудиторії, ще до написання будь-якого коду, а також створити першу функціональну версію лише після вашого схвалення цього напрямку. Розділення пропозиції та її реалізації — це ключовий крок: набагато дешевше відхилити палітру у текстовому вигляді, ніж видаляти її з генерованого CSS.

Ставіться до логотипу як до окремого завдання

Логотип має функціонувати також поза веб-сайтом: у соціальних профілях, у презентаціях та в документах. Його поєднання з запитом щодо сайту часто призводить до створення чогось, що підлаштоване лише під заголовок, тому надайте брендингу окреме завдання.

Запросіть просту концепцію логотипу, яка має виглядати мінімалістичною, сучасною, професійною та унікальною, і залишатися впізнаваною у маленьких розмірах. Вкажіть, де він має використовуватися: веб-сайти, аватарки у соціальних мережах, презентації, документи, а також на світлих та темних фонах. Коротко описайте ідею, яку представляє бренд, а потім запросіть:

1. Візуальну концепцію.
2. Підхід до типографіки.
3. Палітру кольорів.
4. Ідею ікони чи монограми.
5. Версію для світлих фонів.
6. Версію для темних фонів.
7. Пояснення того, чому дизайн підходить бренду.

Додайте чітке обмеження щодо уникнення складних ілюстрацій чи символів, які залежать від дрібних деталей, адже вони стають нерозбірливими у розмірі фавікону.

Дозвольте асистентові займатися реалізацією, поки ви залишаєтесь на рівні задуму

Як тільки напрямок реалізації визначений, асистент з кодування (ChatGPT та Codex у сценарії, з якого походить цей робочий процес) може виконати більшу частину роботи. Перевага полягає у тому, що інструкції залишаються на рівні бажаного результату, а не конкретних файлів чи рядків, які потрібно змінити:

• Банер розділяється навпіл.
• Наразі відключіть коментарями ці частини.
• Змініть назву цієї кнопки.
• Зробіть так, щоб ця кнопка переміщувала користувача до відповідної частини.
• Зробіть логотип ідентичним оригінальному малюнку.

Ви все одно перевіряєте кожен результат, але більше не змушені самостійно навігувати по кодовій базі для кожної дрібної корекції.

Реєструйте домен якомога раніше та продовжуйте розробку локально

Реєстрація домену — це швидко: пошук, перевірка доступності, реєстрація та оплата. Однак зробити його повністю придатним для використання може зайняти більше часу. У описаному тут сценарії минуло приблизно 24 години, перш ніж усе вирішилося так, як очікувалося; тривалість затримки залежатиме від реєстратора та процесу поширення DNS.

Це очікування не обов’язково має заважати розробці. Продовжуйте створювати та тестувати в локальному режимі за допомогою циклу «зміни, перегляд, перевірка, виправлення, ще один тест». Робота локально також означає, що незавершені експерименти ніколи не потрапляють у публічний доступ, а опис змін на вищому рівні допомагає уникнути необхідності пошуку в кількох файлах для корекції окремих рядків.

Використовуйте модель як перевіряючий інструмент, а не лише для створення

Як тільки з’явиться перша версія, попросіть асистента її проаналізувати. У запиті на огляд слід визначити його роль, стримати його від повної переробки всього та вимагати пріоритетних, конкретних рекомендацій.

Попросіть його розглянути скріншот як досвідченого дизайнера інтерфейсу та користувацького досвіду та, без зайвої переробки, визначити найбільші можливості для покращення:

• Макет: відстані між елементами, вирівнювання та загальна візуальна збалансованість.
• Ієрархія та типографіка: наскільки чітко спрямовується погляд користувача, вибір шрифтів та читабельність.
• Цілісність: кольори та елементи бренду на всій сторінці.
• Адаптивність на менших екранах.
• Заклики до дії: чи є кожен з них очевидним та чітко сформульованим.

Попросіть ранжувати знахідки та щоб кожна з них вказувала, що є слабким місцем, чому це важливо та що саме потрібно змінити. Обмежте це лише змінами, які суттєво покращують професіоналізм та зручність використання. Саме останнє речення запобігає тому, щоб огляд перетворився на список косметичних побажань.

Ітерації — це там, де відбувається більша частина роботи

Після початкового дизайну майже не залишається роботи з створення чогось нового. Майже все полягає у вдосконаленні того, що вже існує, і тут найкраще підходять короткі та чіткі вказівки. Надійний шаблон ітерації виглядає так:

• Нумерований список конкретних змін, які ви бажаєте, по одній на рядок.
• Чітка вказівка не переробляти непов’язані розділи та зберігати все, що вже працює належним чином.

Чек-лист перевірки, який модель має виконати після змін: перевірити розташування елементів на десктопному варіанті, перевірити розташування на мобільному варіанті, підтвердити, що посилання на навігацію працюють, підтвердити, що кожна кнопка веде до правильної адреси, переконатися, що нічого випадково не приховано чи не обрізано, та повідомити про будь-які залишкові проблеми, які вона помітила.

Інструкція щодо збереження початкового стану вимагає особливої уваги. Асистенти схильні „покращувати“ сусідній код під час виправлення того, про що ви просили, а чіткий обмежувальний правил зменшує таку тенденцію. Чек-лист самоперевірки не замінює ваш огляд, але допомагає виявити очевидні негативні зміни ще до того, як ви їх перевірите.

Як тільки сайт почне працювати локально, завантажте його код у репозиторій GitHub. GitHub забезпечує історію версій та безпечний спосіб скасування будь-яких змін, внесених асистентом.

Далі під’єднайте цей репозиторій до Cloudflare, щоб кожен додавання змін у репозиторій запускало автоматичне створення та розгортання проекту. З цього моменту публікація полягає просто у збереженні змін та їх надсиланні. Для невеликого інформаційного сайту у цьому випадку достатньо було безкоштовного тарифу Cloudflare; перевірте поточні обмеження тарифу відповідно до ваших потреб.

Коли домен активний та його DNS-записи налаштовані, приєднайте власний домен до розгорнутого проекту. У цей момент введення домену у браузер покаже живий сайт.

Скільки це коштує та де цей підхід не підходить

Для такого проекту постійні витрати є незначними:

• Реєстрація домену: приблизно 12 доларів на рік у цьому випадку.
• GitHub: безкоштовно.
• Cloudflare: безкоштовний тариф виявився достатнім.
• Інструменти ШІ: стільки, скільки коштує ваша підписка на ChatGPT чи інший асистент.

Окрім підписки на асистента, домен є практично єдиним витратним елементом інфраструктури.

Цей підхід не підходить для кожного додатку. Усе, що пов’язано з оплатами, конфіденційними персональними даними, складною автентифікацією, базами даних чи регульованими середовищами, вимагає належної інженерної роботи: моделювання загроз, перевірки коду фахівцем, який розуміє кожну його лінію, тестування та моніторинг роботи. Однак для портфоліо, лендінг-сторінок, сайтів консалтингу, прототипів та простих сайтів із контентом бар’єри для входу значно нижчі, ніж раніше.

Що вирішує, а що не вирішує асистент

Асистент бере на себе значну частину виконавчих завдань: написання та редагування коду, перетворення відгуків щодо дизайну на зміни, усунення візуальних проблем та пояснення незнайомих технічних кроків. Проте деякі рішення залишаються суто людськими:

• Що має представляти сайт.

Який контент має значення.

Чи є візуальний дизайн прийнятним.

Коли перша версія вже достатньо готова до релізу.

Це усуває головну перешкоду. Ключове питання більше не полягає у тому, чи можете ви технічно створити сайт, а у тому, чи можете ви чітко визначити, що саме хочете. Бар’єри реалізації знижуються; потреба у розсудливості — ні.

Основні висновки

• Визначте мету, цільову аудиторію та основне послання ще до вибору будь-якої технології.
• Попросіть модель запропонувати та обґрунтувати дизайн перед написанням коду та чітко схваліть обраний напрямок.
• Обробляйте логотип окремо, щоб він працював у всіх форматах, а не лише у заголовку сайту.
• Використовуйте короткі, конкретні етапи ітерацій із обмеженням „зберегти все інше“ та списком самоперевірки.
• Використовуйте асистента як критика, так і помічника у створенні контенту, отримуючи пріоритезовані та конкретні відгуки.
• Розмістіть код на GitHub та дозвольте Cloudflare розгортати його після кожного pushу, щоб контроль версій та хостинг відбувалися автоматично.
• Застосовуйте цей легкий підхід лише до сайтів з низьким рівнем ризику. Цінність полягає у тому, як всі елементи поєднуються в єдиний робочий процес: ви контролюєте мету, прийняття рішень та схвалення, асистент бере на себе виконання завдань, GitHub зберігає історію змін, а Cloudflare здійснює публікацію.