Как создать сайт, используя одни нейросети

Термин 4. Флекс

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

Пример из жизни. Вы расставляете тарелки на столе в ряд, ровно по центру, с одинаковыми промежутками. Это флекс. Вы говорите «пусть все тарелки будут на расстоянии 5 сантиметров друг от друга и ровно посередине стола» — флекс делает это автоматически.

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

Чего бояться не надо. Главное запомнить: грид — для сеток (когда много блоков в разные стороны), флекс — для линий (когда блоки идут в один ряд). Но если перепутаете, нейросеть всё равно поймёт и сделает правильно.

Термин 5. Ховер

Перевод на человеческий. Это состояние, когда курсор мыши наведён на элемент. Кнопка обычно серая. Вы навели мышь — кнопка стала синей. Это ховер. Убрали мышь — снова серая. Ховер делает сайт живым, отзывчивым.

Пример из жизни. Кнопка лифта. Обычно она не светится. Вы подносите палец — загорается подсветка. Убрали палец — погасла. Это ховер в реальном мире.

Как использовать в промте. «Добавь ховер для кнопок: при наведении фон меняется с зелёного на тёмно-зелёный, курсор становится указателем». Или: «Сделай ховер для карточек товаров: при наведении появляется тень и карточка слегка поднимается вверх».

Чего бояться не надо. Ховер работает только на устройствах с мышкой. На телефонах его нет (там нет курсора). Нейросеть знает об этом и не будет пытаться починить физику.

Термин 6. Паддинг (внутренний отступ)

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

Пример из жизни. Текст в книге никогда не напечатан до самого края страницы. Всегда есть поля сверху, снизу, слева, справа. Это паддинг страницы. Без него читать было бы неудобно.

Как использовать в промте. «Добавь внутренние отступы (паддинг) внутри карточек: 20 пикселей со всех сторон». Или: «Сделай так, чтобы текст в кнопке не касался краёв кнопки — добавь паддинг 12 пикселей сверху и снизу, 24 пикселя слева и справа».

Чего бояться не надо. Паддинг и маржин (следующий термин) часто путают даже начинающие программисты. Нейросеть привыкла к этой путанице и переспросит, если что-то неясно. Но лучше сразу говорить «внутренний отступ» для паддинга и «внешний отступ» для маржина.

Термин 7. Маржин (внешний отступ)

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

Пример из жизни. Расстояние между стульями в кинотеатре. Если стулья вплотную — неудобно. Если между ними 20 сантиметров — нормально. Если полметра — роскошно. Это маржин.

Как использовать в промте. «Добавь внешний отступ (маржин) снизу каждого заголовка 30 пикселей, чтобы текст не прилипал к следующему блоку». Или: «Сделай так, чтобы между карточками товаров было расстояние 24 пикселя — добавь маржин справа для каждой карточки, кроме последней».

Чего бояться не надо. Запомните простое правило: паддинг — это «внутри блока, от края до содержимого». Маржин — это «снаружи блока, от блока до соседей». Если запомнили — вы уже умнее половины новичков.

Термин 8. Брейкпоинт (точка перелома)

Перевод на человеческий. Это ширина экрана, при которой сайт меняет своё поведение. До брейкпоинта сайт выглядит как компьютерная версия. После брейкпоинта включается мобильная версия.

Пример из жизни. Вода в реке. До плотины — одна ширина. В точке плотины — перелом. После плотины — другая ширина. Брейкпоинт — это плотина. До неё сайт один, после — другой.

Как использовать в промте. «Сделай брейкпоинты для адаптива: на экранах шире 1024 пикселей — три колонки, на экранах от 768 до 1024 — две колонки, на экранах меньше 768 — одна колонка». Или просто: «Адаптив сделай с брейкпоинтами 1024 и 768 пикселей».

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

Термин 9. Заглушка

Перевод на человеческий. Это временное содержимое, которое вы потом замените на настоящее. Вместо реальной фотографии котика — серый прямоугольник с надписью «Тут будет фото». Вместо настоящего текста — «Lorem ipsum dolor sit amet». Вместо реальной цены — «999 руб».

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

