Контент-завод: статьи и письма под контролем редактора

Что болело

SEO-статьи по ТЗ, пачки коротких описаний по одному шаблону, письма, посты — типовых текстов в маркетинге много. Вручную каждый проходит цепочку из четырёх ролей: автор → редактор → SEO-специалист → фактчекер, и у каждого чек-лист в голове. Черновик от нейросети приходит быстро, а потом редактор вычищает из него канцелярит и цифры, взятые ниоткуда, и тратит на это то самое время, которое модель сэкономила. Для своей команды я собрал три инструмента, и ни в одном модели не доверено решать, готов ли текст.

Студия текстов для разовых задач

Студию открывают, когда нужен один текст и быстро. В ней семь типов текста (статья, письмо, пуш, пост ВКонтакте, лендинг, пресс-релиз и «другое»), четыре тона, объём от 300 до 10 000 знаков. В генерацию подмешивается контекст: кампания, документы из базы знаний, загруженное ТЗ. После генерации параллельно запускаются три проверки: редполитика, совпадения с чужими текстами через text.ru и SEO-структура. Готовый текст со стороны проверяется так же, без генерации.

Конвейер для длинных текстов

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

1. Бриф: тема, тип, уровень риска, SEO-ТЗ, источники, запрещённые утверждения.
2. Подбор бренд-правил и редполитики из базы знаний.
3. План. Для SEO-статьи его утверждает человек, до этого конвейер стоит.
4. Секции: введение, затем тело — до трёх запросов параллельно, — затем заключение. Каждая секция видит последние 600 знаков предыдущей, чтобы стыки не рвались.
5. Сборка кодом: H1, description, оглавление.
6. Разбор. Модель другого семейства размечает дефекты по абзацам и ничего не переписывает.
7. Правка только безопасных абзацев. Появились новые числа, пропала пометка «нужен источник» или текст вырос больше чем в 1,6 раза — откат.
8. Выписка утверждений: числа, даты, правовые нормы, свойства продукта.
9. Автоматические проверки, и задача уходит редактору.

Писатель в этой схеме — Gemini, разбирают его модели OpenAI. Так же я устроил и ревью кода: модели одного семейства ошибаются одинаково и чужую ошибку пропускают. Задание живёт в базе, его подхватывает системный cron раз в минуту. Вкладку можно закрыть. Оплаченные шаги при продолжении не повторяются, потому что каждый шаг записан в базу как чекпоинт вместе с моделью, временем и стоимостью.

Проверки кодом и решение редактора

Модель в этих трёх проверках не участвует, это порты моих же скиллов для Claude:

• анти-ИИ ставит тексту риск машинности от 0 до 100: смотрит слова-маркеры и конструкции, ритм, одинаковые абзацы, круглые проценты. Этим же детектором я проверял страницу, которую вы читаете. Блокирует он при риске выше 40 и минимум трёх независимых признаках: один маркер — повод поправить, остановка работы из-за него лишняя;
• редполитика — словарь замен, обращение к читателю, канцелярит, типографика, «ё», однозначные замены применяются кнопкой;
• SEO — один H1, иерархия заголовков, лид, абзацы 200–600 знаков, длина description, ключи, обязательные заголовки из ТЗ и объём ±15%.

Подсказку по каждому выписанному утверждению модель дать может, но она лежит в отдельном поле, а статус меняет только человек. Уровень риска задаётся в брифе, от L0 до L4, материалы уровня L4 конвейер не берёт вовсе. Текст уровня L2 или L3 не утвердить, пока у каждой выписанной фразы с числом, датой или нормой нет решения и источника из реестра. Решение привязано к отпечатку фразы по словам и числам: поменяли цифру — решение слетает.

Кнопка «переписать абзац» тоже не трогает текст сразу. Модель сохраняет предложение с исходным и новым текстом рядом, редактор его принимает или отклоняет. Отклонённое остаётся в истории. Доля принятых показывает, есть ли от модели толк или редактор всё равно переделывает за ней.

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

Пачки с пробой

Короткие однотипные тексты запускаются пачкой до 50 строк из списка, CSV или XLSX. Первые десять строк идут пробой. Остальные ждут. Пачка встаёт сама, если из десяти текстов пробы у трёх риск машинного текста выше 40, у двух ошибки редполитики, две строки упали или прогноз стоимости вышел за лимит. Это та же проба промта на нескольких записях, которую я раньше делал руками, только встроенная в интерфейс.

Письма

Письма верстаются перетаскиванием блоков в редакторе на GrapesJS. Источник истины — MJML, сервер компилирует его в HTML с инлайн-стилями и обвязкой для Outlook. Режимов три: визуальный, MJML и HTML только для чтения. Холст — 320, 480, 600 или 680 px, превью — десктоп и телефон.

Бейдж веса краснеет от 100 КБ: Gmail обрезает письма крупнее. Для персонализации есть 12 системных переменных, свои переменные и тестовые профили для превью. Контраст текста проверяется по WCAG AA с порогом 4,5:1. Невалидный MJML письмо не обнуляет: редактор откатывается к последнему рабочему состоянию.

Что сломалось по дороге

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

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

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

С чего начать у себя

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

• Next.js 15
• TypeScript
• Supabase (Postgres)
• OpenAI
• Gemini
• GrapesJS + MJML
• text.ru API
• Claude Code