Методи побудови Obsidian, які використовують лише генії та люди з високим доходом

Заробіток на ШІ — це не про "кількість нотаток"

Спершу давайте спокійно обговоримо.

Не існує жодних досліджень, які б підтверджували причинно-наслідковий зв'язок між річним доходом у 100 мільйонів єн і конфігурацією Obsidian. Немає "секретних плагінів, відомих лише багатіям".

Під "гравцем на 100 мільйонів єн" я маю на увазі не того, хто зберігає величезну кількість знань.

Йдеться про людей, які вміють конвертувати отриману інформацію в:

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

...із надзвичайно високою швидкістю.

Звичайні користувачі Obsidian думають про те, "що зберегти".

Сильні користувачі спочатку думають: "у якій ситуації, використовуючи яке запитання, я отримаю цю інформацію в майбутньому?"

Ще сильніші користувачі відстежують, у яке саме рішення чи результат зрештою конвертувалися отримані знання.

Іншими словами, те, що ви насправді маєте проєктувати, — це не "Другий мозок".

Це Персональна ОС інтелекту, яка посилює прийняття рішень та інтелектуальне виробництво.

Obsidian зберігає нотатки як локальні файли Markdown. Сховище — це просто папка, і зміни, зроблені зовнішніми редакторами чи скриптами, відображаються в Obsidian. Налаштування та інформація про плагіни зберігаються окремо в папці .obsidian. Це означає, що Obsidian — це не просто застосунок, а "сховище знань", з яким можна працювати через Git, CLI, Claude та Codex.

У цій статті ми розглядаємо елементи Obsidian так:

Як тільки ви досягнете цієї перспективи, ваш спосіб використання Obsidian зміниться повністю.

Розділ 1: Дослідження закордонних кейсів — Стратегія перемоги полягала в "пошуку", а не в "організації"

1. Що було вивчено зі сховищ 7 дослідників

Існує тематичне дослідження, опубліковане у 2025 році, яке вивчає використання Obsidian сімома дослідниками комп'ютерних наук у бразильському дослідницькому інституті.

Найважливіший висновок цього дослідження полягав не в тому, як учасники створювали нотатки.

Висновком стало відкриття, що те, як вони планували знаходити ці нотатки в майбутньому, сильно впливало на те, як вони їх створювали та організовували. Учасники використовували рядки пошуку, списки тегів, теги в тексті та внутрішні посилання для різних цілей. Деякі користувачі також поміщали створені нотатки в папку "Вхідні" (Inbox) і обробляли їх раз на тиждень.

Проєктні пропозиції, розроблені дослідниками, можна звести до трьох пунктів:

1. Не вимагайте ідеальної класифікації з самого початку; підготуйте мінімальну початкову структуру.
2. Дозвольте змінювати структуру під час використання.
3. З'єднайте метод створення/організації з майбутнім методом пошуку з самого початку.

Іншими словами, справа не в "створенні правильних папок".

Справа в тому, щоб вирішити, як ваше майбутнє "я" буде шукати, і записувати відповідно до цього шляху пошуку.

Вже цей момент показує, що більшість звичайних курсів з Obsidian є неправильними.

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

Однак насправді питання, яке слід вирішити в першу чергу, таке:

Через три місяці, про що я буду турбуватися, коли мені знадобиться ця інформація?

2. Ніколь ван дер Гувен — Перетворення нотаток на кар'єрний навчальний інструмент

Ніколь ван дер Гувен, яка працює як Developer Advocate та інженер з продуктивності, стверджує, що ведення безперервних нотаток про роботу позитивно вплинуло не лише на швидкість навчання, але й на її кар'єру в технологічній індустрії.

Ключовий момент не в тому, що вона "створила красиву базу знань".

Справа в тому, що вона записує те, що вивчає під час роботи, і використовує це для публічного обміну, пояснень та презентацій.

Вона спрямовує навчальні нотатки за межі особистих записів у:

• Презентації
• Статті
• Відео
• Документи
• Навчальні матеріали
• Наступну роботу

Це "перетворення з введення на виведення" створює економічну цінність знань.

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

Інженер-програміст Бруно Паз агрегує все — від фрагментів коду, нарад і специфікацій проєктів до досліджень і життєвих знань — у Obsidian.

Однак важливішою за розміщення всього в Obsidian є його дизайнерська філософія.

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

Він також стандартизує Frontmatter, як-от type, за допомогою шаблонів, розміщує Wikilinks до пов'язаних нотаток у topics і відображає їх за допомогою Bases або Dataview.

