Cursor ИИ получил долговременную память: как вики-слой сохраняет контекст между сессиями

В чём суть?

Автор кейса столкнулся с проблемой, знакомой любой команде, которая работает с ИИ-ассистентом дольше одной сессии. Код лежит в репозитории и доступен модели. А вот требования, договорённости, результаты исследований и причины отвергнутых решений рассыпаны между транскриптами встреч, чатами, SQL-запросами и памятью участников.

Отправной точкой стала концепция LLM Wiki Андрея Карпати. Идея: между сырыми источниками и ответами модели появляется отдельный слой, связанная Markdown-вики. Сырые документы остаются неизменными, а производное знание постепенно копится в тематических страницах, индексе и журнале изменений.

На практике путь от концепции до рабочего инструмента прошёл через несколько итераций: настройку QMD (локальный поисковый движок для Markdown-файлов), попытку вынести обработку на локальные модели, отдельный MCP-контур и, наконец, возврат к устойчивой схеме: Cursor ИИ, набор project skills (готовых инструкций для агента) и вызов Cursor CLI для фоновой обработки.

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

Четыре довода в пользу такой архитектуры

Контекст не теряется между сессиями. Типичный сценарий: на встрече заказчик формулирует требования, запись проходит через AudioToText и превращается в транскрипт, при анализе модели данных появляются SQL-фрагменты и гипотезы, часть решений меняется после проверки на реальных данных. Через несколько сессий агенту снова нужен весь этот контекст. Без вики каждый раз приходится заново прикладывать документы и разрешать противоречия.

Разделение сырого и синтезированного. Неизменяемый слой raw/ хранит первоисточники. Синтезируемый слой wiki/ (с разбивкой на sources, entities, concepts и analyses) содержит производное знание. Каждое утверждение привязано к первоисточнику. Это снижает риск галлюцинаций (ситуаций, когда модель уверенно выдумывает то, чего не было).

Масштабирование по предметным областям. Каждая база знаний регистрируется в QMD как отдельная коллекция. Например, сначала хранилище содержит данные о продажах, позже добавляется логистика со связями к сущностям из блока продаж. При поиске Cursor ИИ обращается к нужной предметной области, а не ко всему массиву файлов.

Детерминированность. Все операции запускаются одними и теми же командами, а не зависят от формулировки очередного промпта. Автор подчёркивает: этот пункт оказался важнее, чем казалось на старте.

Честные аргументы против

Хрупкость при обновлениях. Cursor обновляется часто. Любая привязка к CLI, skills и внутренним механизмам может сломаться после очередного релиза. Автор сам признаёт, что прошёл через несколько отброшенных решений, включая отдельный MCP-контур и вынос обработки на локальные модели.

Порог входа. Настройка QMD, структурирование каталогов, написание SCHEMA.md и AGENTS.md, оформление операций в skills, это инженерная работа, которая требует времени и квалификации. Для автора Дзена или маркетолога без технического бэкграунда такой контур пока недоступен без помощи разработчика.

Локальные модели не справились. На старте казалось, что фоновую обработку (ingest, то есть загрузку и структурирование новых документов) можно отдать локальным моделям и не тратить облачные лимиты. На практике задача оказалась сложнее, и автор вернулся к облачным моделям через Cursor.

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

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

Что делать с этим прямо сейчас?

Автору Дзена. Если вы ведёте серию статей на одну тему и каждый раз заново объясняете ИИ-ассистенту контекст проекта, попробуйте минимальный вариант: заведите папку с Markdown-файлами, где фиксируете ключевые решения и термины. Даже без QMD и skills это сэкономит токены (единицы текста, которые расходует модель) и время.

Маркетологу и аналитику. Кейс показывает рабочий путь, как довести проектное знание до ИИ-агента так, чтобы он не терял контекст. Если ваша команда ведёт требования и решения на русском, структура raw/ и wiki/ с привязкой к первоисточникам работает на любом языке. Главное, разделить инструкции для модели и детерминированную оркестрацию.

Предпринимателю в РФ. Cursor доступен из России, хотя с ограничениями по оплате. Из доступных в РФ аналогов для кодинга с ИИ стоит смотреть на GigaCode от Сбера. Но сам подход, вики-слой между сырыми документами и моделью, можно реализовать поверх любого редактора, включая VS Code с расширениями.

Концепция Карпати и её реализация в Cursor ИИ пока остаётся инструментом для технически подготовленных команд. Но направление очевидно: модели будут получать собственную проектную память, и те, кто научится её структурировать раньше, перестанут тратить токены и время на повторные объяснения.