Архитектура сайта с ИИ: MCP, LLM, версионирование контента — гайд 2026 | AiManual
AiManual Logo Ai / Manual.
20 Июн 2026 • Гайд

Архитектура сайта под управлением ИИ: MCP-сервер, LLM и версионирование контента — разбор по косточкам

Как построить сайт, которым управляет нейросеть? Разбираем MCP-сервер, интеграцию Claude/GPT, валидацию кода и версионирование. Практические примеры.

Реклама
partv1

Вам нужен сайт, который пишет сам себя? Добро пожаловать в 2026

В 2026 году контент-маркетинг — это гонка вооружений. Чтобы оставаться в топе, нужно публиковать десятки статей в месяц. Люди выгорают, а нейросети — нет. Но просто скормить промпт ChatGPT и вставить результат на сайт — путь к катастрофе. Без архитектуры вы получите кучу рыхлого текста, сломанные верстки и головную боль от откатов. Решение — MCP-сервер, который становится мозгом сайта, связывая LLM, систему версионирования и CD. Сегодня разберем, как это работает на уровне кода и инфраструктуры.

Если вы уже пробовали подключать AI-агентов к CMS, то знаете: WordPress.com с MCP — отличный пример, но он прячет много деталей под капотом. Мы же залезем внутрь.

MCP — не просто протокол, а мост между LLM и живым сайтом

MCP (Model Context Protocol) — это не очередная тулза для автоматизации. Это протокол, который позволяет LLM взаимодействовать с внешними ресурсами и инструментами. В нашем случае — с сайтом. MCP-сервер выступает этаким дирижером: получает от модели запрос "создай страницу", дергает нужные API, сохраняет результат, проверяет его и публикует.

Как это выглядит на практике? У вас есть MCP-сервер, который регистрирует инструменты: create_page, update_page, get_page_version. LLM (Claude 4 Opus, GPT-5, Gemini Pro) вызывает эти инструменты через стандартный протокол. MCP-сервер выполняет код, возвращает результат модели. И так по кругу.

Важно: MCP-сервер — не просто прокси. Он — песочница безопасности. Он решает, какие действия разрешены, а какие нет. Если LLM попытается выполнить опасный SQL — MCP-сервер скажет "нет". Подробнее про то, как строить такие мосты, я писал в статье про MCP-сервер для КОМПАС-3D — там похожая логика, только для инженерных чертежей.

Не все MCP-серверы одинаково полезны. Некоторые настолько болтливы, что тратят контекст на пустые диалоги. Если хотите отсечь лишнюю болтовню — взгляните на mcp-context-proxy, который режет пустые ответы.

Как LLM пишет контент, пока вы пьете кофе: пайплайн

Давайте представим, что LLM нужно создать страницу "О нас". Без MCP-сервера это выглядит так: промпт -> текст -> верстка глазами -> копипаст -> ручная правка. С MCP-сервером так:

  1. LLM получает задачу с четкой структурой: заголовок, подзаголовок, три абзаца, CTA-блок, alt-текст к изображению.
  2. LLM вызывает инструмент create_page через MCP, передавая JSON с полями: content (HTML), title, slug.
  3. MCP-сервер принимает JSON, прогоняет через валидатор: проверяет наличие обязательных полей, отсутствие script-тегов, синтаксис HTML.
  4. Если валидация пройдена — сервер сохраняет новую версию страницы в Git-репозиторий контента и отправляет запрос на деплой.
  5. Если валидация не пройдена — MCP-сервер возвращает LLM ошибку с описанием проблемы и просит исправить.

Вот пример плохого промпта, который приведет к мусору:

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

А вот хороший (с точки зрения архитектуры):

{
  "instruction": "create_page",
  "params": {
    "title": "О компании | Название",
    "h1": "Мы делаем сложное простым",
    "body_html": "
Текст, не более 300 слов...
",
    "cta": {"text": "Заказать консультацию", "url": "/contact"},
    "template": "about"
  }
}

Почему второй хорош? Он машиночитаем, предсказуем и легко валидируется. О том, как правильно проектировать такие запросы, чтобы не упираться в контекст, я подробно написал в статье проектирование архитектуры для ИИ-кодирования.

Версионирование контента — ваш спасательный круг

Самая большая ошибка — думать, что LLM всегда права. Нейросети галлюцинируют, путают даты, генерируют битый HTML. Если у вас нет версионирования, одно неудачное обновление может положить сайт.

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

  • Git-репозиторий — каждый коммит = версия страницы. Плюс: прозрачность, легкость диффа. Минус: сложность для динамического контента.
  • База данных с версионностью — таблица page_versions с полями page_id, version_id, content, created_at, status. Плюс: быстрый откат по ID. Минус: разрастание данных.

Лично я предпочитаю комбинированный подход: Git для статического контента (лендинги, статьи) и БД для динамических элементов (цены, A/B тесты).