Висновок тут очевидний:

Можливість відновити все за допомогою Markdown, коли щось ламається, важливіша, ніж висока функціональність.

4. Ян О'Бірн — Потік інформації від "Споживання → Курації → Створення"

Ян О'Бірн, який використовує Obsidian в освіті та дослідженнях, структурує своє сховище приблизно в такому потоці:

• Consume (Споживання): Вхідні дані, як-от статті, книги, наукові роботи, подкасти
• Curate (Курація): Дистиляція ключових моментів, встановлення зв'язків, створення MOC
• Create (Створення): Вихідні матеріали, як-от блоги, новини, навчальні матеріали
• Meta (Мета): Операційна інформація про саме сховище

Важливі не назви папок.

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

Підсумовуючи ці закордонні кейси, чудові сховища мають п'ять спільних рис:

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) або Мета (Goal), але "Переглянути ціноутворення корпоративного плану до вересня 2026 року" — це Проєкт (Project). Проєкти завжди повинні мати next_action.

30_Areas

Поточні сфери відповідальності. Управління, продажі, найм, фінанси, здоров'я, сім'я, навчання тощо. Сфери залишаються навіть після завершення Проєкту.

40_Notes

Знання для довгострокового використання. Розміщуйте тут контент, який ви можете пояснити своїми словами, а не просто витяги. Не потрібно суворо дотримуватися правила "одна нотатка — одна концепція". В українській мові суб'єкти та передумови легко опускаються, тому надмірне фрагментування руйнує контекст. Стандарт такий:

1 Нотатка = Контент, який ви хочете використати повторно як єдине ціле в майбутньому

50_Sources

Записи зовнішньої інформації. Книги, наукові роботи, статті, відео, матеріали зустрічей, дослідницькі дані тощо. Відокремлюйте "те, що сказала інша сторона" від "того, як я це інтерпретував".

60_Entities

Сутності, як-от люди, компанії, продукти, клієнти, конкуренти та технології. Навіть якщо одна й та сама людина чи компанія з'являються в кількох проєктах, ведіть лише одну Нотатку про сутність (Entity Note).

70_Outputs

Статті, планувальні документи, пропозиції, сценарії відео, презентації, матеріали для продажів, специфікації продуктів тощо. Вкрай важливо розміщувати Результати (Outputs) в окремій папці верхнього рівня. Сховище, націлене лише на зберігання, стає цвинтарем знань.

90_System

Механізми, які керують самим сховищем, такі як шаблони, Схеми, Bases, правила ШІ та Навички (Skills). Побудувавши це, ви зможете пояснювати власні операції.

Чи має бути одне сховище?

В принципі, так. Внутрішні посилання в Obsidian вирішуються в межах одного сховища; розділення сховищ розриває зв'язки між знаннями. У згаданому дослідженні учасники, які розділили своє сховище на три, повідомили про плутанину з пошуком.

Однак фізично відокремте наступне:

• Інформація, для якої контракт забороняє введення зовнішнього ШІ.
• Медична інформація, персональні ідентифікаційні номери, облікові дані.
• Чутливі дані відділу кадрів.
• Регульовані дані.
• Інформація, яку не можна передавати зовнішнім моделям згідно з політикою організації.

Думайте про це як про розділення "Персонального сховища" та "Регульованого сховища".

Розділ 4: Не змішуйте ролі папок, властивостей, посилань і тегів

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

Папки — для "життєвого циклу"

Inbox, Project, Source, Output, Archive тощо. Вони показують, на якому етапі процесу зараз знаходиться нотатка.

Властивості — для "типів і станів, що обробляються машиною"

type, status, created, project, revisit тощо. Властивості Obsidian зберігаються як YAML і можуть мати типи: текст, список, число, прапорець, дата, дата та час, а також теги.

Посилання — для "семантичних зв'язків"

[[Pricing Strategy]], [[ABC Corp]], [[Reversibility of Decisions]] тощо. Перетворення теми на нотатку замість тегу дозволяє самій темі містити пояснення, контраргументи, довідкові матеріали та MOC.

Теги — для "тимчасових наскрізних станів"

Обмежте теги такими речами, як #review, #waiting, #question, #contradiction, #publish.

