Зачем ИИ-генератору презентаций собственный редактор

На связи тим-лид разработки Кэмпа.

Это третья статья цикла о релизе нового генератора презентаций в Кэмпе. Ранее разбирали, почему первая версия не взлетела ^[1], и что сейчас под капотом ^[2]. Ниже расскажу, почему мы с командой решили собирать редактор с нуля.

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

Почему не выбрали готовый редактор

Мы протестировали несколько готовых решений, в том числе сервисы с логикой ^[3] ИИ-презентаций. Результаты нас не устроили. Проблема оказалась в управляемости.

В готовых редакторах:

• ограниченная модель размещения элементов;

• слабый контроль над позиционированием;

• нестабильность при ручном редактировании;

• сложности с корректным экспортом в PPTX.

Для любого пользователя важно спокойно открыть PowerPoint и защитить презентацию. Если после экспорта всё «едет», продукт теряет доверие.

Отсюда первое принципиальное решение: редактор должен проектироваться с учётом экспорта, а не адаптироваться к нему постфактум.

Второе решение — редактор должен быть удобным. Генератор создаёт первоначальный вариант слайдов ^[4], но финальный вид презентации формируется в процессе редактирования.

Поэтому мы отказались от идеи дорабатывать чужое решение под свои задачи и решили разработать редактор самостоятельно, учитывая все потребности ^[5] аудитории.

Почему разработку начали с редактора

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

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

Генерация — это последовательность шагов. Редактор — это состояние документа.

Редактор должен:

• хранить изменения;

• поддерживать ручные правки;

• корректно экспортировать в PPTX;

• обеспечивать совместную работу нескольких участников;

• обрабатывать команды ИИ-агента через общий слой управления состоянием.

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

Редактор как система управления состоянием

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

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

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

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

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

• структура данных редактора должна совпадать с логикой PPTX;

• стили и позиции должны корректно интерпретироваться вне браузера;

• текстовые блоки не должны терять разметку.

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

С точки зрения ^[6] алгоритмов задача не требовала исследовательских решений. Основная сложность заключалась в объёме логики и количестве взаимосвязанных состояний внутри редактора.

ИИ-агент как участник документа

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

Мы изначально закладывали другую логику. ИИ-агент должен работать внутри редактора как участник документа, а не как отдельный запрос.

Это означает, что:

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

• изменения вносятся через ту же систему управления состоянием;

• агент может продолжать работу независимо от состояния конкретной вкладки или сессии пользователя.

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

Что в итоге получилось

В результате редактор стал не интерфейсом над генератором, а единой точкой контроля состояния презентации. Именно он определяет:

• как хранится и изменяется документ; 

• как изменения синхронизируются между участниками; 

• как состояние транслируется в формат PPTX без потери структуры; 

• как к документу подключается ИИ-агент как равноправный участник.

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