- Ключевые факты
- Почему я остановил автоматизацию на черновике
- Четыре контрольные точки моего конвейера
- 1. Журнал тем до генерации
- 2. Источники до уверенного тона
- 3. Явная категория и отдельная обложка
- 4. Черновик как технический предохранитель
- Частые вопросы (FAQ)
- Почему не публиковать автоматически, если статья уже прошла проверки?
- Разве ручная проверка не отменяет смысл автоматизации?
- Что произойдёт, если WordPress вернёт не статус draft?
- Можно ли полностью исключить ошибки?
- Итог
TL;DR: Я сознательно не даю AI-агенту публиковать статьи на denisvk.ru напрямую: его работа заканчивается черновиком в WordPress. Перед этим пайплайн проверяет ротацию тем, назначает рубрику, загружает отдельную обложку и убеждается, что API действительно вернул статус draft. Это не недоверие к ИИ, а нормальная граница ответственности: генерацию можно автоматизировать, окончательное редакционное решение — нет.
Ключевые факты
| Факт | Как это устроено у меня | Источник |
|---|---|---|
| WordPress REST API позволяет явно передать статус записи | Агент отправляет status: "draft", а после создания ещё раз проверяет статус в ответе API | WordPress REST API: Posts |
| Категории задаются массивом идентификаторов | Для дневника передаётся categories: [73]; это защищает от случайного попадания в «Без рубрики» | WordPress: аргумент categories |
| Обложка сначала создаётся как отдельный media-объект | Файл загружается через endpoint медиа, затем его ID передаётся в поле featured_media записи | WordPress REST API: Media |
WordPress принимает ID изображения в поле featured_media | Запись и картинка связываются явно, а не по имени файла или последней загрузке | WordPress: поле featured_media |
Почему я остановил автоматизацию на черновике
Самая опасная часть контент-автоматизации — не генерация текста. Опасно разрешить системе после удачного HTTP-запроса считать материал готовым для читателя. Модель может написать связный текст с неверной датой, повторить старую тему, поставить материал не в ту рубрику или уверенно сформулировать то, чего я никогда не делал.
Поэтому мой ежедневный агент не имеет права принимать финальное редакционное решение. Он собирает пакет: заголовок, HTML статьи, SEO-поля, обложку и категорию. WordPress получает этот пакет только со статусом draft. Если ответ API неожиданно содержит другой статус, скрипт должен завершиться ошибкой, а не сделать вид, что всё прошло нормально.
Есть ещё практическая причина. В дневниковой рубрике я пишу от первого лица, и здесь цена выдуманной конкретики выше, чем в обычной инструкции. Если в файлах и логах нет подтверждения цифре, сбою или результату, агент не должен превращать догадку в мой «личный опыт». Сегодняшняя статья, например, опирается на реально существующие части конвейера: журнал тем, WordPress REST API, генератор обложки и проверку статуса созданной записи.
Четыре контрольные точки моего конвейера
1. Журнал тем до генерации
Перед выбором темы агент читает covered-topics.log. Это простой текстовый журнал, но он решает две задачи: показывает последнюю рубрику для ротации A → B → C → D → E и не даёт незаметно повторить уже написанное. Если ориентироваться только на память модели, дубли неизбежны.
2. Источники до уверенного тона
Если статья касается цены, даты, регуляторики или новости, сначала нужен сетевой поиск. Для build-in-public действует ещё более жёсткое правило: личная деталь должна подтверждаться локальным скриптом, журналом или фактическим результатом запуска. Если подтверждения нет, я предпочитаю честно описать устройство процесса без красивой выдуманной истории.
3. Явная категория и отдельная обложка
WordPress не обязан угадывать мою рубрику. ID категории передаётся в запросе явно. То же самое с обложкой: сначала создаётся media-объект, потом его числовой ID связывается с записью. После генерации на изображение локально добавляется подпись denisvk.ru и эмблема — этот шаг не зависит от того, насколько удачно модель нарисовала сцену.
4. Черновик как технический предохранитель
Статус draft — не декоративное поле, а граница между машинной подготовкой и публикацией. Я могу открыть запись в админке, проверить заголовок, ссылки, тон, HTML и только потом принять решение. Автоматизация экономит рутину, но не забирает у меня ответственность за то, что увидит читатель.
Частые вопросы (FAQ)
Почему не публиковать автоматически, если статья уже прошла проверки?
Потому что техническая валидность не равна редакционной готовности. Корректный HTML, категория и три источника не гарантируют точность всех формулировок и соответствие моему реальному опыту.
Разве ручная проверка не отменяет смысл автоматизации?
Нет. Агент снимает большую часть механической работы: выбирает тему по ротации, готовит структуру, собирает источники, генерирует обложку, загружает медиа и создаёт оформленный черновик. Мне остаётся контроль решения, а не сборка материала с пустого листа.
Что произойдёт, если WordPress вернёт не статус draft?
В текущей логике это считается ошибкой. Скрипт не должен молча дописывать тему в журнал и сообщать об успехе, если фактический статус записи не совпал с ожидаемым.
Можно ли полностью исключить ошибки?
Нет. Проверки уменьшают вероятность отдельных классов ошибок, но не доказывают истинность всей статьи. Поэтому последний шаг остаётся человеческим: прочитать материал в контексте, а не только проверить поля API.
Итог
Мой рабочий результат от AI-агента — не опубликованная статья, а аккуратно собранный черновик, который легко проверить. Журнал тем защищает от повторов, источники — от части фактических ошибок, явная категория и media ID — от технического мусора, а статус draft оставляет финальное решение за мной. Именно такой уровень автономности сейчас выглядит для блога полезным и честным.
Автор: Denis | Дата: 22 августа 2026 | Обновлено: 22 августа 2026
Denis — трейдер с 10+ летним опытом на форексе и крипторынках
