--- LLM: Claude type: blueprint slug: personal-wiki lang: ru date: 2026-04-17 title: "Blueprint: Personal Wiki" tagline: LLM собирает wiki из твоих заметок — автоматически description: LLM компилирует связную wiki из разрозненных заметок. Синтез, не саммари. Инкрементальная, с cross-links и автоматическим индексом. audience: Для тех, кто ведёт заметки в Obsidian, Notion или markdown и хочет превратить их в связную базу знаний price: 16 --- # Blueprint: Personal Wiki Заметки копятся месяцами — конспекты подкастов, клипы из статей, research-заметки. Всё лежит в inbox и медленно тонет. Ты знаешь, что где-то в этих файлах есть ценность, но чтобы её извлечь — нужно сесть и перечитать всё. Это никогда не происходит. Этот Blueprint решает проблему: LLM читает твои сырые заметки, кластеризует по темам и компилирует в связную wiki. Не саммари каждого файла, а синтез — единый нарратив из нескольких источников. Wiki растёт вместе с тобой: каждый новый подкаст или статья автоматически обогащает существующие статьи. Вдохновлён подходом Andrej Karpathy ("LLM Knowledge Bases"). ## Что ты получишь - **Wiki из твоих заметок** — связные статьи, скомпилированные из разрозненных источников, с перекрёстными ссылками - **Автоматический pipeline** — skill или команда для компиляции новых заметок в wiki одним запуском - **Живой индекс** — оглавление всех статей и changelog, чтобы видеть картину целиком и отслеживать рост базы - **Инкрементальность** — только новые и изменённые заметки обрабатываются при повторных запусках ## Как применить 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 ```yaml type: wiki-article created: YYYY-MM-DD sources: - "[[Source File 1]]" - "[[Source File 2]]" tags: [wiki, topic-tags] ``` ### Synthesis article ```yaml 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 статья для некластеризованных заметок - Автоматизация по расписанию (если выбрана)