Как я построил самообновляющуюсю базу знаний для 6 проектов используя Claude Code и LLM Wiki Андрея Карпатого

Практическое руководство по созданию постоянной памяти для вашего ИИ-ассистента для программирования, которая сохраняется между сессиями.

В апреле 2026 года Андрей Карпатый представил обманчиво простую концепцию: вместо использования RAG или бесконечных контекстных окон следует позволить LLM вести структурированную Markdown-вики в качестве базы долговременных знаний. Вы просто предоставляете исходные данные, а модель самостоятельно компилирует, систематизирует и обновляет вики. Вам не нужно заниматься редактированием вручную — модель берет на себя всю работу по ведению записей.

Я взял этот шаблон и применил его к своему повседневному рабочему процессу: 6 проектов, Claude Code в качестве основного инструмента программирования.

Вот что у меня получилось, что сработало, а что нет, а также точные промпты для повторения этого опыта.

Каждая сессия Claude Code начинается с чистого листа. Да, файл CLAUDE.md помогает. Да, модель может прочитать вашу кодовую базу. Но существует разрыв между «может прочитать код» и «понимает проект».

Мне приходилось снова и снова объяснять одни и те же вещи:

Умножьте это на 6 проектов, и вас ждет смерть от тысячи запросов на разъяснение контекста.

К счастью у нас есть Андрей Карпатый, нам повезло, что мы в одно время живем на одной планете с этим человеком и он делиться с нами своими знаниями и открытиями. Я уже писал об Autoresearch, а теперь пишу о LLM wiki, концепт которой он опубликовал в открытом доступе и который в эпоху LLM легко повторить на любом языке и для любого технического стэка. К оригинальной идее я добавил QMD от Тоби Лютке, CEO Shopify, как инструмент быстрого семантического поиска по текстовым файлам и построил ее вокруг Claude Code, попутно интегрировав в Compound Engineering workflow.

Система состоит из четырех уровней:

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

Вам понадобится CLI Claude Code c активной подпиской. Также потребуется инструмент QMD от Тоби Лютке для семантического поиска — он работает полностью локально и не требует вызовов API. Obsidian не является обязательным компонентом, но отлично подходит для удобного просмотра базы знаний человеком.

Вики-папка находится в корневом каталоге каждого проекта, рядом с кодом и добавлена в Git. В ней расположены:

Также в корне проекта находится директория raw/notes/, предназначенная для ручного добавления файлов: статей, которые вы хотите включить в базу знаний, проектной документации или заметок с совещаний. LLM считывает данные из raw/ и записывает их в wiki/

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

Бутстрапинг — это не «документирование всего подряд». Это извлечение 20% структуры, которая дает 80% полезного контекста. Я разделил этот процесс на 5 этапов, каждый из которых нацелен на определенную часть кодовой базы.

Этот промпт позволил сгенерировать наиболее полезные страницы вики:

Метаданные шаблона имеют решающее значение. Без них Claude создает страницы с несогласованным форматированием. Я включаю этот шаблон непосредственно в промпт:

Среднеразмерный проект с 21 моделью генерирует около 25 страниц за один проход за 10 минут.

Ниже пример для моих проектов на Рельсах, но вы можете адаптировать под свой стэк

Инструкция «пропускать тривиальные CRUD-контроллеры» имеет важное значение. Без неё Claude создаёт пустые страницы для каждого контроллера, включая те, что представляют собой лишь стандартные ресурсные действия, не содержащие ничего примечательного.

Этот этап подразумевает чтение не только самого кода, но и стоящих за ним намерений:

Эти три команды git log были тщательно отобраны. Первая находит коммиты, отражающие архитектурные изменения. Вторая фиксирует сводки слияний и pull-реквестов, которые зачастую содержат наиболее ценный контекст. Третья демонстрирует паттерны недавней активности.

Этап анализа пробелов оказался на удивление полезным. Для одного из проектов он выявил 9 классов почтовых рассылок, 20 задач Rake и 16 контроллеров Stimulus, которые не имели никакой документации. Также было сформулировано 7 открытых вопросов, например: «Каков полный путь конвейера от обнаружения до обогащения и проверки?». Эти пробелы органично заполняются в ходе последующих сессий.

