База знаний для Claude Code и Codex

Зачем AI собственная база

Claude Code, Codex и другие современные AI-агенты уже способны выполнять достаточно сложную разработку.

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

Но существует фундаментальная проблема — контекст.

Представим, что я несколько месяцев разрабатываю большой интернет-магазин.

За это время были приняты десятки решений:

1. почему выбрана конкретная архитектура;
2. какие API используются;
3. какие подходы уже тестировались;
4. почему отказались от определенной библиотеки;
5. как устроен обмен с 1С;
6. какие ограничения существуют у проекта;
7. какие ошибки уже возникали;
8. каким способом они были исправлены.

Человек постепенно накапливает эти знания.

Но новая сессия AI далеко не всегда знает всю историю.

Можно создать CLAUDE.md, AGENTS.md или подробную документацию проекта. Это значительно улучшает ситуацию, но по мере роста проекта один файл начинает превращаться в огромный справочник.

Кроме того, появляется другой вопрос.

Что делать со знаниями, которые относятся не к одному проекту?

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

Через месяц эти же сведения могут понадобиться в другом проекте.

Еще через неделю я работаю не в Claude Code, а в Codex.

Заново проводить одно и то же исследование не очень рационально.

Именно эту проблему пытается решить llm-wiki.

Что такое llm-wiki

llm-wiki — open-source проект, разработанный NVK.

Сам автор описывает его как систему LLM-compiled knowledge bases for any AI agent — базы знаний, которые создаются и поддерживаются при помощи языковых моделей.

Проект распространяется через GitHub и поддерживает несколько вариантов использования.

Для Claude Code существует нативный plugin.

Для OpenAI Codex — marketplace plugin.

Также предусмотрены варианты для OpenCode, Pi и других AI-агентов через переносимый AGENTS.md.

То есть база знаний не привязывается исключительно к одной нейросети.

Это важная идея проекта.

Знания принадлежат пользователю, а AI является инструментом для работы с ними.

Сегодня можно использовать Claude Code.

Завтра — Codex.

Для определенной задачи — другую модель.

Но накопленная wiki остается.

Это больше обычной памяти

На первый взгляд llm-wiki можно принять за еще одну систему памяти для AI.

Но это не совсем правильно.

Обычная memory-система в основном пытается сохранить факты предыдущих разговоров.

llm-wiki работает значительно шире.

Она умеет:

• собирать источники;
• импортировать документы;
• проводить исследования;
• запускать несколько исследовательских агентов;
• структурировать найденную информацию;
• создавать тематические wiki;
• проверять противоречия;
• искать пробелы в знаниях;
• отвечать на вопросы по накопленной базе;
• создавать отчеты и другие материалы.

Поэтому правильнее рассматривать llm-wiki как отдельный слой знаний между пользователем и AI-агентом.

Условно архитектуру можно представить следующим образом:

Интернет + документы + проекты → llm-wiki → Claude Code / Codex → результат.

AI больше не обязательно каждый раз начинать исследование с нуля.

Сначала он может проверить, что уже известно.

Как устроена база знаний

llm-wiki использует тематический подход.

Можно создавать отдельные wiki для разных направлений.

Например:

• wordpress
• bitrix
• seo
• php
• ai-development
• project-shop
• project-corporate

Таким образом не приходится складывать всю накопленную информацию в один гигантский файл.

Каждая тема получает собственную структуру.

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

Также предусмотрен локальный режим .wiki/, когда знания необходимо хранить непосредственно рядом с конкретным проектом.

Это удобно, потому что существуют два совершенно разных типа информации.

Первый — глобальные знания.

Например, особенности WordPress REST API.

Они могут пригодиться во многих проектах.

Второй — проектные знания.

Например, правила интеграции конкретного интернет-магазина с его CRM.

Такая информация имеет смысл только внутри одного проекта.

llm-wiki позволяет разделять эти сценарии.

Как установить Claude Code

Для Claude Code установка максимально простая.

Используется официальный plugin-механизм Claude Code:

claude plugin install wiki@llm-wiki

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

Например:

/wiki

показывает состояние wiki.

Для создания новой тематической базы используется:

/wiki init wordpress

После этого можно начинать наполнять ее информацией.

Claude Code является основным runtime, вокруг которого изначально проектируется llm-wiki. При этом логика самой базы остается независимой от конкретной модели.

Как установить для Codex

Для OpenAI Codex предусмотрен отдельный marketplace plugin.

Сначала подключается репозиторий:

codex plugin marketplace add nvk/llm-wiki

Затем устанавливается plugin:

codex plugin add wiki@llm-wiki

После установки основной точкой входа становится:

@wiki

Например:

@wiki research "WordPress performance optimization"

Для небольших запросов существует отдельный облегченный режим $wiki-query.

Это интересная оптимизация.

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

Можно использовать компактный read-only режим.

По данным самого проекта, $wiki-query для Codex занимает около 2,8 КБ инструкций, тогда как полный @wiki значительно больше.

Для AI это важно, поскольку инструкции тоже расходуют доступный контекст.

Первый вариант использования

Представим, что я начинаю глубоко изучать оптимизацию WordPress.

Можно дать Claude Code команду:

/wiki:research "WordPress performance optimization" --new-topic

llm-wiki создаст тематическую wiki и проведет исследование.

Но этим возможности не ограничиваются.

Проект поддерживает параллельное исследование несколькими агентами.

Например:

/wiki:research "WordPress performance optimization" --deep --min-time 1h

В этом случае система не просто выполняет один поисковый запрос.

Она может разбить тему на направления, исследовать их параллельно, находить дополнительные вопросы и постепенно расширять базу.

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

Это принципиальная разница.

Ответ в чате через несколько дней может потеряться.

Результат исследования в wiki остается частью базы.

Можно добавлять свои источники

Необязательно разрешать AI самостоятельно искать всю информацию.

В базу можно добавлять конкретные материалы.

Например:

/wiki:ingest https://example.com/article

Источником может быть URL, файл, PDF или текст.

Это особенно удобно для технической документации.

Представим, что проект использует несколько API.

Можно добавить в wiki документацию платежной системы, CRM, службы доставки и внутренние документы проекта.

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

Вместо:

Найди в интернете, как работает этот API.

можно спросить:

Что наша база говорит о создании заказа через API?

Это снижает количество повторных исследований и позволяет использовать заранее выбранные источники.

Можно импортировать коллекции

Для больших объемов информации существует ingest-collection.

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

Например, llm-wiki умеет работать с Git-репозиториями документации, MediaWiki, архивами сообщений и некоторыми другими источниками.

Пример из документации проекта:

/wiki:ingest-collection https://github.com/bitcoin/bips --wiki bitcoin

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

Для разработчика это открывает интересный сценарий.

Допустим, существует большой open-source проект с сотнями документов.

Вместо постоянного поиска по GitHub можно импортировать нужный корпус в тематическую wiki и дальше обращаться к нему через AI.

Исследование становится накопительным

Одна из главных идей llm-wiki — исследование не должно каждый раз начинаться заново.

Представим, что сегодня я изучаю:

оптимизацию WordPress.

Через неделю:

объектный кеш WordPress.

Еще позже:

Redis для WooCommerce.

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

В llm-wiki все исследования можно добавлять в одну тематическую базу wordpress.

Постепенно она становится специализированной базой знаний.

Через несколько месяцев там уже может находиться информация о:

• WordPress Core;
• WooCommerce;
• Redis;
• WP-Cron;
• REST API;
• WP_Query;
• безопасности;
• оптимизации SQL;
• кешировании;
• разработке плагинов.

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

Можно просто спрашивать базу

Когда информация уже собрана, начинается наиболее полезная часть.

Можно задавать вопросы.

Для Claude Code:

/wiki:query "Как оптимизировать WP_Query на большом каталоге?"

Для Codex можно использовать компактный $wiki-query.

Например:

$wiki-query "Что в базе известно об оптимизации WP_Query?"

Система ищет ответ в существующей wiki.

Есть и более глубокий режим:

/wiki:query "compare Redis and Memcached" --deep

Он полезен, когда ответ требует сопоставить несколько частей накопленных знаний.

Таким образом wiki становится своеобразным внешним мозгом AI-агента.

Пример для WordPress проекта

Представим реальный сценарий.

Я разрабатываю крупный интернет-магазин на WooCommerce.

Создаю wiki:

/wiki init shop-project

Затем добавляю техническое задание.

После этого документацию API CRM.

Затем документацию службы доставки.

Потом правила разработки проекта.

В процессе работы появляются решения.

Например:

для каталога используется определенный механизм кеширования;

синхронизация CRM запускается через очередь;

товары сопоставляются по external ID;

определенный API endpoint имеет ограничение 100 запросов в минуту.

Через несколько месяцев приходит задача:

Добавить массовую синхронизацию остатков.

