Но возникает один вопрос: если позволить им это делать, не несет ли это скрытых издержек?

Чтобы избавить вас от глубокого погружения в когнитивистику и нейробиологию, отвечу коротко — «да, несет». Чтение ИИ-саммари — это не мышление. Видеть связанные заметки — не то же самое, что эти связи создавать. Автоматическое тегирование заметок не заменит понимания того, «какие области сюда относятся».

Последние пару месяцев я выстраивал систему, цель которой — сохранить баланс. Систему, которая бы не просто создавала иллюзию порядка, но позволяла бы всем имеющимся у меня знаниям реально работать, а также находить неочевидные связи среди них. Удивительно, но AI и ML плагины для Obsidian (такие как Similarity или Similar Notes) не могут правдоподобно ответить на вопрос "какие ещё заметки возможно относятся в той, что у меня сейчас открыта?", несмотря на создание индексов, чанкинг и так далее.

Оказалось, AI с его "вероятностным" подходом, и не нужен. Obsidian и его плагин Bases могут быть базой для детерминированного решения задачи – а это значит результаты, которые можно 100% проверить, на которые можно положиться.

При условии, что вы готовы а) думать над тегами и б) погрузиться на продвинутый уровень Obsidian.

Внесём Ясность

Я не буду делать вид, что Bases превосходит Claude, натравленного на вашу базу знаний. Cowork не просто найдет заметку, которая «кажется связанной» – он просто ответит на вопрос, даже если вы ничего не линковали и не тегировали. Это реальная сила.

Но Оракул, отвечающий на вопросы – не имеет ничего общего с вашими знаниями. Теми, что у вас в голове, а не "на диске".

То, что дает описанный ниже сетап — совершенно другое: детерминированное, структурное отображение. Если вы проделали некоторую изначальную работу, Bases покажет вам связи, основанные на логике, которую вы можете прочитать и проверить. Ноль галлюцинаций. Никаких «почему он это выбрал?». Никаких подписок. Никакой отправки ваших личных мыслей через чужой API. Никаких сторонних ИИ-плагинов.

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

Запомните эту мысль — скоро мы поймем, что эта "оплата" на самом деле "инвестиция".

Когнитивные процессы

Что я усвоил на опыте: в любой системе управления знаниями (PKM) я считаю и линкование заметок, и их тегирование когнитивными процессами, несущими «хорошую» ментальную нагрузку.

Проще говоря, перед тем как поставить тег, нужно подумать — и именно это размышление улучшает ваше понимание. Точно так же нужно подумать перед тем, как связать заметки ссылкой, — и это размышление очень ценно с когнитивной точки зрения.

Вот почему эти действия не должны автоматизироваться или исключаться.

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

Это один из ключевых принципов, делающих данный сетап по-настоящему ценным.

Сетап

Логика до безобразия проста:

• Теги (Tags) главный компонент для поддержания связей с самыми отдаленными уголками вашего Графа. Отвечают на вопрос Какие темы с этим связаны?. Теги работают ровно как они и задумывались когда-то – как "ключевые слова", отражая только связанные темы (можно сказать, "что приходит на ум"). Например, #operations, #automation, #ai/agents, #business-development, #sales-enablement, #finance/investments и так далее.
• Ссылки (Links) между заметками отвечают на вопрос Как именно связаны две заметки?Как и тег, сама ссылка это уже результат ментальной работы. Вопрос "Как эти штуки связаны?" подразумевает что вы действительно подумаете над этим, а не просто вставите "См. также".
• Папки (Folders) – опциональны. Но часто ответ на вопрос Что это? тоже важен, поэтому в небольших сетапах за него могут отвечать именно папки — для каждого типа своя папка. Для больших коллекций, особенно с "объектно-ориентированными" заметками, свойство Тип: / Type: работает лучше. Например, "type: article", "type: project", "type: person", "type: workflow" и так далее.

Вот и всё. Никаких навороченных структур — но и никаких пересечений функций между компонентами. Я не использую ссылки, чтобы объяснить принадлежность к теме или к типу. Теги же не отражают суть (Что это?) — у меня нет тега #project. Теги также не отвечают на вопрос Какой тут статус? — для этого есть свойства (properties).

Волшебная боковая панель (Sidebar)

Теперь поговорим о плагине Bases в Obsidian. По факту, ваша коллекция заметок это уже база данных. Bases в этом случае это окошки в неё, которые показывают что-то подходящее под определённые критерии. Например, у вас может быть отдельная база «Проекты», которая покажет все заметки типа project вместе с другими релевантными свойствами, или база «Путешествия» со всеми поездками из папки /Trips, и так далее.

