ИИ и автоматизация · 21 сентября 2026
Почему я перестал каждый раз объяснять ИИ, кто я
Решения остаются в переписках, задачи меняются, а новый разговор начинается с объяснений. Так у меня появилась своя память для ИИ — с поиском и разделением текущего и исторического контекста.

Вы уже объясняли задачу. Обсуждали, кому предназначен продукт, что в нём должно быть и от чего решили отказаться. Потом открываете другой разговор с ИИ — и снова нужно всё собирать. Если дать короткое объяснение, теряются важные ограничения. Если перенести всю переписку, вместе с полезным туда попадут отвергнутые идеи и устаревшие решения.
Мне хотелось продолжать работу с того места, на котором она остановилась. И ещё — менять инструменты, сохраняя накопленное. Вокруг этой задачи у меня постепенно выросло то, что я называю ядром: общая память, к которой можно обращаться из разных рабочих инструментов.
Началось с заметок в Obsidian
Первой основой стал Obsidian. Я собирал материалы и связывал их между собой. Такая база помогает вынести знания из отдельных разговоров: решение можно сохранить отдельно от длинного обсуждения, а описание проекта связать с задачами и другими материалами.
Но собрать сведения и подготовить их к работе — разные задачи. Допустим, в переписке предложили добавить функцию. Позже от неё отказались. Если сохранить оба разговора без пояснения, будущему помощнику придётся угадывать, какой из них считать действующим. Наличие двух записей ещё не означает, что система понимает принятое решение.
Поэтому для меня главным вопросом стало содержание памяти. Что мы решили? Почему? Это уже сделано или только обсуждается? Где исходный материал, по которому можно проверить краткую запись? Без таких различий даже аккуратно разложенные заметки превращаются в собрание убедительных, но противоречащих друг другу версий.
Зачем понадобился собственный интерфейс
По мере роста ядра мне потребовались свои возможности и другое визуальное представление. Так появился Moon Vault — собственный интерфейс поверх накопленных файлов, с поиском по смыслу и картой связей. Основа при этом сохранялась: уже собранные материалы не нужно было начинать заново.
Это был мой выбор способа работы. Из него не следует, что Obsidian не умеет работать с большими базами или что нужные возможности нельзя добавить иначе. Я развивал инструмент под свои задачи. У собственного решения есть и обратная сторона: его приходится поддерживать, проверять поиск, разбираться с тем, как новые материалы попадают в базу.
Карта связей интересна мне возможностью увидеть соседний контекст. Например, у решения по продукту могут быть связи с запросом пользователя и прежним ограничением. Но даже самая красивая карта не скажет, верно ли записано само решение. Порядок внутри заметок остаётся моей ответственностью.
Найти похожее — ещё не значит найти верное
Обычный поиск хорошо помогает, когда помнишь нужные слова. Но часто помнишь только смысл. Например, ищешь, почему перенесли запуск, а в записи это сформулировано как «вернуться после проверки спроса». Поэтому в ядре появился поиск по смыслу: он помогает находить близкие по содержанию материалы, даже если формулировки различаются.
Здесь легко ожидать слишком многого. Похожий текст может относиться к другому проекту. Старое решение может быть изложено подробнее нового и выглядеть убедительнее. Поиск даёт кандидатов для ответа, а их применимость всё равно нужно проверять.
В работе над ядром пришлось отдельно заниматься поиском на русском языке. Подходящую модель нельзя было выбрать только по обещаниям: имело значение, какие записи она находит в моей базе и насколько быстро работает в моей конфигурации. Этот опыт оставил простой критерий: проверять поиск своими вопросами, на которые известен правильный источник.
Мне нужна память, которая помогает восстановить основания решения. Само решение всё равно должно оставаться доступным для проверки.
Не всё сохранённое одинаково актуально
Другой частью работы стало распределение информации по актуальности — я называю это температурой. Есть то, с чем мы работаем сейчас. Есть материал на полке: к нему можно вернуться, но он не должен направлять каждое текущее действие. Есть завершённые направления, которые полезны как история.
Представьте, что вы сначала собирались продавать продукт по подписке, а затем выбрали оплату за отдельную услугу. Оба документа имеют право остаться в памяти. Но для подготовки сегодняшнего предложения важнее действующее решение. Старое пригодится, если вы захотите вспомнить аргументы и пересмотреть выбор.
Одних меток для этого мало. Если изменение не записано, система не обязана о нём догадаться. Температура помогает организовать внимание; она не делает память безошибочной. Я рассматриваю поиск по смыслу и работу с актуальностью как части одной задачи: достать полезный контекст и не выдать историю за сегодняшнюю инструкцию.
С чего можно начать у себя
Повторять всю мою систему для этого необязательно. Я бы начал с одного проекта, который регулярно приходится объяснять заново. Составил короткую запись: цель, текущее состояние, принятые решения, открытые вопросы. Рядом сохранил бы ссылки на материалы, где эти решения можно проверить.
- Отделите сделанное от желаемого. «Хотим подключить оплату» и «оплата работает» — разные сведения.
- Укажите дату существенного решения и явно отметьте, если оно заменяет прежнее.
- Попросите ИИ восстановить задачу по этим материалам и назвать источники. Посмотрите, где ему пришлось угадывать.
Так становится видно, чего именно не хватает: хорошего описания, нужного документа, связи между записями или поиска. Иногда достаточно поправить одну страницу. Именно такую пользу я ищу в памяти: чтобы следующий разговор начинался с понимания задачи, а решение можно было проверить по сохранённым основаниям.