Статья появляется на сайте: заголовок на месте, обложка прикручена, запись уже видна в ленте. Никто не копировал абзацы из одного окна в другое, не искал картинку в загрузках и не открывал админку, чтобы нажать «Опубликовать». Именно это и стоит посчитать — не число «агентов» в схеме и не красоту стрелок на диаграмме, а список действий, которых больше нет.
Оговорка, без которой весь дальнейший счёт превратится в рекламный слайд: «перестали публиковать руками» не значит, что человека в процессе не осталось. В штатном сценарии нет ручной сборки и размещения материала, но тема, рамка, спорные места, разбор странных ошибок и развитие системы по-прежнему за людьми. Дальше речь о том, где проходит эта граница.
Восемь этапов — это не восемь действий
В схеме восемь крупных этапов: контент-план, генерация, редактура, фактчек, обложка, публикационный слой, WordPress и RSS. Соблазн посчитать это восемью удалёнными действиями велик, но он неправильный. Этап — это функция, а действие — это клик, копирование, переход между вкладками или ручная сверка. Внутри одного этапа таких действий может оказаться десяток.
Считать нужно иначе: выписать маршрут одной статьи до автоматизации, потом после — и отметить, что именно исчезло. Это типовая методика аудита, а не подтверждённая карта конкретного проекта. В обычном ручном маршруте до автоматизации цепочка выглядит так: выбрать тему, перенести её в задание, открыть генератор, вставить запрос, скопировать текст, открыть редактор, поправить, проверить факты, найти картинку, загрузить её, открыть WordPress, создать запись, вставить заголовок и текст, назначить рубрики и теги, поставить обложку, выбрать дату, нажать публикацию, проверить страницу и ленту. В автоматизированном сценарии, если он построен по такой логике, в списке остаётся немного: подтвердить план или исключение, посмотреть результат контрольных проверок, вмешаться, если что-то пошло не так.
Вот это и есть честный способ считать: не абстрактные «сто штук», а конкретные типы операций — перенос текста, перенос метаданных, ручная загрузка файла, создание записи через админку, нажатие кнопки публикации, проверка того, что материал доехал до ленты. Каждый пункт когда-то был отдельным источником ошибок. Точную цифру в кликах или минутах назвать нельзя: для неё нужен журнал замеров с периодом наблюдения и количеством статей, а без него любое число будет декоративным. Название Auto-Dzen в этой статье используется только как обозначение конвейера из брифа. Точный статус системы и её внутреннее устройство здесь не утверждаются.
План и генерация: машина перекладывает, человек решает
Первый заметный кусок работы, который исчез, — это перекладывание. Тема превращается в задание, задание — в структуру, структура — в черновик. Раньше между этими состояниями были ручные прыжки: скопировать, вставить, поправить формулировку запроса, снова скопировать. Теперь маршрут идёт внутри конвейера, и человек в него не залезает без причины.
Именно здесь важно не переоценить результат. Структурированный ответ модели снижает число ошибок формата: если задать схему, ответ разложится по нужным полям, и парсер не упадёт на очередной лишней запятой. К содержанию это отношения не имеет. Модель может выдать безупречно оформленный JSON с сомнительным утверждением внутри, и никакая схема этого не поймает. У успешного завершения есть и другие условия: модель может отказаться, ответ может оборваться, схема может не подойти, и такие пограничные случаи всё равно нужно обрабатывать отдельно. Поэтому генерация — не финиш, а начало проверок.
Человеку на этом этапе остаётся то, что плохо формализуется: выбрать тему, определить рамку, решить, стоит ли материал выпускать вообще. Машина хорошо перекладывает и оформляет. Решение о том, что именно стоит говорить, она за нас не принимает.
Редактура и фактчек — разные работы
Их часто смешивают в одну «проверку текста», хотя задачи совершенно разные. Редактура — это тон, ритм, структура, вычистка клише и повторов. Фактчек — сверка дат, названий, версий, цифр и характеристик. Первое частично автоматизируется по формальным признакам, второе — только с оговорками.
Автоматизация ускоряет поиск и сопоставление, помогает расставить флаги на сомнительных местах. Гарантии достоверности она не даёт и дать не может: формально правильный ответ модели — это не проверенный факт, а аккуратно упакованное утверждение, которое ещё нужно сверить. Поэтому разумное правило для такого процесса: спорный материал не уезжает в публикацию, а возвращается человеку. Решение не изящное, зато работает.
Обложка: снаружи одна кнопка, внутри цепочка
Обложка — лучший пример того, как один видимый шаг прячет за собой несколько операций. Для человека это «поставить картинку». Внутри — получить изображение, проверить формат и размер, загрузить файл отдельным запросом, дождаться идентификатора медиаобъекта, передать этот идентификатор в поле обложки записи и убедиться, что картинка прикрепилась к нужному материалу.
Технически в WordPress это два разных маршрута: загрузка медиафайла и создание записи, у которой поле featured_media содержит идентификатор изображения. То есть «поставить обложку» — минимум два запроса и один переход состояния между ними. На каждом переходе что-то может пойти не так: файл не загрузится, загрузка пройдёт, а идентификатор вернётся не тот, запись создастся, а картинка прикрепится к другой статье.
Поэтому автоматизация обложки — не косметика, а отдельный мини-конвейер с собственной логикой проверок. И именно такие места лучше всего показывают цену автоматизации: снаружи стало проще, внутри стало больше кода, который нужно обслуживать.
Публикационный слой, WordPress и RSS — три разные задачи
Их удобно воспринимать как одну большую кнопку «выпустить», но задач здесь три. Публикационный слой — это этап подготовки и выпуска, который в брифе назван Publication. Что именно под ним понимается в конкретной реализации, бриф не расшифровывает; в статье речь о самой функции выпуска, а не об отдельном продукте.
WordPress принимает запись через API. Через POST /wp/v2/posts можно передать заголовок, текст, автора, краткое описание, рубрики, теги и другие параметры, а статус определить как черновик, отложенную публикацию или сразу опубликованную запись. Это снимает необходимость открывать админку и вставлять текст в поля руками, но требует, чтобы все данные были собраны заранее и в правильном виде. API не догадается, что вы имели в виду.
RSS в этой цепочке ничего не создаёт и не публикует. Это формат передачи уже готового контента дальше: WordPress по умолчанию генерирует несколько типов лент, включая RSS 2.0, и материал может уехать по цепочке без участия человека. Полезно держать это в голове, чтобы не приписывать ленте функции, которых у неё нет. Она транспорт, а не автор.
Где конвейер ломается
Самая полезная часть разговора об автоматизации — не про то, как всё хорошо работает, а про то, как оно отказывает. Типичные ветки, которые обычно не видны снаружи:
- модель вернула валидный JSON с сомнительным фактом;
- генерация оборвалась до завершения ответа;
- API ответил ошибкой лимита;
- изображение создалось, но не загрузилось;
- загрузка прошла, а идентификатор обложки вернулся неверный;
- запись создалась черновиком вместо запланированной публикации;
- материал на сайте есть, а в ленте ещё нет;
- повторный запуск стадии породил дубликат.
К каждой ветке нужна своя реакция, и универсальной кнопки здесь нет. Где-то помогает ограниченное число повторов с паузой: при ошибке лимита разумно учитывать заголовок Retry-After, добавлять задержку со случайным разбросом и не пытаться повторять бесконечно, иначе станет только хуже. Где-то нужна проверка обязательных полей перед отправкой. Где-то — остановка и передача человеку, потому что сценарий не совпал с ожидаемым.
Это и есть та часть работы, которую не видно в презентации. Не вызов модели, а обработка всех способов, которыми этот вызов может закончиться не так, — вот что обычно требует больше всего внимания.
Что остаётся человеку
Редакционная политика, утверждение спорных тем, оценка репутационного риска, разбор необычных ошибок и развитие самой системы. Это не временный балласт, который автоматизация скоро съест. Скорее наоборот: именно эта часть делает её осмысленной. В рекомендациях по управлению рисками ИИ-систем это сформулировано прямо — рисками нужно управлять на всём жизненном цикле, роли документировать, надзор описывать, мониторинг вести, а на случай отказа сторонних компонентов иметь заранее прописанные процедуры. Автоматизация без этого не конвейер, а лотерея с красивым интерфейсом.
Есть и обратная сторона: чем больше шагов автоматизировано, тем заметнее цена незамеченной ошибки. Когда человек вставляет текст руками, он хотя бы видит, что вставляет. Когда это делает конвейер, ошибка может доехать до публикации молча. Поэтому контроль встраивается в процесс формально — как проверка, а не как надежда на внимательность.
Разбирать такие схемы удобнее на живых примерах и регулярных разборах, чем по документации. Если это интересно, у GPT-Лаборатории есть Telegram и VK, а ещё MAX — там выходят материалы про автоматизацию, агентов и практическое применение ИИ.
Что считать победой
Победой автоматизации стоит считать не число агентов, а список ручных действий, которых больше нет. Копирования текста, переноса заголовка, ручной загрузки обложки, открытия админки, нажатия кнопки публикации, проверки ленты. При этом по брифу можно подтвердить восемь функциональных этапов, но не точное количество исчезнувших операций: для такой цифры нужен журнал замеров с периодом наблюдения и числом выпусков. Без него любой итог будет декоративным.
Практический вывод простой: посмотрите на свой процесс публикации и выпишите повторяемые переходы. Не «внедрить ИИ», а конкретно — что вы делаете каждый раз руками. Убирать их стоит по одному, оставляя человеку те места, где ошибка дороже сэкономленного клика. Так автоматизация и выглядит в реальности: не магия, а длинная, скучная и очень полезная работа.