Но я узнал вот что (и для многих это неочевидно): Obsidian позволяет перетащить любую настроенную базу на любую боковую панель — левую или правую — чтобы сохранить её связь с заметкой, открытой в основной части интерфейса.

Примечание к мобильным устройствам: В десктопной версии это работает интуитивно, а вот для мобильных устройств понадобится плагин Mobile Sidebar Notes, который позволяет делать то же самое на iPhone и iPad. Поистине киллер-фича для этого сетапа, если iPad — ваш основной рабочий инструмент.

Настоящая магия этой функции раскрывается в запросах Bases с использованием this.file. Тех самых запросах, которые позволяют ссылаться на текущий открытый файл, чтобы выводить актуальную именно для него информацию.

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

Приведу пример.

Если вы настроите фильтр базы как file.name.contains(this.file.name), то при переносе базы в сайдбар она покажет все заметки, в названии которых содержится название текущего открытого файла. Что-то вроде несвязанных упоминаний (unlinked mentions), но только для имен файлов.

Но наш сетап — это не просто жонглирование названиями. Все немного... сложнее.

Запрос 1: Связанные файлы

По умолчанию Obsidian разделяет обратные ссылки (backlinks) и исходящие (outgoing links) на две разные панели. Но когда я читаю заметку, я хочу видеть всё, с чем она связана, в обоих направлениях, в одном месте.

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

file.hasLink(this.file)
this.file.hasLink(file)

Первая строка выводит каждый файл, который ссылается на текущую заметку (ваши бэклинки). Вторая выводит каждый файл, на который ссылается текущая заметка (исходящие). Объедините их в одной базе, перетащите на боковую панель, и у вас появится единая панель всех связей.

Это минимально-жизнеспособная версия магии. Собирается за 30 секунд. Меняет само ощущение от приложения.

Запрос 2: Файлы, содержащие в названии имя файла

Кажется глупостью, пока не попробуешь.

file.name.contains(this.file.name)

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

К заметке про Google панель покажет все заметки, где есть Google в названии – Google Workspace for businesses, Google revenue report 2024, Google Gemini 3.1 release notes, и так далее. Понятно, что пример примитивный – реальная польза, когда панель выводит более сложные понятия, которые вы подзабыли (например внезапный Sales Training, или заметку про клиента).

Это также блестяще работает для дат. Если вы стабильно используете формат yyyy-mm-dd в именах файлов, то для ежедневной заметки 2026-05-19 боковая панель покажет все файлы, в названии которых есть 2026-05-19:

• 2026-05-19 Встреча
• 2026-05-19 Апдейт проекта
• 2026-05-19 Финансовый анализ и так далее.

Запрос 3: Заметки с общими тегами

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

В моем сетапе именно теги несут этот сигнал.

Первая версия запроса, с которым я работал — file.tags.containsAny(this.file.tags) — возвращала все заметки, у которых совпадает хотя бы один тег из всех, принадлежащих основной заметке. Если у неё 3 или 4 тега, панель превращалась в неюзабельный ужас. Поэтому я ужесточил фильтр:

file.tags.filter(this.file.tags.contains(value)).length >= 2

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

Допустим, у вас есть заметка с тегами #cognition, #pkm, #software. Запрос покажет вам все заметки, тегированные как:

• #pkm и #software
• #pkm и #cognition
• #cognition и #software
• и, конечно, те, в которых присутствуют все три тега

Именно здесь обитают неожиданные связи. Сотни таких связей. Обратите внимание на логическую силу именно комбинации двух тегов – смотреть на все заметки отдельно "про Software" или отдельно "про PKM" не имеет пользы. Сила тегов именно в возможности их комбинировать — конкретно "PKM software", конкретно "Cognition in PKM" — вот что релевантно в заметке, которая имеет все три тега.

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

Собираем всё вместе: Панель связанных заметок

Все эти запросы — не отдельные трюки, а единая система. Объедините их в одну базу (Base) и либо перетащите ее на боковую панель, либо напрямую встройте в заметку с помощью ![[]].

Объединенная база считывает четыре сигнала — входящие ссылки, исходящие ссылки, общие теги и совпадения в названиях — и показывает всё, что заслуживает места рядом с этой заметкой хотя бы по одной из этих осей.

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

Звучит как ограничение. На самом деле в этом-то и весь смысл.

Формула релевантности

Финальный штрих – называние вещей своими именами :) В больших коллекциях при множестве совпадений, мне хотелось внятно видеть степень релевантности заметок. Если заметки связаны напрямую, это одно, но если высоко релевантны, но пока не связаны, это другое.

Эту задачу можно решить через создание кастомной формулы в базе:

if(file.hasLink(this.file) || this.file.hasLink(file) || file.name.contains(this.file.name), "direct", if(file.tags.filter(this.file.tags.contains(value)).length >= 3, "very high", if(file.tags.filter(this.file.tags.contains(value)).length >= 2, "high", "low")))

Вы просто создаете новое поле типа formula в нужной базе (в моём случае она называется Related Notes.base), и вставляете вот это в поле формулы. Логика формулы следующая:

1. Прямая связь: поле примет это значение, когда заметки уже связаны (или есть совпадение по имени). Сюда мы, в общем-то, стремимся.
2. Очень высокая релевантность: когда совпадает 3 и более тегов. Это либо 100%-ная связь, которую вы не сделали, либо полные дубликаты заметок.
3. Высокая релевантность: когда совпадает как минимум 2 тега. Часто самые интересные кандидаты здесь.
4. Возможная (низкая) релевантность: когда совпадает только один тег.

Дальше вы настраиваете группировку по этому полю, и вуаля — будете видеть, какие конкретно заметки связаны напрямую, какие являются потенциалом для связи, а какие отдаленно напоминают, совпадая лишь по одному тегу. Иногда и их полезно проглядеть. Или же наоборот, вы захотите отфильтровать именно по релевантности, убрав всё, что "low".

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

Понимание нельзя делегировать

Всё это работает, если вы линкуете и ставите теги осознанно. Система не сможет компенсировать неряшливую структуру. Если ваши теги непоследовательны (здесь #mgmt, там #management), если вы забываете ставить ссылки, если ваша таксономия плывет — Bases отразит ровно то, что вы в нее заложили. ИИ прикрывает все эти дыры статистическими догадками. Bases так не делает – и не должен. Когда боковая панель пуста, это тоже информация: ваша структура слаба. Bases скажет как есть.

Я не против ИИ в приложениях для управления знаниями. Я против той тихой сделки, которую он предлагает: откажись от размышлений, но сохрани видимость наличия мыслей. В вашей собственной системе знаний работа по выстраиванию структуры не подлежит делегированию. Делегируя её, вы получаете результат без самого когнитивного события (доказательством которого этот результат и должен был стать).

Ссылка — это работа. Тег — это работа. Эта работа и есть ваш личный апгрейд.

Описанный в статье сетап не заменяет ничего из вышеперечисленного — он дает этому место, чтобы проявиться. Вы сознательно строите структуру, и система отражает ее именно тогда, когда вам это нужно.

А побочный эффект заключается в том, что вы действительно начинаете понимать свои собственные заметки.

P.S. Если вам понравилась тема на скриншотах — можете свободно забрать ее с GitHub, или в официальном магазине тем – ищите Nu Ayu.

Bear Notes имеет крайне гибкую систему шорткатов в Apple Shortcuts. Не использовать её означает не использовать 50% потенциала Bear и продолжать считать её “милой, минималистичной заметочницей”.

Важные заметки в один клик

Как я уже говорил, для любого упоминания дат, я использую формат YYYY-MM-DD (2026-03-14) – вместо любых “сегодня”, “два дня назад”, “через месяц”, и так далее. Это дало возможно сделать вот такую штуку:

• Есть шорткат, который открывает Bear сразу с поиском любого упоминания сегодняшней даты.
• При активации этого действия моментально открывается окно поиска в Bear со всеми заметками, которые имеют отношение к “сегодня”: в заголовке заметки, в её теле, в метаданных Frontmatter – везде.
• Но это не самое интересное. Повесить этот шорткат на Action Button (которая сегодня присутствует почти во всех айфонах) – вот где стало интересно :) Теперь по нажатию одной хардварной кнопки на телефоне (либо кастомной комбинации CTRL+OPT+COMMAND+T на клавиатуре ноутбука) я моментально вижу, что важно или релевантно сегодня.

Получается, даже если в заметках ко встрече две недели назад я упомянул 2026-03-20 - эта заметка всплывет по нажатию кнопки ровно 20го марта.

Создание новых логов с метаданными

Bear Notes прямо в настройках позволяет начинать любую заметку с ISO-даты.

Но я не хочу “просто создавать новую заметку”.

Мне нужно, чтобы новые записи сразу попадали в #логи, а также содержали некоторую сервисную информацию "вокруг заметки" в метаданных (Frontmatter) – например где была создана заметка, какая сейчас погода, и даже какое настроение.

По нажатию CTRL+OPT+COMMAND+N (или из шторки Control Center) активируется шорткат, который собирает информацию о локации, погоде, спрашивает меня, о чём заметка (это идет в тайтл), спрашивает “какие ещё темы релевантны” (это идёт в поле «keywords»), “как настроение в данный момент, бро”,  и так далее – и собирает это всё в одну новую запись. Все вопросы можно легко пропустить и "просто создать запись".

