Методы построения Obsidian, которые используют только гении и высокооплачиваемые специалисты

Заработок с помощью ИИ — это не про «количество заметок»

Давайте спокойно обсудим.

Нет исследований, которые подтверждают причинно-следственную связь между годовым доходом в 100 миллионов йен и настройкой Obsidian. Не существует «секретных плагинов, известных только богатым».

Под «игроком на 100 миллионов йен» я подразумеваю не того, кто хранит огромное количество знаний.

Речь идёт о людях, которые способны превращать полученную информацию в:

• Принятие решений
• Переговоры
• Найм
• Инвестиционные суждения
• Дизайн продуктов
• Контент
• Продающие материалы
• Организационные системы
• Многократно используемые интеллектуальные активы

…с чрезвычайно высокой скоростью.

Обычные пользователи Obsidian думают о том, «что сохранить».

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

Ещё более сильные пользователи отслеживают, в какое решение или результат в итоге превратились эти знания.

Иными словами, вам нужно проектировать не «второй мозг».

Это персональная интеллектуальная операционная система, которая усиливает принятие решений и интеллектуальное производство.

Obsidian сохраняет заметки в виде локальных Markdown-файлов. Хранилище — это просто папка, а изменения, внесённые из внешних редакторов или скриптов, отражаются в Obsidian. Настройки и информация о плагинах вынесены в папку .obsidian. Это означает, что Obsidian — это не просто приложение, а «репозиторий знаний», с которым можно работать через Git, CLI, Claude и Codex.

В этой статье мы рассматриваем элементы Obsidian следующим образом:

Как только вы достигаете такого понимания, ваш способ использования Obsidian полностью меняется.

Глава 1: Изучение зарубежных кейсов — победной стратегией оказался «поиск», а не «организация»

1. Что мы узнали из хранилищ 7 исследователей

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

Самый важный вывод этого исследования заключался не в том, как участники создавали заметки.

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

Предложения по дизайну, сделанные исследователями, можно свести к трём пунктам:

1. Не требуйте идеальной классификации с самого начала; подготовьте минимальную начальную структуру.
2. Разрешите изменять структуру в процессе использования.
3. С самого начала свяжите метод создания/организации с будущим методом поиска.

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

Дело в том, чтобы решить, как ваш будущий «я» будет искать, и записывать информацию в соответствии с этим путём поиска.

Уже этот пункт показывает, что большинство распространённых курсов по Obsidian работают неправильно.

Многие курсы сначала предлагают определиться с папками, тегами, плагинами и внешним видом.

Однако на самом деле вопрос, который нужно решить в первую очередь, звучит так:

Через три месяца, когда мне понадобится эта информация, что будет меня беспокоить?

2. Николь ван дер Хувен — превращение заметок в инструмент карьерного обучения

Николь ван дер Хувен, работающая как Developer Advocate и Performance Engineer, утверждает, что ведение непрерывных заметок о работе положительно повлияло не только на скорость обучения, но и на её карьеру в сфере технологий.

Ключ не в том, что она «создала красивую базу знаний».

Дело в том, что она записывает то, что узнаёт во время работы, и использует это для публичных выступлений, объяснений и презентаций.

Она направляет учебные заметки за пределы личных записей в:

• Презентации
• Статьи
• Видео
• Документы
• Учебные материалы
• Следующую работу

Это «преобразование ввода в вывод» создаёт экономическую ценность знаний.

3. Бруно Паз — локально, Markdown, минимум плагинов

Инженер-программист Бруно Паз собирает всё — от фрагментов кода, встреч и спецификаций проектов до исследований и жизненных знаний — в Obsidian.

Однако важнее, чем помещать всё в Obsidian, — его философия дизайна.

Он делает акцент на портативности Markdown и управлении историей через Git, придерживаясь политики минимального количества плагинов. Плагины делают Obsidian удобным, но само содержимое не должно слишком зависеть от конкретных плагинов.

Он также стандартизирует Frontmatter, например type, с помощью шаблонов, помещает Wikilinks в связанные заметки в topics и выводит их с помощью Bases или Dataview.

Вывод здесь ясен:

Возможность восстановить всё с помощью одного Markdown, если что-то сломается, важнее, чем высокая функциональность.

4. Ян О’Бирн — поток информации от «потребления» через «курирование» к «созданию»