В обычном AI-сеансе приходится снова объяснять архитектуру проекта.

При наличии wiki сначала можно получить существующий контекст:

/wiki:query "Как в shop-project устроена синхронизация товаров с CRM?"

После этого Claude или Codex может учитывать уже принятые архитектурные решения.

Именно здесь база знаний начинает реально экономить время.

Пример для 1С-Битрикс

Аналогичный подход можно использовать с 1С-Битрикс.

Можно создать wiki:

/wiki init bitrix

И постепенно добавить туда материалы по:

• D7;
• ORM;
• компонентам;
• событиям;
• Highload-блокам;
• интеграции с 1С;
• агентам;
• кешированию;
• REST;
• миграции PHP.

Через некоторое время возникает ошибка после перехода проекта на новую версию PHP.

Вместо полностью нового исследования можно спросить:

/wiki:query "Какие проблемы совместимости PHP 8 уже встречались в наших Bitrix проектах?"

Если подобные случаи раньше были добавлены в базу, AI сможет использовать накопленный опыт.

Получается уже не просто документация.

Это постепенно превращается в личную техническую базу практических решений.

Полезно для нескольких агентов

На мой взгляд, одна из самых интересных особенностей llm-wiki — независимость знаний от конкретного AI.

Сегодня разработчик использует Claude Code.

Для следующей задачи запускает Codex.

Еще часть работы выполняется другим агентом.

Без общего слоя каждый AI получает собственный контекст.

Получается:

Claude знает одно.

Codex знает другое.

Документация содержит третье.

llm-wiki предлагает сделать wiki общей точкой.

Claude может провести исследование и сохранить результат.

Позже Codex сможет обратиться к той же базе.

То есть знания перестают быть привязаны к истории конкретного чата.

Для разработчиков, которые постоянно переключаются между AI-инструментами, это очень полезная концепция.

Проверка знаний через audit

У любой большой базы есть проблема.

Информация может устареть или противоречить друг другу.

Поэтому llm-wiki поддерживает audit.

Например:

/wiki:audit --project my-project

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

Это особенно важно для технической информации.

Представим, что год назад в wiki было записано:

Используем библиотеку версии 3.

Сегодня вышла версия 5 и часть API изменилась.

Если AI безоговорочно доверяет старой базе, он может предложить неправильное решение.

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

Наоборот, чем дольше существует wiki, тем важнее периодически проводить аудит.

Есть thesis-исследования

Интересная возможность llm-wiki — исследование конкретной гипотезы.

Для этого существует режим thesis.

Вместо общего:

Изучи влияние X.

можно сформулировать утверждение, которое необходимо проверить.

Система ищет аргументы как в поддержку, так и против него, после чего формирует вывод.

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

Например:

Redis является оптимальным вариантом кеширования для нашего проекта.

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

Такой подход помогает бороться с одной из проблем AI — склонностью соглашаться с исходной постановкой пользователя.

Можно создавать готовые материалы

Накопленная база нужна не только для вопросов.

llm-wiki поддерживает генерацию output-материалов.

Например:

/wiki:output report --topic wordpress

может использовать накопленные знания для создания отчета.

Предусмотрены и другие типы output.

Получается полезная схема:

исследование → база знаний → готовый материал.

Для контентного проекта это можно использовать при подготовке статей.

Для бизнеса — отчетов.

Для разработки — технической документации.

Главное преимущество заключается в том, что итоговый материал создается не на основании одного случайного AI-запроса, а на основе уже собранной тематической базы.

Для кого подходит llm-wiki

В первую очередь я бы рекомендовал llm-wiki разработчикам, которые активно используют Claude Code или Codex.

Особенно если работа ведется сразу над несколькими крупными проектами.

Вторая аудитория — исследователи.

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

Третья — технические команды.

Wiki может стать общим слоем знаний о проекте, архитектуре и принятых решениях.

Четвертая — авторы технического контента.

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

Пятая — специалисты, которые используют несколько AI-агентов.

Именно здесь независимость wiki от Claude или OpenAI становится особенно полезной.

Когда плагин будет лишним

llm-wiki нужен далеко не каждому.

Если Claude Code используется несколько раз в месяц для небольших задач, отдельная инфраструктура базы знаний будет избыточной.

То же самое относится к маленьким проектам.

Для сайта из нескольких страниц достаточно хорошего CLAUDE.md или AGENTS.md.

Не нужно создавать сложную wiki только потому, что такая возможность существует.

