За 10 дней мы сделали MVP тренажёра переговоров «Вершина» для Хакатона Мэра Москвы (Задача №9 от ОЭЗ «Алабуга»). Нас было пятеро, до конкурса мы не были знакомы. В финал мы не вышли. Зато у нас осталось работающее мини-приложение для Telegram, и я хочу рассказать, как оно устроено. Меня зовут Янина Шкуропат и я отвечала за продукт в команде.

Собеседнику в нашем тренажёре вам можно соврать. Сказать, что у вас есть другое предложение, которого нет. Надавить ультиматумом. Уступить два раза подряд и посмотреть, что будет. В реальных переговорах такие эксперименты стоят денег и отношений. В тренажёре — это один раунд переговоров с ИИ-персоной.

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

Какую боль мы решали

Навык переговоров появляется только в диалоге. Аудитория нашего Telegram mini app — это менеджеры по закупкам и продажам, руководители команд, HR и рекрутеры, основатели своего дела.

Я выделила три боли:

1. Регулярная тренировка с коучем — дорого и часто не связано с реальностью. 

2. Теория не становится навыком. Методика BATNA, интересы сторон и открытые вопросы остаются теорией, пока не научишься использовать их в разговоре. 

3. Нет разбора твоего поведения. Чужой кейс не отвечает на вопрос, что не так сказал именно ты.

Discovery: 12 тренажёров за день

Это моя любимая стадия. Я нашла и протестировала 12 продуктов для тренировки переговоров за день, так как горел дедлайн. Рынок за пару лет ИИзменился до неузнаваемости, раньше такой набор фичей можно было увидеть в кино. Сильнее всего зацепило приложение Hyperbound.io, там я поймала wow-эффект, когда ИИ-собеседник начал на меня давить и потом бросил трубку. Также я обратила внимание на Gong.io, благодаря руководителю развития продаж компании Anthropic, который сказал, что эффективность продаж выросла на 64%. 

Из ресёрча я собрала УТП. Базовые роли я взяла из одного продукта, самую сильную идею из другого. Получилось три опоры:

• универсальный тренажёр, который можно встроить в LMS или CRM;

• собеседник на выбор: синтетическая ИИ-персона с заданным поведением или персона, обогащённая через MCP данными о конкретном человеке;

• слой геймификации, который пользователь включает сам.

Второй пункт стал главным. Тренироваться можно перед реальной встречей с цифровым двойником реального собеседника, а не с абстрактным “токсичным клиентом”.

Главная идея: решает код, модель только говорит

Если отдать языковой модели и разговор и оценку (метрики), то такой же результат нельзя воспроизвести. Сегодня она уступила на пятой реплике, завтра на третьей, ну и оценивает всегда по-разному. Для тренажёра это критично. Человек меняет тактику и должен видеть, что именно изменилось.

Поэтому мы разделили роли. Суммы в сделке, уступки и финал считает код. Модель размечает реплику игрока и формулирует ответ собеседника. Одинаковая стратегия даёт одинаковый исход. Формулировки каждый раз разные, как у живого человека.

Как устроен один ход

На каждую реплику игрока приходится пять шагов.

1. Разметка. Модель размечает реплику по закрытой схеме: предложение по условиям, открытый вопрос, давление, ссылка на объективный критерий, упоминание альтернативы, уточнение, реплика не по теме. Придумать новую метку или новое условие она не может. Если модель не ответила или ответила не по схеме, включается эвристика по ключевым словам.

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

3. Тон. Модель получает уже решённый ход, например “предложи 3% скидки, возрази про бюджет”, и формулирует его в характере персонажа. Решения она здесь не принимает.

4. Страж. Он проверяет реплику до того, как её увидит игрок. Не должно быть странных чисел, раскрытого скрытого факта, согласия, которого не было, и самоповтора. При нарушении модель получает объяснение ошибки и пробует снова. Попыток три. Потом ИИ-персонаж говорит заготовленную реплику.

5. Запись. Реплики уходят игроку потоком, ход пишется в базу атомарно.

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

Сделка как математика

