Свалка в Notion начинается не с объёма. Свалка начинается с отсутствия правил. Можно держать пятьдесят страниц и ничего в них не находить. А можно держать пятьсот, и ориентироваться за секунды. Разница не в количестве данных, а в том, как они организованы.
Этот материал про семь правил, по которым Notion остаётся рабочей системой, а не превращается в кладбище заметок. Не нужно внедрять все семь одновременно, достаточно понять, где сейчас главная боль, и начать с правила, которое её закрывает.
Что это
Свалка в Notion это не эстетическая проблема. Это операционная: агенту негде зацепиться, человеку некуда вернуться, поиск не помогает, потому что индексировать нечего. Когда у страниц нет баз со свойствами, нет статусов, нет понятных названий, Notion превращается в личную копилку, в которой сам автор через месяц ничего не находит.
Рабочее пространство Notion это не набор страниц. Это набор баз со свойствами, между которыми ходят агенты, представления и человек. Если этого разделения нет, не работает ни одна автоматизация, ни один шаблон, ни одна интеграция. Пространство функционирует как текстовый файл, а не как структурированная система.
Ключевое правило: Notion работает как система, когда у каждого типа данных есть своя база со свойствами. Всё остальное следствие.
Зачем нужно
Порядок в Notion решает сразу несколько задач, которые незаметно копятся, пока пространство живёт «как привыкли».
- Агент понимает, куда писать. Без баз со свойствами ИИ-агенту нечего заполнять: он видит стену текста, а не структурированные записи с категориями и статусами.
- Поиск работает. Свойства «Статус», «Категория», «Дата», «Теги» это индекс. Когда они есть, Notion находит за секунды. Когда их нет, остаётся только Ctrl+F по полному тексту.
- Снижается когнитивная нагрузка. Человеку не нужно помнить, что где лежит. Правила и шаблоны делают это за него.
- Дубли не появляются. Когда у каждой сущности своя база и понятное имя, дубль сразу видно.
- Архив не превращается в кладбище. Завершённые записи уходят в архив с понятным статусом, а не копятся в общем списке.
Как устроено
Семь правил работают как слои: правила на пути входа, свойства в базе, статус на каждой записи. Если хотя бы один слой пропущен, система рассыпается в копилку.
flowchart LR
A["Входящие"] --> B{"Есть правила?"}
B -->|Да| C["База со свойствами"]
B -->|Нет| D["Свободная страница"]
C --> E["Находится за секунды"]
D --> F["Теряется через неделю"]Правило 1. Одна сущность в одной базе
Каждый тип данных живёт в отдельной базе: задачи в задачах, контент в CMS, клиенты в CRM, проекты в проектах. Смешение сущностей в одной базе даёт свалку из «всё обо всём», где фильтр по статусу теряет смысл.
Правило 2. Свойства вместо текста
Статус, категория, дата, теги, ответственный это свойства базы, а не текст в теле страницы. Свойство работает как индекс: по нему фильтруются записи, строятся представления, агенты читают данные. Текст в теле индексируется только полнотекстовым поиском, и для структурной работы он бесполезен.
Правило 3. Статусы для каждой базы
У каждой записи в рабочей базе есть статус: Новая, В работе, Готово, Архив. Без статуса невозможно отличить актуальное от завершённого, собрать активный контур в одном представлении или передать работу агенту с понятным «следующим шагом».
Правило 4. Называйте понятно
Заголовок страницы должен отвечать на вопрос «что это?» без открытия самой страницы. «Без названия», «Заметка 3», «TODO» признак нерабочего пространства. Хорошее название содержит суть. Например: «Договор с ООО Ромашка, июнь 2026», «Спринт 12: релизы и баги», «Идея: автоматизировать онбординг».
Правило 5. Архивируйте, а не копите
Завершённые записи не удаляются, они архивируются. Архивная запись остаётся в базе, но скрыта из активных представлений. Это страховка: данные не теряются (нужны для аудита и восстановления контекста), шум уходит. Удаление «на всякий случай» через полгода оборачивается потерей контекста.
Правило 6. Шаблоны для повторяемых записей
Если запись одного типа появляется хотя бы раз в неделю, у неё должен быть шаблон. Шаблон фиксирует свойства по умолчанию, разделы тела, чеклист. Без шаблона однородность базы рассыпается: одна задача с дедлайном, другая без, третья с тегами, четвёртая без. Через месяц база превращается в зоопарк.
Правило 7. Одно место для входящих
Любая новая запись сначала попадает в инбокс, единую точку входа. Из инбокса она распределяется в целевую базу. Без инбокса записи появляются сразу в разных местах, плодятся дубли, теряется контекст «откуда пришло и зачем». Инбокс становится узлом, через который проходит всё входящее и в котором видно, что ещё не разобрано.
Когда использовать
Не нужно внедрять все семь правил сразу. Достаточно найти свою главную боль и закрыть её одним правилом, потом подключить следующее.
| Ситуация | Правило, которое закрывает боль |
|---|---|
| В пространстве 200 страниц и ничего не найти | 1. Одна сущность в одной базе |
| Данные лежат в тексте страницы, а не в свойствах | 2. Свойства вместо текста |
| У записей нет статусов, непонятно, что актуально | 3. Статусы для каждой базы |
| Названия «Без названия», «Заметка 3», «TODO» | 4. Называйте понятно |
| Боитесь удалять, всё «на всякий случай» | 5. Архивируйте, а не копите |
| Каждый раз создаёте задачу с нуля | 6. Шаблоны для повторяемых записей |
| Записи появляются в разных местах, появляются дубли | 7. Одно место для входящих |
Пример
Пример того, как выглядит база задач до и после внедрения правил.
До: список задач в виде подзаголовков на свободной странице. Статусы приходится держать в голове. Дата дедлайна иногда есть в тексте, иногда в заголовке, иногда нигде. Поиск по «В работе» не работает: это слово может быть где угодно. После: база данных Задачи с такими свойствами: Название (title), Статус (Новая, В работе, Готово, Архив), Категория (Контент, Код, Коммуникации), Дата (дедлайн), Ответственный (person), Теги (multi-select). Запись создаётся через шаблон, попадает в инбокс, оттуда через представление В работе уходит в активный контур. Поиск по статусу работает мгновенно, фильтр по категории тоже.
Ограничения
Ограничения
Что учитывать
Правила помогают, но у них есть границы применимости.
Объём не равен беспорядку — пятьсот структурированных записей находят за секунды, а пятьдесят хаотичных страниц теряются.
Порядок это структура, а не малое количество данных.
Внедрение правил требует времени — за один день нельзя перевести всё пространство в новые рельсы.
Лучше внедрять правила по одному, фиксируя привычку.
Шаблоны не решают всё
— шаблон помогает с повторяемыми записями, но если у самих сущностей нет статусов и свойств, шаблон превращается в косметику.
Архив это не удаление — заархивированная запись остаётся в базе, просто скрыта из активных представлений.
Это страховка, а не потеря данных.
Агент работает только со структурой
— без баз и свойств у ИИ-агента нет точек опоры, и он начинает писать «как получится», ломая и без того шаткую систему.
Антипаттерны
Антипаттерны
Чего не делать
Семь частых ошибок, которые превращают пространство в свалку.
Держать всё на свободных страницах
— потому что у страницы нет свойств, и через месяц невозможно найти по статусу или категории.
Писать статус в заголовке страницы
— потому что заголовок это title, и его нельзя использовать для фильтрации в представлении.
Хранить дубли одной и той же информации в нескольких местах
— потому что при изменении одни копии обновятся, другие останутся старыми, и через полгода никто не вспомнит, какая правильная.
Создавать записи сразу в разных базах, минуя инбокс
— потому что это путь к дублям и потере контекста: никто не помнит, откуда запись пришла и зачем.
Удалять завершённые записи «на всякий случай» — потому что они могут понадобиться для аудита, отчёта или восстановления контекста.
Архив решает эту задачу без потери данных.
Называть страницы «Без названия», «Заметка», «TODO»
— потому что такие заголовки не отвечают на вопрос «что это?» без открытия страницы и делают поиск бесполезным.
Применимо для этого материала
→ не выявлено — антипаттерны из источника покрыты шестью пунктами выше, дополнительных нерелевантных паттернов нет.
Чеклист
Чеклист
Проверка перед запуском
Семь пунктов, по которым видно: пространство работает как система.
Каждый тип данных в отдельной базе — задачи в задачах, контент в CMS, клиенты в CRM, проекты в проектах.
Никаких смешанных сущностей в одной базе.
Все ключевые параметры вынесены в свойства
— статус, категория, дата, теги, ответственный это свойства базы, а не текст в теле страницы.
У каждой записи есть статус
— без статуса невозможно отличить актуальное от архивного и собрать активный контур в одном представлении.
Названия страниц понятны без открытия — заголовок должен отвечать на вопрос «что это?» без клика.
«Без названия» и «Заметка 3» признак нерабочего пространства.
Завершённые записи архивируются — архив скрывает запись из активных представлений, но не удаляет её.
Данные остаются, шум уходит.
Шаблоны созданы для повторяемых типов
— если запись одного типа появляется хотя бы раз в неделю, у неё должен быть шаблон, иначе однородность базы рассыпается.
Входящие попадают в инбокс — единая точка входа для новых записей.
Из инбокса они распределяются по целевым базам, а не плодятся сразу в разных местах.
Ссылки
Ссылки
- Документация: Notion: Databases
- Документация: Notion: Properties
- Документация: Notion: Templates
- Документация: Notion API