- Ключевые факты
- Почему одного HTTP 201 мне оказалось мало
- Моя финальная сверка: четыре независимых сигнала
- 1. У записи есть конкретный ID
- 2. Статус остался draft
- 3. В списке categories есть 73
- 4. featured_media совпадает с загруженной картинкой
- Что здесь всё ещё может сломаться
- Частые вопросы (FAQ)
- Почему нельзя доверять ответу POST-запроса?
- Зачем проверять draft, если он уже указан при создании?
- Почему журнал тем обновляется последним?
- Достаточно ли этих четырёх проверок для полной редакционной проверки?
- Итог
TL;DR: Сегодня я добавил в ежедневный AI-конвейер простое правило: ответ «пост создан» ещё не означает, что черновик готов. После записи я отдельно проверяю четыре вещи — ID поста, статус draft, нужную рубрику и ID обложки — и только после этого считаю запуск успешным.
Ключевые факты
| Что проверяю | Зачем | Источник |
|---|---|---|
| Созданный пост повторным GET-запросом | REST API возвращает запись как отдельный ресурс; повторное чтение показывает состояние, которое сохранил WordPress | WordPress REST API Reference |
Статус draft | У WordPress есть отдельные статусы записей; черновик не равен опубликованной записи | WordPress: get_post_statuses() |
| Рубрику и featured media | Категории и ID обложки передаются и хранятся как отдельные поля записи | Схема REST-записи WordPress |
| Загрузку изображения | Медиа создаётся отдельным запросом POST /wp/v2/media, поэтому успешный пост сам по себе не доказывает, что обложка прикреплена | WordPress Media endpoint |
Почему одного HTTP 201 мне оказалось мало
Раньше финал автоматизации выглядел слишком оптимистично: запрос вернул JSON с ID — значит, задача выполнена. На практике это проверяет только один шаг. Картинка могла загрузиться, а создание поста — упасть. Пост мог сохраниться, но попасть не в ту рубрику. Поле обложки могло остаться пустым. И самое неприятное: запись могла оказаться не в том статусе, который я ожидал.
Поэтому я перестал считать ответ на команду создания окончательной истиной. Теперь агент берёт ID из ответа и сразу читает этот же объект из WordPress заново с авторизацией. Это маленькая разница в коде, но большая разница в смысле: я проверяю не то, что попросил API сделать, а то, что сайт реально сохранил.
Моя финальная сверка: четыре независимых сигнала
1. У записи есть конкретный ID
ID — это не просто красивое число для лога. По нему я строю прямую ссылку в админку и выполняю контрольный запрос. Если ID нет, никакого «почти готово» не существует: запуск считается неуспешным.
2. Статус остался draft
Это главный предохранитель. Мой агент готовит материал, но не принимает редакционное решение за меня. Публикация и дальнейшая раздача контента относятся к отдельному процессу. Поэтому после создания я сравниваю фактическое поле status со строкой draft, а не надеюсь на отправленный параметр.
3. В списке categories есть 73
Для этой записи нужна рубрика «Дневник», её ID — 73. Я проверяю именно числовой ID в ответе WordPress. Заголовок или текст могут быть правильными, но без категории материал ломает структуру сайта и создаёт ручную уборку.
4. featured_media совпадает с загруженной картинкой
Сначала WordPress создаёт медиа и возвращает его ID. Затем этот ID передаётся в запись. На финальной проверке я сравниваю оба числа. Так я отличаю «картинка лежит в медиатеке» от «картинка действительно стала обложкой статьи».
Только когда все четыре условия выполнены, я добавляю тему в локальный журнал уже написанных материалов. Порядок важен: если записать тему раньше, неудачный запуск оставит фантомную отметку, и агент начнёт избегать статьи, которой в WordPress на самом деле нет.
Что здесь всё ещё может сломаться
Эта схема не делает систему безошибочной. После моей проверки другой процесс может изменить статус или отредактировать запись. Может истечь пароль приложения, измениться доступ к метаполям SEO-плагина или временно пропасть сеть. Но теперь каждая ошибка относится к конкретному этапу: загрузка медиа, создание поста или финальное чтение. Вместо общего «cron не сработал» у меня появляется проверяемая точка отказа.
Следующий шаг, который я хочу добавить, — короткий машинный отчёт с ожидаемым и фактическим значением каждого поля. Не просто «ошибка проверки», а, например: ожидалась рубрика 73, получена 1. Такой лог быстрее читать и человеку, и следующему агенту, который будет разбирать сбой.
Частые вопросы (FAQ)
Почему нельзя доверять ответу POST-запроса?
Ему можно доверять как ответу конкретной операции, но этого мало для проверки всего конвейера. Обложка, запись, категория и статус — разные части состояния. Повторный GET показывает итоговый объект, сохранённый WordPress.
Зачем проверять draft, если он уже указан при создании?
Потому что для меня запрет на автоматическую публикацию — не пожелание, а инвариант. Критичные поля лучше проверять по фактическому ответу сервера, даже если они были явно переданы в запросе.
Почему журнал тем обновляется последним?
Журнал служит памятью ротации. Если внести строку до успешного создания и проверки поста, несуществующая статья будет считаться написанной, а следующая попытка уйдёт в другую тему.
Достаточно ли этих четырёх проверок для полной редакционной проверки?
Нет. Они подтверждают техническую целостность черновика, но не качество текста, точность формулировок и уместность выводов. Редакторская проверка остаётся отдельным этапом.
Итог
Мой сегодняшний вывод простой: автоматизация должна подтверждать результат, а не только отсутствие исключения. Для ежедневного AI-блога минимальный контракт готовности теперь выглядит так: пост существует, он остаётся черновиком, находится в рубрике 73 и использует именно загруженную обложку. Лишь после этого я разрешаю процессу записать тему в историю и завершить запуск как успешный.
Автор: Denis | Дата: 11 ноября 2026 | Обновлено: 11 ноября 2026
Denis — трейдер с 10+ летним опытом на форексе и крипторынках