Сценарий состоит из контекста, ролей, скрытых фактов собеседника и от двух до четырёх условий торга. Условия берутся из справочника на 13 типов: цена, скидка, объём, срок оплаты, срок поставки, срок контракта, гарантия, время реакции, бюджет, ставки в команде, зарплата, премия, срок пересмотра.

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

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

Так скрытые интересы собеседника становятся асимметрией весов, а не декорацией. Правильный вопрос вскрывает, что ему важнее, и открывает обмен.

24 сценария в MVP: пять сфер (закупки, продажи, найм, руководство, фаундер) на пять целей (размещение заказа, скидка у подрядчика, повышение зарплаты, продление контракта, бюджет проекта). Без пары «фаундер + повышение зарплаты». Плюс свой сценарий с нуля. Настраивает его визард из шести шагов: цель, условия сделки, альтернатива, что известно, собеседник, проверка.

Как врать правильно: правила реакции

Когда модель разметила реплику, движок применяет явные правила.

Обратите внимание на последнюю строку. Числа из реплики не по теме не попадают в торг, поэтому подсунуть собеседнику выгодную цифру в обход торга не получится.

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

Фазы переключаются по условиям, а не по желанию модели: открытие, исследование, торг, закрытие. Собеседник уступает по кривой, которая зависит от времени и характера. Токсичный CPO держится и уступает поздно. Занятой CEO нетерпелив. Поэтому сдаться на третьей реплике или тянуть бесконечно не получится.

Ветвление получается из комбинации правил — разные стратегии уводят партию по разным траекториям. Финала два:
1. Сделка: предложения сошлись по всем условиям и игрок подтверждает итог на карточке.
2. Отказ: собеседник ушёл, игрок ушёл сам, отклонил условия на последнем ходу или кончились ходы.

Каждое срабатывание правила пишется в журнал с номером хода и прогрессом выгоды. Из этого журнала собирается разбор этапа переговоров из 9 метрик.

Разбор: 9 метрик и цитаты

Все метрики считаются из журнала ходов и состояния движка. У метрик поведения и речи есть зоны «плохо / норма / хорошо» и указан конкретный источник (как и почему так считаем): исследование, практика или экспертная оценка. Метрики исхода меряются критериями самого игрока.

• Итог сделки: % выгоды, выигрыш над альтернативой, соблюдение своей границы.

• Поведение: уступки, реакция на возражения, выяснение скрытых фактов, опора на внешние факты.

• Речь: доля открытых вопросов, слова-паразиты.

Так же пользователь получает конкретные советы для роста по метрикам, которые сильнее всего отстают от нормы.

Методическая база: Гарвардский метод (интересы вместо позиций, объективные критерии, BATNA), а также лучшие практики ведущих школ продаж.

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

Цифровой двойник через MCP

Я работаю в Cognico.ru, поэтому в MVP есть пример интеграции с MCP cognico.ru. Собеседника можно задать тремя способами: вручную по карточке, из записи встречи в Cognico или без карточки. Тогда это Молчун.

Импорт из встречи работает так:

1. Пользователь подключает свой кабинет по OAuth 2.1 + PKCE. У каждого свой кабинет.

2. Выбирает запись встречи и человека.

3. Модель получает только реплики этого человека и саммари встречи.

4. Она заполняет закрытую карточку: имя, роль, форма обращения, длина реплик, формальность, жёсткость, черты манеры, характерные фразы.

5. Пользователь проверяет карточку и только потом сохраняет.

Токены Cognico лежат в базе в зашифрованном виде (Fernet). У собственного собеседника есть ручка жёсткости от 0 до 1. Она напрямую задаёт скорость уступок.

---

Архитектура

Mini App “Вершина” на Vue 3 общается с бэкендом на FastAPI по HTTPS, реплики приходят потоком SSE. Модели вынесены в переходник на Deno Deploy. Карточка собеседника собирается из Cognico.ru по MCP. Всё крутится на одном сервере в Яндекс.Облаке.