Изначально я пропустил каталоги plans/ и todos/ которые появляются при использовании compound engineering подхода. Это было ошибкой. В этих файлах содержится именно та информация о причинах принятия решений, которая делает вики-базу ценной: текущие инициативы, известный технический долг, отложенные решения и приоритеты.

В процессе работы над 6 проектами удалось обработать 519 файлов и создать контент, который стал одним из самых ценных разделов базы знаний. В одном из проектов 151 файл с задачами был систематизирован в четкий реестр технического долга с указанием приоритетов.

Настоящая экономия времени: система субагентов Claude Code позволяет запускать процесс подготовки сразу для нескольких проектов. Я дал Claude Code команду настроить 4 проекта одновременно — он создал отдельные агенты, каждый из которых читал кодовую базу своего проекта и параллельно писал страницы вики. Четыре проекта за 25 минут вместо 100.

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

Это важнейший компонент всей системы. Добавьте в файл CLAUDE.md следующую строку:

Always check wiki/ before answering questions about this project's architecture, patterns, or decisions.

Без этой строки Claude Code не будет проактивно обращаться к вики, ограничиваясь лишь чтением кода. С ней же Claude считывает wiki/index.md в начале каждого соответствующего запроса, находит нужные страницы и основывает свои ответы на предварительно собранных знаниях, вместо того чтобы каждый раз анализировать кодовую базу с нуля.

Остальная часть раздела wiki в файле CLAUDE.md содержит вспомогательную информацию: описание структуры вики, инструкции по сохранению полученных знаний на страницах вики в конце сессии, протокол запросов для поиска по базе знаний и напоминание о необходимости фиксировать пробелы в информации в файле wiki/gaps.md. Однако именно эта выделенная жирным шрифтом строка является триггером. Все остальное следует из нее.

После настройки файла CLAUDE.md начните новый сеанс Claude Code и задайте вопрос об архитектуре. Claude должен обратиться к wiki/index.md, найти соответствующие страницы, прочитать их и предоставить обоснованный ответ со ссылками на конкретные разделы вики. Если модель просто считывает код, не обращаясь к вики, значит, инструкции в CLAUDE.md недостаточно строгие.

Claude Code оснащен системой хуков, которая выполняет shell-команды при наступлении определенных событий жизненного цикла. Я настроил хук SessionStart, который срабатывает при каждом запуске сессии и после каждого /clear: он выводит первые 60 строк файла wiki/index.md и последние 15 строк wiki/log.md в контекст Claude. Это позволяет Claude быть в курсе содержания вики и последних изменений еще до того, как вы успеете задать вопрос.

Этот хук размещается в файле .claude/settings.json в корне вашего проекта. Если данный файл уже существует и содержит настройки прав доступа или плагинов, добавьте в него ключ hooks, не перезаписывая при этом остальное содержимое.

Когда вы фиксируете изменения в схеме, моделях, маршрутах или файле Gemfile, вики должна обновляться автоматически. Git-хук post-commit отслеживает измененные файлы и запускает Claude Code в фоновом режиме без участия пользователя, выполняя соответствующий целевой запрос.

1. Всё работает в фоновом режиме.

Хук использует nohup и &, поэтому он никогда не блокирует ваш рабочий процесс. Обновления вики появляются незаметно при выполнении следующей команды git status.

2. Бюджетные ограничения на каждый вызов.

Claude в headless-режиме поддерживает флаг --max-budget-usd. Обновление изменений в модели обычно обходится в сумму от 0,05 до 0,15 доллара. Я устанавливаю лимит в 0,50 доллара, чтобы неконтролируемое обновление не привело к перерасходу бюджета API.

3. Ограничения инструментов.

Флаг --allowedTools ограничивает возможности Claude — разрешены только операции чтения и записи файлов, сетевые вызовы запрещены. Это делает автоматизированные запуски предсказуемыми.

Флаг -p (prompt) запускает Claude Code в неинтерактивном режиме: программа выполняет запрос и сразу завершается.

