Одна цифра в API: почему я явно задаю рубрику каждому AI-черновику

TL;DR: Сегодняшний черновик попал в рубрику «Дневник» не потому, что WordPress понял смысл текста, а потому, что мой агент явно передал categories: [73]. Одна пропущенная цифра превращает рабочую автоматизацию в источник ручной уборки, поэтому теперь категория — обязательная часть проверки, а журнал тем обновляется только после успешного создания черновика.

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

Факт	Что это значит для моего процесса	Источник
Записи создаются через POST /wp/v2/posts, а рубрики передаются в поле categories.	Агент должен отправить ID рубрики явно; одного правильного заголовка недостаточно.	WordPress: Posts REST API
WordPress различает статусы draft и publish.	В запросе я фиксирую status: draft: решение о публикации не принимает генератор статьи.	WordPress: статусы записей
Обложка сначала загружается отдельным запросом POST /wp/v2/media.	Полученный ID передаётся в featured_media; текст и картинка связываются уже при создании записи.	WordPress: Media REST API
В моём локальном журнале до сегодняшнего запуска было 97 тем; последняя строка имела метку D.	По ротации A → B → C → D → E следующей стала рубрика E, а не тема, выбранная «по настроению» модели.	Локальный файл covered-topics.log, проверен 27 сентября 2026 года

Ошибка, которая выглядит слишком мелкой, чтобы быть опасной

У меня пять настоящих рубрик WordPress. У каждой есть не только название, но и числовой ID: «Трейдинг» — 30, «Бизнес-идеи» — 61, «ИИ» — 62, «Мои проекты» — 72, «Дневник» — 73. Человек в админке видит слова. API ждёт точное поле и точное число.

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

Я больше не считаю ответ «запись создана» достаточным. Для меня успех — это черновик с нужным статусом, нужной рубрикой и нужной обложкой. Сегодня правильный фрагмент запроса выглядит по смыслу так:

{
  "status": "draft",
  "categories": [73],
  "featured_media": 12345
}

ID обложки здесь приведён только как пример. А вот 73 — реальный ID «Дневника» на моём сайте.

Как я связал ротацию тем с WordPress

1. Сначала читаю память, потом пишу

Перед генерацией агент читает covered-topics.log. Сегодня в нём было 97 строк, а последняя запись за 26 сентября относилась к D — материалу о сбое генерации Cheburek FM. Следующий слот по правилу ротации — E. Это простая логика, но она не даёт блогу превратиться в бесконечную ленту одной любимой темы.

Отдельно проверяется смысловой дубль. В «Дневнике» уже были тексты о памяти из журнала, ремонте ротации, резервной цепочке обложек и проверке фактов до написания. Поэтому сегодня я не пересказываю устройство журнала ещё раз, а разбираю следующий конкретный узел — соответствие выбранной рубрики полю в API.

2. Название рубрики преобразуется в ID

После выбора E агент не отправляет в WordPress букву E и не просит CMS угадать категорию по тексту. Он использует заранее заданное соответствие: E → 73. Это скучная часть системы, и именно поэтому она надёжнее творческой догадки.

3. Черновик остаётся черновиком

Я сознательно разделяю создание контента и публикацию. Контент-агент формирует материал, добавляет SEO-поля, связывает обложку и сохраняет запись со статусом draft. Он не публикует статью и не отправляет её в Telegram или соцсети. Это отдельная граница ответственности: генератор не должен сам себе выдавать разрешение на публикацию.

4. Журнал обновляется последним

Если записать тему в локальную память до ответа WordPress, а запрос затем упадёт, журнал будет утверждать, что статья уже существует. На следующем запуске агент пропустит тему, хотя черновика нет. Поэтому правильный порядок для меня такой: выбрать тему → создать обложку → загрузить медиа → создать и проверить черновик → только после этого дописать строку в журнал.

Это не делает систему неуязвимой. Например, сеть может оборваться после того, как WordPress создал запись, но до того, как клиент получил ответ. Для полной защиты понадобится ключ идемпотентности или проверка по уникальному служебному признаку. Пока мой практический минимум — не отмечать работу выполненной заранее и сохранять ID полученного поста.

Что сработало, а что пока остаётся слабым местом

Сработало: явная карта рубрик убрала неоднозначность между редакционной буквой и WordPress-категорией. Ротация определяется до написания, а статус draft задаётся в том же запросе, где передаётся категория.

Остаётся слабым местом: локальный журнал — обычный текстовый файл. Он удобен, прозрачен и легко проверяется глазами, но сам по себе не является транзакцией с WordPress. Если процесс прервётся в неудачный момент, локальное и удалённое состояния могут разойтись. Следующий уровень надёжности — сверять последний сохранённый post ID и фактические поля записи через REST API перед тем, как считать запуск завершённым.

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

Почему не определять рубрику автоматически по тексту?

Потому что сегодня рубрика уже известна из редакционной ротации. Классификатор добавил бы вероятность ошибки там, где достаточно точного соответствия «E → 73».

Что произойдёт, если не передать categories?

Запись может оказаться в категории по умолчанию, часто это «Без рубрики». Сам текст при этом будет создан, поэтому поверхностная проверка успешного HTTP-ответа не заметит редакционную ошибку.

Почему агент не публикует статью сразу?

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

Зачем хранить журнал, если темы уже есть в WordPress?

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

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

Нет. Правильный заголовок не доказывает, что установлены категория, статус и обложка. Проверять нужно поля, которые важны для готовности черновика.

Итог

Главный урок сегодняшнего запуска простой: в автоматизации контента качество живёт не только в тексте. Поле categories: [73] занимает несколько символов, но именно оно сохраняет структуру блога. Поэтому я считаю задачу завершённой только тогда, когда WordPress вернул настоящий черновик с правильной рубрикой и обложкой, а локальный журнал обновлён уже после этого.

---

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