Тему автоматизации контента и агентных систем я разбираю регулярно. Если она вам близка - заходите в канал, там без глянца, с тем, что реально сломалось и как чинилось.

Что вообще значит «контент-завод»

Коротко: это не один скрипт, который пишет посты, а система с несколькими ролями - она предлагает темы, пишет тексты, проверяет их и публикует, а человек только нажимает кнопку одобрения.

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

Мой контент-завод на Claude устроен как тонкое ядро плюс цеха вокруг. Ядро держит реестр брендов, очередь заданий, точку одобрения человеком, планировщик публикаций, журнал и метрики. Всё содержательное - тексты, картинки, вычитку - делают отдельные цеха, подключённые к общей шине по контракту на вход и выход. Ни один из цехов, которые у меня уже работали раньше как самостоятельные проекты, я не переписывал заново - они просто подключились к этой шине.

Почему быстрый запуск - это про демо, а не про систему

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

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

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

Как темы попадают в работу без моего участия

Коротко: темы не придумываются вручную каждый день - петля сама отбирает кандидатов по спросу и кладёт их в панель и в бота.

Раньше самым долгим шагом было решить, что публиковать сегодня. Сейчас это решает петля. Каждое утро она отбирает темы по нескольким источникам и предлагает их блоками по дням прямо в панели, а также через бота в Telegram. Я отмечаю тему и каналы, куда её вести - и всё. Темы, которые пролежали больше 7 дней невостребованными, удаляются сами. Банк тем не разрастается в свалку черновиков, которые никто никогда не откроет.

Источник, откуда конкретно взялась тема, в интерфейсе не показывается специально. Решение принимается по самой теме и её потенциалу, а не по авторитету источника.

Кто на самом деле решает, публиковать текст или нет

Коротко: у меня решение о качестве текста выносит код, а не одна модель - три вычитки проходят по цепочке, и результат каждой записывается в базу, а не остаётся только в переписке.

Это то место, где я специально не доверил решение модели целиком. Текст проходит цепочку: код проверяет формальные вещи первым, затем идёт редактор А, затем редактор Б. Решение на каждом шаге ложится в базу как запись, а не остаётся только в переписке с моделью. Если скоринг текста ниже 70, он уходит на доработку, и таких попыток у него максимум две. Дальше нужно моё вмешательство, а не бесконечный цикл переписывания в надежде, что модель попадёт в цель.

Модель, которая сама же написала текст, плохо годится в судьи самой себе - вот почему решение нельзя оставлять только за ней. Формальная проверка кодом и независимая вычитка - это разные механизмы, и я держу их раздельно.

Если тема системного взгляда на такие связки вам интересна, у меня есть отдельный разбор - Система искусственного интеллекта для чайников: разбор завода. Там про то, из каких частей вообще собирается работающая ИИ-система, если не сводить её к одному чат-боту.

Почему публикация не уходит наружу автоматически

Коротко: наружу ничего не публикуется без моего явного одобрения, кроме одного узкого исключения с таймером, и оно работает только для веток уже одобренного мной корневого текста.

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

Единственное исключение - ветка уже одобренного мной корневого текста. Она встаёт в очередь с таймером, и если я её не остановил за это время, она уходит по расписанию сама - с отдельной пометкой в журнале, что ушла именно так, а не по прямому клику. Сам корневой текст по такому механизму не уходит никогда - только его производные ветки в другие каналы. Это осознанная уступка скорости, а не дыра: остановить легко, а без вмешательства система не тормозит на случаях, где я и так почти всегда согласен с текстом, который сам же одобрил в виде корня.

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

Как устроена связка текста и картинки

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

В правилах записано: визуал - только тому тексту, который прошёл замер на тестовой площадке (Threads, Telegram) и превысил порог, зафиксированный в отдельном файле настроек, а не подобранный на глаз. Если порог не пройден, отказ пишется в журнал прогонов, и обложка не рисуется - это не сбой, это остановка по правилу. Обойти это можно только явной отметкой от меня из панели или бота о запуске без теста. Сам агент такую отметку не делает.

Смысл в том, чтобы не тратить ресурс цеха картинок на тексты, которые ещё не доказали, что они работают. Сначала слово, потом иллюстрация к нему - а не наоборот.

Где текст физически уходит на площадки без нормального API

Коротко: часть каналов - Сетка, TenChat, Дзен, Threads - публикуются не через API, а браузером с моей же сессией, потому что у площадок нет пригодного API для этого.

Это отдельный узел системы. Он работает там, где нормального программного входа на площадку просто нет: заходит браузером с моей сохранённой сессией и кликает по интерфейсу так, как кликал бы я сам. Есть жёсткое условие: пока селекторы интерфейса площадки не помечены как проверенные после ручной разведки, публикация через них не начинается. Гадать по чужой вёрстке нельзя - ошибочный клик в чужом интерфейсе необратим. Сессии площадок лежат отдельно от кода, с ограниченными правами доступа, и никогда не попадают в git.

Telegram при этом публикуется от моего аккаунта напрямую, без браузерного обхода - там канал устроен так, что прямой путь есть и он надёжнее.

Что система знает и чего не знает о фактах обо мне

Коротко: любые факты, цифры и регалии обо мне цех текста берёт из одного проверенного файла, а не придумывает и не берёт из общих ощущений.

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

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

Метрики: пустое значение - это не ноль

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

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

Что уже ловилось на граблях и как это зашито в правила

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

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

С чего я бы начал, если бы строил такое заново

Коротко: не с генерации текста, а с трёх вещей - откуда система знает правду о вас, кто и как одобряет результат, и что происходит, если что-то пошло не так.

Если раскладывать по порядку значимости, а не по эффектности: сначала - источник правды о фактах и продуктах. Без него любая генерация рано или поздно начнёт придумывать. Затем - точка одобрения человеком: автопубликация без неё превращает завод в машину по производству репутационных рисков. И только затем - собственно генерация текста и картинок, потому что это та часть, которую действительно можно собрать быстро, если первые два пункта уже стоят на месте.

Генерация текста моделью Claude - самая простая часть всей цепочки. Сложная часть - это дисциплина вокруг неё: что происходит, когда модель ошиблась, кто это заметит и что с этим замечанием сделает система дальше.

Источники

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