Букв много, но действие на круг требует 2-3 секунды – зато заметка сразу попадает куда надо, содержит всё, что помогает её потом найти, и вообще вспомнить что было в этот день.

Логи, как видите, несут некий функционал дневника – не просто поглядеть на контент, но и восстановить хронологию и текстуру момента времени, и даже “соседних” явлений. Это не “девочкин розовый дневничок”, это инструмент, помогающий мозгу более качественно погрузиться в нужный момент времени, максимизируя ассоциативную память.

Создание новых знаний

Ровно по той же логике работает и шорткат на создание новой заметки-знания.

Здесь дополнительная информация это не погода или локация, а кейворды и релевантные понятия.

Заметка создается сразу в #knowledge с кучей подходящих ключевых слов, так как я не всегда знаю 100% возможных контекстов, в которых эта заметка может понадобиться.

Здесь, возможно, неплохо было бы добавить Apple Intelligence, которая могла бы автоматизировать наполнение ключевыми словами. Однако мне кажется важным, кто эти кейворды придумал – если “оригинал” это я, шанс найти эти слова в будущем явно выше.

В конце дня и я иногда просмотриваю логи на предмет вопросов “Какие новые знания я сегодня получил?” и “Какие знания стоит обновить?”. Например, что-то поменялось у клиента, о чём важно помнить – это идёт в соответствующую запись.

Daily Summary

Это пока, по большей части, “баловня”, но баловня, иногда показывающая интересные инсайты.

Я сделал ярлык, который собирает все...

• События в календаре
• Выполненные Задачи
• Заметки, созданные в этот день
• Заметки, упоминающие этот день

...для конкретного дня, анализирует все это с помощью Apple Intelligence, собирает резюме и помещает его непосредственно в Apple Journal.

Это всего лишь попытка собрать разрозненные кусочки и активности обратно в единую картину – а-ля “вот такой сегодня был день” + найти интересные взаимосвязи между отдельными элементами. Теоретически, это может служить основой для дальнейших размышлений о дне, неделе, или месяце. Понятно, что Apple Journal вы можете заменить на любое другое удобное приложение. Мне было прикольно поэкспериментировать именно с ним, поэтому никаких других специальных причин его использовать нет.

Было бы здорово так же использовать Apple Intelligence для помощи в идентификации новых “знаний”, которые могут пригодиться, исходя из определенного контекста. Но пока это более эффективно делать, что называется, своей головой :)

Заключение

Есть скрытая магия связки Bear и экосистемы Apple. Внешне перед вами всё та же аскетичная минималистичная среда, чистый лист, который не давит на мозг перегруженными интерфейсами и миллионом кнопок. Но «под капотом» вы можете собрать мощнейший движок, который работает исключительно по вашей логике.

Мы часто путаем действие «сохранить текст» с действием «сохранить контекст». Без контекста (когда это было, где, зачем, в каком состоянии и с чем связано) любая база знаний со временем неизбежно превращается в глухую свалку. Автоматизируя сбор метаданных через шорткаты, мы снимаем с себя когнитивную рутину. Мы освобождаем ресурс для главного — для осмысления и создания тех самых новых продуктов, о которых говорили ранее.

Минимализм инструмента не должен означать примитивность вашего процесса. Не бойтесь усложнять систему на невидимом уровне, если на поверхности это дает вам те самые 2-3 секунды на ввод данных и кристальную ясность при их поиске.

Папка с полным бардаком разношёрстных файлов, качественно проиндексированная поиском или AI технически в большем порядке, чем красивая струтура тегов, которая требует 4-5 шагов чтобы добраться до нужного элемента + часы усилий на определение этой самой структуры.

Эти 10-12 минут текста будут про то, как быстро, безболезненно и эффективно организовать свои а) мысли и б) работу с помощью практически любых приложений для заметок. Всё, что вы прочитаете дальше, одинаково применимо к Apple Notes, Craft, Obsidian, и, я уверен, ко многим другим подобным приложениям.

Пять Элементов

Как новичкам, так и многим опытным коллегам кажется, что для эффективной работы со знаниями и информацией в целом, нужна сложная структура и многоуровневая логика. Многие из нас проводят значительное время обдумывая схемы, стройные графы, активно используют maps of content, и так далее.

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

В целом, всё чаще всего сводится к пяти категориям сущностей.

