Кейс Content Factory: как построить AI-конвейер контента с редактором в контуре

С какой проблемы начинался Content Factory

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

Сам текст был только частью работы. Для каждого материала требовалось:

• понять, какую проблему читателя он решает;
• проверить, не опубликована ли похожая статья;
• собрать запросы и определить поисковый интент;
• подготовить структуру и примеры;
• выдержать стиль Paramiko;
• проверить факты и обещания;
• добавить внутренние ссылки, метаданные, FAQ и CTA;
• передать материал на согласование;
• после публикации проверить страницу, sitemap и аналитику.

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

Поэтому единицей автоматизации стала не статья, а весь путь от идеи до измеряемого результата.

Как мы спроектировали конвейер

Content Factory удобно рассматривать как систему состояний. Материал не просто «есть» или «нет». Он последовательно получает статусы: идея, отобрано, бриф готов, черновик готов, QA пройден, требуется редактор, одобрено, опубликовано, проверено, требует обновления.

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

1. Сбор тем из реальных сигналов

Конвейер не должен придумывать темы в пустоте. На вход поступают:

• вопросы клиентов и лидов;
• поисковые подсказки;
• данные Яндекс Вебмастера и Google Search Console;
• темы из Telegram, CRM и базы знаний;
• опубликованные материалы Paramiko;
• кейсы по продажам, поддержке, WB/Ozon и интеграциям;
• повторяющиеся операции, которые бизнес пытается автоматизировать.

Например, запрос клиента «можно ли связать Telegram, сайт и CRM без ручного переноса заявок» сильнее абстрактной темы «тренды автоматизации». В нем уже есть проблема, сценарий и потенциальный следующий шаг.

AI на этом этапе помогает нормализовать формулировки, объединить дубли и разложить идеи по кластерам. Но он не должен самостоятельно объявлять тему приоритетной только потому, что она звучит технологично.

2. Скоринг вместо случайной очереди

Каждая тема получает оценку по нескольким критериям:

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

Например, статья «Что такое нейросеть» может иметь широкий спрос, но почти не помогает квалифицировать запрос на автоматизацию. Тема «Как связать заявки из Telegram с CRM и не потерять историю диалога» уже уже по охвату, зато ближе к реальной задаче бизнеса.

На выходе появляется не склад идей, а очередь с объяснимым приоритетом.

3. Бриф как контракт между системой и редактором

До генерации текста создается структурированный бриф. В нем фиксируются:

• главный и дополнительные запросы;
• целевая аудитория;
• проблема читателя;
• обещание статьи;
• обязательные вопросы;
• структура H2/H3;
• допустимые источники;
• внутренние ссылки;
• ограничения по фактам и формулировкам;
• CTA;
• требования к метаданным и schema.org.

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

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

4. Черновик создается не одним проходом

Попытка написать всю статью одним запросом дает нестабильный результат. Поэтому черновик собирается по этапам.

Сначала AI формирует тезисы и проверяет, отвечает ли структура на интент. Затем раскрывает разделы, используя бриф и разрешенные источники. После этого отдельный проход сокращает повторы, убирает канцелярит и проверяет связность переходов.

Для статьи про автоматизацию продаж в контекст можно передать схему движения заявки, поля CRM и правила квалификации. Для материала про WB/Ozon — описание доступных отчетов, ограничения API и перечень действий, которые требуют подтверждения продавца. Контекст должен быть релевантным задаче, а не состоять из всей корпоративной базы знаний.

Каждая версия сохраняется. Если редактор видит странное утверждение, можно установить, на каком этапе оно появилось: в брифе, источниках, генерации или редактуре.

Как сохраняется tone of voice

Инструкция «пиши как эксперт» почти бесполезна. Модель не знает, как именно говорит конкретная компания, пока стиль не разложен на проверяемые правила.

Для Paramiko tone of voice описывается через наблюдаемые признаки:

