Это короткая заметка Андрея Карпатого — бывшего директора по AI в Tesla и одного из основателей OpenAI. Он не из Anthropic, у него свой взгляд со стороны: что такое LLM на бытовом уровне и как с ней удобно работать. Заметка маленькая, текстовая, без кода — хорошая «добивающая» вещь, чтобы у вас сложилась ментальная модель того, что вообще происходит, когда вы общаетесь с Claude.
Главная мысль гиста — не про вашу систему лестниц напрямую (там LLM в коде нет), а про то, как использовать LLM-агента типа Claude Code в повседневной работе с документами и заметками. Но идея переносится: то же самое полезно держать в голове, когда вы накапливаете контекст по своему проекту — описание схемы базы, правила бизнеса, список заказов, чек-листы. Чем аккуратнее это сложено в файлы, тем лучше Claude сможет с этим работать.
Карпатый формулирует так:
Опыт большинства людей с LLM и документами выглядит как RAG: вы загружаете коллекцию файлов, LLM достаёт релевантные фрагменты в момент запроса и генерирует ответ. Это работает, но LLM каждый раз заново выводит знания с нуля. Нет накопления.
RAG (retrieval-augmented generation, «генерация с дополнением через поиск») — это когда вопрос пользователя сначала используется, чтобы найти подходящие куски в куче документов, а потом эти куски подсовываются LLM как контекст. Карпатый говорит: проблема в том, что при таком подходе LLM каждый раз начинает с чистого листа. Прочитала фрагмент, ответила, забыла. Никакого накопленного понимания у системы не появляется.
Его альтернатива — wiki, которую LLM сама ведёт и обновляет:
Вместо того чтобы просто доставать данные из сырых документов в момент запроса, LLM инкрементально строит и поддерживает постоянную wiki — структурированную, перелинкованную коллекцию markdown-файлов, которая стоит между вами и сырыми источниками.
Когда вы добавляете новый документ, LLM не просто его индексирует — она читает, выделяет главное и встраивает это в уже существующую wiki: обновляет страницы по сущностям, переписывает сводки, отмечает противоречия со старыми данными. Знание скомпилировано один раз и потом поддерживается актуальным, а не пересобирается заново на каждый вопрос.
Карпатый формулирует ключевую мысль так:
Wiki — это постоянный, накапливающийся артефакт. Перекрёстные ссылки уже на месте. Противоречия уже отмечены. Синтез уже отражает всё, что вы прочитали.
Карпатый описывает разделение труда так: вы отвечаете за поиск источников, исследование и постановку правильных вопросов. LLM делает чёрную работу — суммирование, перекрёстные ссылки, раскладывание по местам. Его метафора:
Obsidian — это IDE; LLM — программист; wiki — это codebase.
Obsidian здесь — популярный редактор markdown-файлов с боковой панелью со ссылками между ними. На практике у Карпатого с одной стороны экрана открыт LLM-агент, с другой — Obsidian. Агент правит файлы, человек смотрит результат вживую: ходит по ссылкам, читает обновлённые страницы.
Для вас аналогия такая: Claude Code — это «программист», ваша папка с документацией проекта (схема БД, правила приёма заказа, описание расчёта распилов, история решений) — это «codebase». Чем больше там аккуратно сложено, тем точнее Claude отвечает на вопросы и предлагает изменения.
Карпатый перечисляет области, где паттерн полезен:
Карпатый выделяет три слоя:
Сырые источники — собранная вами коллекция исходных документов: статьи, файлы данных, картинки. Они неизменяемые: LLM из них только читает, никогда не правит. Это ваш источник истины.
Wiki — каталог markdown-файлов, которые написала LLM: сводки, страницы по сущностям, страницы по концепциям, сравнения, обзор. Этим слоем LLM владеет полностью. Вы это читаете; LLM пишет.
Схема — отдельный файл (например, CLAUDE.md в случае Claude Code), который рассказывает LLM, как устроена wiki, какие соглашения и какому workflow следовать. Карпатый формулирует его роль так:
Это ключевой конфигурационный файл — именно он делает LLM дисциплинированным мейнтейнером wiki, а не дженерик-чат-ботом.
Для вашей ситуации это особенно близкий приём: CLAUDE.md в репозитории с лестницами уже работает по тому же принципу. Туда складываются договорённости — какие куски кода трогать осторожно, какие термины как называются, что вообще делает проект. Чем точнее этот файл, тем меньше Claude уходит в сторону.
Ингест. Вы кладёте новый документ в коллекцию и говорите LLM его обработать. Типичный поток: LLM читает документ, обсуждает с вами ключевые выводы, пишет страницу-сводку, обновляет индекс, обновляет соответствующие страницы по сущностям и концепциям, добавляет запись в лог. Один документ может затронуть 10–15 страниц wiki. Карпатый говорит, что лично он предпочитает добавлять источники по одному и оставаться вовлечённым — читает сводки, проверяет правки, направляет акценты.
Запрос. Вы задаёте вопросы по wiki. LLM ищет нужные страницы, читает их, синтезирует ответ с цитатами. Важная мысль:
Хорошие ответы можно складывать обратно в wiki как новые страницы.
То есть, если вы запросили сравнение, провели анализ, нашли связь — это не должно растворяться в истории чата. Положите ответ в wiki, и ваши собственные исследования будут накапливаться так же, как и добавленные источники.
Линт. Периодически просите LLM проверить wiki на здоровье. Что искать: противоречия между страницами, устаревшие утверждения, страницы-сироты без ссылок, важные понятия, у которых нет своей страницы, недостающие перекрёстные ссылки, пробелы в данных, которые можно закрыть веб-поиском.
Два специальных файла помогают LLM (и вам) ориентироваться в wiki по мере её роста.
index.md — про контент. Каталог всех страниц с короткой сводкой по каждой. Организован по категориям (сущности, концепции, источники). LLM обновляет его при каждом ингесте. Отвечая на вопрос, LLM сначала читает индекс, чтобы понять, куда смотреть, и потом углубляется в нужные страницы. Карпатый отмечает, что это удивительно хорошо работает на масштабе ~100 источников и ~сотен страниц — без всяких embedding-баз и сложного RAG-стека.
log.md — хронологический. Append-only запись того, что и когда делалось: что добавили, что спрашивали, когда был линт. Карпатый предлагает приём: если каждая запись начинается с консистентного префикса вида ## [2026-04-02] ingest | Article Title, лог становится парсимым обычными unix-инструментами:
grep "^## \[" log.md | tail -5— это даст последние 5 записей. Лог даёт таймлайн эволюции wiki и помогает LLM понимать, что недавно происходило.
В какой-то момент захочется небольших утилит, чтобы LLM эффективнее работала с wiki. Самая очевидная — поисковик по страницам. На малом масштабе хватает и индексного файла, но дальше нужен нормальный поиск. Карпатый рекомендует qmd — локальный поисковик по markdown-файлам с гибридным BM25/vector search и LLM re-ranking, всё на устройстве. У него есть и CLI (LLM может вызывать его как обычную команду), и MCP-сервер (LLM может использовать его как нативный tool).
Это часть гиста, тесно завязанная на Obsidian — но идеи переносятся куда угодно.
Здесь у Карпатого важная мысль, которая объясняет, зачем вообще всё это затеяно:
Нудная часть поддержки базы знаний — это не чтение и не размышление, это бухгалтерия. Обновлять перекрёстные ссылки, держать сводки актуальными, отмечать, когда новые данные противоречат старым утверждениям, поддерживать консистентность между десятками страниц. Люди забрасывают wiki, потому что бремя поддержки растёт быстрее, чем ценность.
Дальше — простой и важный аргумент: LLM не устают, не забывают обновить ссылку и могут затронуть 15 файлов за один проход. Поэтому стоимость поддержки близка к нулю — и wiki не загибается.
Карпатый формулирует разделение труда:
Работа человека — подбирать источники, направлять анализ, задавать хорошие вопросы и думать о том, что всё это значит. Работа LLM — всё остальное.
Идея, по словам автора, духом близка к Memex Ванневара Буша (1945) — личному курируемому хранилищу знаний с ассоциативными цепочками между документами. То, что Буш не смог решить, — кто делает поддержку. Это берёт на себя LLM.
В вашем случае LLM в коде нет — вся работа идёт через Claude Code, и вы не строите систему вокруг RAG'а. Но мысль гиста легко переносится:
CLAUDE.md в корне проекта — ваша «схема» в терминах Карпатого. Чем точнее в нём прописаны соглашения (что трогать, что не трогать, как называется что), тем дисциплинированнее ведёт себя агент.Карпатый сам подчёркивает в конце:
Этот документ намеренно абстрактный. Он описывает идею, а не конкретную реализацию. Точная структура каталогов, соглашения схемы, форматы страниц, тулинг — всё это будет зависеть от вашего домена, ваших предпочтений и LLM на ваш выбор.
То есть: не нужно один-в-один копировать Obsidian + qmd + Marp. Возьмите паттерн, выкиньте лишнее, оставьте то, что подходит вашей задаче. Для системы лестниц «wiki» — это, скорее всего, просто репозиторий с осмысленной структурой markdown-файлов и аккуратным CLAUDE.md сверху. Этого и достаточно.