Когда мы начали строить MediaMashin, самая очевидная идея звучала просто: если система умеет найти инфоповод, собрать факты, подготовить статью и разнести её по площадкам, зачем вообще оставлять человека между генерацией и публикацией? На бумаге это выглядело как лишний шаг. На практике именно этот шаг оказался одним из ключевых элементов всей цифровой системы продаж.
Исходная задача: не автоматизировать текст, а управлять риском публикации
Наша задача была не в том, чтобы AI как можно быстрее писал статьи. Бизнес-задача шире: получать полезный контент, который приводит целевую аудиторию, не публикует выдуманные факты и не превращает медиасеть в поток случайных текстов.
Поэтому цепочка была построена не как «модель → публикация», а как RADAR → Research → EDITOR → Telegram review → WordPress → DISTRIBUTOR → METRICS. Каждый этап решает отдельную задачу. RADAR находит событие. Research проверяет фактическую основу. EDITOR собирает материал. И только после этого появляется человеческое решение о том, можно ли выпускать конкретную версию.
Почему одного quality-gate оказалось недостаточно
Мы используем детерминированные проверки: минимальную глубину материала, наличие обязательных смысловых блоков, отсутствие неподтверждённых чисел, корректность ссылок, соответствие коммерческой логике и другие признаки. Такой gate полезен, потому что он ловит формальные дефекты лучше человека, который устал после десятка текстов.
Но gate не умеет принимать все редакционные решения. Текст может формально пройти проверки и при этом быть неуместным по тону, слишком очевидным, слабым для конкретной площадки или просто не совпадать с тем, что мы хотим сказать рынку сегодня. Поэтому мы выбрали не замену человека алгоритмом, а разделение ответственности.
Telegram как human-in-the-loop интерфейс
Нам нужен был интерфейс, который не заставляет открывать отдельную админку и при этом позволяет принять решение по конкретной статье. Telegram оказался практичным вариантом: редактор получает карточку материала и три действия — Approve, Reject и Changes.
Ключевой момент — решение привязано не просто к article id, а к digest конкретной версии контента. Это значит, что одобрение нельзя случайно применить к изменившемуся тексту. Если статья отправлена на доработку и регенерирована, она получает новый content digest и должна снова пройти review.
Такой контракт защищает от неприятного класса ошибок, когда человек одобрял одну версию, а наружу уходила уже другая. Мы сознательно сделали подтверждение частью данных, а не просто кнопкой «окей» в интерфейсе.
Что произошло после запроса изменений
Вместо создания новой независимой статьи система сохраняет тот же article id и связь с исходным событием, но обновляет текст, digest и карточку review. Старое решение очищается. Для нас это важно: история материала остаётся цельной, а публикационный контракт относится только к текущей версии.
Мы также ограничили backlog review. В очереди не должно накапливаться бесконтрольное число статей только потому, что генератор способен их производить. Сейчас система держит ограниченную очередь, и это помогает сохранять реальную способность человека принимать решение, а не превращать review в формальность.
Что в итоге автоматизировано, а что сознательно осталось человеку
Автоматизация берёт на себя поиск событий, Research, подготовку черновика, проверяемые quality-gate, сбор платформенных вариантов, учёт состояний и последующую дистрибуцию. Человеку остаётся решение: соответствует ли конкретный материал нашей позиции и можно ли его выпускать сейчас.
Такой подход не устраняет ошибки полностью. Это и не было целью. Он делает другое: разделяет машинно проверяемые ошибки и редакционное решение, а затем связывает каждое внешнее действие с конкретной подтверждённой версией контента.
Почему это относится не только к медиа
Этот же принцип мы применяем при проектировании цифровых систем продаж. Хорошая автоматизация не обязана выталкивать человека из каждого процесса. Важнее определить, где машина сильнее в повторяемых проверках, а где бизнесу требуется ответственность, контекст или право остановить действие.
Именно поэтому мы называем себя архитекторами цифровых систем продаж, а не просто автоматизаторами. Автоматизация — один из инструментов. Сама задача — построить систему, где интернет-магазин, контент, AI, аналитика, CRM и интеграции работают как управляемый контур, а не как набор несвязанных сервисов.
Что бы мы сделали иначе
Если бы начинали этот участок заново, мы бы ещё раньше разделили две сущности: качество текста и право на публикацию. Это разные вопросы. Quality-gate должен отвечать «соответствует ли материал машинно проверяемому контракту», а человек — «нужно ли это выпускать и устраивает ли нас смысл конкретной версии».
Для бизнеса это универсальный вывод: автоматизировать стоит не действия сами по себе, а управляемые процессы с понятными точками контроля. Иногда лучшая автоматизация — это не отсутствие человека, а правильное место, где его решение действительно имеет ценность.
Как мы это внедрили
Внедрение мы строили не вокруг одного инструмента, а вокруг последовательного процесса. Сначала фиксировали бизнес-задачу и границы автоматизации, затем подключали нужные компоненты и проверяли каждый переход отдельно. В этой работе использовали: Telegram Bot API, n8n, MediaMashin, OpenRouter. Для нас это важно: архитектура цифровой системы продаж должна объяснять не только какие сервисы используются, но и зачем каждый из них находится в цепочке.
MediaMashin использует цепочку RADAR → Research → EDITOR → Telegram review → WordPress → DISTRIBUTOR → METRICS. Это было не декларацией, а условием реализации: мы проверяли этот участок отдельно и только после этого считали его частью рабочего контура.
В Telegram редактор получает действия Approve, Reject и Changes; решение привязано к digest конкретной версии статьи. Это было не декларацией, а условием реализации: мы проверяли этот участок отдельно и только после этого считали его частью рабочего контура.
После запроса изменений статья регенерируется с тем же article id, но с новым content digest и новым review. Это было не декларацией, а условием реализации: мы проверяли этот участок отдельно и только после этого считали его частью рабочего контура.
Review backlog ограничен 3 статьями, чтобы автоматизация не создавала неконтролируемую очередь. Это было не декларацией, а условием реализации: мы проверяли этот участок отдельно и только после этого считали его частью рабочего контура.
Какой результат получили
Проверенный результат: Публикация не выполняется только потому, что AI сгенерировал текст: требуется решение редактора по конкретной версии. Мы считаем результатом именно наблюдаемое поведение системы, а не обещание будущего эффекта для любого бизнеса.
Проверенный результат: Отклонённая или изменённая версия не может использовать старое подтверждение. Мы считаем результатом именно наблюдаемое поведение системы, а не обещание будущего эффекта для любого бизнеса.
Границы решения
Ограничение, которое мы сохраняем в публичном выводе: Не утверждать, что human-in-the-loop устраняет все ошибки. Это помогает не превращать инженерный кейс в рекламное обещание.
Ограничение, которое мы сохраняем в публичном выводе: Не раскрывать токены, chat id и другие секреты. Это помогает не превращать инженерный кейс в рекламное обещание.
Практический вывод для бизнеса
Главный вывод из этой реализации — цифровая система продаж ценна не количеством подключённых сервисов, а тем, насколько предсказуемо проходит путь от сигнала и действия до проверяемого результата. Мы поэтому разделяем поиск, проверку, генерацию, человеческое решение, публикацию и измерение. Такой подход делает автоматизацию управляемой и позволяет менять отдельный компонент без необходимости заново изобретать весь процесс.