Мы в КОМЭКСПО выпускаем много материалов. Новости платформы, разборы, гайды, интервью, анонсы курсов. Чем больше текстов, тем важнее, чтобы каждый был не только интересным, но и точным. Нейросети в редактуре мы используем почти каждый день, и за это время выработали понятный процесс, которым хочется поделиться.
Он не про то, чтобы ИИ переписал всё за нас. Он про то, как сделать ассистента полезным инструментом проверки, а не генератором красивых, но пустых формулировок.
С чего начинается проверка
Возьмём типичную фразу из черновика: «мы протестировали сервис и получили результат за две минуты». Казалось бы, всё просто. Но чтобы оставить это предложение в статье, нужны два отдельных подтверждения. Что автор действительно проводил тест. И что время действительно измерялось.
Если в материалах есть только описание продукта, такое предложение в текст не идёт. Либо переформулируем, либо убираем.
Именно на этом и строится проверка. Ассистенту нужны черновик, фактура и редакционные правила. Его задача найти конкретные расхождения и показать спорные места, а не переписать текст покрасивее.
Мы принципиально разделяем проверку фактов и редактуру. Если смешать их в один проход, легко получить гладкий текст, в котором неподтверждённое обещание просто сформулировано более уверенно.
Как готовим материалы
Создаём отдельную беседу и передаём в неё три документа.
Первый. Статья, сам черновик.
Второй. Фактура, материалы, на которых статья основана.
Третий. Редакционное задание с требованиями к стилю, структуре и ключевым запросам.
В фактуру складываем всё, что используется в тексте. Условия тарифов, характеристики, результаты собственных проверок. Обязательно сохраняем даты. Условия, актуальные полгода назад, не подтверждают сегодняшнюю цену. Это отдельная ловушка, в которую легко попасть.
Если личных испытаний не было, прямо так и пишем. «Автор изучил описание продукта. Самостоятельное тестирование не проводилось». Для редактора это существенное ограничение, а не формальность.
В черновике нумеруем абзацы от P01 и дальше. Тогда замечание можно привязать к конкретному месту. Формулировка «в середине статьи есть повтор» неудобна, особенно после нескольких правок.
Начальный запрос: задаём границы проверки
Перед ассистентом ставим чёткую рамку.
Перед тобой черновик статьи, фактура и редакционное задание.
Проверяй текст по приложенным материалам. Отделяй подтверждённые сведения от выводов автора и неподтверждённых утверждений.
Не переписывай статью целиком. Сначала составь замечания к конкретным фрагментам.
Для каждого замечания укажи номер абзаца, точную цитату и объяснение проблемы.
Если в материалах нет подтверждения, пиши «требуется проверка». Отсутствие подтверждения само по себе не доказывает, что утверждение ошибочно.
Не придумывай источники, результаты испытаний и обстоятельства из опыта автора.
Этот запрос база. Дальше идут отдельные проходы под конкретные задачи.
Этап 1. Проверка фактов
Первый проход узкий. Ищем числа, даты, характеристики, условия и утверждения о выполненных действиях. Стилистику откладываем.
Найди в статье утверждения, которые можно проверить.
Особое внимание ценам, срокам, ограничениям, названиям функций, сравнениям и описанию личного опыта.
Сопоставь каждое существенное утверждение с приложенной фактурой.
Отмечай противоречия, потерянные условия и отсутствие подтверждения.
Проверяй, сохранились ли слова «от», «до», «при», «кроме» и другие ограничения, которые меняют смысл.
Не оценивай стиль и не предлагай общую редактуру на этом этапе.
Учебный пример
Исходные данные. Сервис стоит 990 ₽ в месяц при оплате за год. В тариф входят 100 документов в месяц. Время обработки зависит от объёма файла. Автор сервис не тестировал.
В черновике появляется фраза: «Мы проверили сервис. За 990 рублей в месяц он обрабатывает любые документы за две минуты».
Здесь сразу четыре замечания.
Первое. Упоминание теста противоречит сведениям об авторском опыте.
Второе. Из цены исчезло условие годовой оплаты.
Третье. Слово «любые» игнорирует лимит в 100 документов.
Четвёртое. Время обработки ничем не подтверждено.
Исправленный фрагмент выглядит так: «При оплате за год тариф стоит 990 ₽ в месяц. В него входят 100 документов ежемесячно. Время обработки зависит от объёма файла».
Здесь каждое изменение объясняется через исходные данные. Это и есть полезная правка.
Этап 2. Выводы, которые нельзя выдавать за факты
Отдельно проверяем предложения, где из характеристики продукта сделан более широкий вывод.
Наличие экспорта в Excel не доказывает, что сервис подойдёт любой бухгалтерии. Возможность загрузить PDF не подтверждает корректную обработку сканов. Запуск функции через API ничего не говорит о сроках её внедрения в конкретной компании.
Дополнительный запрос.
Найди выводы, которые шире приведённых доказательств.
Проверь слова «любой», «всегда», «полностью», «гарантированно» и похожие обобщения.
Для каждого случая объясни, что именно подтверждено материалами и какая часть вывода требует дополнительных данных.
Если это авторская оценка, предложи формулировку, в которой её можно отличить от установленного факта.
Не каждое такое предложение нужно удалять. Автор может объяснять свой выбор или сомневаться в удобстве продукта. Но мнение должно оставаться мнением.
Например, «мне неудобно подтверждать каждое действие отдельно» описывает предпочтение автора. А фраза «подтверждения делают сервис непригодным для бизнеса» уже требует гораздо большего обоснования.
Этап 3. Логика и внутренние противоречия
После фактов переходим к связности. Здесь ассистент сопоставляет разделы между собой.
Проверь статью на внутренние противоречия.
Найди случаи, когда цена, срок, ограничение или порядок действий меняются между разделами без объяснения.
Проверь, хватает ли читателю сведений для выполнения каждой инструкции. Отмечай пропущенные действия и нерасшифрованные обозначения.
Если статья обещает конкретный результат, установи, объяснено ли его получение.
Для каждого замечания приведи связанные фрагменты. Не заменяй проверку общими советами.
Типичный случай. Автор пишет, что бот сохраняет задачу после подтверждения, а в инструкции запись в Google Sheets подключена напрямую к распознаванию. Текст обещает один порядок действий, а описание настройки задаёт другой.
Другой пример. Сообщение «заявка передана менеджеру», хотя в инструкции настроен только вывод контакта поддержки. Исправлять нужно либо формулировку результата, либо сам сценарий.
Мы проверяем такие места раньше отдельных слов. Пропущенный шаг мешает повторить инструкцию сильнее, чем неудачный переход между абзацами.
Этап 4. SEO без ломки языка
Передаём ассистенту основной запрос, дополнительные формулировки и требования к тексту. Не просим его самостоятельно назначать обязательную плотность ключевых слов. Это плохая идея.
Сопоставь статью с SEO-заданием.
Проверь, отвечает ли заголовок содержанию и раскрыта ли тема основного запроса.
Найди неестественные вхождения, повторение близких ключевых фраз и абзацы, которые не добавляют смысла.
Предлагай замену только вместе с исходным фрагментом. Сохраняй тему и полезные подробности.
Не добавляй разделы только ради ключевых слов. Не обещай позиции в поиске.
Классический пример. «Проверка статьи нейросетью помогает проверить текст с помощью ИИ перед публикацией». Здесь одна мысль повторяется трижды. Достаточно сказать: «Нейросети можно поручить проверку черновика перед публикацией». А дальше объяснить, что именно проверять. Дополнительное вхождение ключа этой задачи не решает.
Этап 5. Редактура по нашим правилам
На этом этапе ищем повторы, пустые оценки и нарушения оформления. Передаём ассистенту нашу редакционную инструкцию и несколько характерных примеров.
Проверь текст по приложенным правилам.
Найди повторы мысли, общие обещания, канцелярские формулировки и предложения, которые можно удалить без потери содержания.
Сохраняй технические подробности, числа и условия.
Не добавляй разговорные вставки, шутки и личные истории ради имитации авторского голоса.
Для каждой правки покажи исходное предложение, замену и короткую причину.
Если фрагмент соответствует правилам, оставь его.
Фраза «инструмент существенно повышает эффективность обработки данных» требует конкретизации. Но если исходные материалы не объясняют, что именно он делает, редактор не должен самостоятельно дописывать функции.
Иногда правильное замечание выглядит просто. «Уточнить, какие данные обрабатывает инструмент и какой результат получает пользователь». Такой пробел лучше сохранить до проверки, чем заполнить уверенным предположением.
Как применять правки
После нескольких проходов собираем замечания в один перечень, присваиваем номера. Просматриваем их до изменения статьи. Повторяющиеся объединяем, спорные оставляем отдельно.
Затем даём конкретное задание.
Примени замечания 1, 3, 4 и 7.
Остальные фрагменты не меняй.
Сохрани структуру статьи, подтверждённые сведения и авторскую позицию.
Если исправление требует отсутствующих данных, оставь пометку [нужно уточнить].
После редактирования отдельно перечисли изменённые абзацы.
Ограничение объёма правки здесь принципиально. Если согласовано исправление условия тарифа, нет причины заодно менять вступление, подзаголовки и примеры.
После редактуры обязательно повторно проверяем изменённые фрагменты. Удаление одного неподтверждённого обещания не должно привести к появлению другого.
Финальная проверка
Просим ассистента найти оставшиеся пометки, незаполненные поля, противоречащие числа и ссылки на отсутствующие материалы. Затем самостоятельно проверяем самые существенные утверждения по исходным данным.
Для гайда это прежде всего команды, последовательность действий, ограничения и описание результата. Для сравнения сервисов важны цены, состав тарифов и условия доступа.
Мы не считаем ответ «ошибок не найдено» достаточным основанием для публикации. Нам нужен текст, в котором проверены конкретные спорные места. Если срок не подтверждён, он остаётся на уточнении. Если автор не проводил тест, в статье не появляется рассказ об испытаниях.
Что в итоге
Проверка с помощью ИИ не отменяет редактора. Она снимает рутину и помогает не пропустить то, что легко ускользает при вычитке. Но решения всё равно принимает человек. Именно он решает, оставить спорную фразу или убрать, добавить данных или признать пробел.
Если вы тоже используете нейросети в редактуре, попробуйте разбить процесс на отдельные этапы. Так вы получите не «переписанный текст», а список конкретных замечаний, с которыми можно работать.