Ян О’Бирн, использующий Obsidian в образовании и исследованиях, структурирует своё хранилище примерно по такому потоку:

• Потребление: Вводные материалы — статьи, книги, доклады, подкасты
• Курирование: Извлечение ключевых моментов, связывание их, создание MOC
• Создание: Результаты — блоги, рассылки, учебные материалы
• Мета: Операционная информация о самом хранилище

Важны не названия папок.

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

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

1. Ориентация на поиск — отталкивайтесь от будущих запросов
2. Ориентация на результат — стремитесь к результатам, а не просто к хранению
3. Локальность — используйте Markdown как источник истины
4. Минимальная схема — не усложняйте поля ввода
5. Эволюционность — изменяйте структуру в процессе использования

Глава 2: Шесть метрик, определяющих «хранилище на 100 миллионов йен»

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

Я бы измерял производительность хранилища по этим шести метрикам:

1. Задержка захвата

Время от возникновения идеи до её сохранения.

Цель — в течение 30 секунд. Структура, которая заставляет вас думать о тегах, связанных заметках и месте сохранения в момент ввода, — слабая.

2. Время поиска

Время, необходимое для получения нужной информации.

Стремитесь к 30 секундам для общей информации и 60 секундам для важных записей решений.

3. Стоимость восстановления контекста

Время, необходимое для восстановления смысла истории при просмотре старых заметок.

Заметка только с заголовком встречи — слабая. Заметка, в которой сохранены «Контекст», «Решение», «Причина», «Предпосылки» и «Следующее действие», — сильная.

4. Отслеживаемость решений

Процент важных суждений, по которым вы впоследствии можете проследить:

• Почему было принято решение
• Что было отклонено
• Какие были предпосылки
• При каких условиях решение может быть отменено

5. Коэффициент конверсии в результат

Процент сохранённых исходных заметок (Source Notes) или вечнозелёных заметок (Evergreen Notes), которые были использованы для статей, предложений, продуктов, решений, встреч или продаж.

6. Исполнимость агентом

Процент случаев, когда Claude или Codex могут искать, предлагать и проверять, не неправильно понимая правила хранилища.

Обобщая, ROI (окупаемость инвестиций) системы знаний можно представить так:

ROI знаний = (Повторно использованные знания + Улучшенные решения + Предотвращённые ошибки) / Время, затраченное на запись, организацию и поддержку

Даже если количество заметок растёт, но они не используются повторно, растёт только знаменатель.

Глава 3: Структура хранилища, удобная для русскоязычных пользователей

Если бы я создавал хранилище с нуля, я бы использовал такую верхнеуровневую структуру:

MyVault/

├── 00_Inbox/

│ ├── AI/

│ └── Clippings/

├── 10_Daily/

│ └── 2026/

├── 20_Projects/

├── 30_Areas/

├── 40_Notes/

│ └── MOCs/

├── 50_Sources/

├── 60_Entities/

│ ├── People/

│ ├── Companies/

│ └── Products/

├── 70_Outputs/

│ ├── Drafts/

│ └── Published/

├── 80_Assets/

├── 90_System/

│ ├── Templates/

│ ├── Bases/

│ ├── Schemas/

│ ├── AgentSkills/

│ └── AI/

├── 99_Archive/

├── scripts/

├── .claude/

├── .agents/

├── .codex/

├── CLAUDE.md

└── AGENTS.md

00_Inbox

Несортированные входящие. Не организуйте здесь. Теги в целом не нужны. Это место «просто сохранить».

10_Daily

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

20_Projects

Деятельность с условием завершения. «Увеличить продажи» — это область (Area) или цель, но «Пересмотреть цены корпоративного плана к сентябрю 2026 года» — это проект. У проектов всегда должно быть next_action.

30_Areas

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

40_Notes

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

1 заметка = контент, который вы хотите повторно использовать как единое целое в будущем

50_Sources

Записи внешней информации. Книги, статьи, видео, материалы встреч, исследовательские данные и т.д. Отделяйте «то, что сказала другая сторона» от «того, как я это интерпретировал».

60_Entities

Сущности: люди, компании, продукты, клиенты, конкуренты, технологии. Даже если один и тот же человек или компания встречаются в нескольких проектах, сохраняйте только одну заметку о сущности.

