Контент-завод на n8n: разбор моей схемы планирования публикаций

В папке десять статей из RSS, а по плану завтра нужно объяснить свою услугу. Можно автоматически опубликовать ещё одну новость. Только задачу блога это не решит.

В моём проекте контент-завода на n8n Orchestrator задуман как планировщик: он сопоставляет материалы с будущими публикациями и показывает, чего не хватает. Сначала потребность плана, затем выбор источника и доступного способа подготовки.

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

Что входит в схему Orchestrator

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

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

Шаг 1. Привести разные источники к одной карточке

Ручная ссылка, RSS и файл дают разные данные. Orchestrator удобнее передавать единый объект source_event: проект, тип источника, адрес или ID файла, название, текст и ключ повторной обработки.

Например, возьмём существующую статью о моём эксперименте с монтажом. Ниже учебная запись по реальному публичному источнику, а не экспорт журнала n8n:

{
  "project": "my_blog_demo",
  "source_type": "manual_link",
  "source_url": "https://shvedkov.pro/post/ai-agents/ii-videomontazher-style-kit",
  "source_title": "Эксперимент с ИИ-монтажом",
  "facts": ["субтитры снизу", "проверка положения глаз"],
  "suggested_category": "expert",
  "suggested_format": "text",
  "status": "new"
}

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

Шаг 2. Найти повторы и определить тему

В исходной схеме ключ материала строился из проекта, типа источника и идентификатора: URL, GUID или ID файла. Он помогает не обработать повторный вход одного источника как новую задачу.

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

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

Классификация сначала может работать правилами: личная заметка, экспертное объяснение, предложение услуги, внешний инфоповод. Если подключаете ИИ, его ответ остаётся проверяемой рекомендацией. Ссылка из видеосоцсети сама по себе не доказывает, что материал полезен вашей аудитории или станет популярным.

Шаг 3. Посчитать, чего не хватает в плане

В апрельском примере я использовал соотношение 40/30/20/10 для четырёх рубрик: привлечение внимания, экспертные материалы, личное и предложение услуги. На десять публикаций это 4, 3, 2 и 1. Это пример настройки, не универсальная формула продвижения.

Посмотрим на учебную ситуацию, где семь мест уже заполнены:

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

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

Шаг 4. Сопоставить место в расписании с возможностями подготовки

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

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

Полезные состояния должны различать причины:

• needs_source - подходящего исходника нет;
• production_not_supported - исходник есть, но нужный формат не поддержан;
• queued_for_production - задача передана на подготовку;
• ready - материал подготовлен, но ещё не обязательно утверждён;
• scheduled - согласованная версия поставлена в расписание;
• published - результат проверен по правилам площадки;
• failed - известна ошибка, требуется разбор.

Например: «На следующее согласованное время нужен пост об услуге. Исходника нет. Пришлите условия или разрешите замену». Это полезнее молчаливой публикации очередной новости.

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

Какие записи хранить в Baserow

В моей схеме четыре основные таблицы: настройки проекта tenants, входящие материалы post_idea, расписание content_plan и история published_content.

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

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

Как проверить один запуск и посчитать его стоимость

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

При проверке фиксируйте:

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

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

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

Помогу разобрать ваш маршрут от материала до публикации

Если источников много, а нужные посты всё равно не выходят, на бесплатной диагностике в Zoom за 40-60 минут предварительно посмотрим, где теряется работа: выбор темы, исходник, подготовка, проверка или размещение.

Для первой встречи достаточно описания процесса. Проектирование n8n, Baserow и подключений, тестовый запуск и обслуживание согласуем отдельно. В Нейроцехе есть обучение настройке своих публикаций с поддержкой; эта апрельская схема не является обещанным комплектом функций клубной подписки.

Обсудить автоматизацию своего контент-плана