Игрок (Telegram Mini App, Vue 3)    Жюри по ссылке (разбор без входа)
        |                                    |
        v                                   v
   Caddy: HTTPS, статика фронта, /api -> бэкенд
 |
        v
   FastAPI: движок, страж, метрики, разбор, поток реплик

        |-> Deno Deploy -> Groq (qwen3.8, gpt-oss)

        |-> Cloudflare Workers AI (резерв)

        |-> Cognico MCP (OAuth 2.1 + PKCE)

        |-> PostgreSQL 18 (партии, ходы, разборы)

        |-> content/ (YAML: сценарии, персонажи, пороги)

Выкладка: коммит из репозитория, релиз, миграции, systemd. CI на GitHub Actions.

Слои бэкенда. Они жёстко разделены.

• backend/arena/domain/ хранит правила: сделку, зону соглашения, кривые уступок, фазы, разметку, стража, метрики. В нём нет ни базы, ни HTTP.

• backend/arena/application/ содержит операции: аккаунт, каталог, переговоры, тон модели, разметка, разбор, Cognico.

• backend/arena/api/ описывает эндпоинты, формы запросов и ответов, коды ошибок.

• backend/arena/infrastructure/ отвечает за базу, загрузку content/, провайдеры моделей и клиент Cognico.ru

• backend/migrations/ хранит миграции Alembic.

• content/, deploy/ и proxy/ отдельно: контент, выкладка и переходник к Groq.

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

Контент как данные. Сценарии, персонажи, пороги метрик и тексты разборов лежат в YAML в репозитории. Менять сценарий можно без правки кода.

Модели по задачам. У каждой задачи своя модель со своим лимитом бесплатного Groq.

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

Доступ к моделям. Запросы идут через переходник на Deno Deploy в регионе Амстердам. Ключ Groq лежит только в секретах переходника. Сервер знает лишь токен доступа к переходнику.

Безопасность

• Вход из Mini App по подписи initData токеном бота (HMAC-SHA256, срок жизни сутки). Один пользователь Telegram, один аккаунт.

• Пароли хешируются argon2id.

• Токены сессий в базе хранятся только в виде хешей.

• Есть лимиты попыток входа.

• Токены Cognico зашифрованы (Fernet).

Контракт API описан в docs/api-contract.md, живая документация лежит на /docs запущенного бэкенда.

Стек

• Бэкенд: Python 3.12, FastAPI, pydantic, SQLAlchemy 2, Alembic, psycopg 3, httpx, argon2-cffi, cryptography, PyYAML, uvicorn, pytest.

• Фронтенд: Vue 3 (Composition API), TypeScript, Pinia, Vue Router, Vite, pnpm, Telegram Mini Apps.

• Данные: PostgreSQL 18, YAML в репозитории

• Модели: Groq, резерв Cloudflare Workers AI

• Инфраструктура: Яндекс.Облако, Caddy, systemd, бэкапы, GitHub Actions

  

Фронтенд: как проверяли код, который писал ИИ

Фронтенд в проекте вела Анастасия Ярош. Telegram Mini App на Vue 3 нужно было собрать с нуля и в одиночку за один спринт. Без AI-инструментов в срок бы не уложились, но у них есть побочный эффект: легко получить много кода, который никто не понимает и не сможет поддерживать. Поэтому Настя сделала ставку на процесс проверки.

Бэкенд ещё не был готов и она подняла свою среду на моках. Локальную версию развернули через GitHub Pages и Actions. Это позволило разрабатывать и проверять интерфейс параллельно с бэкендом. Правило приёмки было простым — каждое автодополнение сверяется со спецификацией, и в проект попадает только то, что Настя понимает и может поддержать.

Что проверялось руками, а не доверяли ИИ:

1. Сценарии. Полный флоу с геймификацией и без. Состояния loading, error и empty, повторные действия, возврат назад.

2. Интеграция. API подключён, ответы корректно обрабатываются, ошибки не ломают UI.

3. Платформа. В браузере и внутри Telegram Mini App интерфейс ведёт себя по-разному. Отдельно смотрели тему, размеры, safe-area и навигацию.

4. Ассеты. Изображения и SVG после генерации проверяли глазами. SVG чистили вручную, картинки подгоняли под контейнеры.

