Blueprint: Personal Wiki

Паттерн для построения LLM-компилируемой базы знаний из разрозненных заметок. Вдохновлён подходом Andrej Karpathy ("LLM Knowledge Bases"). Сырые заметки собираются в папках-источниках, LLM компилирует их в связную wiki, человек читает и дополняет через Q&A. Wiki растёт инкрементально — каждый запрос обогащает базу.

Как применить

1. Открой coding agent (Claude Code, Cursor, Codex) в директории vault
2. Покажи ему этот Blueprint: "Собери мне Personal Wiki по этому Blueprint"
3. Агент задаст вопросы из секции "Вопросы для адаптации"
4. Ответь про свои папки, соглашения, инструменты
5. Агент создаст папку wiki, индексные файлы, skill для компиляции

Контекст: одна сессия, vault — рабочая директория. Агенту нужен доступ к файлам vault для чтения источников и создания wiki.

Когда использовать

• Заметки копятся в inbox/research/podcasts, но никогда не переосмысливаются
• Нужно видеть картину по теме целиком, а не по отдельным файлам
• Хочется задавать сложные вопросы по своей базе знаний
• AI-саммари полезны, но теряются в потоке — нужна структура

Ключевая идея

Ты не пишешь wiki руками. LLM компилирует её из сырья и сам поддерживает.

Человек:

• Собирает raw-материал (клипы, конспекты, ресёрчи)
• Выбирает что компилировать
• Задаёт вопросы по wiki
• Решает, какие темы углубить

LLM:

• Кластеризует raw-материал по темам
• Компилирует concept articles (синтез, не саммари)
• Расставляет cross-links
• Поддерживает index и changelog
• Создаёт synthesis-статьи (второй порядок)
• Проводит linting (consistency, связность, gaps)

Архитектура

Источники (raw)                    Wiki (compiled)
─────────────────                   ─────────────────
 Inbox/          ─┐
 Research/        ├──→ LLM ──→    Wiki/
 Podcasts/       ─┘    │           ├── _Index.md
                       │           ├── _Changelog.md
                       │           ├── Article A.md     ← primary
                       │           ├── Article B.md     ← primary
                       │           ├── ...
                       │           ├── Synthesis X.md   ← second-order
                       │           └── Synthesis Y.md   ← second-order
                       │
                       └──→ Tag sources: wiki-status: processed

Три слоя

1. Raw — сырые заметки. Никогда не редактируются LLM (кроме добавления статуса). Источник правды.
2. Primary articles — скомпилированы из raw. Одна статья = один кластер тем из нескольких источников.
3. Synthesis articles — скомпилированы из primary articles. Кросс-тематические концепции, которые проявляются только при взгляде сверху.

Ключевые принципы

1. Синтез, а не саммари

Статья wiki — это единый нарратив, а не список пересказов каждого источника. LLM читает все источники кластера, находит пересечения, противоречия, паттерны, и пишет связный текст. Конкретные данные, цитаты и цифры сохраняются. Но структура — авторская, не copy-paste.

2. Статусы отслеживают прогресс

Каждый raw-файл получает поле wiki-status в метаданных (YAML frontmatter, properties, или любой аналог):

Статус	Значение
(нет поля)	Не обработан
raw	Явно помечен как необработанный
processed	Скомпилирован в wiki
updated	Отредактирован после компиляции — нужна перекомпиляция

Это даёт инкрементальность: при повторном запуске LLM обрабатывает только новые и изменённые файлы.

3. Плоская структура wiki

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

• Проще связывать (ссылки не ломаются при реорганизации)
• Граф связей нагляднее
• Нет дебатов "куда положить" — кладёшь в wiki, связываешь ссылками

4. Index и Changelog — мета-файлы

_Index.md — таблица всех статей с темой, количеством источников, датой. LLM обновляет при каждой компиляции. Заменяет RAG для небольших баз — LLM читает index и знает, что где искать.

_Changelog.md — лог: дата, какие статьи скомпилированы, из каких источников. Provenance — всегда можно проследить откуда что взялось.

5. Cross-linking замыкает граф

После компиляции — обязательный проход по всем статьям:

• "См. также" — секция в конце каждой статьи с ссылками на связанные статьи
• Inline links — первое упоминание концепта, покрытого другой статьёй, становится ссылкой
• Ссылки должны точно совпадать с именами файлов (частый источник битых связей)

6. Synthesis проявляет скрытые темы

После первого прохода компиляции LLM анализирует ВСЕ статьи и находит темы, которые упоминаются в 3+ статьях, но нигде не раскрыты полностью. Это кандидаты на synthesis-статьи — второй порядок компиляции. Они не имеют raw-источников; их источники — другие wiki-статьи.

