Вайб-кодинг с нуля: 6 частей запроса, который собирает рабочий сайт

По теме выходит новый практикум. Там путь от идеи до работающего результата проходит руками, а не только на примерах. Подробнее о практикуме

Вайб-кодинг простыми словами: что это и как он работает

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

Дальше начинается настоящая работа. Первый результат почти всегда требует правок:

1. Уточнить, что должно быть на странице.
2. Попросить изменить конкретный блок.
3. Проверить страницу в работе.
4. Найти расхождение с задачей.
5. Снова описать нужное изменение.
6. Запустить проверку после правки.

ИИ видит текст запроса, файлы, доступный контекст и результаты команд, но не знает замысел целиком. Если задача звучит как «сделай красиво», агент сам решает, что значит «красиво». Один раз получится удачно. В другой раз появится лишний экран, исчезнет рабочая кнопка или изменится половина проекта.

Поэтому хороший цикл выглядит так:

1. Сформулировать цель.
2. Дать агенту изучить текущие файлы.
3. Попросить короткий план.
4. Подтвердить план.
5. Внести небольшое изменение.
6. Проверить, что оно работает.

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

Чем вайб-кодинг отличается от обычного программирования

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

В агентном маршруте часть этих действий передаётся Claude Code. Он может:

• найти подходящий файл;
• прочитать связанный код;
• предложить изменения;
• после подтверждения отредактировать файлы;
• запустить доступные команды проверки;
• исправить обнаруженные ошибки.

Человек остаётся в процессе и отвечает за цель, границы, приоритеты и оценку результата. ИИ-агент берёт на себя большую часть технических действий внутри заданной рабочей директории.

Такое распределение и есть автоматизация: агент не только подсказывает, а напрямую выполняет задачи. Вайб-кодинг строится именно на этом переходе от построчного написания кода к управлению действиями агента через цель и обратную связь.

Разница видна на примере.

При обычном подходе задача может звучать так: «Открой src/components/Hero.tsx, добавь кнопку, задай ей класс, подключи обработчик и проверь сборку». Человек сам пишет каждую часть.

При вайб-кодинге запрос может быть таким: «Добавь на первый экран кнопку “Записаться”, ведущую к форме контактов. Сохрани десктопную версию без изменений. После правки запусти сборку». Агент сам ищет компонент, выбирает место изменения и выполняет команды. Но результат всё равно нужно проверить.

Ключевая ошибка новичка - считать агента автономным разработчиком, который сам понимает бизнес-цель. Агент действует по доступному контексту. Неясная задача даёт неясный результат. Без проверки ошибка может остаться незамеченной.

Подходит ли вайб-кодинг новичку и что нужно для старта

Терминал нужен для запуска Claude Code и команд проекта. Папка проекта нужна как рабочая граница: Claude Code запускается из директории проекта и работает с ней и вложенными каталогами.

Минимальный набор такой:

• открытый терминал или командная строка;
• папка с проектом;
• Claude Code;
• аккаунт Claude, подписка, Claude Console или поддерживаемый облачный доступ.

Anthropic рекомендует нативную установку Claude Code. Для macOS, Linux и WSL документация приводит такую команду:

curl -fsSL https://claude.ai/install.sh | bash

Для Windows PowerShell используется другая команда:

irm https://claude.ai/install.ps1 | iex

После установки Claude Code запускается из папки проекта командой:

claude

Учитывай три ограничения.

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

Второе - результат требует проверки. Он может изменить файлы и запустить команды, но сообщение «готово» само по себе не доказывает, что сайт работает.

Третье - агенту нужны границы доступа. Для первого проекта достаточно отдельной папки. Не клади туда секреты, ключи и файлы, которые не относятся к задаче. Не подтверждай непонятные команды автоматически.

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

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

Какую первую задачу выбрать, чтобы собрать сайт за вечер

Первый проект должен иметь видимый результат без сложной инфраструктуры. Хорошие варианты:

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

ai-website-builder - локальный шаблон для сборки и изменения сайта через разговор с AI-ассистентами. Он ближе всего к задаче «собрать настоящий сайт». Для него нужны Git, Node.js и доступ к AI-инструменту.

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

Не выбирай для первого вечера задачу, где рабочий результат зависит от большого числа внешних частей:

• база данных;
• авторизация;
• API;
• машинное обучение;
• OCR;
• торговая симуляция;
• несколько автономных агентов;
• сложный каталог на Next.js с автоматической генерацией данных.

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

Размер первой цели можно проверить одним вопросом: «Смогу ли я показать результат в браузере и понять, что именно сломалось, если он не заработает?» Если ответ отрицательный, задачу пора уменьшить.

Как начать вайб-кодинг: от папки до первого запуска

1. Открой терминал в системе. Подойдёт терминал или командная строка, из которой можно запускать команды. В Windows используй PowerShell или рабочее окружение, настроенное для Claude Code.

2. Установи Claude Code. Для macOS, Linux и WSL выполни:

curl -fsSL https://claude.ai/install.sh | bash

Для Windows PowerShell выполни:

irm https://claude.ai/install.ps1 | iex

3. Войди в аккаунт Claude. Для работы нужен Claude subscription, Claude Console account или поддерживаемый облачный доступ.

4. Создай или открой папку проекта. Важно перейти именно в корень проекта. Для Linux, macOS и WSL пример выглядит так:

mkdir -p ~/projects/my-first-site
cd ~/projects/my-first-site

В PowerShell:

mkdir C:\Users\you\projects\my-first-site
cd C:\Users\you\projects\my-first-site

5. Запусти Claude из папки.

claude

В PowerShell команда такая же:

claude

1. Попроси изучить проект.

   Если папка новая, агент увидит пустую структуру. Если в ней уже есть файлы, сначала попроси описать их назначение и технологии.

   Скопировать

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

2. Попроси составить план.

   План нужен до первой крупной правки. Он помогает увидеть, какие файлы агент собирается затронуть.

   Скопировать

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

3. Проверь предложенные изменения.

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

4. Подтверди запись файлов.

   Claude Code запрашивает разрешение перед изменениями в зависимости от режима разрешений. Подтверждай только понятные действия внутри папки проекта.

5. Попроси выполнить первую часть.

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

   Скопировать

   Создай только каркас одностраничного сайта по согласованному плану. После создания покажи изменённые файлы и запусти доступную проверку.

6. Запусти проверку.

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

7. Осмотри результат.

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

8. Повтори цикл.

   Для каждого следующего блока снова формулируй действие, ограничение и проверку.

Если Claude Code печатает код в ответе, но не создаёт файл, сначала проверь, что запущен именно Claude Code, а не обычный чат. Затем проверь текущую папку и разрешение на запись.

Что попросить Claude сделать перед первой правкой

Маршрут из документации выглядит так:

1. Изучить проект.
2. Составить план.
3. Внести изменение.
4. Проверить результат.

Первый запрос может быть коротким:

Что делает этот проект? Опиши структуру файлов и технологии. Не меняй файлы.

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

Следующий запрос:

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

После проверки плана можно разрешить изменение:

План подтверждаю. Внеси только описанное изменение. Не трогай остальные страницы и не добавляй новые зависимости. После правки запусти указанную проверку.

Документация Claude Code описывает похожую последовательность: агент находит нужный файл, показывает предлагаемые изменения, просит разрешение, редактирует файл и запускает доступные проверки.

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

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

Как написать запрос, чтобы сайт получился рабочим

По моему опыту, недостаточно написать: «Сделай красивый сайт кофейни». Агенту неизвестны количество блоков, стиль, поведение кнопок, ограничения по файлам и способ проверки.

Собери запрос из шести частей:

• цель страницы;
• страницы и блоки;
• ограничения;
• текущие файлы или технологии;
• критерий готовности;
• команда проверки.

Цель отвечает на вопрос «что должно получиться». Блоки задают состав страницы. Ограничения удерживают агента от лишних изменений. Критерий готовности превращает субъективное «нормально» в проверяемое условие.

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

Собери одностраничный сайт-портфолио для начинающего дизайнера.

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

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

Готово, когда первый экран, блок проектов и контакты видны, кнопка работает, мобильная версия не ломает структуру, а проверка проходит.

Шаблон уже разделён на четыре фазы: изучить, спланировать, реализовать, зафиксировать. В последней фазе агент показывает изменённые файлы и способ проверки. Это снижает риск получить красивое описание вместо рабочего результата.

Если проект уже существует, добавь конкретные пути:

Прочитай @src/pages/Home.tsx и @src/styles/home.css.
Измени только мобильную раскладку между 375px и 768px.
Десктопную версию не меняй.
После правки запусти сборку.

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

Как собирать сайт небольшими частями и не запутать ИИ

Я пришёл к такому порядку:

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

2. Сделай первый экран. Добавь заголовок, описание, кнопку и визуальный стиль.

3. Добавь содержательные блоки. Внеси преимущества, проекты, меню или другой контент, который нужен странице.

4. Подключи форму. Сначала добейся корректного отображения и поведения элементов формы.

5. Проверь мобильную версию. Отдельно попроси проверить небольшую ширину и сохранить десктоп без изменений без причины.

6. Запусти проверки. Проверь сборку и доступные тесты после заметного изменения.

7. Подготовь публикацию. Только после локальной проверки переходи к целевой платформе.

Большая задача теряет связность по мере заполнения контекста. В длинном диалоге накапливаются файлы, ошибки, планы и старые ограничения. Агент может начать забывать ранние инструкции или допускать больше ошибок.

Когда один этап завершён, попроси сохранить состояние в сообщении:

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

Если следующая задача независима, начни новый контекст через:

/clear

Если задача связана с текущей, но контекст переполнен, используй:

/compact

В новую сессию передай короткую сводку и конкретную цель. Не нужно пересказывать весь разговор.

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

Как проверить сайт, а не просто поверить ответу Claude

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

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

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

Не добавляй проверку только в финальный запрос. После каркаса проверь каркас. Форму проверь сразу после её создания. Мобильную версию проверь после правки.