Я бы рассматривал llm-wiki тогда, когда начинает возникать хотя бы одна из проблем:

AI приходится постоянно повторно объяснять контекст;

одни и те же исследования выполняются несколько раз;

накопилось много технической документации;

работа ведется несколькими AI-агентами;

проект развивается месяцами или годами;

знания нужно использовать сразу в нескольких проектах.

В этих случаях затраты на организацию базы начинают окупаться.

Какие есть ограничения

Первое — wiki необходимо поддерживать.

Автоматизация не отменяет информационную гигиену.

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

Второе — источник может ошибаться.

Если в wiki попала неправильная статья, AI не сделает ее автоматически правильной.

Третье — информация устаревает.

Особенно быстро это происходит в веб-разработке и AI.

Поэтому важные сведения необходимо периодически перепроверять.

Четвертое — база занимает контекст.

Именно поэтому в llm-wiki появились облегченные query-профили.

Для простого вопроса лучше использовать компактный read-only запрос, а не загружать полный исследовательский workflow.

Пятое — это дополнительный инструмент, который необходимо освоить.

Для простых задач его сложность не оправдана.

Как использовать эффективнее

Я бы не начинал с попытки создать «базу обо всем».

Это практически гарантированно приведет к хаосу.

Лучше начать с одной конкретной области.

Например:

wordpress-development

В нее добавить только качественные материалы, которыми вы действительно пользуетесь.

После этого провести несколько исследований.

Затем начать задавать базе вопросы в реальной работе.

Если подход оказывается полезным, можно создавать следующие тематические wiki.

Например:

bitrix-development

php

seo

ai-tools

Отдельно можно создавать локальные .wiki для крупных клиентских проектов.

Таким образом постепенно формируется собственная AI-инфраструктура знаний.

Чем отличается от документации

Может возникнуть логичный вопрос.

Зачем все это, если можно просто написать документацию?

На самом деле одно не заменяет другое.

Хорошая документация по-прежнему необходима.

Но обычная документация в основном пассивна.

Человек должен знать, где находится нужный документ, открыть его и найти информацию.

llm-wiki добавляет поверх документов AI-слой.

Можно задать вопрос естественным языком.

AI самостоятельно определит, какие части базы относятся к задаче.

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

Поэтому я бы рассматривал wiki не как замену документации, а как интеллектуальный слой над ней.

База знаний меняет AI-разработку

Сейчас основное внимание вокруг AI-программирования сосредоточено на моделях.

Какая модель лучше пишет код?

Claude?

GPT?

Gemini?

Но по мере развития инструментов все большее значение начинает иметь другой вопрос:

какой контекст получает модель?

Даже самая мощная модель плохо поможет, если ничего не знает об архитектуре конкретного проекта.

И наоборот.

Хорошо организованная база знаний может значительно повысить полезность даже без смены модели.

Именно поэтому проекты вроде llm-wiki выглядят интересными.

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

Что получаем результате

llm-wiki — интересный open-source инструмент для тех, кто уже серьезно использует AI в разработке.

Его главная идея достаточно проста:

не заставлять AI каждый раз начинать с нуля.

Исследование, которое Claude провел сегодня, может пригодиться Codex через месяц.

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

Принятые архитектурные решения можно сохранить и использовать в следующих сессиях.

А знания по технологиям постепенно превращаются в персональную техническую базу.

Особенно интересно, что проект не замыкается на Claude Code.

Claude является основным runtime llm-wiki, но существуют официальные варианты для Codex, OpenCode, Pi и переносимый AGENTS.md для других агентов.

Поэтому я бы рассматривал llm-wiki не просто как очередной plugin.

Это попытка создать независимый слой долгосрочных знаний для AI-агентов.

Для небольших задач такой подход будет избыточным.

Но если вы ежедневно работаете с Claude Code или Codex, ведете несколько проектов, регулярно проводите технические исследования и постоянно сталкиваетесь с необходимостью повторно объяснять AI один и тот же контекст — llm-wiki определенно стоит попробовать.

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

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

Разработка сайтов с Denkon

AI-инструменты постепенно становятся полноценной частью процесса веб-разработки — от анализа требований и проектирования архитектуры до написания кода, тестирования и ведения технической документации.

Я использую современные инструменты там, где они позволяют ускорить работу без потери контроля над качеством. Если вам нужен новый сайт, интернет-магазин, доработка существующего проекта или индивидуальная разработка на WordPress и 1С-Битрикс, можно обсудить задачу и подобрать оптимальный подход к реализации.

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