Workflow

Первичная компиляция (cold start)

1. Сканировать все источники → список файлов с темами
2. Кластеризовать по темам (2+ файла = кластер)
3. Показать topic map человеку → человек выбирает
4. Запустить компиляцию кластеров (параллельно)
5. Пометить источники wiki-status: processed
6. Обновить _Index.md и _Changelog.md
7. Lint: добавить cross-links
8. Предложить synthesis-статьи → человек выбирает
9. Скомпилировать synthesis

Single ingest (один файл → wiki)

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

1. Человек: "вот подкаст, сделай саммари"
2. LLM: создаёт summary → сохраняет в нужную папку-источник
3. LLM: читает _Index.md → подходит под существующую статью?
   ├── Да → дополняет статью новым контентом, тегает, пишет в changelog
   └── Нет → оставляет как raw (подхватится при batch-компиляции)
4. Если статья обновлена → quick lint (новые cross-links)

Ключевой принцип: не копить — интегрировать сразу, если есть куда. Как у Karpathy: "I end up filing the outputs back into the wiki to enhance it for further queries. So my own explorations always add up."

Критерии "подходит":

• Совпадает основная тема с существующей статьёй
• Добавляет новые данные, контрастный взгляд или более глубокий анализ
• Не просто дублирует уже покрытое

Batch-компиляция (много файлов → wiki)

Когда накопилось много необработанных заметок:

1. Найти файлы БЕЗ wiki-status (новые)
2. Найти файлы с wiki-status: updated (изменённые)
3. Кластеризовать только их
4. Показать topic map → человек выбирает кластеры
5. Компилировать параллельно → новые статьи или дополнения
6. Re-lint всю wiki (новые статьи могут создать новые связи)
7. Предложить synthesis-статьи если появились новые кросс-темы

Q&A (использование wiki)

1. Человек задаёт вопрос
2. LLM читает _Index.md → находит релевантные статьи
3. Читает статьи → формирует ответ
4. (Опционально) Ответ сохраняется как новая заметка → filing обратно в wiki

Когда что использовать

Ситуация	Процесс
Послушал подкаст, прочитал статью	Single ingest — саммари + интеграция
Накопилось 5+ новых заметок	Batch — кластеризация + компиляция
Нужен ответ по теме	Q&A — вопрос по wiki
Давно не обновлял wiki	Batch + lint + synthesis

Компоненты решения

Кластеризатор

Для каждого файла LLM определяет:

• Основная тема (2-5 слов)
• Язык (ru/en)
• Тип контента (research, summary, meeting notes, pitch, raw dump)

Группировка: файлы с пересекающимися темами → один кластер. Файлы без пары → "unclustered" → catch-all статья или ждут следующей партии.

Компилятор (один на кластер)

Входные данные:

• Список файлов для чтения
• Название выходной статьи
• Рекомендованная структура (секции)
• Теги

Выход:

• Одна wiki-статья (markdown)
• Обновлённые метаданные в исходных файлах

Требования к статье:

• Синтез, не пересказ
• Конкретные данные (цифры, цитаты, имена)
• Ссылки на источники
• 1500-3000 слов (большой кластер), 800-1500 (маленький)

Линтер

Проходит по всем статьям wiki и:

• Добавляет секции "См. также" с контекстными пояснениями
• Вставляет inline-ссылки на первое упоминание концепта
• Находит inconsistencies (одна и та же цифра по-разному)
• Находит redundancies (дублирование текста между статьями)
• Предлагает темы для synthesis-статей (упоминаются в 3+ статьях, нет отдельной)

Синтезатор

То же, что компилятор, но:

• Входные данные — wiki-статьи, не raw-файлы
• Задача — извлечь cross-cutting theme и написать связный нарратив
• Добавляет emergent insights — выводы, видимые только при пересечении тем
• Использует synthesis-of вместо sources в метаданных

Метаданные статей

Primary article

type: wiki-article
created: YYYY-MM-DD
sources:
  - "[[Source File 1]]"
  - "[[Source File 2]]"
tags: [wiki, topic-tags]

Synthesis article

type: wiki-article
created: YYYY-MM-DD
synthesis-of:
  - "[[Wiki Article A]]"
  - "[[Wiki Article B]]"
tags: [wiki, topic-tags, synthesis]

Вопросы для адаптации

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

Источники

• В каких папках у тебя лежат сырые заметки (inbox, research, конспекты подкастов)?
• Есть ли другие источники, которые стоит включить (meeting notes, клипы, bookmarks)?
• На каких языках твои заметки?

Структура wiki

• Как назвать папку wiki? Есть ли предпочтения по расположению в vault?
• Плоская структура (все статьи в одной папке) или нужны подпапки по темам?
• Как именовать файлы статей — на русском, английском, смешанно?