• короткие абзацы;
• спокойный тон без хайпа;
• объяснение через процессы и ограничения;
• примеры из малого и среднего бизнеса;
• отсутствие обещаний «заменить сотрудников»;
• конкретные действия вместо абстрактных выгод;
• один следующий шаг вместо нескольких конкурирующих CTA.

К правилам добавляются хорошие и плохие примеры. Например, фраза «решение кардинально повысит эффективность вашего бизнеса» помечается как пустая. Вместо нее редактор ожидает конкретный эффект: «менеджеру не нужно вручную переносить имя, телефон и источник заявки из Telegram в CRM».

Полезно хранить tone of voice отдельно от промпта генерации и версионировать его. Если правило меняется, в журнале видно, по какой версии создавалась статья. Это упрощает разбор качества и обновление старых материалов.

Автоматический QA до редактора

Редактор не должен вручную искать все технические ошибки. Перед согласованием черновик проходит набор проверок.

Структурные проверки

Система проверяет наличие H1, блока «Коротко», основной структуры, FAQ, одного CTA, meta title и meta description. Заголовки не должны перескакивать с H2 на H4, а FAQ — повторять основную статью дословно.

Смысловые проверки

Отдельный проход ищет:

• неподтвержденные числа и обещания;
• утверждения без источника;
• противоречия между разделами;
• повторы одной мысли;
• слишком общие формулировки;
• подмену практического ответа описанием технологии;
• советы, которые могут привести к публикации, оплате или изменению данных без подтверждения человека.

AI может проводить такую проверку, но не должен сам себе безусловно выставлять оценку «готово». Результат QA — список замечаний и уровень риска, а не формальное разрешение на публикацию.

Технические проверки

Перед передачей редактору можно автоматически проверить:

• длину title и description;
• корректность внутренних и внешних ссылок;
• уникальность slug;
• наличие canonical;
• формат JSON-LD;
• совпадение видимого FAQ с разметкой;
• отсутствие битых изображений;
• присутствие статьи в sitemap после публикации.

Эти проверки детерминированы, поэтому их разумно выполнять кодом, а не языковой моделью.

Где остается редактор

Редактор нужен не для исправления запятых после AI. Его задача — принять решения, для которых недостаточно формального правила.

Он проверяет:

1. Верно ли понята проблема читателя.
2. Не преувеличивает ли текст возможности системы.
3. Соответствуют ли примеры реальным процессам.
4. Есть ли у статьи собственная позиция и практическая ценность.
5. Можно ли подтвердить кейсы и результаты.
6. Не раскрываются ли клиентские данные.
7. Действительно ли материал готов к публикации от имени компании.

В интерфейсе согласования редактору лучше показывать не только финальный текст, но и бриф, источники, замечания QA и изменения между версиями. Тогда он видит происхождение спорного фрагмента и не перечитывает материал вслепую.

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

Публикационный контур: почему черновик не должен сам попадать на сайт

Генерация и публикация — разные уровни доступа. Сервис, который пишет черновики, не обязан иметь право менять production.

В безопасной схеме AI создает файл или запись со статусом draft. Автоматические проверки формируют отчет. Редактор утверждает конкретную версию, после чего отдельный процесс публикует материал.

Это защищает от нескольких типовых ситуаций:

• модель сослалась на несуществующую страницу;
• в источнике оказался ошибочный факт;
• повторный запуск перезаписал отредактированный текст;
• в CTA попала неправильная ссылка;
• статья вышла до согласования кейса;
• промпт или внешняя страница попытались навязать системе постороннее действие.

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

После публикации система делает обратную проверку: страница отвечает кодом 200, canonical указывает на правильный URL, разметка читается, ссылка появилась в sitemap, а кнопка Telegram содержит ожидаемую метку перехода.

Что дает такой подход по времени и деньгам

Эффект Content Factory стоит считать не количеством сгенерированных слов, а временем на выпуск принятого материала.