Как использовать в промте. «Вместо реальных фотографий поставь серые квадраты-заглушки с текстом „Фото“. Вместо реальных цен поставь „от 1000 руб“ как заглушку. Я потом заменю». Или: «Наполни карточки товаров текстом-заглушкой, но сохрани структуру».

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

Термин 10. Контейнер

Перевод на человеческий. Это блок, который ограничивает ширину контента по краям экрана. Представьте газету. Текст не расползается на весь стол — он ограничен шириной колонки. Контейнер делает то же самое: на огромном мониторе сайт не растягивается на все 3000 пикселей, а останавливается на 1200 пикселях и центрируется.

Пример из жизни. Вы кладёте вещи в чемодан. Чемодан — это контейнер. Вещи не вываливаются наружу. Контейнер на сайте — такой же чемодан для контента.

Как использовать в промте. «Заверни весь контент в контейнер с максимальной шириной 1200 пикселей и выровняй по центру страницы». Или: «Сделай контейнер для текста шириной 800 пикселей, чтобы читать было комфортно».

Чего бояться не надо. Контейнер — это просто «ограничитель ширины». Если не знаете, какую ширину поставить — ставьте 1200 пикселей для компьютера. Нейросеть поймёт.

Как просить нейросеть, используя эти слова без страха

Вот три готовые фразы-шаблона, которые покрывают 90% ситуаций. Просто копируйте и заменяйте свои значения.

Шаблон 1. Для структуры (макет + контейнер + грид/флекс).

«Сделай макет сайта из следующих блоков: шапка, геройский блок, три карточки в грид, форма, футер. Весь контент заверни в контейнер с максимальной шириной 1200 пикселей по центру. Карточки расположи в грид три колонки на компьютере, на телефоне — одну колонку (адаптив). Меню в шапке сделай через флекс, пункты прижаты к правому краю».

Шаблон 2. Для деталей (паддинг + маржин + ховер).

«Добавь внутренние отступы (паддинг) внутри карточек: 20 пикселей со всех сторон. Внешний отступ (маржин) между карточками сделай 24 пикселя. Для кнопок добавь ховер: при наведении фон становится темнее, курсор — указатель, лёгкое увеличение тени».

Шаблон 3. Для работы с заглушками.

*«Вместо реальных изображений поставь серые прямоугольники-заглушки с текстом „Фото“. Текст в карточках пока сделай текстом-заглушкой (Lorem ipsum). Цены пока поставь „от 1000 руб“ как заглушку. Структура важнее содержания, заглушки потом заменю». *

Главная идея девятой главы

Эти 10 слов — не программирование.

Это просто названия вещей, которые вы и так знаете.

Макет — это план.

Адаптив — чтобы работало на телефоне.

Грид — ровные ряды и колонки.

Флекс — выравнивание в линию.

Ховер — реакция на мышь.

Паддинг — отступ внутри.

Маржин — отступ снаружи.

Брейкпоинт — ширина, где сайт меняется.

Заглушка — временное содержимое.

Контейнер — ограничитель ширины.

Вы не обязаны использовать эти слова. Нейросеть поймёт и без них. Но с ними вы говорите на её языке. А на родном языке вас понимают быстрее, точнее и без лишних уточнений.

ПРАКТИКУМ К ГЛАВЕ 9

Задание 1 (5 минут).

Откройте нейросеть и отправьте промт, в котором вы используете как можно больше из этих 10 слов. Не важно, правильно или нет. Просто попробуйте. Например: «Сделай макет сайта. В контейнере 1200px. Три карточки в грид. Адаптив. Паддинг в карточках 20px. Маржин между карточками 24px. Ховер для кнопок. Заглушки вместо фото». Посмотрите на результат. Нейросеть поняла?

Задание 2 (5 минут).

Возьмите любой старый промт из первых глав, где вы использовали «народный язык» («сделай три штуки в ряд, чтобы красиво, и чтобы на телефоне нормально было»). Перепишите его, используя термины из этой главы («сделай грид из трёх колонок, добавь адаптив с брейкпоинтом 768px»). Сравните результаты. Второй вариант будет точнее?