Метаданные

• Используешь ли ты YAML frontmatter в заметках? Есть ли обязательные поля?
• Есть ли в vault система тегов, которую нужно учитывать?

Workflow

• Как чаще появляется новый контент — по одному файлу или пачками?
• Нужна автоматизация по расписанию (cron/scheduled agent) или ручной запуск по команде?
• Кто принимает решения по кластерам — ты каждый раз, или агент может решать сам?

Инструменты

• Какой coding agent ты используешь (Claude Code, Cursor, Codex, другой)?
• Поддерживает ли он параллельный запуск агентов?
• Есть ли у него доступ к файловой системе vault?

Нюансы и грабли

Ссылки должны совпадать с именами файлов

Самый частый баг — LLM генерирует ссылку [[File Name and Extra Words]], а файл называется File Name.md. Obsidian (и другие инструменты) не находят связь. После каждой компиляции стоит проверять ссылки.

Файлы в нескольких кластерах

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

Параллельная компиляция

Кластеры независимы → компилируются параллельно (каждый в своём агенте). Это критично при 5+ кластерах — последовательная компиляция занимает x5 времени. Единственное ограничение — файлы-пересечения (см. выше).

Index заменяет RAG (до определённого масштаба)

Karpathy отмечает: при ~100 статьях и ~400K слов LLM справляется без RAG, если index-файлы хорошо поддержаны. LLM читает _Index.md, находит нужные статьи, читает их. Для 200+ статей, возможно, понадобится поисковый слой.

Не мешай компиляции с ручными заметками

Wiki — территория LLM. Если хочешь добавить свои мысли — добавляй как raw-заметку в источники и запускай перекомпиляцию. Или используй отдельную секцию в статье (## Мои заметки) которую LLM не перезаписывает.

Catch-all статья неизбежна

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

wiki-status: updated нужно отслеживать вручную

LLM не знает, что файл изменился после обработки (нет файлового watcher). Два варианта:

• Человек ставит updated вручную при редактировании
• Скрипт сравнивает mtime с датой компиляции в changelog

Масштабирование

Паттерн работает для:

• Исследования — papers, статьи, Twitter threads → research wiki
• Подкасты — конспекты → тематическая база знаний
• Курс/книга — разрозненные драфты → структурированный outline
• Competitive intelligence — мониторинг конкурентов → живая wiki
• Onboarding — документация, процессы, FAQ → knowledge base для новичков
• Personal OS — все заметки → searchable, linked second brain

Реализация-пример

Obsidian + AI-агент (Claude Code, Cursor, Windsurf или любой другой с доступом к файлам).

Компонент	Реализация
Источники	2-3 папки с сырыми заметками (inbox, research, podcasts — или как угодно)
Wiki	Отдельная папка (например Wiki/), плоская структура без подпапок
Index	Wiki/_Index.md — таблица всех статей с темой, кол-вом источников и датой
Changelog	Wiki/_Changelog.md — лог компиляций: дата → статья → из каких источников
Статусы	YAML frontmatter wiki-status: processed в каждом обработанном файле-источнике
Кластеризация	AI сканирует источники → строит topic map → человек выбирает кластеры
Компиляция	По одному агенту на кластер (параллельно, если инструмент позволяет)
Линтинг	Отдельный проход по всем статьям: cross-links, «См. также», проверка ссылок
Synthesis	Отдельный проход: темы, упомянутые в 3+ статьях → кандидаты на synthesis-статьи
Автоматизация	Скрипт или команда для повторного запуска (skill, slash command, Makefile — зависит от инструмента)

Типичный результат cold start: из ~50-100 raw-заметок получается 8-15 primary-статей и 3-5 synthesis-статей.

Выходные артефакты

После сборки у пользователя должны быть:

Артефакт	Описание	Как проверить
Папка wiki	Отдельная папка с плоской структурой	Существует, пустая или с первыми статьями
_Index.md	Таблица всех статей	Файл существует, формат таблицы корректный
_Changelog.md	Лог компиляций	Файл существует, есть хотя бы одна запись
Статусы в источниках	wiki-status: processed в обработанных файлах	Grep по источникам подтверждает
Primary-статьи	Скомпилированные статьи из кластеров	Есть ссылки на источники, секция "См. также"
Cross-links	Inline-ссылки и "См. также" между статьями	Ссылки не битые, ведут на существующие файлы
Skill или команда	Способ повторного запуска компиляции	Запуск команды обрабатывает новые файлы

Необязательно при cold start, но появятся со временем:

• Synthesis-статьи (после накопления 5+ primary)
• Catch-all статья для некластеризованных заметок
• Автоматизация по расписанию (если выбрана)