70_Outputs

Статьи, плановые документы, предложения, сценарии видео, презентации, продающие материалы, спецификации продуктов и т.д. Крайне важно поместить «Результаты» в независимую папку верхнего уровня. Хранилище, нацеленное только на хранение, становится кладбищем знаний.

90_System

Механизмы, управляющие самим хранилищем: шаблоны, схемы, Bases, правила ИИ, навыки. Создав это, вы сможете объяснить собственные операции.

Должно ли быть одно хранилище?

В принципе, да. Внутренние ссылки в Obsidian разрешаются внутри хранилища; разделение хранилищ разрывает связи между знаниями. В упомянутом исследовании участники, разделившие хранилище на три, сообщали о путанице в поиске.

Однако физически отделите следующее:

• Информация, для которой внешний ввод ИИ запрещён контрактом.
• Медицинские данные, личные идентификационные номера, учётные данные.
• Конфиденциальная информация об отделе кадров.
• Регулируемые данные.
• Информация, которую нельзя передавать внешним моделям в соответствии с политикой организации.

Думайте об этом как о разделении «Личного хранилища» и «Хранилища с ограничениями».

Глава 4: Не смешивайте роли папок, свойств, ссылок и тегов

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

Папки — для «жизненного цикла»

Входящие, Проект, Источник, Результат, Архив и т.д. Они показывают, на каком этапе процесса находится заметка.

Свойства (Properties) — для «обрабатываемых машиной типов и состояний»

type, status, created, project, revisit и т.д. Свойства Obsidian сохраняются в YAML и могут иметь типы: текст, список, число, флажок, дата, дата и время, теги.

Ссылки (Links) — для «семантических связей»

[[Ценовая стратегия]], [[ООО «АБС»]], [[Обратимость решений]] и т.д. Превращение темы в заметку, а не в тег, позволяет этой теме содержать объяснения, контраргументы, справочные материалы и MOC.

Теги (Tags) — для «временных сквозных состояний»

Ограничьте теги такими вещами, как #review, #waiting, #question, #contradiction, #publish.

