На связи тим-лид разработки Кэмпа.
Это третья статья цикла о релизе нового генератора презентаций в Кэмпе. Ранее разбирали, почему первая версия не взлетела, и что сейчас под капотом. Ниже расскажу, почему мы с командой решили собирать редактор с нуля.
Изначально мы его рассматривали как отдельную часть системы, а не как надстройку поверх генератора.Такой подход выбрали потому, что презентация должна существовать как управляемый документ: с возможностью ручных правок, экспорта в PPTX и дальнейшего расширения логики. Если начать с генератора, редактор неизбежно будет подстраиваться под уже существующие ограничения, а не задавать правила работы документа.
Почему не выбрали готовый редактор
Мы протестировали несколько готовых решений, в том числе сервисы с логикой ИИ-презентаций. Результаты нас не устроили. Проблема оказалась в управляемости.
В готовых редакторах:
-
ограниченная модель размещения элементов;
-
слабый контроль над позиционированием;
-
нестабильность при ручном редактировании;
-
сложности с корректным экспортом в PPTX.
Для любого пользователя важно спокойно открыть PowerPoint и защитить презентацию. Если после экспорта всё «едет», продукт теряет доверие.
Отсюда первое принципиальное решение: редактор должен проектироваться с учётом экспорта, а не адаптироваться к нему постфактум.
Второе решение — редактор должен быть удобным. Генератор создаёт первоначальный вариант слайдов, но финальный вид презентации формируется в процессе редактирования.
Поэтому мы отказались от идеи дорабатывать чужое решение под свои задачи и решили разработать редактор самостоятельно, учитывая все потребности аудитории.
Почему разработку начали с редактора
Если мы хотим контролировать экспорт, правки и дальнейшее развитие продукта, редактор нельзя делать поверх генератора.
Разработку начали с логики самого редактора: как внутри системы существует документ презентации и как он изменяется. И только когда эта основа была определена, к ней подключили генерацию.
Генерация — это последовательность шагов. Редактор — это состояние документа.
Редактор должен:
-
хранить изменения;
-
поддерживать ручные правки;
-
корректно экспортировать в PPTX;
-
обеспечивать совместную работу нескольких участников;
-
обрабатывать команды ИИ-агента через общий слой управления состоянием.
Это полноценная система управления документом. Поэтому редактор изначально закладывался как самостоятельный архитектурный слой, а не как фича поверх генератора.
Редактор как система управления состоянием
Работу начали с прототипа. Первая версия редактора была собрана быстро, чтобы проверить базовую логику.
Дальше мы попробовали несколько альтернативных реализаций на разных библиотеках. Часть решений не подошла из‑за ограничений, поэтому их отбросили. В итоге выбрали библиотечную основу, поверх которой реализовали собственную логику работы редактора.
LLM использовали как инструмент ускорения разработки: для быстрого создания черновых реализаций и проверки гипотез. Это позволило быстрее перебирать варианты, а окончательные архитектурные решения команда принимала и реализовывала вручную.
Ключевая часть — управление состоянием документа. Нужно было обеспечить корректную работу правок, пересборку слайдов и предсказуемый экспорт в PPTX — это оказался очень важный пункт для аудитории, потому что презентацию в итоге открывают и защищают в PowerPoint.
Именно поэтому соответствие формату PPTX стало архитектурным требованием, а не этапом «после генерации». Чтобы файл открывался корректно, нужно было синхронизировать внутреннее состояние редактора с логикой PPTX:
-
структура данных редактора должна совпадать с логикой PPTX;
-
стили и позиции должны корректно интерпретироваться вне браузера;
-
текстовые блоки не должны терять разметку.
Если состояние редактора невозможно однозначно сопоставить с PPTX, экспорт становится недетерминированным. Поэтому соответствие форматов было заложено на уровне проектирования.
С точки зрения алгоритмов задача не требовала исследовательских решений. Основная сложность заключалась в объёме логики и количестве взаимосвязанных состояний внутри редактора.
ИИ-агент как участник документа
Обычно интеграция ИИ в редактор выглядит так: пользователь нажимает кнопку, отправляется запрос к модели, сервер возвращает текст, фронтенд вставляет его в документ. По сути, это внешний вызов LLM, который один раз изменяет содержимое.
Мы изначально закладывали другую логику. ИИ-агент должен работать внутри редактора как участник документа, а не как отдельный запрос.
Это означает, что:
-
агент подключается к документу через тот же коллаборационный слой, что и пользователь;
-
изменения вносятся через ту же систему управления состоянием;
-
агент может продолжать работу независимо от состояния конкретной вкладки или сессии пользователя.
В такой модели ИИ не просто генерирует фрагмент по запросу, а становится полноценным участником процесса редактирования.
Что в итоге получилось
В результате редактор стал не интерфейсом над генератором, а единой точкой контроля состояния презентации. Именно он определяет:
-
как хранится и изменяется документ;
-
как изменения синхронизируются между участниками;
-
как состояние транслируется в формат PPTX без потери структуры;
-
как к документу подключается ИИ-агент как равноправный участник.
С архитектурной точки зрения ключевым решением стало выделение редактора в отдельный слой, который контролирует состояние, а не зависит от логики генерации. Именно это позволило заложить фундамент для дальнейшего развития, чем мы и продолжаем заниматься сейчас.
Автор: KempAI
