Как 72 строки журнала тем стали памятью моего AI-блога

TL;DR: У моего AI-блога нет надежной «памяти» внутри самой модели: перед каждым новым черновиком она читает отдельный журнал тем. Сегодня в нем 72 записи, и именно этот простой файл помогает мне продолжать ротацию рубрик A → B → C → D → E и не выдавать старую идею за новую. Но журнал решает только половину задачи — после создания я все равно проверяю статус, категорию и обложку уже в WordPress.

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

Факт	Что это значит для моего процесса	Источник
До сегодняшнего запуска в локальном журнале было 72 строки	Новый агент видит историю тем между независимыми запусками и может выбрать следующую рубрику после последней записи	Мой локальный covered-topics.log, проверено 2 сентября 2026 года
WordPress принимает draft как отдельный статус поста	Я явно передаю статус черновика и затем читаю созданную запись обратно, чтобы убедиться, что она не опубликована	WordPress REST API: Posts
Категории и ID обложки — отдельные поля записи	Правильная тема в тексте еще не гарантирует правильную рубрику или featured image: эти поля нужно отправить и проверить отдельно	Схема записи WordPress
Изображение сначала создается как media item через POST /wp/v2/media	Только после загрузки обложки я получаю ее ID и связываю его с черновиком	WordPress REST API: Media
Application Password предназначен для программного доступа и может быть отозван отдельно	Скрипту не нужен мой основной пароль от панели; запросы идут по HTTPS с отдельным ключом приложения	WordPress: Application Passwords

Что сломалось, когда я полагался только на инструкцию

Идея была простой: каждый день брать следующую рубрику по кругу. На бумаге этого достаточно. На практике независимый запуск AI-агента не обязан помнить, что было вчера, а длинная инструкция не сообщает ему результат предыдущего запуска.

Это видно в моей же истории. В начале августа последовательность сбилась: после B шла A, затем снова B, потом снова A. Позже рядом появлялись две записи D и две E. Сами статьи от этого не стали плохими, но правило ротации уже не выполнялось. Я получил хороший пример того, что промпт описывает желаемое поведение, а состояние системы должно храниться отдельно.

Таким состоянием стал covered-topics.log. Каждая строка содержит дату, букву рубрики и короткое название. Перед работой агент читает последние записи, определяет последнюю букву и ищет следующую тему. Сегодня последней была D, поэтому я пишу в E — дневник. Одновременно весь список работает как простой стоп-лист от повторов.

Как сейчас устроена защита от повторов

1. Сначала история, потом идея

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

2. Ротация и уникальность проверяются раздельно

Ротация отвечает на вопрос «какая рубрика следующая?», а журнал — «писал ли я это уже?». Если объединить эти проверки в одну, агент легко выберет правильную букву, но повторит старый сюжет. Для рубрики B есть еще один уровень: внутри нее чередуются вложение небольшой суммы, обычный офлайн-бизнес и онлайн-подработка.

3. Строка в журнале появляется только после готового результата

Мой запуск измеряет число строк до начала и считает работу успешной, только если после нее строк стало больше. Предусмотрены две попытки. Это примитивный, но понятный сигнал: если тема не записана, следующий запуск не должен молча считать сегодняшний цикл завершенным.

При этом я вижу ограничение: новая строка еще не доказывает, что WordPress принял правильную категорию и оставил запись черновиком. Поэтому после API-запроса я читаю пост обратно и сравниваю три поля: status, categories и featured_media. Лог — память контента, ответ WordPress — подтверждение доставки.

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

Почему не хранить историю прямо в промпте?

Часть старых тем действительно перечислена в основной инструкции, но такой список быстро разрастается и требует ручного обновления. Отдельный журнал проще дополнять автоматически, читать перед запуском и проверять обычными инструментами.

72 строки гарантируют отсутствие смысловых дублей?

Нет. Журнал ловит точные и очевидные повторы, но близкие по смыслу темы все равно требуют редакторского решения. Это одна из причин, почему я не включаю автоматическую публикацию: AI готовит черновик, а не принимает окончательное решение за меня.

Почему простой текстовый файл, а не база данных?

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

Что произойдет, если WordPress вернет не ту категорию?

Проверка после создания должна завершить запуск ошибкой, а не объявить успех. Это не исправляет проблему автоматически, зато не прячет ее. Для меня наблюдаемая ошибка лучше, чем тихо созданный пост в «Без рубрики».

Итог

Главный урок этого этапа: AI-агенту недостаточно хорошей инструкции — ему нужна внешняя память и проверяемый результат. Мой журнал из 72 строк уже решает практическую задачу ротации и повторов, а обратная проверка WordPress закрывает статус, рубрику и обложку. Следующий шаг, который я считаю разумным, — добавить нормализованный тематический ключ, чтобы ловить не только одинаковые заголовки, но и близкие по смыслу сюжеты. Без автопубликации: финальное «да» статье по-прежнему должен давать человек.

---

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