До внедрения полезно замерить четыре показателя:

• сколько часов проходит от выбранной темы до готового черновика;
• сколько времени редактор тратит на сборку и исправления;
• какая доля черновиков доходит до публикации;
• сколько технических ошибок обнаруживается после публикации.

Пример расчета: команда выпускает восемь статей в месяц. На сбор темы, брифа, структуры, метаданных, ссылок и первичную проверку уходит в среднем четыре часа на материал. Это 32 часа повторяемой работы. Если конвейер сокращает ее до полутора часов, высвобождается 20 часов в месяц.

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

экономия времени = количество материалов × (время до автоматизации − время после автоматизации)

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

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

Основные риски и способы контроля

Убедительные, но выдуманные факты

Модель может заполнить пробел числом, названием сервиса или якобы результатом кейса. Поэтому факты должны быть связаны с источниками, а неподтвержденные поля — блокировать публикацию.

Размывание экспертности

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

Дубли и конкуренция страниц

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

Утечка данных

В CRM, чатах поддержки и отчетах маркетплейсов есть персональные и коммерческие данные. В контентный контур передаются только необходимые обезличенные фрагменты. Доступ к источникам и публикации разделяется, секреты не включаются в промпты, действия журналируются.

Неконтролируемая автопубликация

Даже качественный пайплайн иногда ошибается. Поэтому автоматическая публикация вводится по классам риска, а не включается сразу для всех материалов. Сначала — только черновики. Затем — безопасные evergreen-темы при прохождении всех проверок. Кейсы и спорные материалы остаются на ручном подтверждении.

Как внедрить Content Factory без лишней сложности

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

Шаг 1. Разберите текущий процесс

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

Шаг 2. Определите обязательный формат

Зафиксируйте поля карточки материала: тема, интент, аудитория, источники, структура, внутренние ссылки, CTA, статус и ответственный. Без общей модели данных автоматизация быстро распадется на несвязанные скрипты.

Шаг 3. Автоматизируйте один узкий участок

Хорошая первая версия может только собирать бриф, готовить черновик и запускать QA. Редактор продолжает работать в привычном интерфейсе, а публикация остается ручной.

Шаг 4. Добавьте измерение

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

Шаг 5. Подключите публикацию через подтверждение

Только после стабильной работы с черновиками добавляйте создание страницы, метаданные, schema.org, sitemap и проверку публичного URL. Production-доступ должен принадлежать отдельному сервису с ограниченными правами.

Шаг 6. Улучшайте систему по реальным данным

После публикации важны не оценки внутри генератора, а показы, клики, дочитывания, переходы и обращения. Статьи, которые получают показы без кликов, требуют пересмотра title и description. Материалы с трафиком, но без следующего действия, — проверки интента, примеров и CTA.

Так Content Factory превращается из генератора текста в управляемый редакционный процесс.

FAQ

Может ли AI-конвейер работать без редактора?

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

Чем Content Factory отличается от генерации статей в ChatGPT?

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

Какие данные нужны для запуска?

Минимально — список опубликованных страниц, темы и аудитория, правила tone of voice, несколько хороших примеров, требования к структуре и понятный процесс согласования. Поисковую аналитику, CRM, Telegram и внутреннюю базу знаний можно подключать постепенно.

Как не допустить выдуманных кейсов и цифр?

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

Нужно ли сразу подключать автопубликацию?

Нет. Сначала система должна стабильно готовить черновики и проходить QA. Затем можно автоматизировать создание страницы, но оставить кнопку подтверждения. Полную автопубликацию имеет смысл включать только для заранее определенных безопасных форматов.

Как понять, окупается ли конвейер?

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

Какой стек нужен для Content Factory?

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

Следующий шаг

Если хочешь понять, что автоматизировать у себя — напиши Дмитрию в Telegram @dmkosik / опиши процесс для диагностики Paramiko.