Как выбираем интерфейсную платформу для IWE: 5 вариантов, 8 характеристик
Проблема: один вход
Сейчас единственная точка входа в нашу интеллектуальную рабочую среду (IWE) — Telegram-бот @aist_me_bot. Бот уже умеет многое: отвечает на вопросы, показывает цифровой двойник, проводит тесты, ведёт марафоны, публикует в клуб. За ним стоят три MCP-сервера, три Pack’а с доменными знаниями, пять ИИ-агентов и база данных.
Но у Telegram есть потолок.
Аудитория. Telegram популярен в СНГ, на Ближнем Востоке и в части Азии. Но не в США, не в Японии, не в Латинской Америке. Привязка к одному мессенджеру = потеря большей части мира.
Интерфейс. IWE — это персональная среда для интеллектуальной работы. Дашборд с прогрессом, визуализация цифрового двойника, навигация по знаниям, интерактивные упражнения — всё это не помещается в парадигму чат-бота с кнопками.
Нетехническая аудитория. VS Code и Git — инструменты разработчика. Даже Discord — это гик-аудитория. Нужен интерфейс с нулевым порогом входа: открыл браузер — работаешь.
Вопрос встал ребром: какую платформу выбрать для веб-интерфейса IWE, чтобы выйти на международную аудиторию?
Принцип трёх интерфейсов
Прежде чем сравнивать варианты, мы с архитектором зафиксировали ключевую идею коммуникации. Любой интерфейс платформы должен быть удобным для трёх типов взаимодействия:
- Человек и ИИ — персональное обучение, ассистент, цифровой двойник
- ИИ и ИИ — агенты обмениваются данными, оркестрация
- Человек и Человек — сообщество, обсуждения, peer learning
Ни один из вариантов ниже не закрывает все три одинаково хорошо. Но каноническая поверхность должна быть сильнее всего в первом — потому что IWE в первую очередь персональная среда.
АрхГейт: 8 характеристик, порог 64 из 80
В нашей платформе есть блокирующее правило: архитектурное решение не принимается без формальной оценки. Метод называется АрхГейт — каждая характеристика от 1 до 10, пороговый балл = средняя ≥ 8.
Стандартных характеристик 7 (ЭМОГССБ). Для этого решения добавлена 8-я — международность, потому что выбор интерфейсной платформы — это ещё и вопрос охвата аудитории.
| # | Характеристика | Вопрос |
|---|---|---|
| Э | Эволюционируемость | Что сломается при изменении? Насколько легко менять части, не трогая целое? |
| М | Масштабируемость | Что будет при 10x пользователей? |
| О | Обучаемость | Сколько нужно прочитать, чтобы начать? |
| Г | Генеративность | Создаёт ли это платформу? Порождает ли новые возможности? |
| С | Скорость | Бот < 3 сек, CLI < 1 сек, веб < 3 сек на первую загрузку? |
| С | Современность | Используем ли мы актуальные методы и инструменты? |
| Б | Безопасность | Какие угрозы? Где PII? Кто контролирует auth и данные? Injection surface? |
| i18n | Международность | Работает ли это для пользователей в любой стране, на любом языке? |
5 вариантов: что рассматривали
Вариант 1: Telegram Mini Apps (TMA)
Идея: не уходить из Telegram, а расширить возможности через Mini Apps — встроенные веб-приложения внутри мессенджера.
| Э | М | О | Г | С | С | Б | i18n | Итого |
|---|---|---|---|---|---|---|---|---|
| 7 | 6 | 8 | 5 | 8 | 8 | 7 | 6 | 55/80 |
Почему не прошёл. Генеративность — 5: TMA не создаёт платформу, а привязывает к парадигме мессенджера. UI ограничен viewport Telegram. Международность — 6: Telegram популярен в ~15% мирового интернета. Безопасность — 7: Telegram берёт на себя auth, но данные проходят через их серверы; контроль над PII частичный.
Вариант 2: Standalone Web App (Next.js + AI SDK v6)
Идея: построить полноценное веб-приложение с нуля. Полный контроль над интерфейсом, деплой на Vercel, AI SDK для нативного подключения к MCP-серверам.
| Э | М | О | Г | С | С | Б | i18n | Итого |
|---|---|---|---|---|---|---|---|---|
| 9 | 9 | 8 | 8 | 8 | 9 | 8 | 9 | 68/80 |
Почему прошёл. Максимальный контроль: ты владеешь обеими сторонами контракта (frontend + backend). Безопасность — 8: полный контроль над auth (NextAuth), данными (Neon), hosting (Vercel); можно реализовать CSP, CORS, rate limiting; PII в своей БД. Next.js 15 — самый популярный React-фреймворк, обширная документация. AI SDK v6 даёт нативную поддержку MCP — все Pack-серверы доступны из чата.
Вариант 3: MCP Apps
Идея: использовать новый формат Anthropic — приложения, работающие через Model Context Protocol. Пользователь взаимодействует через Claude.ai или ChatGPT.
| Э | М | О | Г | С | С | Б | i18n | Итого |
|---|---|---|---|---|---|---|---|---|
| 5 | 5 | 5 | 7 | 7 | 9 | 6 | 6 | 50/80 |
Почему не прошёл. Спецификация MCP Apps — 4 недели от роду, API может радикально измениться. Требует платной подписки на Claude/ChatGPT ($20+/мес) — не для массовой аудитории. Безопасность — 6: данные пользователей проходят через Anthropic/OpenAI; нет контроля над auth-слоем. Перспективный подход, но не для primary surface сегодня.
Вариант 4: Multi-surface (Web-ядро + адаптеры)
Идея: взять Вариант 2 как ядро, а все остальные поверхности (TG бот, TMA, MCP Apps, Discourse) — как тонкие адаптеры к тому же бэкенду.
| Э | М | О | Г | С | С | Б | i18n | Итого |
|---|---|---|---|---|---|---|---|---|
| 9 | 10 | 7 | 9 | 8 | 9 | 8 | 9 | 69/80 |
Почему лучший. Масштабируемость — 10: любая поверхность, любой масштаб. Новый канал = новый адаптер, ядро не меняется. Генеративность — 9: это платформа по определению. Безопасность — 8: core-данные всегда в своей БД (Neon), адаптеры — тонкие прокси; auth контролируется ядром. Единственный минус — обучаемость чуть ниже (7): нужно понимать архитектуру адаптеров.
Вариант 5: Discourse (open-source форум)
Идея: Discourse — зрелая платформа для сообществ с AI-плагином и MCP-сервером. 12 лет развития, trust levels, модерация.
| Э | М | О | Г | С | С | Б | i18n | Итого |
|---|---|---|---|---|---|---|---|---|
| 6 | 8 | 7 | 5 | 7 | 6 | 7 | 7 | 53/80 |
Почему не прошёл. Discourse — отличная платформа для сообщества (человек и человек: 9/10). Но для человек и ИИ — слабо: sandbox ограничен 2 секундами на tool, нет structured output, нет per-user AI-памяти. Безопасность — 7: open-source, возможен self-hosting, хороший трек-рекорд; но стандартный хостинг = чужие серверы. Генеративность — 5: форум не создаёт платформу для AI-native фич.
Сводная таблица
| # | Вариант | Балл | Порог 64/80 | Вердикт |
|---|---|---|---|---|
| 1 | Telegram Mini Apps | 55/80 | нет | Отклонён |
| 2 | Standalone Web App (Next.js) | 68/80 | да | Принят |
| 3 | MCP Apps | 50/80 | нет | Отклонён |
| 4 | Multi-surface (Web + адаптеры) | 69/80 | да | Выбран |
| 5 | Discourse | 53/80 | нет | Отклонён |
Что выбрано: Multi-surface с Web-ядром
┌─────────────────────┐
│ Core Backend │ Node.js + MCP + Neon DB
│ + API Layer │ Единые сервисы для всех поверхностей
└──────────┬──────────┘
│
┌────────────────┼────────────────┬──────────────┐
▼ ▼ ▼ ▼
Web App TG Bot TMA MCP Apps
(Next.js) (существует) (Phase 2) (Phase 3)
КАНОНИЧЕСКАЯ
ПОВЕРХНОСТЬ
Web App — каноническая поверхность. Работает в любом браузере, в любой стране, на любом языке. PWA даёт опыт, близкий к мобильному приложению. AI SDK v6 подключает все Pack-серверы нативно.
Telegram-бот остаётся. Он не исчезает — становится «быстрым каналом» для коротких взаимодействий. Заметку записать, вопрос задать, прогресс глянуть. Web App — для глубокой работы: дашборды, аналитика, упражнения, длинные сессии.
Что это значит для пользователя
Новый пользователь (не из Telegram):
Находит сайт → регистрируется за 30 секунд → видит дашборд с маршрутом обучения, чатом с ассистентом, цифровым двойником и навигацией по знаниям. Выбирает язык. Начинает с бесплатного тира (пользовательский уровень на платформе – Т1-Т4).
Существующий пользователь бота:
Получает ссылку → авторизуется через Telegram OAuth → видит ВСЕ свои данные из бота. Продолжает пользоваться ботом для быстрых действий, а Web App — для глубокой работы.
Участник платного семинара:
Покупает доступ → личный кабинет: материалы, упражнения, прогресс, чат с ассистентом по материалам, сертификат. Web App закрывает потребность в LMS.
Стек технологий
| Компонент | Технология | Почему |
|---|---|---|
| Frontend | Next.js 15 + React | Самый популярный фреймворк, SSR, edge functions |
| AI | Vercel AI SDK v6 | Нативная поддержка MCP, streaming, tool use |
| i18n | next-intl | Зрелое решение, ICU MessageFormat, роутинг по локали |
| Auth | NextAuth.js | Email + Google OAuth + Telegram OAuth |
| DB | Neon (PostgreSQL) | Уже используется ботом, pgvector для embeddings |
| Hosting | Vercel (frontend) + Railway (backend) | CDN + edge, глобальное покрытие |
| PWA | Service Worker + Manifest | Опыт мобильного приложения без app store |
Фазы развития
| Фаза | Что получаем | Оценка |
|---|---|---|
| Phase 0 | Скелет: регистрация, landing, i18n на двух языках | ~15-20h |
| Phase 1 | MVP: дашборд, чат с ассистентом, ЦД viewer, Pack viewer, PWA | ~25-30h |
| Phase 2 | Продукт: Stripe, тиры подписки, LMS для семинаров | ~15-20h |
| Phase 3 | Масштаб: TMA-адаптер, MCP Apps, Discourse, новые языки | по спросу |
Phase 0 и Phase 1 строятся рядом с ботом, на том же бэкенде. Бот не меняется.
Почему не Replit?
В процессе выбора я также рассматривал Replit — AI-платформу, которая строит приложения по описанию на естественном языке. Agent 3 впечатляет: описываешь → получаешь работающее приложение с деплоем.
Но при проверке через АрхГейт Replit набирает 49/80 — ниже порога 64. Главные провалы:
- Генеративность (4): Replit не создаёт платформу — ты арендуешь чужую. Невозможен template-sync, невозможна модель контуров L2→L3→L4
- Безопасность (5): Код и данные пользователей на чужих серверах. PII в чужом облаке. MCP-серверы подключаются к чужой инфраструктуре
- Эволюционируемость (5): Vendor lock-in. GitHub export есть, но после экспорта — полная перенастройка
Replit — отличный ускоритель прототипирования: за 2-4 часа проверить гипотезу UI перед тем как писать в Next.js. Но не архитектурная альтернатива.
Что дальше
Решение пока не принято. ADR-001 зафиксирован как проект и требует доп.согласования. Следующий шаг — Phase 0: создать репо IWE-web-app, скелет с auth + i18n + landing.
Бот продолжает работать. Он стал первой поверхностью. Теперь строится вторая — каноническая.
Полное архитектурное решение: ADR-001 в PACK-digital-platform. Source-of-truth: Pack DP, не этот пост.