1. Временные записи: те, что несут ценность в моменте, свободны в своей форме, и требовательны больше к скорости их создания, чем к структуре или содержанию. Сюда относятся Daily Notes, быстрые заметки “на полях”, meeting notes, и так далее.
2. Репрезентации знаний: это уже структурированные формы, которые несут долгосрочную ценность, наполняются и развиваются со временем, имеют логические связи с другими записями, образуя сеть знаний. Это концепции "вне времени", по сути, похожие на страницы Википедии – но личной и индивидуально значимой. Здесь живёт прямое отражение понимания темы: качество записи прямо прямо пропорционально качеству понимания и мышления.
3. Записи к проектам: это заметки или документы, которые нацелены собрать в себе информацию по какой-либо активности, ограниченной по времени, но достаточно сложной по своей сути – например документ, описывающий проект с его, целями, ключевыми лицами, стадиями, а также списком задач или активностей. Такой документ будет ценен только но время проекта, и имеет целью собрать воедино разрозненную информацию о сложной активности и главное — помогать действовать.  Наверное можно сказать, что это разновидность записи из предыдущего пункта , но специализированная, временная, и нацеленная на действия.
4. Продукты системы: проекты заканчиваются продуктами. Основные – артефакты – чаще всего предназначены для внешнего мира, и поэтому в системе не живут, разве что копии документов или репрезентации. Однако почти всегда есть еще и побочный продукт: это новые знания. (Возвращаемся к пункту 2) Также, когда мы импортируем какой-то внешний файл (идею, статью, книгу, документ), полезно понимать, что это продукт чей-то (чужой) системы – и надо определить, какую роль он должен занять в нашей.
5. Сервисные записи и структуры: по факту это некие дэшборды или “оглавления”, где вы вручную, либо с помощью средств конкретного приложения, собираете в одном месте информацию c определенной целью. Именно здесь приложения для заметок отличаются друг от друга в большей степени. Collections в Craft, список заметок внутри одного тега в Bear, Dataview в Obsidian, и даже смарт папки в Apple Notes – всё это имеет своей целью собрать в одном месте что-то “важное”, отфильтровав “неважное”. В рамках DIKW можно сказать, что это любой функционал, позволяющий упростить переход из Data → Information.

Принципы

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

• Ключевой принцип: важно то, как я работаю с тем, что важно, и не важно, как работаю с тем, что неважно. Тратить одинаковые усилия на организацию проектных документов и списков покупок – бред. Это простой и логичный вывод, однако потребовалось время, чтобы до этой истины дойти.
• Система существует для чего-то. Фокус на продуктах системы ("что мы тут вообще создаём?") создает продуктивное давление – усиливает любую структуру и толкает узнавать что-то новое. Без продуктов легко завязнуть в вечной организации и “письмах самому себе”, которые никто не прочитает. И, да, корень в слове "продуктивность" – "продукт" ;)
• Для организации мыслей, знаний, и проектов почти всегда достаточно одного приложения. Однако это приложение должно
• а) позволять делать записи быстро,
• б) соединять заметки друг с другом, и
• в) уметь в качественный поиск. Последнее крайне важно.
• Основной инструмент порядка – Поиск. Поиск по большей части работает с текстом. Поэтому качественный поиск невозможен без качественного текста. В коллекциях и хранилищах записей структура важна сильно меньше, чем находимость с помощью ключевых слов.

Основа: Bear Notes

На данный момент, приложение, в котором я провел суммарно больше всего времени, и которое приносит наибольшее удовольствие от работы (а это супер немаловажно!) – это Bear Notes. Оно обладает всеми необходимыми возможностями для очень быстрой, и при этом эффективной работы с очень серьезными объёмами информации.

А самое главное – не отвлекает от того, зачем вообще заметки предназначены: от качественной и беспрепятственной выгрузки всего из головы на цифровую бумагу.

Для Windows и Linux, я думаю, что самая близкая альтернатива это UpNote. Очень похожая логика, простота, но при этом есть важные отличия в части backlinks и интеграциями в ОС. Если возможностей UpNote мало, Obsidian это логичный кросс-платформенный next level.

Что происходит в Bear Notes

Bear Notes примечателен тем, что он вообще не принуждает вас что-то там решать, или создавать структуры. Вы просто… начинаете писать. Мой сетап со временем пришёл именно к этому – не мешать главному.

Logs - временные записи

Поэтому в Bear Notes у меня основной и самый используемый тег это #logs. Сюда по дефолту идут все новые записи. Логи обладают некоторыми определенными свойствами:

