ИИ для создания веб-сайта: как Claude правит код и деплоит без доступа к продакшену

Речь не о генераторах одностраничников. Речь о связке, где внешняя языковая модель (например, Claude через API) получает доступ к терминалу на отдельном сервере разработки и делает ровно то, что делал бы программист руками: читает файлы, правит код, запускает сборку. При этом рабочий сайт обновляется только через автоматический пайплайн, а контент (статьи, поля в WordPress) живёт отдельно от кода и не зависит от его откатов. Ниже разберём, что для этого нужно и как повторить.

Что понадобится?

• Два VDS-сервера (или два каталога на одном). Dev-сервер для разработки, prod-сервер для рабочего сайта. Минимальная цена prod-сервера от 2 000 рублей в месяц
• Стек сайта: Next.js плюс headless WordPress (CMS без фронтенда, которая отдаёт контент через API) плюс MariaDB
• MCP-сервер (Model Context Protocol, протокол, через который модель получает «руки» на сервере). Один файл на Node.js, около 11 КБ
• Внешний API языковой модели: Claude или аналог. Бюджет на токены (единицы текста, которые модель обрабатывает за один запрос) при активной разработке составляет от 50 до 100 долларов в месяц
• GitHub-аккаунт с настроенным CI/CD (автоматическая сборка и доставка кода на сервер через GitHub Actions)
• Playwright (инструмент для автоматических скриншотов) для проверки результата на стейджинге
• Время на первую настройку: один-два дня на связку серверов и пайплайна, дальше каждая правка занимает минуты

Как устроен цикл от запроса до обновления сайта?

1. Формулируете задачу на обычном языке. Например: «Прижми кнопку в блоке героя на главной к левому краю контейнера». Никакого технического задания на три недели переписки.

2. Модель читает документацию проекта и код. Она выполняет команду вроде cat docs/*.md, загружает карту секций и дизайн-систему, затем смотрит сам код. Это не дообучение (fine-tuning, обучение модели на ваших примерах): проектная база знаний достаточно компактна и целиком помещается в контекст запроса.

3. Модель правит файлы на dev-сервере. Все изменения происходят только на сервере разработки. В описанной архитектуре это VDS в Нидерландах, до рабочего сервера в России модель физически не дотягивается.

4. Сборка и проверка на стейджинге. Модель запускает:

npm run build
pm2 restart all

После этого Playwright делает автоматические скриншоты десктопной и мобильной версии на тестовом поддомене.

1. Пуш в основную ветку. Модель отправляет изменения в git:

git add .
git commit -m "hero block: align CTA left"
git push origin main

1. Автоматический пайплайн доставляет сборку на prod. GitHub Actions выполняет цепочку: установка зависимостей, сборка, проверка бандла, копирование готовых файлов на рабочий сервер в России через rsync, перезапуск процесса, проверка здоровья сайта через curl.

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

Контент отделён от кода, и вот зачем

Тексты и поля ACF (Advanced Custom Fields, настраиваемые поля в WordPress) идут не через git, а через wp-cli (командная строка WordPress) и админку headless-WordPress. Код и контент живут в разных потоках.

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

Что реально крутится на дешёвом сервере?

На VDS за 2 000-3 000 рублей в месяц никакой языковой модели нет. Там работает сайт (Next.js, WordPress, MariaDB) и тонкий MCP-брокер. Весь «интеллект» исполняется на GPU провайдера API, на его мощностях.

Расход токенов не зависит от посещаемости. Хоть миллион визитов в день, рантайм-вызовов модели ноль: посетителю отдаётся заранее собранная статика. Токены тратятся только когда вы меняете код или контент.

Два формата развёртывания

• Совмещённый: dev и prod на одной VDS, в разных каталогах, под разными пользователями. Dev-пользователь не имеет прав записи в prod-каталог. Дёшево, для большинства сайтов на старте этого хватает.
• Разнесённый: dev-машина с MCP-брокером в одной стране, prod в другой, между ними только git и GitHub Actions. Физическая изоляция: даже при удачной атаке через инъекцию в промпт (prompt injection, когда злоумышленник пытается перехватить управление моделью) агент не дотянется до рабочего сервера мимо пайплайна.

Для проектов с аудиторией в России разнесённый вариант (dev в Европе, prod в РФ) решает ещё и вопрос юрисдикции: данные пользователей остаются на российском сервере.

Что это значит для вас?

Авторам Дзена и копирайтерам. Если вы ведёте свой сайт и устали зависеть от разработчика ради каждой мелкой правки, ИИ для создания веб-сайта позволяет формулировать задачи обычным языком. Менять вёрстку, обновлять блоки, публиковать контент, всё без знания кода. Контент при этом живёт отдельно и не пострадает при откате дизайна.

Маркетологам. Цикл «задача, правка, prod» сжимается с дней до минут. Тестировать гипотезы на лендингах, менять CTA, обновлять акции можно без очереди к разработчику. Бюджет на ИИ фиксирован и не растёт с трафиком.

Предпринимателям в РФ. Архитектура с prod-сервером в России и dev-сервером за рубежом закрывает вопрос хранения данных по 152-ФЗ. Из российских аналогов для API можно рассматривать YandexGPT и GigaChat, но для задач правки кода на момент публикации зарубежные модели вроде Claude справляются точнее. Совмещённый вариант (всё на одном сервере в РФ) тоже работает и обходится дешевле.

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