Задание 3 (3 минуты).

Распечатайте или перепишите от руки эти 10 слов с краткими пояснениями:

— Макет — план расположения блоков

— Адаптив — работает на телефонах

— Грид — сетка для блоков (ряды и колонки)

— Флекс — выравнивание в линию

— Ховер — эффект при наведении мыши

— Паддинг — отступ внутри блока

— Маржин — отступ снаружи блока

— Брейкпоинт — ширина, где сайт перестраивается

— Заглушка — временный текст/картинка

— Контейнер — ограничитель ширины

Повесьте этот лист рядом с компьютером. Через неделю вы будете знать их наизусть.

Задание 4 (по желанию, 10 минут).

Попросите нейросеть объяснить эти же 10 терминов так, будто вы пятилетний ребёнок. Или так, будто вы профессор филологии. Сравните объяснения. Это упражнение покажет вам, насколько гибко нейросеть подстраивается под аудиторию. И заодно закрепит термины в голове.

ГЛАВА 10. Как тестировать и «допрашивать» нейросеть, чтобы она сама находила свои баги

К этому моменту вы уже создали не один десяток промтов. Вы получили кучу кода. Что-то работало сразу, что-то — после пары уточнений. Но рано или поздно случается ситуация, от которой волосы встают дыбом.

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

И вы сидите и думаете: «Что мне теперь написать? „Почини“? Но что именно чинить? Я же не знаю, в чём проблема».

Знакомая боль? Это нормально. Вы не программист, вы не обязаны знать, где ошибка. Но вы можете заставить нейросеть найти её самостоятельно.

Это называется «допрос нейросети». Вы становитесь следователем, а нейросеть — свидетелем, который что-то знает, но не говорит, пока вы не спросите правильным образом.

Почему нейросеть врёт (и не замечает этого)

Нейросети обладают удивительным свойством: они уверены всегда. Даже когда неправы.

Если нейросеть ошиблась в коде, она не скажет: «Извините, кажется, я допустила ошибку в 15-й строке, вот исправленный вариант». Она просто выдаст код, который ей кажется правильным. А вы будете мучиться.

Это происходит не потому, что нейросеть злая или глупая. Просто у неё нет встроенного «тестировщика». Она умеет генерировать ответы, но не умеет проверять свои ответы на ошибки — если вы её об этом не попросите.

Ваша задача — стать этим внешним тестировщиком. Но не через знание кода, а через правильные вопросы.

Три главных закона допроса нейросети

Прежде чем мы перейдём к конкретным техникам, запомните три закона. Они работают всегда.

Закон 1. Никогда не проси «почини сайт». Всегда проси «найди ошибку».

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

Закон 2. Давай нейросети «улики» — скриншоты, описание поведения, ошибки из консоли.

Чем больше улик, тем точнее диагноз. Скриншот того, как выглядит сломанный сайт. Описание «кнопка не нажимается вообще» или «кнопка нажимается, но форма не отправляется». Красные строчки ошибок из консоли браузера (F12). Всё это — улики.

Закон 3. Заставляй нейросеть объяснять, прежде чем исправлять.

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

Техника 1. «Красная строка из консоли» (самая простая и мощная)

Вы открываете сайт в браузере. Что-то не работает. Вы нажимаете клавишу F12. Открывается панель разработчика. Там есть вкладка «Console» (Консоль). Там красные строчки. Это браузер сам говорит, в чём ошибка.

Вы копируете эти красные строчки. Целиком. Вместе со словами «Uncaught TypeError» и всем, что там есть.

Вы вставляете их в чат с нейросетью и пишете:

«Вот код моего сайта. [Вставить код]. Вот ошибка из консоли браузера: [вставить красные строчки]. Объясни, в чём проблема, и дай исправленный код. Ничего больше не меняй».

Нейросеть прочитает ошибку, поймёт, где проблема (например, «вы пытаетесь вызвать функцию showMessage, но она не определена»), и исправит код.

Вы не поняли ни слова из красной строки. Это не важно. Нейросеть поняла.

