Границы редакционной автоматизации

Предложение новой статьи часто приходит в свободной форме: заголовок, несколько строк объяснения и название темы. Редактор тратит время на одинаковые операции, хотя окончательное решение о материале требует его участия. Построим учебный процесс для ProfessorWeb, который приводит заявку к понятной форме и готовит запись для рассмотрения. Сначала определим, какую часть работы можно описать правилами.

В серии используется собственный пример editorial-intake-lab. Три заявки, роли и события синтетические; реальные посетители ничего не отправляли. Приложения уроков содержат начальное состояние, последовательные решения и ожидаемые данные. Поле example_execution: not_run означает, что workflow здесь не запускался. Нам понадобится понимание полей JSON; устройство n8n рассмотрим далее.

Собственные файлы этого шага доступны в архиве fixtures и контрактов серии, папка lesson-01. Это приложения к объяснению, а не готовый экспорт workflow.

От предложения к подготовленной записи

Введём заявку P-001: «Проверка старых URL». Автор хочет объяснить, как составить реестр прежних адресов и сравнить ожидаемые ответы после переноса сайта. Заголовок записан с пробелами по краям, тема — как WEB. Это не препятствие для человека, но неудобный вход для точного сравнения. Автоматизация может удалить внешние пробелы и привести код темы к нижнему регистру.

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

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

Этап	Вход	Подготовленный результат	Ручное решение
Приём	Исходная заявка	Сохранённый идентификатор	Уточнить намерение автора
Нормализация	Поля заявки	Заголовок и код темы	Оценить точность содержания
Маршрутизация	Известная тема	Название очереди	Назначить исполнителя
Подготовка	Проверенные поля	Редакторская карточка	Принять или отклонить материал

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

Событие, условие и действие

Workflow — связанная последовательность обработки. Trigger запускает её при событии: ручном старте, наступлении времени или поступлении запроса. Условие выбирает дальнейший путь по данным. Действие создаёт нужный результат. В учебном процессе событием будет получение синтетической заявки, условием — принадлежность темы редакционной очереди, действием — формирование JSON-карточки.

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

Введём две понятные темы: web и seo. Третья заявка P-003 относится к web3. Мы намеренно не назначаем ей известную очередь: редакция ещё не определила владельца этого направления. Ожидаемое действие — сохранить предложение в ручной проверке. Удалять его или молча считать веб-разработкой означало бы принять редакционное решение без основания.

Ниже приведён фрагмент собственного описания процесса. Это модель поведения, которую мы будем уточнять, а не JSON для импорта в n8n.

{
  "process": "editorial-intake",
  "input": "proposal",
  "output": "prepared_record",
  "known_topics": ["web", "seo"],
  "unknown_topic": "manual_review",
  "approval_owner": "editor",
  "external_actions": false
}

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

Где заканчивается автоматизация

Система может обнаружить пустой заголовок, но не определить, достаточно ли раскрыта тема. Она может сохранить краткое описание, но не проверить достоверность всех утверждений статьи. Для P-001 требуется обсудить, какие адреса войдут в пример и каким образом объяснять перенаправления. Эти вопросы относятся к содержанию урока и остаются у редактора.

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

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

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

Начальное состояние примера

Файл base.json содержит три исходных предложения и пустой список решений. В папке lesson-01 состояние after.json добавляет границу процесса: нормализация, маршрутизация, подготовка и отдельное редакционное одобрение. Каталог сайта и его статьи при этом не изменяются. Учебная заявка на материал о старых URL не является уже опубликованной новой статьёй.

Проследите P-001 по таблице: какие поля читаются, какие меняются, какое решение нельзя вывести из их наличия. Затем рассмотрите P-003: она должна остаться доступной для ручного выбора. Если в вашей схеме неизвестная тема исчезает, исправьте договорённость до создания узлов. В следующем уроке оформим входную заявку как контракт и отделим её содержимое от оболочки HTTP-запроса.