Такие понятия, как «Маркетинг» или «ИИ», по возможности должны быть ссылками. Использование тегов в качестве концептуального словаря приводит к разрастанию тегов (например, #AI, #ArtificialIntelligence, #GenerativeAI). Вместо этого используйте Псевдонимы (Aliases) в заметках-концепциях.

Глава 5: Минимальная схема свойств

Не пытайтесь заполнить 20 пунктов с самого начала. Разделите схему на три этапа:

Этап захвата

Только самое необходимое:
``yaml
type: inbox
created: 2026-07-24
status: inbox
``

Этап повышения (Promoted)

Добавляйте, когда информация приобретает ценность для долгосрочного хранения:
``yaml
type: note
created: 2026-07-24
status: active
topics:
- "[[Ценовая стратегия]]"
- "[[B2B SaaS]]"
source_notes:
- "[[SRC Исследование цен конкурентов 2026-07]]"
confidence: medium
sensitivity: internal
``

Этап эксплуатации (Operational)

Добавляйте элементы, необходимые для проектов или решений:
``yaml
type: project
created: 2026-07-24
status: active
owner: me
area: "[[Управление]]"
due: 2026-09-30
next_action: Сравнить годовые планы 5 конкурентов
``

Глава 6: Правила для имён файлов на русском языке

Нет необходимости принудительно переводить русскоязычный текст или заголовки на английский. Однако имена свойств и папок, используемые для машинной обработки, оставляйте в ASCII. Я использую следующие соглашения об именах:

• Проект: PJT Редизайн корпоративного ценообразования
• Решение: DEC 2026-07-24 Сделать годовой план стандартным предложением
• Вечнозелёная заметка: Цена определяется риском неудачи внедрения, а не количеством функций

Делайте заголовки вечнозелёных заметок «утверждениями», а не «названиями категорий». Утвердительные заголовки помогают вспомнить содержание просто по результатам поиска.

Глава 7: Шаблоны, которые стоит включить

Ежедневная заметка (Daily Note)

Включите «Журнал трения» (Friction Log). Запись «того, что я искал, но не нашёл» позволяет улучшить хранилище на основе реальных сбоев поиска. Развивайте структуру на основе неудачных поисков, а не эстетических предпочтений.

Заметка проекта (Project Note)

Заметка проекта — это не склад задач. Это командный центр проекта, где любой может понять текущий статус за 30 секунд.

Заметка решения (Decision Note)

В высокодоходной работе качество решений важнее информации. Поэтому заметки решений — самый ценный тип заметок. Самое важное поле — Триггер отмены (Reversal Trigger). Отличный принимающий решения — это тот, кто может записать в момент принятия решения, при каких условиях он изменит своё мнение.

Глава 8: MOC — это «отредактированные модели мышления», а не списки ссылок

Хорошая MOC (карта содержания) содержит суждение редактора. Это отредактированная когнитивная модель, которая сжимает ваше текущее понимание целой области, а не просто список связанных заметок.

Глава 9: Создание «панели управления» с помощью Bases

Obsidian Bases — это ключевая функция, позволяющая отображать, фильтровать и сортировать свойства заметок, как в базе данных. Используйте её для создания «Базы активных проектов» или «Базы обзора решений», чтобы восстанавливать зависшие решения.

Глава 10: Уровневая система плагинов

• Уровень 0 (только ядро): Properties, Templates, Daily Notes, Bases, Search, Canvas и т.д.
• Уровень 1 (когда возникает трение): QuickAdd, Templater, Tasks.
• Уровень 2 (только если Bases недостаточно): Dataview.

Держите количество активных сообщественных плагинов не более 12. Записывайте для каждого цель, альтернативу и условия удаления.

Глава 11: Решающее изменение 2026 года — официальный CLI Obsidian

По состоянию на июль 2026 года у Obsidian есть официальный CLI. Он позволяет управлять десктопной версией из терминала: поиск, чтение, создание, обновление свойств, проверка задач. Это позволяет Claude и Codex работать, используя собственную логику разрешения Obsidian, а не просто редактировать Markdown напрямую.

Глава 12: Правильная структура для AI-нативного хранилища

Позволять ИИ свободно редактировать все заметки — это не «использование ИИ». Это всё равно что передать все документы компании непроверенному стажёру. Правильное разделение труда:

• Человек: Цели, ценностные суждения, окончательное утверждение, редактирование MOC.
• Obsidian: Источник истины, связи, история, представления.
• Claude: Извлечение смысла, сравнение, контраргументы, черновики.
• Codex: Структурные изменения, скрипты, валидация, проверка различий.
• Git: Восстановление, аудит, изоляция экспериментов.
• Валидатор: Обнаружение нарушений схемы и аномалий в ссылках.

Глава 13: Размещение CLAUDE.md и AGENTS.md

Claude Code читает CLAUDE.md как непрерывные инструкции. Codex ищет AGENTS.md. Поместите в эти файлы «Контракт на эксплуатацию хранилища», чтобы определить язык (русский текст, ASCII свойства), правила безопасности (по умолчанию пробный запуск) и правила схемы.

Глава 14: Превращение задач Obsidian в навыки (Skills) через Claude

Определяйте «Навыки агента» для задач, которые вы выполняете более трёх раз, или для стандартизированного качества. Например, навык obsidian-distill может преобразовывать сырые заметки встреч в Решения, Задачи и Вечнозелёные заметки. Хороший навык — это повторно выполняемый рабочий стандарт с явными входными данными, процедурами, запретами и условиями завершения.

Глава 17: Схемы совместной работы Claude, Codex и Obsidian CLI

• Схема 1: Дистилляция заметок встреч (Claude извлекает решения/задачи).
• Схема 2: Еженедельный управленческий обзор (Claude резюмирует прогресс за неделю и зависшие проекты).
• Схема 3: Аудит дрейфа схемы (Codex обнаруживает несоответствия свойств).
• Схема 4: Аудит предпосылок решений (Claude проверяет, всё ли ещё верны предположения, лежащие в основе прошлых решений).

Это использование выходит за рамки «резюмирования заметок с помощью ИИ». Вы используете ИИ как интеллектуальный контроллер, который проверяет ваши прошлые суждения.

Глава 18: Включение валидатора хранилища

Если ИИ редактирует ваше хранилище, не удовлетворяйтесь просто «выглядит нормально». Реализуйте минимальное статическое тестирование с помощью скриптов (например, vault_check.py), чтобы проверять разрешённые типы, статусы и обязательные свойства.