1. Все Логи начинаются с даты создания. Я вообще везде, при любом упоминании дат, использую формат YYYY-MM-DD, чтобы никогда не запутаться.
2. Логи абсолютно не требуют структуры или какого-либо обслуживания. Всё что сюда записывается, записывается как есть. Быстро, грязно – главное “сохранить” и “оцифровать”. Примеры:
1. 2026-03-01 Notes on Types of Information,
2. 2024-06-23 HR Syncup Meeting Notes,
3. 2025-10-10 Shopping List.
3. Логи никуда не коннектятся, никаких линок и бэклинок. Это не Вики. Это временные записи. Приложения, которые умеют в Unlinked Mentions (Obsidian, Bear) здесь имеют преимущество – вы всегда найдете необходимый термин / концепцию / слово, если оно просто упомянуто в тексте логов. Но даже если вы работаете в Craft или Apple Notes не забывайте про старый добрый Search – он решает в 90% случаев.

Красота логов в том, что вам не надо ничего “менеджить” или специально “складывать в архив”. Логи живут себе спокойно ровно столько, сколько вам нужно. Не обременяют никакими структурами или коннекшенами, и автоматически устраняют любое FOMO про “а вдруг мне это пригодится”.

Пригодится – найдёшь через поиск.

Knowledge – репрезентация знаний

Дальше идут записи уже про некие “стабильные” сущности. Как я говорил в предыдущей части, здесь качество понимания предмета напрямую отражается в качестве записи.

Если я понимаю концепцию, допустим, Cloud Infrastructure, то очевидно, что я смогу создать стройную заметку или документ с чётким определением, ключевыми терминами, понятной логикой, структурой, упоминанием соседних понятий, и так далее.

Если моя заметка ограничивается “ну эцсамое, эт чёто про облака” то вполне возможно мой текущий уровень понимания пока не тянет на то, чтобы называться знанием. И тем не менее, если со временем я немереваюсь это знание взрастить – заметка про Cloud Infrastructure  в какой-то момент должна стать стройной и насыщенной, как отражение моего понимания и мышления.

Таким образом, в тег #knowledge идут записи про сущности, концепции, людей, компании, клиентов, места, инструкции, и так далее и так далее. Самое главное, должна быть причина иметь целую заметку про какую-то концепцию. Заметки-знания помогают:

а) найти нужное;

б) определить его место и отношения внутри всей системы;

в) убедиться что я вообще понимаю о чём речь.

Фокус в заметках-знаниях лежит на том, куда они коннектятся, а не на том, где они лежат или как протегированы.

Если в Логах коннекты не имеют ценности (кроме, разве что, навигационной) и скорее всего лишь замусоривают систему, то в Знаниях связи это определяющие элементы. Я могу сказать что “понимаю что-либо”, если я знаю к чему это относится, и какие здесь отношения с другими элементами системы.

Вопросы, регулярно звучащие при “создании знания”:

• “мне вообще понятно что это такое?“
• “как я могу это определить?“
• "а что ещё сюда относится?"
• "что ещё релевантно из соседних тем и концепций?”
• "с чем это может быть связано?"

Projects – чеклисты для результатов

Тег #projects я использую для документов, которые собирают задачи по проектам в одном месте в виде чеклистов. Это сильно удобнее, чем любой таск менеджер. Я не хочу видеть список активностей по постройке “кораблей, которые бороздят”, рядом с напоминаниями про ипотеку и алименты.

Разделение администритивных вещей и проектных крайне важно и эффективно.

В проектные заметки я также собираю и всю релевантную информацию, которая нужна под рукой: цели проекта, сроки, последний статус, ссылки на ресурсы, внешние документы, ссылки на другие заметки, в том числе важные meeting note’ы из логов, иногда даже аттачменты с продуктами проектов.

Это не означает что я не могу пользоваться Apple Reminders. Просто в этом случае ремайндеры остаются тем, чем были задизайнены – напоминалками, а не проектной доской :)

Если же всё-таки проект необходимо разбить на задачи, каждую со своей датами и обязательным трекингом, последние версии Reminders обладают полноценным Kanban’ом. Не проблема.

Переход Projects → Knowledge

Любой проект заканчивается двумя вещами:

1. Продуктами: артефактами, решениями, моделями.
2. Новыми знаниями: уроками, дополненными концепциями, инструкциями, и так далее

Обе эти штуки можно сохранить в системе. Да-да – в #knowledge.

Но особенно интересны заметки а-ля

• 10 причин почему мы не смогли продавать,
• Чеклист готовности к зимней поездке на летней резине,
• Как мы решили проблему планирования загрузки через AirTable,
• Три вещи, которые нужно знать для Quarterly Business Review

– лишь некоторые из сотен примеров знаний, как побочных продуктов проектов.

Collections

Организация отдельных элементов в Коллекции – через тег #collections/topic – это осознанное собрание в одном месте записей, которые мне нужны именно в одном месте, именно во всём своем множестве.

Например, я знаю, что мне точно нужно просматривать список всех своих черновиков – #collections/drafts служит именно для этого.