Пример ошибки: Храните только последнюю версию? Тогда при регрессе вам придется перегонять LLM заново — цена ошибки вырастает кратно. Особенно это больно, когда модель перезаписывает работающий контент своим "творчеством".

Интересный способ уменьшить объем хранимых версий — использовать граф знаний. В статье индексация кода в граф знаний показано, как 120-кратное сокращение токенов помогает работать с историей правок, не перегружая LLM.

Кстати, если вам нужно, чтобы MCP-сервер сам понимал изменения кода и не пожирал всю VRAM — зацените Code-memory MCP-сервер. Он отлично работает в связке с версионированием.

Собираем все вместе: живой пример работы системы

Давайте проследим полный цикл на конкретном кейсе. Допустим, вы даете LLM задачу: "Обнови страницу услуг, добавь блок с ценами".

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

1 Запрос и генерация

LLM получает текущую версию страницы (через MCP-инструмент get_page_content), анализирует структуру и генерирует новый HTML. Важно: в запрос включается только релевантный контекст (метаданные, SEO-шаблон), чтобы не перегружать токены. Помогает в этом MCP Tool Registry — он подмешивает только нужные инструменты.

2 Валидация

MCP-сервер запускает цепочку проверок:

  • Синтаксический анализ HTML — нет ли незакрытых тегов.
  • Безопасность — запрещенные теги (script, iframe, object) вырезаются или заменяются на safe-варианты.
  • Контент-политика — совпадают ли заголовки, есть ли дубликаты slug, соответствует ли длина SEO-рекомендациям.
  • Специфичная бизнес-логика — например, цены не могут быть отрицательными.

Ошибка №1: Доверять LLM в генерации неэкранированных данных. Пример: LLM может вставить <img src=x onerror=alert(1)> — если не санитизировать атрибуты, получите XSS.

Ошибка №2: Проверять только JSON-схему, но не содержимое. LLM может вернуть валидный JSON с невалидным HTML.

3 Версионирование и публикация

После успешной валидации MCP-сервер сохраняет новую версию контента (increment version_id), коммитит в Git, запускает CI/CD пайплайн. Если что-то пошло не так на продакшне — откат к предыдущей версии занимает секунды.

Для статического контента схема идеальна. Для динамического (например, онлайн-калькулятор) нужно дополнительно кешировать результаты и связать с графом знаний — об этом я писал в статье самоподдерживающаяся Wiki-база знаний на LLM.

Подводные камни (и как на них не наступить)

  • Контекстное окно. LLM не может держать в голове весь код сайта. MCP-сервер должен подавать только актуальные куски. Решение — использовать контекстные фильтры и разбивать сайт на микросервисы.
  • Расход токенов. Каждая регенерация стоит денег. Кешируйте запросы и ответы. MCP Tool Registry умеет собирать статистику по использованию.
  • Галлюцинации. LLM может выдумать факты. Добавьте RAG-слой: перед генерацией подтягивайте реальные данные через MCP-инструмент search_knowledge_base. Отличный пример — MCP Tool Registry для RAG.
  • SEO. LLM не знает ваших стратегий. Используйте GEO (Generative Engine Optimization), чтобы контент попадал в ответы ChatGPT и Perplexity — статья про GEO.
  • Безопасность MCP. Не забывайте про аутентификацию запросов к MCP-серверу. Если злоумышленник сможет вызвать delete_all_pages — контента не станет.

Частые вопросы

Вопрос: Какой стек выбрать для MCP-сервера?

Ответ: Python (FastAPI) или Go. Python — простота интеграции с AI-библиотеками, Go — производительность и малый вес. MCP спецификация не привязана к языку.

Вопрос: Стоит ли использовать локальную LLM для управления сайтом вместо облачной?

Ответ: Для регулярных небольших изменений — да, если есть хорошая видеокарта. Пример настройки локальной LLM с MCP разобран в статье MCP и локальные LLM.

Вопрос: Как часто MCP-сервер должен обновлять контент?

Ответ: Частота задается правилами, а не MCP-сервером. Можно сделать еженедельную автоматическую ревизию, можно — ручной триггер. Главное — не увлекаться: каждая регенерация стоит токенов и может ухудшить качество, если модель переписывает рабочий материал.

Что дальше? Совет, который вы не ожидали

Не пытайтесь внедрить полную автоматизацию сайта с первого дня. Начните с одного MCP-инструмента — генерации черновиков для блога. Пусть LLM пишет текст, MCP-сервер сохраняет версию, а вы вручную проверяете и публикуете. Через месяц, когда привыкнете к пайплайну, добавляйте автоматическую публикацию. Через три месяца — подключите A/B тестирование версий контента.

Почему так? Потому что главная проблема не в технологии, а в доверии. Пока вы не научитесь доверять MCP-серверу и LLM в связке, полная автоматизация будет стрелять в ногу. Идите маленькими шагами — и сайт под ИИ-управлением станет вашим лучшим сотрудником, а не источником админского стресса.

Подписаться на канал

←
На главную