Чтобы настроить Make AI для Дзена, соберите не один длинный сценарий, а управляемый конвейер из пяти этапов: очередь тем, генерация черновика, автоматическая проверка, ручное согласование и публикация. Make должен передавать данные между этапами и хранить статусы, AI — готовить текст по строгому заданию, а редактор — принимать финальное решение. Начинать с полной автопубликации рискованно: сначала добейтесь повторяемого качества черновиков и защиты от дублей.
Если в вашем аккаунте Make нет официально поддерживаемого способа отправки материала в Дзен, оставьте последний шаг ручным. Это не ломает автоматизацию: сценарий всё равно сокращает работу с брифом, генерацией, проверками и передачей готового материала редактору. Подключать публикацию стоит только через актуальный документированный интерфейс с понятными правами доступа.
Короткая схема: новая тема получает уникальный идентификатор, проходит генерацию и проверки, меняет статус на approved после решения редактора и лишь затем попадает в канал публикации.
Краткие выводы
- Разделяйте генерацию и публикацию: статус draft не должен автоматически означать approved.
- Храните единый job_id, версию брифа и внешний идентификатор публикации — это защищает от повторной отправки.
- Проверяйте не только наличие текста, но и структуру, ссылки, запретные теги, метаданные и смысловые дубли.
- Ограничивайте число автоматических исправлений и повторов после ошибок.
- Оставляйте ручной финальный шаг, если поддерживаемый канал публикации не подтверждён документацией.
Содержание
- Что автоматизировать
- Архитектура сценария
- Пошаговая настройка
- Защита от сбоев и дублей
- Чек-лист перед запуском
- Типичные ошибки
- FAQ
Что автоматизировать, а что оставить человеку
Удобно разделить процесс на три слоя. Первый слой — редакционный: тема, основной запрос, аудитория, поисковый интент, уникальный угол и ограничения. Второй — производственный: генерация, форматирование, проверка обязательных блоков и подготовка метаданных. Третий — публикационный: согласование, отправка в канал, проверка результата и сохранение URL.
Make отвечает за оркестрацию: получает событие, вызывает нужные сервисы, ветвит поток и записывает статус. Сценарий можно запускать по расписанию или через вебхук Make, когда новая тема добавлена во внутреннюю очередь. Для небольшой команды вебхук удобен тем, что одна запись запускает только одну задачу, а не повторный обход всей таблицы.
Человеку стоит оставить проверку фактов, соответствия голосу бренда, спорных формулировок и итоговое одобрение. Практичную схему ролей и статусов можно сверить с материалом о редакционном процессе SEO-статей.
Архитектура сценария Make
До добавления модулей определите контракт данных. Одна задача должна проходить весь маршрут без переименования полей. Минимальный набор: job_id, topic, primary_query, secondary_queries, audience, intent, angle, brief_version, status, draft_html, seo_title, meta_description, sources, reviewer_comment, publication_id, publication_url, created_at и updated_at.
Статусы лучше ограничить фиксированным списком: queued, generating, needs_review, approved, publishing, published, rejected и error. Тогда фильтры сценария не зависят от свободного текста вроде «почти готово». Текущее состояние можно держать в рабочей базе, таблице или Data Store Make, который хранит данные между запусками сценария.
| Этап | Вход | Результат | Условие остановки |
|---|---|---|---|
| Очередь | Тема и бриф | job_id, queued | Тема уже существует |
| Генерация | Валидный бриф | Черновик и метаданные | Ответ пустой или повреждён |
| Проверка | Черновик | needs_review либо error | Критическое правило не пройдено |
| Согласование | Проверенный материал | approved либо rejected | Нет решения редактора |
| Публикация | Только approved | published, URL и внешний ID | Канал недоступен или запись уже создана |
Пошаговая настройка Make AI для Дзена
1. Создайте очередь и уникальный ключ
Источником может быть таблица, CRM или внутренняя база. Для каждой темы формируйте job_id один раз. Не используйте только название: редактор может его изменить. Перед созданием задачи ищите совпадение по job_id, а дополнительно — по основному запросу, интенту и нормализованному заголовку.
Запись со статусом published нельзя отправлять повторно. Запись в error можно повторить только после проверки типа ошибки и увеличения счётчика попыток. Это простое правило защищает от дублей при повторном вебхуке или ручном перезапуске сценария.
2. Проверяйте бриф до обращения к AI
Обязательные поля брифа: основной запрос, от двух до пяти вторичных запросов, dominant search intent, аудитория, уникальный угол, ожидаемая структура и один целевой призыв к действию. Если хотя бы одно обязательное поле пустое, Make должен вернуть задачу в очередь с понятной причиной, а не просить модель самостоятельно додумывать цель.
В промпте отделяйте факты от инструкций. Укажите допустимые HTML-теги, запрет на H1, минимальный объём, требования к FAQ и ссылкам. Отдельно потребуйте не придумывать статистику, кейсы, цитаты и возможности продукта.
3. Вызовите сервис генерации через HTTP
Для API-запроса используйте HTTP-модуль Make: передайте бриф как структурированный JSON и запросите структурированный ответ. Если генерацию выполняет SerpJet, ориентируйтесь на документацию внешнего API SerpJet. Ключ доступа храните в защищённом подключении Make, а не в ячейке таблицы или тексте сценария.
В ответе полезно ожидать отдельные поля content, title, seo_title, description, meta_description и keywords. Такое разделение проще валидировать, чем один большой текст. Сохраняйте исходный ответ и номер версии, чтобы редактор понимал, что именно было проверено.
4. Добавьте автоматический контроль качества
После генерации проверьте базовые технические условия: текст не пустой, длина выше установленного минимума, H1 отсутствует, запрещённых тегов нет, заголовок и метаописание попадают в заданные диапазоны, ссылки имеют допустимые протоколы. Затем проверьте смысловые условия: интент закрыт, прямой ответ находится в начале, есть практические шаги, ошибки, FAQ и вывод.
Для развилки используйте Router и фильтры Make. Ветка valid_draft переводит задачу в needs_review. Ветка fixable отправляет ровно один запрос на исправление конкретных нарушений. Ветка blocked сохраняет причину и останавливает задачу. Бесконечный цикл «перепиши ещё раз» скрывает проблемы и расходует ресурсы.
5. Организуйте ручное согласование
Редактор должен видеть черновик, бриф, список источников и результаты проверок. Решение фиксируется явно: approved, rejected или needs_changes. Комментарий обязателен для отклонения и доработки. Make продолжает публикационную ветку только после перехода в approved.
После одобрения заморозьте версию текста. Если контент меняется, статус возвращается в needs_review. Перед отправкой полезно пройти технический чек-лист публикации: заголовок, canonical, robots, ссылки и структурированные данные нужно контролировать отдельно от качества текста.
6. Подключите публикацию без предположений
Не стройте сценарий вокруг несуществующего коннектора. Сначала проверьте актуальный каталог приложений Make и документацию доступного вам канала Дзена. Если документированного способа с нужными правами нет, Make создаёт финальный пакет: HTML, заголовок, описание и заметку редактору, а публикация выполняется вручную.
Если официальный поддерживаемый интерфейс доступен, вынесите отправку в отдельный сценарий. Он должен принимать только approved, перед созданием искать сохранённый publication_id и после успеха записывать внешний ID, URL и время. Так смена канала публикации не затронет генерацию и редакционную проверку.
Как защитить сценарий от сбоев и дублей
Идемпотентность означает, что повторный запуск с тем же job_id не создаёт вторую публикацию. Перед каждым необратимым шагом сценарий читает текущее состояние. Если publication_id уже заполнен, задача завершается без отправки. Если статус не approved, публикационный модуль вообще не запускается.
Разделяйте временные и постоянные ошибки. Для ограничения запросов или краткой недоступности сервиса допустимы несколько повторов с паузой. Ошибка авторизации, неверный формат ответа или отсутствие обязательного поля требуют остановки. В Make для этого предусмотрены обработчики ошибок и неполные выполнения.
- Для пустого ответа: один повтор, затем error.
- Для невалидной структуры: одна адресная доработка, затем needs_review или error.
- Для ошибки доступа: немедленная остановка и уведомление ответственного.
- Для повторного вебхука: поиск job_id и возврат текущего статуса без новой генерации.
- Для сбоя после отправки: сначала поиск внешнего ID, только затем решение о повторе.
Чек-лист перед включением расписания
| Проверка | Ожидаемое поведение |
|---|---|
| Один и тот же job_id приходит дважды | Вторая задача не создаётся |
| В брифе нет основного запроса | Генерация не запускается |
| API генерации отвечает ошибкой | Срабатывает ограниченный повтор и журналирование |
| В HTML есть H1 или запрещённый тег | Черновик блокируется до исправления |
| Найдена близкая статья с тем же интентом | Задача уходит на решение редактора |
| Редактор выбрал rejected | Публикационная ветка недоступна |
| Внешний publication_id уже сохранён | Повторная отправка не выполняется |
| Поддерживаемый канал Дзена недоступен | Создаётся пакет для ручной публикации |
Типичные ошибки
- Сразу включать расписание. Сначала прогоните несколько задач вручную и проверьте каждую ветку.
- Считать generated равным approved. Генерация завершает только производственный этап.
- Хранить секреты в таблице. Токены должны находиться в защищённых подключениях.
- Не сохранять версию брифа. Тогда невозможно понять, по каким требованиям создан черновик.
- Повторять запрос бесконечно. Ограничивайте попытки и различайте типы ошибок.
- Проверять только непустой текст. Нужны технические, смысловые и редакционные правила.
FAQ
Можно ли публиковать в Дзен напрямую из Make?
Только если в вашем текущем окружении есть документированный поддерживаемый способ с необходимыми правами. Если он не подтверждён, оставьте финальный шаг ручным и не имитируйте интеграцию через нестабильные обходные решения.
Нужны ли AI Agents для такого сценария?
Нет. Для первой версии достаточно обычного сценария Make, HTTP-запроса к сервису генерации, фиксированного контракта данных и детерминированных проверок. Агентный подход нужен лишь там, где действительно требуется выбор инструментов и сложное ветвление.
Как не допустить повторной публикации?
Используйте неизменяемый job_id, сохраняйте publication_id и URL, а перед отправкой проверяйте оба поля. Дополнительно сравнивайте основной запрос, интент и нормализованный заголовок с уже опубликованными материалами.
Где хранить статус задачи?
В Data Store Make, рабочей таблице или базе вашего проекта. Важно не место, а единый источник истины: все сценарии должны читать и изменять один и тот же статус по одному job_id.
Какую роль может выполнять SerpJet?
SerpJet может готовить SEO-черновик и метаданные, а Make — управлять очередью, статусами и передачей результата редактору. Подход к связке систем разобран в статье про API-генерацию SEO-статей для агентства.
Заключение
Надёжная автоматизация Дзена начинается не с кнопки «опубликовать», а с прозрачных статусов, единого идентификатора и редакционного шлюза. Соберите минимальный маршрут queued → generating → needs_review → approved → published, протестируйте ошибки и только потом добавляйте расписание. Чтобы вынести генерацию SEO-черновиков и метаданных в отдельный управляемый сервис, попробуйте SerpJet и подключите результат к вашему сценарию Make.