Также, например, если вы хотите выбрать какой-то рецепт на вечер, но не знаете какой, иметь список всех рецептов в #collections/recipes разумно.

Раньше, как и многие, я делал списки по любому поводу – вроде #collections/customers – но со временем стало ясно, что никакой практической ценности такая организация не имеет. А вот головной боли добавляет. Если бы я регулярно работал с клиентскими заметками, причём всеми сразу – наверняка они были бы нужны в одном месте. Но если такой необходимости нет, такая организация – прекрасный пример траты времени на "неважное".

Ключевой вопрос перед организаций чего-то под одним тегом – "где и когда мне требуется смотреть на все эти элементы в одном месте". Какую роль и смысл несёт тот или иной тег (или папка)?

Теги #logs, #knowledge, #projects – помогают понять, что за заметка передо мной. Они образуют законченную систему, где любая новая заметка точно попадает в какую-то одну "корзину", не пересекаясь с другими.

Поиск информации: зачем всё это нужно

Определение порядка для физического мира и цифрового, как ни странно, отличаются. Если в физическом мире “порядок” чаще относится к нахождению элементов в пространстве (“разложить всё по полочкам”, “не мог найти ключи, которые завалились под стол”), то в цифровом мире "порядок" означает “Находибельность” –  возможность быстро найти то, что нужно.

“Захламленная” папка, которая идеально проиндексирована поиском или ИИ, технически находится в большем «порядке», чем красиво вложенная древовидная структура, в которой невозможно быстро ориентироваться.

Именно поэтому больший упор я делаю на создание текстовых “якорей” – которые максимизируют способы найти нужное. Теги, папки, YAML, и так далее – это всего лишь разновидности способов отфильтровать ненужное. Но в отличие от простого текстового поиска а) их логика отличается от приложения к приложению и б) они требуют от пользователя серьезных усилий по организации.

В следующем посте мы посмотрим на крутые возможности Bear Notes по автоматизации ежедневных действий. Его поддержка Apple Shortcuts гораздо более обширная и интересная, чем у Apple Notes...

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

«Проблема продуктивности» кроется не в недостатке дисциплины; я вижу это как аппаратно-программную несовместимость.

В этой статье я описываю современные вызовы продуктивности на нескольких уровнях. Этот фреймворк лично мне помог начать решать правильные проблемы.

Начнем с определений

Мы все стремимся «быть продуктивными» — но в чём именно?

Я определяю Продуктивность как способность ясно осознавать и выпускать Продукты во всех важных сферах жизни.

Продукт — это ценное, осознанное изменение реальности, согласованное с целями и ценностями действующего лица.

Продукты — это не только физические артефакты (вроде документов или презентаций); они могут быть внутренними или нематериальными:

• «Здоровый ты» — это продукт.
• «Семейный ужин» — это продукт вашего осознанного планирования и похода за покупками.
• «Новая ментальная модель» или решение, подкрепленное новыми знаниями, — это продукт.

Почему продукты так важны — и дело не только в том, что слово «Продуктивность» происходит от слова «Продукт»:

• Продукт подразумевает субъектность и ответственность — это ваш продукт;
• Продукт определяется границами — он имеет определенный масштаб и форму, физическую или нет;
• Продукт содержит ценность — это ценное изменение, а не просто какое-то изменение.

Истинная продуктивность также требует широкого горизонта планирования. Когда ваш горизонт — «завтра», вы можете позволить себе выгореть. Когда ваш горизонт — «вся жизнь», такие факторы, как здоровье, семья и ясность ума, становятся важными переменными в вашем уравнении продуктивности. Чтобы проверить это, попробуйте задуматься вот о чем:

• Продуктивно ли выполнить план релиза, если половина команды при этом выгорела?
• Продуктивно ли полностью посвятить себя улучшению здоровья, спустив на это все свои деньги?
• Продуктивно ли закрывать по 120 задач в день и видеть своих детей по 2 минуты?

Когда горизонт планирования короткий, мы выносим издержки (здоровье, выгорание) за скобки; когда он длинный, эти издержки становятся внутренними переменными, которыми необходимо управлять.

6 несоответствий в проблеме продуктивности

Несоответствие 1: Осознание значимости

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

• Пропустили письмо — сорвали сделку;
• Проигнорировали сообщение — испортили отношения;
• Потеряли пароль — лишились денег.

Если вы поддерживаете порядок в физическом мире, не менее важно поддерживать порядок и в цифровом.

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

Несоответствие 2: Парадокс порядка

Ситуация усложняется тем, что «Порядок» в этих мирах означает две разные вещи.

В физическом мире порядок пространственный (например, «мои ключи лежат под пальто»).

В цифровом мире порядок — алгоритмический / поисковый.

