Контент-завод 2.0 для SEO-контента

Проблема

Конвейер для первого клиента (питомник «Росток») закрывал задачу: семантика, тексты с граундингом и голосом бренда, обложки, постинг по расписанию. Но при попытке масштабировать на несколько брендов упирались в стену: одна операционная таблица, один ключ OpenRouter, нет формализованного подключения новых клиентов, нет прозрачного учёта расходов на ИИ по каждому заказчику и нет изоляции настроек каналов.

Решение

Мульти-клиентская архитектура

Ядро — PostgreSQL и Prisma: клиенты, ClientSettings, AdminSettings, таблица расходов cost_records, логи. У каждого клиента свой spreadsheetId, свой ключ OpenRouter, свой Telegram-канал; таблица создаётся из мастер-шаблона в Google Drive. Операционный интерфейс остаётся привычным: листы «Задания», «Настройки», «Статистика», «Лог».

Цепочка генерации (5 этапов)

Ключ / строка задания в таблице.
Семантика — Wordstat и ИИ; при сбоях предусмотрена деградация без остановки конвейера.
Заголовки — парсинг и нормализация разметки и нумерации.
Текст — граундинг по фактам: URL из блока фактов не попадают в черновик лишними вставками; хосты фиксируются в колонке «Источники». После текста статус ведёт к этапу картинки, а не сразу к «готово к проверке».
Картинка — отдельный воркер по расписанию и статусам; загрузка в S3-совместимое хранилище, в таблице — публичная ссылка.

Публикация — только текст в Telegram (HTML с учётом лимитов). Дзен в продукте не публикуется напрямую: зеркалирование TG → Дзен на стороне клиента (например через @zen_sync_bot); обложку для Дзен при необходимости подключают вручную.

Веб-онбординг

Клиент заполняет форму в браузере; бэкенд портфолио/CMS не светит секрет — на сервис уходит POST /api/onboarding с токеном в Authorization. Поддерживается аудио-бриф по HTTPS: однократная загрузка, конвертация, транскрипт, временные файлы удаляются, URL сырого аудио в БД не хранится. ИИ извлекает структуру брифа → записи в БД; при шаблоне таблицы — копия Google Sheet и выгрузка в лист «Настройки». Интеграторы получают уведомление в Telegram. Отдельного onboarding-бота с длинной анкетой нет.

Учёт расходов

Все вызовы ИИ привязаны к cost_records. В мульти-клиентском режиме генерация идёт с ключом клиента; при пустом или PENDING ключе подставляется глобальный ключ из конфига (как зафиксировано в договорённостях по проекту). Шаг онбординга (транскрипт + извлечение полей) идёт на глобальном OpenRouter — заложено в себестоимость хостинга и сопровождения.

Очереди и надёжность

Redis и BullMQ разделяют этапы: семантика, текст, картинка, публикация, перегенерация. Планировщик опрашивает таблицы, ставит задачи в очередь, соблюдает лимиты публикаций. Поддерживаются режим мульти-клиент (есть админ-настройки и активные клиенты) и legacy (одна таблица из env и глобальный ключ). Синхронизация листа «Настройки» в PostgreSQL на тике планировщика возможна при включённой опции; её можно отключить переменной окружения.

Результат

Одна кодовая база обслуживает N клиентов параллельно: изоляция данных, своих таблиц и ключей. Подключение нового клиента сводится к прохождению веб-формы и ручным шагам интегратора (выдача ключа OpenRouter, замена PENDING в БД при необходимости). Конвейер из пяти этапов совпадает с продуктовым ТЗ и договорной матрицей приёмки; деплой — Docker Compose (Postgres, Redis, приложение, опционально NocoDB для просмотра БД).

Нужен контент-конвейер под несколько клиентов или ниш? Напишите — обсудим задачу.