Как я научил нейроагента собирать страницы с контентом для корпоративного сайта

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

Сапожник без сапог, или айтишник без ИИ

До этого проекта у нас был стандартный для ИТ‑компании конвейер: PR и автор пишут статью, дизайнер собирает иллюстрации по ТЗ, корректор вычитывает текст. А дальше начинается путь от файла до публикации страницы — и вот тут то всё упирается в человека. А вернее в его свободные ресурсы и приоритеты в задачах.

Зайти в админку, выбрать компоненты, расставить заголовки и картинки, проверить, как это выглядит, включить страницу в блог, sitemap, RSS и еще десяток служебных механизмов, о которых читатель никогда не узнает, — всё это делает человек, у которого параллельно горит пул клиентских проектов. В загруженные недели контент просто оседал в очереди «на потом». Задачу внутри команды я сформулировал так: сократить путь от точки «статья написана» до точки «читатель её открыл». И отдельно — достать из этой цепочки людей, чье время стоит дороже, чем механическая верстка.

Идеальный сценарий — никакого ручного вмешательства

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

Через 30–40 секунд в админке должна появиться первая версия страницы, собранная из нашей галереи компонентов. Тот, кто запускает публикацию, вообще может не открывать админку. Агенту предстояло самому разобрать файл, сопоставить текст и картинки с нужными блоками и собирать страницу.

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

Первый цикл: агент как внешний наблюдатель сайта

Первый подход к задаче был осторожным: не пускать агента в админку и дать ему работать «снаружи». План выглядел так: взять библиотеку элементов сайта, научить агента заходить на публичную часть сайта, по образцу имеющихся страниц собирать статические версии новых и выкладывать их так, чтобы частота редактирования была минимальной. Казалось, что это безопасный компромисс: никаких прав записи в боевую админку, только генерация новых HTML‑страниц по аналогии.

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

Инициативность агента стала проблемой

К четвертой итерации стало ясно, что подход не работает. Агент заходил на сайт и пытался выдернуть элементы, но использовать наш код не собирался. Он писал свой — HTML и CSS, отдалённо похожие на то, что есть в продакшене. Внешне это напоминало веб‑страницу, но внутри была другая структура, другие классы, никакого единообразия и непредсказуемые последствия для каждой будущей правки.

В общем до продакшена такой странице не хватало процентов девяноста доработки. Довести её до приличного вида стоило столько же времени, сколько обычная ручная сборка, а иногда и больше. И так мы оказывались в схеме, которую как раз хотели исправить: один сотрудник (пусть теперь он зовется ИИ‑агент) собирает страницу, другой все проверяет и правит после первого.

Неудача — тоже опыт

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

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

Второй цикл: пустить агента внутрь, но через интерфейс

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

Так две машины нашли общий язык. Интерфейс стал понятен для самой нейросети: это мог быть API, MCP или другой понятный машине способ взаимодействия — важно, что он был формализован.

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

Словарь для нейросети

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

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

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

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

Промпт в одну строку вместо десятка ручных действий

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

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

Архитектура агента 

Вокруг этого решения живёт агент, который можно сравнить с кодовым агентом вроде условного Claude Code. Он находится внутри папки проекта, видит и читает файлы, умеет запускать команды и обращаться к интерфейсу сайта. В этой папке лежат служебные файлы с описанием правил, интерфейсов, структур компонентов и логики публикации. Для агента это фактически учебник: как устроен сайт, какие CMS используются, какие браузеры подключаются, какие cron‑задачи отвечают за статистику и аналитику — и, главное, как выглядит полный цикл публикации.

Из этого учебника возникает то, что мы считаем «ТЗ для ИИ»: оно состоит из написанной автором статьи с подобранными иллюстрациями. Никакой отдельной подготовки не требуется: агент берёт этот файл на вход, и вся остальная сложность уже описана в служебных материалах.

Непривязанность к конкретной LLM и Codex

Отдельный принцип, которого я придерживался, — решение не должно жёстко зависеть от одной модели. Текущее решение практически не зависит от выбора движка: это набор инструментов, которым может управлять любая современная нейросеть, умеющая работать с текстом, кодом и вызовом функций. На момент написания статьи я по факту использовал сразу несколько разных вариантов (kimi + kimi code, gpt5.5 + codex). Они уверенно справляются с задачей, потому что она комплексная: нужно и прочитать текст, и правильно сопоставить его с компонентами, и корректно дернуть API.

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

Что улучшилось в бизнес‑процессе

Теперь, когда появился ИИ‑агент, сценарий публикации контента на сайте выглядит так: 

• автор заканчивает статью, 

• кладёт файл в нужную папку, 

• запускает задачу

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

Если еще чуть «помучить» агента, то есть внести локальные правки в инструкцию или дать пару уточняющих промптов, можно добиться того, что статья получится при публикации неотличимой от той, что готовил человек. 

Главный эффект, который вижу как руководитель, — минус 60% времени человека на выпуск одного материала. Раньше в цепочке публикации стояли автор, PR, верстальщик или разработчик, SEO‑специалист и ещё кто‑то, кто следил за sitemap и RSS. Теперь сборку страницы, обновление служебных частей и первичную проверку берёт на себя агент. Людям остаётся то, где без них никак: смысл текста, бренд, юридические риски. 

Что важно знать, если вы тоже хотите научить агента собирать страницы

Этот проект убедил меня в нескольких вещах. 

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

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

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

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