Цифровой порядок — это не про аккуратность; это про находимость. «Захламленная» папка, которая идеально проиндексирована поиском или ИИ, технически находится в большем «порядке», чем красиво вложенная древовидная структура, в которой невозможно быстро ориентироваться.

И да, это также означает, что некоторые из наших попыток оптимизации решают совершенно не ту проблему.

Несоответствие 3: Аналоговый мозг в цифровом мире

Мы живем в двух мирах, но наш мозг от природы принадлежит только одному.

В цифровом мире:

• Ничто не переполняется: Объем памяти бесконечен.
• Ничто не имеет веса: 100 файлов ощущаются ровно так же, как один.
• У действий нет цены: Копирование и вставка ничего не стоят.
• У интерфейсов нет границ: Плавающие элементы и бесконечные ленты сбивают с толку наше пространственное мышление.

Неудивительно, что люди чувствуют себя перегруженными. Наш мозг эволюционировал так, чтобы ожидать физической обратной связи — «стука», когда мы бросаем камень; сопротивления материала, когда что-то двигаем.

Мы идем против миллионов лет эволюции каждый раз, когда обновление программы сдвигает привычную кнопку.

Несоответствие 4: Проблема пропускной способности

Цифровые хранилища и информационные потоки теперь бесконечны.

С появлением ИИ доступ к знаниям стал безграничным.

Но пропускная способность человека ограничена.

У нас по-прежнему лишь 24 часа в сутках, ограниченный ресурс когнитивной нагрузки и конечный объем внимания. «Проблема продуктивности» — это не лень; это несоответствие ресурсов. Мы пытаемся обработать бесконечный поток с помощью конечного процессора.

Несоответствие 5: Приложения — это Империалисты с кризисом идентичности

В отличие от аналогового мира, цифровое пространство практически не регулируется. Каждое приложение или сервис рождается со своим собственным набором правил, интерфейсов и логикой.

Проблема не только в том, что приложений слишком много. Проблема в кризисе идентичности современного софта. Почтовые клиенты пытаются быть таск-менеджерами; мессенджеры пытаются быть файловыми хранилищами; приложения для заметок пытаются быть операционными системами.

Приложения ведут себя как Империалисты. Они бьются за ваше «время в приложении» и внимание, часто запирая вас в своей экосистеме. Они предлагают широкий набор [порой — весьма посредственных] функций, физически ограничивая при этом совместимость с другими инструментами.

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

Несоответствие 6: Кризис суждения

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

• Кризис кураторства: Мы переходим от мира дефицита (где нужно найти информацию) к миру перенасыщения (где нужно отфильтровывать цифровой шлак). Теперь ценность заключается в смелости сказать «нет» (в праве вето).
• Налог на энтропию: Создать черновик стало в 10 раз быстрее, но проверить его на достоверность — в 10 раз сложнее. Мы променяли проблему «чистого листа» на проблему «галлюцинации в стоге сена».
• Усиление намерения: ИИ обнажил жестокую правду: большая часть нашей «работы» на самом деле сводилась к «обработке». Теперь, когда реализация ничего не стоит, единственное, что имеет значение, — это Ясность намерения. Если вы не представляете свою Точку Б кристально четко, ИИ уверенно приведет вас к статистически вероятной, но абсолютно бессмысленной Точке В.
• Распад субъектности: Это самый опасный уровень. «Делегируя понимание» моделям, мы рискуем столкнуться с атрофией нашей стратегической мышцы. Если вы только редактируете и никогда не создаете с нуля, со временем вы теряете способность бросать вызов системе. Вы становитесь менеджером черного ящика, который перестали понимать. А как только вы теряете способность подвергать логику сомнению, вы теряете способность быть лидером…

Резюме

Если мы сведем все эти измерения к единому определению проблемы, то увидим, что:

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

В аналоговом мире ценность заключалась в действии.

На заре цифрового мира ценность заключалась в знании.

В мире ИИ ценность кроется в кураторстве и ответственности.

Системы продуктивности по-прежнему сфокусированы на том, чтобы «делать больше». Но в эпоху ИИ это самое «больше» и есть проблема. Истинная продуктивность сместилась от эффективности к осознанности намерений.

И это также означает умение говорить вещам «Нет».

Повышение продуктивности — это осознанное заполнение разрыва между вашим текущим состоянием (Точкой А) и желаемым (Точкой Б). По мере того как ИИ обретает безграничную мощь (и, по сути, наделяет нас этой безграничной мощью), критически важно сохранять кристальную ясность мышления и видение тех продуктов, которые вы на самом деле хотите выпустить.

Потому что возможно всё.

Каков будет ваш следующий продукт?