Флаг --bare важен для автоматизированных запусков — он пропускает хуки, плагины и MCP-серверы, делая выполнение более быстрым и предсказуемым.

QMD от Тоби Лютке сочетает в себе полнотекстовый поиск по алгоритму BM25, векторные эмбеддинги и опциональное переранжирование с помощью LLM. Он работает полностью локально — никаких вызовов API и передачи данных за пределы вашего компьютера. Вы индексируете свою вики как «коллекцию», после чего QMD предлагает три режима поиска: по ключевым словам (самый быстрый), семантический (понимает смысл) и гибридный с переранжированием (наилучшее качество).

Ключевая интеграция: QMD оснащен плагином для Claude Code, который регистрирует MCP-сервер. После установки Claude Code получает возможность напрямую обращаться к информации в вашей вики через инструменты MCP в ходе любого сеанса — без необходимости ручного ввода команд в терминале. Установите его через маркетплейс плагинов Claude Code. Именно это превращает вики в по-настоящему «живой» инструмент: Claude не просто читает страницы по вашему запросу, он способен самостоятельно выполнять поиск по всем проиндексированным коллекциям в процессе своих рассуждений.

Протокол запросов CLAUDE.md ссылается на эти инструменты MCP, поэтому Claude использует их автоматически, когда ему требуется контекст проекта. В качестве резервного варианта для поиска по ключевым словам используется ripgrep, если QMD недоступен.

Для моих 6 проектов, содержащих 192 страницы вики, QMD проиндексировал 388 фрагментов, распределенных по 7 коллекциям.

Честно говоря, для вики-проектов объемом менее 100 страниц вполне достаточно ripgrep. Семантический поиск QMD проявляет себя, когда вы не знаете точных терминов: запрос «как работает конвейер данных» находит страницы о «поиске → обогащении → проверках», которые обычный поиск по ключевым словам пропустил бы. Но с плагином MCP использование QMD становится совершенно естественным — Claude задействует его автоматически, даже если вы его об этом не просили.

Основная база знаний расположена в ~/wikis/master/ — это единственная директория, выделенная отдельно, так как она объединяет несколько репозиториев. В ней хранятся: шаблоны, обнаруженные в двух и более проектах, общие стандарты написания кода, матрица использования gem-файлов для всех проектов, извлеченные уроки и выявленные сложности, трекер технического долга для повторяющихся проблем, а также краткие сводки по каждому из проектов.

Я запустил Claude Code в директории мастер-вики, предоставил ему доступ ко всем шести проектным вики через флаг --add-dir (который позволяет читать и записывать данные за пределами текущей рабочей области) и передал следующую инструкцию:

Постоянная синхронизация

Для каждого проекта настроен посткоммитный хук, создающий файл-флаг при любом изменении содержимого вики. Планировщик задач проверяет наличие этих флагов каждые два часа и при их обнаружении автоматически запускает Claude Code в фоновом режиме для синхронизации измененных проектов с основной базой знаний. Дополнительное ежемесячное задание выполняет полную синхронизацию всех проектов, вне зависимости от наличия флагов.

После выполнения каждого post-commit хука в папке ~/wikis/.sync-needed/ создается маркерный файл с названием проекта. Это позволяет задаче синхронизации главной вики определять, какие именно проекты подверглись изменениям.

Главная проблема любой базы знаний это захламление со временем.

Три запланированные задачи постоянно чистят и дополняют документацию без моего участия. Для этого я использую пользовательские таймеры systemd в Arch Linux, однако в других системах для тех же целей вполне подойдет cron.

Еженедельная проверка базы знаний охватывает все проекты, запуская Claude в фоновом режиме с запросом на выявление страниц-сирот, логических противоречий с текущим кодом, устаревшей информации и нерабочих ссылок. Система обновляет файл gaps.md и выполняет повторную индексацию QMD. Бюджет ограничен 0,50 доллара на каждый проект.

Двухчасовая мастер-синхронизация проверяет проекты, отмеченные соответствующими флагами, и выполняет их синхронизацию. Если флаги отсутствуют, задача не запускается, что позволяет экономить ресурсы при отсутствии изменений.