Концепції, як-от "Маркетинг" або "ШІ", по можливості мають бути посиланнями. Використання тегів як концептуального словника призводить до розростання тегів (наприклад, #ШІ, #ШтучнийІнтелект, #ГенеративнийШІ). Натомість використовуйте Псевдоніми (Aliases) у концептуальних нотатках.

Розділ 5: Мінімальна схема властивостей

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

Етап захоплення

Лише найнеобхідніше:
``yaml
type: inbox
created: 2026-07-24
status: inbox
``

Етап підвищення

Додавайте, коли з'являється цінність для довгострокового зберігання:
``yaml
type: note
created: 2026-07-24
status: active
topics:
- "[[Pricing Strategy]]"
- "[[B2B SaaS]]"
source_notes:
- "[[SRC Competitor Pricing Research 2026-07]]"
confidence: medium
sensitivity: internal
``

Етап експлуатації

Додавайте пункти, необхідні для Проєктів або Рішень:
``yaml
type: project
created: 2026-07-24
status: active
owner: me
area: "[[Management]]"
due: 2026-09-30
next_action: Compare annual plans of 5 competitors
``

Розділ 6: Правила для назв файлів українською мовою

Немає потреби примусово перекладати текст нотаток чи заголовки на англійську. Однак тримайте назви Властивостей (Properties) та імена папок, що використовуються для машинної обробки, в ASCII. Я використовую такі угоди про іменування:

• Проєкт: PJT Redesign of Corporate Pricing
• Рішення: DEC 2026-07-24 Make Annual Plan the Standard Proposal
• Evergreen Note: Price is Determined by Implementation Failure Risk Rather Than Feature Count

Робіть заголовки Evergreen Note "Твердженнями", а не "Назвами категорій". Заголовки-твердження допомагають згадати зміст просто за результатами пошуку.

Розділ 7: Шаблони, які варто включити

Щоденна нотатка

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

Нотатка проєкту

Нотатка проєкту — це не склад завдань. Це Командний центр проєкту, де будь-хто може зрозуміти поточний стан за 30 секунд.

Нотатка рішення

У високоприбутковій роботі якість рішень важливіша за інформацію. Отже, Нотатки рішень (Decision Notes) є найціннішим типом нотаток. Найважливішим полем є Тригер перегляду (Reversal Trigger). Відмінний особа, яка приймає рішення, — це той, хто може записати в момент прийняття рішення, за яких умов він змінить свою думку.

Розділ 8: MOC — це "відредаговані моделі мислення", а не списки посилань

Хороший MOC (Map of Content) містить судження редактора. Це відредагована когнітивна модель, яка стискає ваше поточне розуміння цілої області, а не просто список пов'язаних нотаток.

Розділ 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: Правильна структура для сховища, орієнтованого на ШІ

Дозволити ШІ вільно редагувати всі нотатки — це не "використання ШІ". Це все одно, що передати всі документи компанії неперевіреному стажеру. Правильний розподіл праці такий:

• Людина: Цілі, ціннісні судження, остаточне затвердження, редагування MOC.
• Obsidian: Джерело істини, зв'язки, історія, представлення.
• Claude: Дистиляція сенсу, порівняння, контраргументи, створення чернеток.
• Codex: Структурні зміни, скрипти, валідація, перегляд дифів.
• Git: Відновлення, аудит, ізоляція експериментів.
• Валідатор: Виявлення порушень схеми та аномалій посилань.

Розділ 13: Розміщення CLAUDE.md та AGENTS.md

Claude Code читає CLAUDE.md як безперервні інструкції. Codex шукає AGENTS.md. Розмістіть "Операційний контракт сховища" в цих файлах, щоб визначити мову (українська проза, властивості ASCII), правила безпеки (типово dry-run) та правила схеми.

Розділ 14: Перетворення завдань Obsidian на Навички через Claude

Визначайте "Навички агента" (Agent Skills) для завдань, які ви виконуєте більше трьох разів або для яких потрібна стандартизована якість. Наприклад, навичка obsidian-distill може перетворювати сирі нотатки з зустрічей на Рішення, Завдання та Evergreen Notes. Хороша Навичка — це стандарт роботи, що повторно виконується, з явними вхідними даними, процедурами, заборонами та умовами завершення.

Розділ 17: Патерни співпраці для Claude, Codex та Obsidian CLI

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

Це використання, яке виходить за рамки "підсумовування нотаток за допомогою ШІ". Ви використовуєте ШІ як інтелектуальний контролер, який аудитує ваші минулі судження.

Розділ 18: Включення валідатора сховища

Якщо ШІ редагує ваше сховище, не зупиняйтеся на простому "виглядає добре". Впровадьте мінімальне статичне тестування за допомогою скриптів (наприклад, vault_check.py), щоб перевірити дозволені типи, статуси та обов'язкові властивості.