Этот приём закрывает 70% всех багов. Серьёзно. 70%. Потому что браузер уже нашёл ошибку, он просто не умеет её чинить. А нейросеть умеет чинить, но не видит ошибку, пока вы ей не покажете. Вместе они — идеальная команда.

Техника 2. «Скриншот как улика»

Некоторые ошибки не показываются в консоли. Кнопка не того цвета. Текст налезает на картинку. Блок съехал влево. Это визуальные баги.

Современные нейросети (GPT-4o, Gemini с функцией просмотра картинок) умеют смотреть на скриншоты. Вы делаете скриншот того, что видите в браузере. Сохраняете как картинку. Загружаете в чат (там обычно есть кнопка скрепки или «загрузить изображение»). И пишете:

«Посмотри на этот скриншот. Вот что не так: текст налезает на картинку (отмечено красной стрелкой на скриншоте). Вот мой код. Исправь, чтобы текст был под картинкой, а не на ней».

Нейросеть увидит проблему своими глазами (да, она действительно «видит» картинки) и предложит исправление.

Если ваша нейросеть не умеет смотреть картинки (например, бесплатный ChatGPT без GPT-4o или Claude), вы описываете проблему словами максимально подробно:

«В блоке с карточкой товара картинка имеет ширину 100%, а текст начинается прямо под ней, но налезает на 20 пикселей. Нужно, чтобы текст был строго под картинкой, с отступом 16 пикселей сверху».

Чем точнее описание, тем лучше исправление.

Техника 3. «Скажи, что не так» (провокация на объяснение)

Вы получили код. Он не работает. Вы не знаете, в чём проблема. Вы не видите красных строк в консоли. Скриншот выглядит нормально, но кнопка не нажимается.

Вы отправляете нейросети такой промт:

«Вот код. Он не работает так, как задумано. Кнопка „Отправить“ ничего не делает. Не давая новый код, объясни, какие 5 возможных причин могут вызывать эту проблему. Просто перечисли гипотезы».

Нейросеть начнёт рассуждать:

«Возможные причины:

— У кнопки не указан обработчик события onclick или addEventListener.

— Функция-обработчик не определена (опечатка в имени).

— Форма отправляется на сервер, но нет бэкенда, а нужно предотвратить стандартное поведение (preventDefault).

— Код JavaScript находится в неправильном месте (до того, как кнопка загрузилась).

— Ошибка в консоли, которую вы не заметили (проверьте ещё раз)».

Вы читаете этот список. Проверяете каждый пункт. В пункте 4 узнаёте свою ситуацию: да, JS-код стоит в начале, до кнопки. Вы говорите нейросети: «Проблема в пункте 4. Как исправить?»

Нейросеть даёт точное исправление.

Вы нашли ошибку, не понимая кода. Вы просто попросили нейросеть подумать вслух, а сами выступили в роли следователя, который выбирает правильную версию.

Техника 4. «Протестируй свой код сам»

Самый элегантный приём. Вы заставляете нейросеть быть своим собственным тестировщиком.

Промт выглядит так:

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

Нейросеть вернёт список:

«Проблема 1: Картинки не имеют атрибута alt — плохо для SEO и доступности. Исправление: добавьте alt=«описание картинки».

Проблема 2: Кнопки имеют слишком маленький размер на мобильных устройствах (36px). Исправление: увеличьте до 48px с помощью медиа-запроса.

Проблема 3: Отсутствует обработка ошибок в форме — при пустом поле телефон форма всё равно отправляется. Исправление: добавьте проверку на пустоту».

Вы получаете готовый список того, что нужно исправить. Вы отправляете его нейросети обратно: «Исправь проблемы 1, 2 и 3». И получаете идеальный код.

Вы не нашли ни одной ошибки сами. Вы просто попросили нейросеть найти ошибки в своём же коде.

Техника 5. «Код ревью» (как у настоящих программистов)

Программисты делают «ревью» — когда один смотрит код другого и ищет проблемы. Вы можете устроить ревью, где нейросеть смотрит свой код, но от лица другого эксперта.

Промт:

*«Ты — строгий технический лид с 10-летним стажем. Вот код моего сайта. Проведи код-ревью. Укажи на все недостатки: дублирование кода, плохие названия переменных, проблемы с производительностью, несовместимость с браузерами. Для каждого недостатка предложи улучшенный вариант. Будь максимально критичен». *

Нейросеть выдаст разбор:

«1. В строках 45—48 вы трижды используете один и тот же стиль для кнопок. Вынесите в общий класс. button.

— Вы используете alert () для сообщений — это раздражает пользователей. Используйте кастомное модальное окно.

— Картинки не сжаты — добавьте в код атрибуты width/height, чтобы избежать скачков вёрстки».

Вы отправляете: «Исправь всё, что нашёл». И получаете код, который прошел бы проверку в любой IT-компании.

Техника 6. «Сравни с эталоном»

У вас есть две версии кода. Первая — та, что работает (или ближе к истине). Вторая — та, что не работает. Вы просите нейросеть сравнить их.

Промт:

«Вот код А (работает как надо). Вот код Б (не работает, кнопка не нажимается). Сравни их и покажи различия. Объясни, какое различие вызывает проблему. Исправь код Б по образцу кода А».

Нейросеть подсветит различия:

«Код А: button.addEventListener (’click’, showMessage);

Код Б: button.addEventListener (’click’, showMassage);

Разница: опечатка в названии функции showMassage вместо showMessage. Исправляю».

Вы бы никогда не заметили эту опечатку. Нейросеть заметила за секунду.

Техника 7. «Воспроизведи шаги» (для сложных логических багов)

Бывает, что код работает, но при определённых действиях ломается. Например: «Если нажать кнопку „Добавить в корзину“ два раза подряд, цена удваивается, а должна оставаться прежней».

Вы описываете нейросети последовательность действий:

«Вот код корзины. Шаги воспроизведения бага: 1. Открыть сайт. 2. Нажать „Добавить“ на товаре „Кофе“. 3. Снова нажать „Добавить“ на том же товаре. Результат: в корзине две позиции „Кофе“ вместо одной с количеством 2. Ожидаемое поведение: одна позиция, количество 2. Найди ошибку и исправь».

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

Чем точнее вы опишете шаги, тем точнее будет исправление.

Создаём «План допроса» для любой ситуации

Теперь соберём всё вместе. Вот пошаговый алгоритм, который вы применяете, когда что-то идёт не так.

Шаг 1. Соберите улики.

Откройте консоль (F12) и скопируйте красные ошибки. Сделайте скриншот визуального бага. Опишите словами, что именно не работает и при каких действиях.

Шаг 2. Отправьте нейросети запрос на диагностику.

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

Шаг 3. Добейтесь объяснения, а не исправления.

Сначала попросите объяснить проблему. Если объяснение звучит логично и соответствует тому, что вы видите, переходите к шагу 4. Если нейросеть путается — попросите уточнить или дайте больше улик.

Шаг 4. Дайте команду на исправление.

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

Шаг 5. Проверьте исправление.

Вставьте новый код. Работает? Отлично. Не работает? Вернитесь к шагу 1, но теперь добавьте в промт: «Предыдущее исправление не сработало. Вот новый код и та же ошибка. Найди другую причину».

Чего никогда не надо делать при допросе

Вот список действий, которые гарантированно приведут к провалу.

Не надо. Просить «почини» без объяснения, что именно сломано.

Надо. Описать проблему словами, скриншотом или ошибкой из консоли.

Не надо. Отправлять один промт «всё сломано, переделай с нуля».

Надо. Сохранять то, что работает, и чинить только то, что сломано.

Не надо. Злиться на нейросеть и писать капслоком «ТЫ ТУПАЯ, СДЕЛАЙ НОРМАЛЬНО».

Надо. Спокойно дать больше улик. Нейросеть не обижается, но от капслока умнее не становится.

Не надо. Править код вручную, надеясь на лучшее.

Надо. Вернуться к нейросети с уточнением. Ваши ручные правки нейросеть не видит и может их затереть.

Не надо. Пытаться понять код, чтобы найти ошибку.