Статья четвертая из серии. Былоисследование,личная история,продуктовый инсайт. Здесь будет продукт. Публикую манифест до того, как написана первая строчка кода — чтобы потом было честно сравнить, где я прав, а где разбился о реальность.
Большинство AI-ботов — это if-else вокруг GPT
Откройте любой «AI-коуч», «AI-психолог» или «AI-ассистент по саморазвитию». Под капотом почти всегда одно и то же: промпт с инструкцией «веди себя как коуч», пара-тройка условий на кнопки, и молитва, что модель не начнёт галлюцинировать диагнозы. Состояние — в лучшем случае в Redis с TTL на сутки. История — последние N сообщений в контексте. Логика — «спроси у Claude, что делать дальше».
Это работает ровно до первого серьёзного вопроса:а откуда взялся этот вывод обо мне?И тут выясняется, что никакого вывода нет — есть только последний ответ модели на последний запрос, сгенерированный заново, с нуля, без памяти о том, что было вчера.
Я строю продукт, где этот вопрос — центральный. Бот в мессенджере MAX, который ведёт адаптивный диалог с пользователем и строит многослойный профиль его личности. Не тест из 20 вопросов с готовым результатом. Не «спроси у ИИ, какой ты архетип». А система, в которойкаждый ответ пользователя — это неизменяемое событие, профиль —read model поверх event log, а LLM —не ядро, а один из узлов, причём не самый важный.
В этой статье — спецификация до первого коммита. Почему event sourcing. Почему инварианты. Почему Stability Engine. И почему я начал с YAML-файла на 700 строк, а не сnpm init.
Проблема: статичные тесты и амнезия чат-ботов
Человек не понимает своих паттернов. Это базовая неопределённость, которая сидит в нас почти всё время:как я думаю, что меня реально мотивирует, почему я снова и снова попадаю в один и тот же сценарий, где мои скрытые таланты, что мне на самом деле мешает.
Существующие инструменты отвечают на это плохо. MBTI и соционика — статичны: прошёл тест один раз, получил четыре буквы, забыл. Они не учитывают контекст жизни, не обновляются, не показывают динамику. Психотерапия — медленна и дорога, и даже там месяцы уходят на то, чтобы просто нащупать паттерны. А «AI-коучи» в телеграме страдают той самой амнезией: каждая сессия начинается с нуля, предыдущие разговоры — в лучшем случае в виде summary, который модель сама и галлюцинирует.
Что здесь на самом деле нужно — это система, которая:
- помнит каждый ответ как факт, а не как токены в контекстном окне;
- умеет показать,откудавзялся тот или иной вывод;
- меняет профиль только тогда, когда накопилось достаточно сигналов, а не после одной эмоциональной реплики в 3 часа ночи;
- различает «пользователь в поиске» и «пользователь в кризисе» — и во втором случае молча отходит в сторону, а не продолжает профилировать.
Всё это — не столько про ML, сколько про архитектуру. Поэтому я и начал со спеки.
Концепция: ÆON Map System
Профиль устроен как карта из семи слоёв. Каждый слой — это группа «карт» (cards), которые накапливают сигналы из диалога и в какой-то момент «назначаются» — когда уверенность достигает порога.
Слой I — Core.Когнитивный стиль и поведенческие паттерны. Как человек думает, как принимает решения, какие сценарии повторяет.
Слой II — Emotional & Motivational.Что реально мотивирует, а не что человек декларирует. Ценности-ядро.
Слой IV — Archetype.Архетипическая матрица — не юнговская поп-версия, а композиция из сигналов предыдущих слоёв.
В MVP — три этих слоя. Остальные четыре — стратегический, динамический, интеграционный и мета-слой — добавляются в v1 и v2.
Каждая завершённая сессия добавляет запись вBook of Consciousness— таймлайн трансформации. Финальный артефакт —глиф: уникальное визуальное изображение профиля, которое перегенерируется по мере того, как профиль уточняется.
Важно, чтопорядок разблокировки слоёв — линейный(сначала I, потом II, потом IV), номаршрутизация сигналов — сквозная: один ответ на вопрос из слоя II может дать сигнал в карту из слоя IV, если модель-классификатор увидит там релевантный паттерн. Это и есть разница между «пройди тест и получи результат» и «живая система, которая слушает всё».
Архитектурное решение: event sourcing, инварианты, стабильность
Теперь к интересному. Почему такая архитектура, а не очередной endpoint с промптом.
Event Core: ответ — это факт, а не состояние
Центральная сущность —Answer. Когда пользователь отвечает на вопрос, рождается событиеanswer.givenс полями:session_id,question_id,answer_value,answered_at. Оно записывается в таблицуeventsв PostgreSQL, и это append-only:никаких UPDATE, никаких DELETE. Инвариант INV-02, зафиксированный в спеке:
> Answer неизменяем после записи. Пользователь не может редактировать ответ — только пройти новую сессию.
Почему это важно. Если пользователь вчера ответил «я экстраверт», а сегодня — «я интроверт», это не ошибка данных. Это факт: два разных ответа в двух разных контекстах. Профиль должен уметь это держать — не как противоречие, которое надо «исправить», а как сигнал о том, что человек меняется (или что вопрос был плох). Если разрешить редактирование, мы теряем историю, а вместе с ней — возможность видеть динамику.
Профиль (AeonProfile) — этоread model, проекция над event log. Его можно пересобрать из нуля в любой момент, прогнав все события черезaeon_engine. Это даёт главное: воспроизводимость. Баг в логике построения профиля — не катастрофа, а патч + пересборка проекции.
Инварианты живут в domain/, а не в контроллерах
В спеке — 10 доменных инвариантов и 2 safety-инварианта. Каждый — с полемenforcement: где именно в коде он держится. Несколько примеров:
-INV-03: карта назначается только приconfidence ≥ CARD_CONFIDENCE_THRESHOLD(0.72). Проверка — в Stability Engine, не в LLM. Модельпредлагаетсигнал, решение принимает детерминированный код.
-INV-06:llm.calledevent пишется в базудоотправки ответа пользователю, а не после. Транзакционно. Если мы упали между вызовом LLM и ответом — у нас есть факт вызова, и мы можем разобраться.
-INV-07: одно сообщение пользователя = не более одногоanswer.given. Идемпотентность поmax_update_id. Ретрай вебхука от MAX не должен давать дубль события.
-INV-09: карта не назначается, пока суммарный вес сквозных сигналов по её типу не перевалит порог. Даже если слой уже разблокирован.
Каждый инвариант покрывается property-based тестом на Vitest + fast-check. Это не unit-тест «проверим один случай», это «сгенерируй 1000 случайных последовательностей событий и проверь, что инвариант держится». Именно такие тесты ловят дыры в логике, которые на примерах не видны.
Stability Engine: где живёт здравый смысл
Отдельный модульsrc/stability/, не размазанный по коду. Его работа — контроль порогов, лимитов и safety:
-DAILY_SESSION_LIMIT— 3 сессии в день, защита от злоупотреблений и LLM-расходов.
-CARD_CONFIDENCE_THRESHOLD— нельзя назначать карту на слабых сигналах.
-MIN_ANSWERS_PER_LAYER— 4 ответа минимум, иначе следующий слой не открывается.
-Safety Gate 1— rule-based проверка на кризисные маркеры (суицид, самоповреждение, насилие)долюбого дорогого вызова LLM.
Последнее — критично. Многие делают наоборот: отправляют сообщение в LLM, и уже он «решает», кризис это или нет. Но это значит платить за токены на каждом кризисном сообщении и доверять детекцию стохастической модели. Я делаю rule-based (словари маркеров + лёгкий классификатор) в детерминированном коде, с отдельными тестами. Если Gate 1 сработал — бот отвечает тепло и даёт телефон доверия 8-800-2000-122, и никакой LLM не вызывается. Gate 2 — в system prompt основного LLM, как второй рубеж для edge cases.
PDA как методология
Вся спека написана по методологии PDA — Possibility-Driven Architecture. В двух словах: сначала строится карта неопределённости (user-level и system-level), потом граф домена, потом инварианты, константы, события, архитектура, наблюдаемость. Код — в самом конце. Идея в том, что приложение — это машина снижения неопределённости: пользователь приходит с вопросами о себе, уходит с чуть более устойчивой моделью себя. Архитектура проектируется под это, а не под «как быстрее написать CRUD».
Отсюда — все решения выше. Event sourcing — чтобы любая итерация снижения неопределённости была обратимой. Инварианты — чтобы система не ломалась на входных данных, которые проектировщик не предвидел. Stability Engine — потому что есть класс решений, которые LLM принимать не должен никогда.
Почему LLM — периферия, а не ядро
Вот архитектурная схема, которая показывает поток: MAX webhook → адаптер → Stability Engine → Dialog Engine → Event Core. LLM вызывается параллельно, из Dialog Engine, и его вызов логируется как событие до отправки ответа. Aeon Engine работаеттолько с event store— он не имеет доступа к LLM и не должен иметь.
Контринтуитивный тезис:LLM в этой системе — не самый важный компонент. Самые важные — Event Core и Stability Engine. LLM можно заменить (Claude → OpenAI — fallback уже предусмотрен). Event Core и инварианты заменить нельзя — на них держится весь смысл.
Это не про «ИИ плохой» и не про «давайте всё делать на правилах». Это про разделение: что именно должен решать LLM, а что — нет.
LLM решает: как сформулировать следующий вопрос так, чтобы он был живым и адаптивным; как интерпретировать свободный текст ответа; как сгенерировать глиф (через DALL·E); как написать финальный текстовый профиль.
LLM не решает: когда назначать карту; когда прекращать сессию из-за кризиса; когда пользователь исчерпал лимит; какой слой разблокировать следующим; что такое «достаточная уверенность». Всё это — детерминированный код с тестами.
Такое разделение даёт две вещи, которые дороги в продукте. Первая — предсказуемость: поведение системы в edge-кейсах определено правилами, а не настроением модели. Вторая — дешевизна эксплуатации: если половина решений принимается до вызова LLM, расходы на API падают кратно.
Что дальше: трансляция сборки
План такой. Всего итераций — восемь, от нулевой (скелет: Docker, PostgreSQL, «привет» в MAX) до седьмой (safety, глиф, share-карточка). Каждая итерация — отдельная веткаfeat/iter-N, закрытие итерации — merge вmainи новая статья или короткий апдейт.
Формат трансляции — гибрид: первая из трёх больших статьей здесь, между ними — короткие апдейты со скриншотами и ссылками на коммиты. Репозиторийоткрытый, GitHub Issues и Projects — публичные.
Что будет во второй статье: итерация 1 и 2 — Event Core в PostgreSQL (append-only таблица с constraint-проверками, которые гарантируют INV-02 на уровне базы), идемпотентность поmax_update_id, первый вопрос через Dialog Engine, property-based тесты на инварианты. С рабочим кодом, миграциями и разбором граблей.
Если вам резонирует подход «спека до кода, инварианты до фич» — подписывайтесь, будет подробно. Если считаете, что всё это overengineering для бота в мессенджере — тоже подписывайтесь, через пару итераций проверим.
Спека целиком лежит в репозитории в файлеaeon-max-bot.vibepp.yaml— 700 строк машиночитаемого YAML, из которого Cursor-агент в принципе может восстановить половину кода. В репо уже есть что показать. Подписывайтесь, чтобы не пропустить.
Что думаете про такой подход? Если у вас есть опыт event sourcing в AI-продуктах — особенно интересно, где я ещё не вижу подводных камней. Критика приветствуется.
