GIGAPROTO: мобильный UI из бизнес-требований

Какую задачу решал

21–22 марта 2026 года на хакатоне Сбер × ПРОСТО я работал в мультиагентном треке над GIGAPROTO — прототипом платформы, которая превращает документ с бизнес-требованиями в мобильный интерфейс. Пользователь загружает файл или описывает задачу в чате, а система разбирает требования, предлагает структуру экранов и даёт возможность посмотреть результат.

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

Два исходных банковских кейса

Для подготовки дали два тренировочных задания.

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

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

Что получилось в интерфейсе

В проекте есть React-приложение с тремя рабочими областями: стартовая страница, экран проекта и мониторинг. На стартовой странице можно ввести запрос или загрузить документ. Внутри проекта слева расположен чат, справа — предпросмотр мобильного экрана; над ним переключатели телефона, планшета и десктопа, режим JSON-кода и элементы экспорта.

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

Рабочая область: пример контрольной схемы «История операций».

Почему JSON, а не картинка

Я выбрал GenUI-подход: агент возвращает дерево компонентов, которое можно отрисовать как интерфейс. В проекте есть React-рендерер с реестром компонентов, а предпросмотр на странице проекта вынесен в отдельный iframe. У каждого узла есть тип, свойства, вложенные элементы и стили. Например, фрагмент встроенного контрольного примера:

{
  "type": "navbar",
  "props": {
    "title": "История операций",
    "showBack": true
  }
}

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

Та же схема во вкладке «Код»: типы, свойства и вложенные элементы можно сопоставить с экраном предпросмотра.

Как устроен агентный процесс

В Python-части проекта этапы разделены на самостоятельные модули:

1. Парсер переводит DOCX, PDF, TXT и Markdown в текст. Для изображений предусмотрена отдельная ветка анализа через GigaChat Vision.
2. Analyst выделяет цель, аудиторию, экраны, интеграции и требования с идентификаторами REQ-….
3. Designer запрашивает три варианта — минимальный, стандартный и расширенный с аналитикой. Перед генерацией он получает контекст дизайн-гайдлайнов.
4. Validator возвращает оценку покрытия, пропущенные требования и замечания к структуре и UX.
5. Refiner предусмотрен для исправления схемы при оценке покрытия ниже 0,8, после чего выполняется повторная проверка.
6. Recommender формирует отдельные предложения по улучшению интерфейса.

flowchart TD
    A[Документ с требованиями] --> B[Парсер и Analyst]
    B --> C[Designer и контекст гайдлайнов]
    C --> D[Три варианта JSON-схемы]
    D --> E[Validator]
    E --> F[Refiner при замечаниях]
    F --> E
    E --> G[Рекомендации и предпросмотр]
    classDef stage fill:#e1f1da,stroke:#4b8057,color:#234e32;
    class A,B,C,D,E,F,G stage;

Замечания Validator служат входом для следующей итерации.

Реализация под капотом

Frontend написан на React, TypeScript и Vite. Spring Boot служит API-шлюзом, FastAPI выполняет парсинг и агентные этапы. PostgreSQL хранит документы, требования, прототипы, проверки и сообщения. Для поиска гайдлайнов используется pgvector с переходом к текстовому поиску, если векторный поиск недоступен. В LLM-клиенте предусмотрен Redis-кэш.

В коде есть проверка структуры JSON, фильтрация опасных строк и отдельный учёт вызовов агентов. Экспортная часть собирает файлы React/Vite/Tailwind-проекта и предусматривает ZIP и Git. Это самостоятельные части прототипа, которые нужно согласовать с форматом схемы и пользовательским интерфейсом.

Результат и границы

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

Frontend успешно собирается, а встроенная схема «История операций» проходит проверку структуры и служит контрольным примером рендерера.

В версии с хакатона оставались незавершённые стыки между ответами pipeline, frontend и шлюзом. В экспорте нужно исправить конфликт имени App в создаваемом проекте. Исходники хранятся в закрытом GitLab.

Главный результат моей работы — прототипирование через явную структуру требований и UI, которую можно посмотреть и проверить. Следующий шаг для такой системы — единый контракт данных и проверка полного пути от загруженного задания до открывающегося экспортированного проекта.