Ежемесячная полная синхронизация принудительно объединяет все проекты в главную вики, независимо от наличия флагов. Это ежемесячное обновление позволяет выявить все изменения, которые могли быть пропущены при инкрементальной синхронизации.

Каждая операция с вики — инициализация, загрузка, запрос или проверка — записывается в wiki/log.md с отметкой времени. В каждой записи фиксируется выполненное действие, созданные или обновленные страницы, обнаруженные пробелы и то, что послужило триггером для запуска процесса.

Это служит двум целям. Во-первых, это сообщает Claude, что вики уже известно, поэтому он не пересоздает существующие страницы. Во-вторых, это дает вам понятную для человека историю развития вики. Вы можете использовать grep для лога, чтобы увидеть, когда та или иная тема была задокументирована в последний раз или когда впервые был выявлен пробел в знаниях.

Стоимость использования API минимальна. По-умолчанию используется основная квота вашей подписки, но даже если бы мы платили за API кредиты Антропика, то первоначальная настройка обходится примерно в 0,50–1,00 доллара США на проект. Обновление вики после коммита стоит 0,05–0,15 доллара за раз. Еженедельный линтинг обходится в 0,30–0,50 доллара на проект, а общая синхронизация — в 0,50–1,00 доллара. Для шести активно развивающихся проектов ежемесячные расходы составляют примерно 20 долларов.

Флаг `--max-budget-usd` при каждом автоматизированном вызове служит вашей страховкой. Если что-то пойдет не так, процесс остановится по достижении лимита, вместо того чтобы бесконтрольно расходовать средства.

Я создал две вещи, чтобы это заработало — навык и команду, — обе они опубликованы в виде гистов, которые вы можете добавить в свою систему.

Навык (wiki-researcher) выполняет поиск по вики перед началом любой другой исследовательской работы. Он использует инструменты MCP от QMD для проведения ключевых и семантических поисковых запросов как по вики текущего проекта, так и по общей мастер-вики для всех проектов. Инструмент анализирует лучшие результаты, а затем формирует раздел «Прошлые знания», в который входят: принятые ранее важные решения, применимые шаблоны, известные ошибки, возможности для повторного использования компонентов и пробелы, которые может восполнить текущая работа.

Команда (/plan) дополняет ваш текущий процесс планирования. Сначала она запускает исследователь вики, а затем передает выполнение выбранной вами системе планирования — будь то /workflows:plan от Compound Engineering, собственный агент планирования или простой промпт. Полученные из вики знания используются при составлении плана в качестве дополнительного контекста.

Если вы используете плагин Compound Engineering, как и я, команда /plan автоматически запускает /workflows:plan в CE. Процесс выглядит следующим образом:

Если вы не используете Compound Engineering, команда /plan всё равно будет работать: она выполняет исследование вики, а затем вы можете направить результат туда, куда посчитаете нужным.

Этот навык совместим с любым рабочим процессом планирования. Ключевым моментом является использование инструментов MCP от QMD (которые соответствуют стандартному протоколу MCP), поэтому любой агент, способный вызывать инструменты MCP, может его использовать. Если у вас есть собственный агент планирования или вы используете другой плагин, просто настройте своего агента на вызов навыка wiki-researcher перед этапом исследования.

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

Когда я запускаю /plan для новой функции, исследователь вики-базы подготавливает контекст примерно следующего вида (переведен на русский для наглядности):

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

(Пример вымышленный, я не проектирую аутентификацию с нуля, я опубликовал в опенсурс свой gem rails_simple_auth который использую во всех своих проектах и это описано в wiki)

И на последок я делюсь всем что нужно, чтобы систематически собирать знания по модели LLM Wiki у себя в проектах.

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

Статью написал Иван Кузнецов, ex-fullstack dev, ex-fintech-executive, теперь продуктовый менеджер, vibe-кодинг и RoR энтузиаст. Веду закрытое сообщество для опытных пользователей ИИ Нейробилд, перевод подготовлен с использованием лучшего редактора для вдумчивых текстов Writero.