Как я построил резервную цепочку для AI-обложек блога — build-in-public

TL;DR: Сегодня я прогнал реальную цепочку обложки для этого блога: отдельная AI-задача, ожидание результата, скачивание JPEG, watermark, загрузка в медиатеку и только потом создание черновика WordPress. Основная генерация сработала на четвёртой проверке статуса; резервный источник не понадобился, но именно его наличие не даёт временной ошибке внешнего сервиса остановить весь выпуск.

Ключевые факты

Факт	Что это значит в моей схеме	Источник
Kie AI принимает Nano Banana Pro через POST /api/v1/jobs/createTask и возвращает идентификатор задачи	Генерация асинхронная: после отправки нельзя считать, что файл уже готов	Документация Kie AI
Kie AI рекомендует callback для production вместо постоянного опроса	Мой текущий cron пока опрашивает статус, но следующий технический шаг — нормальный callback с проверкой ответа	Документация Kie AI
WordPress создаёт изображение отдельным запросом POST /wp/v2/media	Сначала я получаю media ID и только затем передаю его посту как обложку	WordPress REST API: Media
У поста есть отдельные поля для статуса, рубрик и featured media	Я явно отправляю draft, категорию «Дневник» и ID загруженной картинки	WordPress REST API: Posts

Почему я разделил картинку и статью

На бумаге хочется сделать один большой сценарий: ИИ написал текст, нарисовал обложку, WordPress всё принял — готово. На практике это несколько независимых систем. У генератора картинок может закончиться очередь, ссылка на результат может появиться не сразу, скачивание может оборваться, а WordPress может принять файл, но отклонить поля поста.

Поэтому для меня «создать статью» — не одна операция. Сначала появляется локальный файл обложки. Я проверяю, что это действительно JPEG, накладываю watermark и лишь затем отправляю файл в медиатеку. WordPress возвращает числовой media ID. Только после этого создаётся сам пост с featured_media, categories: [73] и жёстко заданным status: draft.

Это кажется лишней бюрократией, пока что-нибудь не ломается. Зато при ошибке я понимаю, где она произошла: генерация, скачивание, обработка изображения, медиатека или создание поста. У каждой стадии есть проверяемый результат, а не одно расплывчатое «cron не сработал».

Что показал сегодняшний прогон

Основной маршрут

22 сентября 2026 года я отправил тематический англоязычный промпт в Nano Banana Pro с форматом 16:9, разрешением 1K и выходом в JPEG. Первые три проверки вернули состояние ожидания, четвёртая — успех. После этого сценарий скачал изображение и применил watermark. Резервная генерация сегодня не запускалась.

Важная деталь: четыре проверки — это не обещание скорости сервиса. Это только результат одного сегодняшнего запуска. Завтра очередь может пройти быстрее, медленнее или вернуть ошибку. Именно поэтому я не зашиваю в логику предположение «картинка всегда готова через 30 секунд».

Резервный маршрут

Если основной сервис не возвращает URL результата, сценарий пытается получить изображение из резервного источника с тем же промптом. Это не гарантия одинакового визуального стиля: разные модели интерпретируют описание по-разному. Для меня fallback решает более узкую задачу — не оставлять выпуск без обложки из-за временной недоступности одного API.

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

Что я ещё хочу улучшить

Текущая схема рабочая, но не идеальная. Опрос каждые 10 секунд прост, зато делает лишние запросы. Документация Kie AI предлагает callback для production — это разумнее, но callback тоже нельзя принимать вслепую: нужно валидировать пришедшие данные и не позволять внешнему запросу самостоятельно публиковать запись.

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

Частые вопросы (FAQ)

Почему не отправлять URL картинки прямо в WordPress?

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

Зачем нужен fallback, если Nano Banana Pro обычно отвечает?

Автоматизация проектируется не под «обычно», а под предсказуемое поведение при ошибке. Резервный источник не делает картинку идентичной, но позволяет сценарию завершить черновик и оставить человеку возможность заменить обложку до публикации.

Почему пост всё равно остаётся черновиком?

Потому что успешный HTTP-ответ не равен редакторскому качеству. Нужно проверить смысл текста, источники, рубрику, SEO-поля и визуальный результат. Статус draft отделяет техническое создание материала от решения о публикации.

Можно ли полностью убрать ручную проверку?

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

Итог

Главный урок сегодняшнего прогона: надёжность даёт не конкретная нейросеть, а раздельные этапы и явные проверки между ними. Основная генерация сегодня сработала, fallback не использовался, изображение прошло обработку и было загружено отдельно. Но пост всё равно создаётся только как черновик — именно это не позволяет красивой автоматизации превратиться в автоматическую ошибку на сайте.

---

Автор: Denis | Дата: 22 сентября 2026 | Обновлено: 22 сентября 2026
Denis — трейдер с 10+ летним опытом на форексе и крипторынках