Агенту можно дать конкретный чек:

Проверь результат по списку:
- сайт запускается;
- сборка проходит;
- первый экран виден;
- кнопка реагирует на клик;
- мобильная ширина не ломает блоки;
- в консоли нет новых ошибок;
- форма принимает ввод и ведёт себя согласно задаче.

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

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

Если агент пишет «всё готово», попроси факты:

Какие файлы изменены? Какие команды проверки запущены? Какой был результат каждой команды? Какие пункты из чек-листа проверены вручную?

Такой запрос переводит разговор с уверенной оценки на перечисление действий и наблюдений.

Что делать, если после правки сайт сломался

Сначала не проси Claude чинить всё поверх сломанного состояния. Новая правка может усложнить откат. Зафиксируй, что именно работало и после какого действия появилась проблема.

Для отката доступны два варианта:

/rewind

Или дважды нажать Esc.

При восстановлении можно вернуть:

• код;
• разговорный контекст;
• код и контекст одновременно.

Выбор зависит от причины сбоя. Если сломался только файл, достаточно вернуть код. Если агент потерял направление и продолжил неправильный план, может потребоваться восстановить и контекст.

Checkpoints имеют ограничение. Они сохраняют изменения Claude, но не покрывают ручные правки пользователя и произвольные Bash-команды. Поэтому не считай checkpoint полной историей проекта.

Git нужен как дополнительная страховка. Его роль - хранить версии и помогать вернуться к рабочему состоянию после неудачной итерации. Перед активными изменениями полезно иметь зафиксированную рабочую версию.

Рабочий порядок такой:

1. Сохрани рабочее состояние в Git.
2. Выполни одну заметную правку.
3. Проверь сайт.
4. Если всё работает, сохрани следующую версию.
5. Если сайт сломался, останови агента.
6. Используй /rewind, двойное нажатие Esc или Git.
7. Повтори правку с более узким запросом.

Не откатывай вручную всё подряд, если проблема появилась после команды, которую запускал ты сам. Checkpoints не обязательно вернут результат произвольного Bash-действия.

Почему Claude печатает код, а не создаёт файлы

Частая ошибка - смешать два режима. В обычном чате можно получить готовый фрагмент кода, но он не появится на диске сам. Claude Code работает с файлами проекта из терминала.

Правильная последовательность для PowerShell:

cd C:\path\to\project
claude

Для macOS, Linux и WSL:

cd ~/projects/my-first-site
claude

После запуска дай конкретную команду:

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

Если Claude просит подтверждение операции Write или Edit, проверь путь и разреши действие, если оно относится к нужному проекту.

Если агент снова только печатает код, проверь:

• запущен ли Claude Code, а не обычный чат;
• находишься ли ты в корне проекта;
• не пытается ли агент записать файл выше рабочей директории;
• есть ли разрешение на запись;
• не ограничены ли операции настройками проекта.

Используй относительные пути:

Создай src/components/Hero.tsx в текущем проекте.

Так агенту проще понять границу работы. Абсолютный путь к случайной папке повышает риск ошибки и запроса дополнительных разрешений.

Почему команда claude не находится и проект тормозит в Windows

После установки программа может быть на диске, но терминал не знает, где искать бинарник. Для Zsh добавь каталог в PATH и перечитай настройки:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc
claude

Для Bash замени файл настроек:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
claude

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

В WSL другая проблема связана с расположением файлов. Путь /mnt/c/Users/... ведёт к смонтированной Windows-файловой системе. Для проекта с большим количеством файлов это может замедлять чтение, поиск, сборку и обновление.

Официальный FAQ Claude Code рекомендует хранить репозиторий внутри Linux-файловой системы:

mkdir -p ~/projects
cd ~/projects
git clone <repository>
cd <project>
claude

Не запускай рабочую сессию из:

/mnt/c/Users/...

Вместо этого используй:

~/projects/my-first-site

Перенос проекта в ~/projects не исправляет уже сломанные команды сам по себе. Он меняет место, из которого WSL читает и обновляет файлы. После переноса снова открой нужную директорию и запусти Claude Code из неё.

Как безопасно подготовить сайт к публикации

Вайб-кодинг создаёт и меняет проект. Публикация - отдельный этап; способы выложить сайт наружу собраны в статье «Куда выложить сайт, который собрал ИИ». По этой фактуре нельзя рекомендовать конкретный хостинг: источник описывает общий порядок, но не выбирает Vercel, Netlify, GitHub Pages или другую платформу.

Перед деплоем пройди последовательность:

1. Запусти тесты. Используй тестовую команду, которая уже предусмотрена проектом.

2. Собери приложение. Сборка должна пройти без ошибок.

3. Отправь проект на целевую платформу. Платформа зависит от конкретного проекта и выбранного способа размещения.

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

Для агента можно сформулировать подготовительную задачу:

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

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

Управляемый сценарий выглядит так:

1. Run the test suite
2. Build the application
3. Push to the deployment target
4. Verify the deployment succeeded

В статье это можно передать так:

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

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

Вопросы и ответы