В итоге получился рабочий фронтенд, сделанный с нуля и в срок. Настя пробовала Cursor, SourceCraft с Grok, плагины Copilot, DeepSeek и Алису, выбирая инструмент под задачу. Её главный вывод — ИИ ускоряет исполнение, но не заменяет постановку задачи и UX/UI-мышление.

---

Геймификация как слой, а не режим

Мы сознательно не делали из тренажёра игру. Так как один из вариантов юзкейсов — b2b, где геймификация будет бесить. Геймификация в нашем продукте — это слой поверх партии, который пользователь включает сам. По умолчанию он выключен. Когда выключен, интерфейс не показывает бейджи, прогресс и коллекцию, а разбор и метрики работают как обычно.

Технически слой только читает журнал ходов и состояние движка. На исход и метрики он влиять не может. Есть коллекция “Покорённые вершины” из пяти бейджей. Например, “Скалозавр” выдаётся тому, кто не принял невыгодные условия под давлением или ультиматумом.

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

Админки нет, и это продуктовое решение

Контекст симуляции задаётся в визарде. Игрок сам администратор своей тренировки. Мы сознательно не делали отдельную админку. Тренажёр сделан в формате self-service — человек настраивает разговор под свою реальную ситуацию. Для B2B я предусмотрела свой MCP для интеграции с LMS и CRM.

Что я исключила из MVP

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

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

Что не вошло (aka дальнейшие планы на развитие продукта):

• голосовой режим (распознавание и синтез речи);

• дашборд прогресса с трендами (в MVP есть история сессий);

• генерация сценария моделью на лету;

• числовая цена альтернативы (BATNA);

• частичная сделка, то есть согласие по части условий;

• версии мини-приложений для «ВКонтакте» и мессенджера Max, адаптивный web;

Как я работала с командой

Пятеро незнакомых людей, один недельный спринт. Маргарита Рубин отвечала за бэкенд, Анастасия Ярош за фронтенд и деплой, две дизайнерши, Анна Кашицына и Анастасия Дементьева, за сценарии, флоу и визуальную метафору. Я, Янина Шкуропат, за продукт и ресёрч.

Нам помогло сработаться и не впасть в конфликты одно правило: одно решение на каждый спорный вопрос. Когда скрины и флоу менялись в очередной раз, мы не спорили, а перестраивались. На ретро по методу 4L мы нашли и минусы — не хватило DS/ML-экспертизы, на макетах не проработали часть флоу и получили тупики, а лимит токенов кончился в процессе.

Меня лично удивило, как быстро собирается сложный MVP с подписными ИИ-сервисами. Раньше на такой набор уходили месяцы и целая команда. Здесь мы уложились всего в недельный спринт.

Что дальше

Хотим идти по B2C и B2B параллельно.

• B2C: регистрация в Telegram Apps, партнёрства с ИТ-сообществами, сообществами продажников, стартаперов и университетов, версии для «ВКонтакте» и Max.

• B2B: свой MCP для LMS и CRM, глубокий custdev, поиск пилотов с интеграторами CRM и компаниями, у которых есть LMS. Главный вопрос для custdev — важны ли голосовые созвоны для начала тренировки переговоров.

---

Попробуйте наш тренажер переговоров

Настройка условий и тренировка одного сценария занимает 5-7 минут. Открой Telegram Mini App “Вершина”, выбери “Новые переговоры”, затем «Скидка у подрядчика» и собеседника Токсичный CPO. Чтобы увидеть работу движка, задайте открытый вопрос о его ситуации, сошлитесь на рыночную цену или уступите два раза подряд, ничего не попросив взамен. Потом откройте разбор и посмотрите точку разворота.

Mini App «Вершина» доступна до 30 декабря: https://t.me/negotiation_simulator_bot/vershina_ai

Подробнее о продукте и команде: https://peak-negotiate-ai.lovable.app/

PS. Эта статья основана на фитбеке и рефлексии команды по методу 4L сразу после хакатона. Будем рады поддержке и, надеюсь, кого-то вдохновим не бояться и пробовать сделать что-то, чем будете гордиться )