Codex — это режим ChatGPT и агент, то есть программа, которая может работать с файлами проекта. Например, он может раз в неделю собирать отчёт, разбирать отзывы клиентов, проверять текст перед публикацией или готовить черновик письма. Для этого ему нужны сами материалы и понятное задание: что сделать и в каком виде сохранить. Перед использованием результат проверяет человек.

Если результат нельзя сразу использовать, его придётся перепроверить и переделать. Например, заново сверить цифры в отчёте, поправить текст или исправить код. Тогда Codex не экономит время.

1. Что такое Codex в рабочем процессе

Обычный чат отвечает на отдельный вопрос. Codex работает с папкой проекта: читает заданные файлы, находит связанные с задачей строки или части программы, вносит изменения, запускает тесты (автоматические проверки), линтер (автоматическую проверку кода) или сборку (проверку, что из кода получается рабочая программа) и возвращает перечень изменённых файлов, diff (список всех изменений), результаты проверок и список того, что ещё нужно проверить человеку.

Codex стоит оценивать не по отдельному ответу, а по всей переданной работе. Для неё нужны:

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

Когда входных данных не хватает, агент начинает угадывать. Иногда угадывает удачно, а иногда выбирает не тот формат, обращается не к тому источнику или делает лишний шаг.

Codex можно использовать для конкретных задач:

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

Большинство этих задач можно проверить на локальной копии — папке проекта на вашем компьютере. Расписание и внешние действия подключайте позже, когда понятны входы и порядок проверки.

Где работает Codex

Один и тот же агент доступен в нескольких местах:

• в приложении ChatGPT — самый простой старт, с папкой проекта и наглядным diff;
• в командной строке (CLI — окне, где команды вводят текстом) — для быстрых операций и повторяющихся запусков;
• в редакторе кода — когда правки нужно видеть рядом с файлами;
• в облаке — на сервере, то есть на удалённом компьютере, когда задача может выполняться без вашего компьютера;
• в GitHub — онлайн-сервисе, где хранят код и историю изменений, — когда нужны версии, обсуждение изменений и pull request (предложение принять изменения).

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

Локальная и облачная работа

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

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

Для облачной задачи полезна отдельная рабочая копия проекта — git worktree (отдельная папка с тем же проектом, где изменения не смешиваются с основной копией). Это особенно пригодится для задач по расписанию: пока команда работает днём, агент ночью собирает отчёт в своей копии.

Сколько работы отдавать сразу

Работу можно передавать в трёх режимах.

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

Черновик. Агент создаёт документ, таблицу, код или ответ. Человек смотрит результат и решает, что с ним делать.

Ограниченные изменения. Агент меняет разрешённые файлы, запускает проверки или создаёт pull request. Заранее определите папку и список действий; старую версию можно вернуть.

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

2. Первый час с Codex

Начать проще всего с приложения ChatGPT. В новом чате выберите режим Codex и откройте папку проекта. Если проекта ещё нет, создайте пустую папку с понятным названием. В приложении есть разные режимы: Chat — обычный разговор, Work — работа с документами и таблицами, Codex — работа с папкой и файлами.

Режимы легко перепутать: Chat нужен для обычного разговора, Work — для документов и таблиц, Codex — для работы с папкой и файлами.

Не начинайте с большой переделки. Сначала проверьте, что агент видит нужную папку:

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

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

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

Правила проекта (AGENTS.md) и первая сохранённая версия

После чтения можно попросить:

Сделай черновик AGENTS.md по тому, что узнал о проекте. Покажи файл и отдельно укажи, что нужно поправить руками.

Команда /init осматривает папку и создаёт заготовку файла правил. Проверьте в ней команды, пути и ограничения: заготовка может ошибаться.

До первой задачи сохраните исходное состояние. Если проект ещё не использует Git — систему, которая сохраняет историю изменений, — можно попросить агента:

Включи Git в этой папке и сделай первую сохранённую версию проекта. Ничего больше не меняй.

Git — система, которая сохраняет историю изменений проекта. Коммит — одна сохранённая версия проекта. Если агент внёс лишние правки, можно вернуться к состоянию до задачи, а не восстанавливать всё вручную.

Что посмотреть после задачи

Перед тем как принять результат, откройте diff — список строк, которые добавились, изменились или удалились, — и проверьте три вещи:

1. какие файлы изменились и не залез ли агент в соседние папки;
2. нет ли удалённых строк там, где вы ничего не просили удалять;
3. не появились ли в файлах пароли, ключи или другие секреты.

Читать весь код необязательно. Достаточно понять, какие файлы затронуты и что изменилось.

3. Выберите задачу, которую можно измерить

Я бы начинал с операции, которую уже несколько раз сделали вручную. Например:

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

У такого процесса есть повторяющиеся шаги и результат, который можно посмотреть. На первых этапах должна оставаться возможность отменить изменения.

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

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

Что измерить до старта

Запишите хотя бы пять вещей:

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

Ориентир — время до приемлемого результата. Скорость ответа сама по себе ничего не значит: черновик за десять минут, после которого час восстанавливают логику отчёта, времени не экономит.

Разложите материалы

Минимальная структура папки:

project/
├── sources/       # исходные документы и данные
├── examples/      # примеры хорошего результата
├── work/          # промежуточные материалы
├── outputs/       # результаты для проверки
├── AGENTS.md      # постоянные правила
└── README.md      # краткое описание проекта

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

Определите главный источник

В отчёте главным источником может быть одна таблица, в исследовании — набор исходных материалов, в контенте — подтверждённые материалы или расшифровка.

Если источники расходятся, правило лучше написать прямо:

Не выбирать значение по догадке. Показать оба варианта, указать источники и вынести вопрос на ручное решение.

Такое правило объясняет, что делать при расхождении. Просьба «будь внимательным» не говорит, какое действие нужно выполнить.

4. Как ставить задачу

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

Результат

Что должно появиться в конце: файл, таблица, список решений, пробная версия, diff или черновик сообщения.

«Разберись с клиентами» — направление.

«Подготовь таблицу с активными сделками, рисками и вопросами к следующему созвону» — результат.

Входы

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

«Используй sources/sales/ и заметки последней недели. Старые отчёты смотри только для сравнения» лучше, чем «изучи всё».

Ограничения

Напишите, чего агент не должен делать:

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

Ограничения должны объяснять, какой риск они закрывают. Список из двадцати запретов только усложнит задачу.

Как принять результат

Нужны признаки, по которым можно сказать «готово»:

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

Если данных не хватает

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

Шаблон задачи

Результат:
Что должно появиться в конце:

Используй:
Какие папки, файлы и источники доступны:

Не делай:
Что запрещено менять, отправлять или додумывать:

Готово, когда:
Как я приму результат:

Если данных не хватает:
Что показать вместо самостоятельной догадки:

Плохая и хорошая формулировка

Плохо:

Сделай выгрузку заказов.

Хорошо:

Добавь команду /export, которая сохраняет заказы за последний месяц в CSV — обычный табличный файл, который открывается в Excel. Файлы, отвечающие за команды, лежат в handlers/, запрос к базе — в db/orders.py. Новые библиотеки не добавляй, структуру базы не меняй. Готово, когда файл открывается в Excel без искажений кириллицы, текущие автоматические проверки проходят и для новой команды есть отдельная проверка.

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

Когда нужен план

Если задача большая, размытая или вы сами ещё не определились, сначала попросите план:

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

Есть и другой полезный режим — интервью:

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

Для работы на несколько дней план можно хранить в PLANS.md. Тогда он не исчезнет вместе с историей конкретного чата.

5. Первый запуск и проверка

Первый запуск проведите по шагам:

1. прочитать и понять, что находится в папке;
2. согласовать план — список шагов до начала работы;
3. дать небольшой участок работы;
4. посмотреть изменения и проверки;
5. сохранить версию.

Не начинайте с «почини всё». Для документа возьмите один раздел, для кода — один сценарий, для отчёта — одну неделю или один сегмент клиентов.

В конце попросите агента перечислить:

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

Фраза «готово» сама по себе ничего не подтверждает.

Если результат не подходит

Чаще всего причина одна из пяти.

1. Неправильные входы. В папке старая версия, не тот период или неполный набор файлов.
2. Неясный формат. В задаче не сказано, что должно быть на выходе.
3. Пропущено правило. Агент столкнулся с исключением, о котором никто не договорился.
4. Не хватает доступа. Для действия нужна внешняя система или отдельное подтверждение.
5. Нет проверки. Результат выглядит убедительно, но его не сверяют с источником или ожидаемым поведением.

Если результат не подходит, не переписывайте весь запрос. Сначала найдите причину и измените только соответствующую часть задачи.

Команды, которые пригодятся

Названия команд и их поведение могут меняться. На практике чаще всего пригодятся:

• /plan — составить план до изменений;
• /init — создать черновик AGENTS.md;
• /review — проверить ветку (отдельную линию изменений), несохранённые правки или сохранённую версию проекта;
• /skills — посмотреть доступные инструкции;
• /compact — сжать раннюю часть длинного чата;
• /status — посмотреть состояние текущего запуска и лимитов;
• /fork — продолжить работу в отдельном чате-копии;
• /resume — вернуться к задаче, которую сохранили для продолжения.

/review можно использовать не только перед объединением изменений в общий код. Пусть агент проверит конкретную инструкцию: например, «найди неподтверждённые цифры и места, где нарушен заданный стиль».

Список команд и их поведение лучше сверять с актуальной документацией по командной строке Codex: интерфейс и названия со временем меняются.

6. Четыре безопасных сценария для первого запуска

Еженедельный отчёт

Вход: таблица продаж, заметки отдела, отчёт прошлой недели.

Результат: черновик с изменениями, рисками и вопросами.

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

Собери черновик отчёта за текущую неделю из sales/ и заметок встреч. Сравни показатели с прошлой неделей. Не объясняй изменение цифры, если в источниках нет причины. Отдельно покажи новые сделки, сделки в риске и вопросы, требующие решения. Сохрани результат в outputs/weekly-report.md. Перед сохранением перечисли расхождения.

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

Исследование и контент

Вход: статьи, интервью, расшифровки, заметки, ссылки.

Результат: список источников, структура материала или первый черновик.

Проверка: факты связаны с источниками, наблюдения отделены от выводов, неизвестные места вынесены отдельно.

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

Сначала разберите источники, потом просите написать статью. Так в текст не попадут случайные выводы из неразобранной папки.

Обратная связь клиентов

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

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

Проверка: каждая тема подтверждается исходными фрагментами или помечена как единичная; предложения не выдаются за факты.

Разложи отзывы из feedback/ по темам. Сохрани исходные формулировки рядом с каждой темой. Отдельно выдели частые проблемы, единичные сигналы и вопросы, на которые нет данных. Предложи возможные действия, но не ранжируй их по приоритету без критериев.

Это помогает подготовить обсуждение продукта, но не решает, какую функцию строить первой.

Внутренний инструмент

Вход: описание операции, пример данных, ограничения по доступу.

Результат: пробная версия инструмента на вашем компьютере с одной полезной функцией.

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

Собери локальный экран для загрузки CSV. Пользователь выбирает файл, видит первые десять строк и получает понятное сообщение, если нет обязательного столбца. Авторизацию, платежи, публикацию и внешние сервисы не подключай. Готово, когда приложение запускается локально, основной сценарий проверен, а изменённые файлы перечислены.

Ограничение оставляет пробную версию простой и не даёт ей незаметно обрасти лишними библиотеками.

7. Правила проекта (AGENTS.md), которые не нужно повторять

Файл AGENTS.md хранит постоянные правила проекта: где лежат исходники, куда сохранять результат, что нельзя менять, как запускать проверки и что считать готовым.

Команда /init может создать черновик автоматически. После этого его всё равно нужно проверить руками: агент может неверно определить команду запуска или принять временный файл за важный.

Минимальный пример:

# Проект

- Исходники находятся в `sources/`.
- Черновики — в `work/`.
- Результаты для проверки — в `outputs/`.

# Правила

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

# Проверка

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

Сколько правил писать

Записывайте в файл только то, что должно быть верно почти всегда. Если правило пришлось повторить в задании дважды, его стоит перенести в AGENTS.md. Если оно относится к одной процедуре, оставьте его в отдельной инструкции.

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

Если агент останавливается там, где может действовать безопасно, правило лучше сформулировать точнее:

## Инициатива

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

Так контроль остаётся на рискованных действиях, а чтение каждого файла не превращается в отдельный запрос разрешения.

Правила могут быть вложенными

Общие инструкции можно хранить в корне проекта, а узкие — рядом с конкретной папкой. Временный AGENTS.override.md может заменить обычные правила на своём уровне. Такая схема удобна, когда у кода, контента и данных разные ограничения. Подробности есть в официальной документации OpenAI по AGENTS.md.

8. Отдельные инструкции (Skills) для повторяющихся процедур

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

1. найти новые материалы за нужный период;
2. проверить дату и источник;
3. отделить наблюдения от выводов;
4. разложить материалы по категориям;
5. вынести противоречия и пробелы;
6. сохранить обзор и вопросы для решения.

Skill в Codex хранится в виде файла SKILL.md — текстового файла с правилами процедуры; рядом могут быть шаблоны, справочные материалы и скрипты. Описание формата есть в документации OpenAI по таким инструкциям.

Короткий пример:

---
name: weekly-report
description: Собирает черновик еженедельного отчёта из папки sales.
---

1. Прочитай правила проекта и материалы за текущую неделю.
2. Сверь данные с главным источником.
3. Не заполняй пропуски догадками.
4. Сохрани черновик в `outputs/`.
5. Отдельно перечисли расхождения и вопросы.

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

Не нужно писать пошаговый рецепт на каждую мелочь. Для новой версии Codex часто достаточно цели, границ и способа проверки. Жёсткий сценарий оставляйте там, где порядок шагов действительно важен.

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

Практичный запрос для проверки:

Проверь AGENTS.md и отдельные инструкции на правила, которые приводят к лишней работе, конфликтам или ненужным вопросам. Объясни, что именно мешает, и предложи минимальные изменения. Файлы пока не меняй.

9. Git, diff и обратимость

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

Для кода Git даёт несколько контрольных точек:

• рабочие изменения до фиксации;
• diff для просмотра;
• сохранённая версия проекта;
• pull request для обсуждения и проверки.

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

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

Pull request можно воспринимать как короткий отчёт о работе: что изменилось, зачем, какие проверки прошли и что осталось посмотреть. В небольшой команде по нему проще быстро понять, что именно принимается.

10. Как выбрать режим работы и следить за лимитом

Даже сильная версия ИИ (искусственного интеллекта) не исправит неясную задачу. Она не определит, какую дату считать отчётной, какой источник главный и что делать с расхождениями.

Уровень рассуждений — это настройка, которая определяет, сколько времени и вычислений программа потратит на задачу. Выбирайте его по сложности работы:

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

Начинайте с Low или Medium. Если агент не справился, сначала проверьте входы, формулировку и критерий готовности. Повышение уровня не добавит отсутствующий файл и не угадает нужный формат.

Уровень рассуждений влияет на время ответа и расход лимита. Лимит — это доступный объём использования Codex. Лимиты и доступные режимы меняются, поэтому перед большой задачей смотрите раздел Usage (экран с расходом лимита) в настройках. Смотрите на стоимость всей работы:

ручная работа + проверка + исправления + цена задержки

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

Новая версия Codex может задавать больше уточняющих вопросов, читать правила буквально и тщательнее проверять мелкие изменения. Это полезно, пока правила точные. Если в AGENTS.md написано слишком общее «ничего не делать без разрешения», программа будет останавливаться на каждом безопасном шаге.

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

11. Длинные чаты и настройки

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

Один чат — одна связная задача

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

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

Важные решения лучше переносить в файлы:

• правила — в AGENTS.md;
• процедуру — в отдельной инструкции;
• исходные данные — в sources/;
• решения и открытые вопросы — в короткий рабочий документ;
• удачные примеры — в examples/.

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

config.toml

Настройки, которые действуют между запусками, можно хранить в обычном файле config.toml. Там задаются версия Codex по умолчанию, уровень рассуждений, правила подтверждений и подключения к внешним сервисам. В приложении те же параметры обычно доступны через раздел Settings (настроек).

Обычно есть общий файл настроек ~/.codex/config.toml, настройки внутри проекта .codex/config.toml и разовые параметры для запуска из командной строки. Настройки проекта относятся к конкретной рабочей папке, а общие — ко всей среде. Описание задачи и правила проверки держите в AGENTS.md и отдельных инструкциях: настройки отвечают за среду, а не за смысл работы.

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

12. Доступы, безопасность и подключения к внешним сервисам

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

На первых этапах не давайте агенту самостоятельный доступ к:

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

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

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

Подключения к внешним сервисам (MCP)

Агент видит папку проекта. CRM — система учёта клиентов и продаж, таск-трекер — сервис для ведения задач, база данных и аналитика — рабочая информация. Codex не увидит эти системы, пока вы не передадите данные или не подключите внешний инструмент.

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

Перед подключением нужно решить:

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

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

Расписание

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

Если днём в проекте работают люди, задачу по расписанию лучше запускать в отдельной рабочей копии проекта. Иначе ночной отчёт может столкнуться с незавершёнными ручными изменениями.

13. Один агент или несколько

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

Несколько агентов, то есть несколько отдельных помощников, нужны, когда работу можно разделить на независимые части:

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

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

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

1. результаты действительно независимы;
2. их нужно сравнивать;
3. основному исполнителю понятно, как разбираться с противоречиями.

Если ответы на эти вопросы отрицательные, лучше поручить работу одному агенту: так будет проще и дешевле.

Сложные роли можно хранить в проекте отдельно, например в .codex/agents/. Но новичку достаточно разделить работу в самом запросе и дать одному исполнителю собрать итог.

14. Неделя первого эксперимента

День 1. Приложение и папка

Откройте приложение ChatGPT, выберите Codex и рабочую папку. Попросите описать проект, ничего не меняя.

День 2. Git и правила

Сделайте первый коммит. Запустите /init или создайте короткий AGENTS.md вручную. Поправьте команды запуска и проверки.

День 3. Одна реальная задача

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

День 4. Режим плана

Возьмите задачу побольше и попросите план через /plan. Уточните только вопросы, без которых работу нельзя продолжить, а затем поручите её выполнение.

День 5. Расход лимита

Откройте раздел Usage (экран с расходом лимита) в настройках утром и вечером. Посмотрите, сколько лимита уходит на простые и сложные задачи. Не используйте высокий уровень рассуждений для любой мелкой правки.

День 6. Первый skill

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

День 7. Облако или второй skill

Если проект уже лежит на GitHub, отдайте одну безопасную задачу в облачный Codex и примите результат через pull request. Если GitHub пока не нужен, вместо этого закрепите вторую повторяемую процедуру.

В конце недели сравните процесс с исходной точкой:

• сколько времени прошло до первого пригодного результата;
• сколько правок внёс человек;
• какие ошибки агент заметил сам;
• что пришлось объяснять заново;
• какая часть риска всё ещё требует ручной проверки.

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

15. Что чаще всего ломается

Правила приходится повторять в каждом задании

Постоянные правила перенесите в AGENTS.md, а отдельную процедуру — в отдельную инструкцию.

Агент не видит, как проверить результат

Добавьте команды запуска и проверки в правила проекта. Попросите перечислить, какие проверки выполнены.

Большая задача начинается без плана

Используйте /plan, интервью или PLANS.md до первой правки.

Полный доступ выдан с первого дня

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

Две задачи меняют одну папку

Разделите чаты и рабочие копии. Для параллельной или ночной задачи используйте отдельную рабочую копию проекта.

Расписание включили слишком рано

Проведите несколько ручных запусков, оформите процедуру в отдельной инструкции и только потом включайте автоматический черновик. Отправку оставьте на следующий уровень.

Руководитель смотрит каждый шаг

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

Один чат используется для всего проекта

Контекст разрастается, старые решения мешают новым. Разделяйте связные задачи, используйте /compact и переносите важное в файлы.

Старые запреты мешают новой модели

Если агент спрашивает разрешение на каждый безопасный шаг или создаёт лишние проверки и отчёты, проверьте AGENTS.md и отдельные инструкции. Не добавляйте ещё одну инструкцию поверх старой — сначала найдите конфликт.

Высокий уровень рассуждений используется всегда

Для мелкой правки дополнительное время на рассуждение редко меняет результат. Начните с Low или Medium и повышайте уровень только по результату.

16. Шаблоны для старта

Бриф задачи

Результат:
Входные материалы:
Ограничения:
Критерии готовности:
Что делать при пропуске или противоречии:
Что показать перед сохранением или отправкой:

Запрос на план

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

Запрос на завершение

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

Проверка перед передачей результата

[ ] Оригиналы сохранены.
[ ] Источники и спорные места указаны.
[ ] Изменения можно увидеть и отменить.
[ ] Проверки связаны с изменённым участком.
[ ] Внешняя отправка или публикация подтверждены отдельно.
[ ] Следующий запуск сможет начать работу из файлов проекта.

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

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

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

Агент берёт на себя часть рутины. Решения, для которых нужны контекст и ответственность, остаются у человека.

Маркетолог начинает редактировать через ChatGPT тексты. Менеджер загружает расшифровку встречи и просит подготовить follow-up. HR сравнивает резюме кандидатов. Руководитель прикрепляет отчёт и ищет отклонения. Разработчик отправляет кусок кода, чтобы быстрее найти ошибку.

Через несколько месяцев нейросетями пользуется уже половина команды. Производительность выросла, часть рутины исчезла, появились первые автоматизации.

И только потом возникает вопрос: а что именно всё это время сотрудники отправляли в ИИ?

Полные записи разговоров с клиентами? Резюме с телефонами и почтой? Договоры? Финансовые таблицы? Коммерческие предложения? Внутренние исследования? Исходный код? Доступы к другим системам?

Потому что вместе с ИИ компания создаёт новый способ работы со своей информацией. Если этот способ никто не спроектировал, сотрудники спроектируют его сами.

Самые опасные ошибки обычно выглядят как нормальная работа

Хороший пример — история Samsung в 2023 году. Сотрудники компании использовали ChatGPT для совершенно понятных рабочих задач и передали во внешний сервис конфиденциальные материалы, включая исходный код и содержание внутренней встречи. После серии подобных случаев компания ограничила использование генеративных ИИ-сервисов сотрудниками.

В этой истории интересен не масштаб Samsung, а сам механизм.

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

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

Четыре вещи, которые нужно спроектировать вместе с ИИ

Удобно смотреть на любое внедрение через четыре уровня:

1. Задача. Что именно мы поручаем ИИ?
2. Данные. Какая информация нужна ему для этой задачи?
3. Инфраструктура. Где эта информация будет обрабатываться?
4. Ответственность. Кто проверяет результат и отвечает за дальнейшее действие?

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

Например, задача звучит прекрасно: автоматически анализировать звонки отдела продаж.

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

Для составления короткого follow-up нейросети большая часть этого вообще не нужна.

Хорошая автоматизация начинается с вопроса «без каких данных она всё ещё сможет решить задачу».

С персональными данными всё шире, чем кажется

Обычно под персональными данными представляют паспорт, СНИЛС или банковскую карту.

Но понятие значительно шире: это информация, которая относится прямо или косвенно к определённому или определяемому человеку.

В обычной работе такими данными могут оказаться:

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

Поэтому удалить имя недостаточно.

Если в документе осталось: «финансовый директор единственного филиала компании X в Казани, 43 года», конкретный человек вполне может быть понятен и без фамилии.

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

Пять вопросов к любому процессу с персональными данными

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

Не обязательно становиться специалистом по 152-ФЗ, чтобы заметно улучшить процесс. Для начала достаточно заставить команду отвечать на пять вопросов:

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

Эти вопросы быстро вскрывают странные решения.

Допустим, служба поддержки внедряет ИИ-бота. Пользователь пишет туда имя, номер телефона, адрес доставки, номер заказа, прикладывает фотографию товара и описывает проблему.

Но если модель должна только определить проблему и подготовить ответ, зачем ей адрес клиента? Возможно, достаточно номера заказа, фотографии и текста обращения, а всё остальное внутренняя система уже знает сама.

Чем меньше чувствительных данных входит в ИИ-процесс, тем меньше потом приходится защищать.

Не всё чувствительное является персональными данными

Вторая распространённая ошибка — защищать только данные людей.

Представим файл, в котором нет ни одной фамилии и ни одного телефона. Зато внутри:

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

Для компании потеря такого документа может оказаться не менее болезненной.

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

Поэтому перед отправкой файла полезно задавать два вопроса:

Можно ли по этим данным определить человека?

Будет ли проблема, если эта информация окажется за пределами компании?

Первый вопрос ловит персональные данные. Второй — всё остальное, что имеет ценность именно потому, что пока известно не всем.

Причём коммерческая тайна — это не просто файл с названием SECRET. Для полноценного режима коммерческой тайны организация должна сама оформить и поддерживать соответствующие внутренние меры и документы.

Не загружайте документ целиком только потому, что это возможно

Одна из самых полезных практик при работе с ИИ — создавать отдельную рабочую версию исходных данных.

Допустим, маркетолог хочет улучшить коммерческое предложение.

Исходник:

Иван Петров, ООО «Альфа», проект «Вектор», стоимость 4 700 000 рублей, запуск 18 сентября.

Для редакторской задачи модель вполне может получить:

Клиент №7, Компания А, проект [ПРОЕКТ], стоимость [СУММА], запуск [ДАТА].

Смысл документа сохранился. Ненужные для задачи данные исчезли.

Рабочая последовательность может выглядеть так:

1. Создать копию исходника и не менять оригинал.
2. Удалить ФИО, телефоны, email, адреса, реквизиты и номера документов, если они не нужны.
3. Заменить компании, проекты, суммы и внутренние обозначения условными метками.
4. Проверить косвенные признаки, по которым всё ещё можно восстановить человека или клиента.
5. Удалить технические детали, не участвующие в задаче.
6. Только после этого передавать очищенную версию модели.

Главный принцип здесь не в механическом удалении фамилий.

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

Если вы обучаете собственную модель — это уже другой сценарий

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

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

Нужно отдельно проверить:

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

Здесь полезно запомнить простую вещь:

данные, которые компания накопила, и данные, которыми она вправе обучать ИИ, — не обязательно один и тот же набор.

Облако, корпоративный сервис или локальная модель?

После разговора о рисках легко уйти в крайность: всё чувствительное обрабатывать только локально.

Иногда это действительно правильное решение, но универсального ответа нет.

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

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

При этом локальная модель тоже может быть настроена плохо.

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

Вопрос не в том, где моднее запускать модель.

Вопрос в том, какой уровень контроля требуется конкретным данным.

Корпоративный тариф

Здесь возникает ещё одна опасная иллюзия.

У корпоративных продуктов и API могут быть существенно более строгие правила работы с данными, чем у обычных пользовательских аккаунтов. Например, бизнес-продукты OpenAI по умолчанию не используют данные клиентов для обучения моделей. (верим)

Это действительно важно, но две фразы нельзя путать:

«данные не используются для обучения»

и

«данные не передаются внешнему поставщику».

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

Поэтому перед профессиональным использованием нового ИИ-сервиса стоит проверять не только качество модели.

Нужно понять:

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

Само пользовательское соглашение тоже можно сначала разобрать с помощью ИИ: дать документ модели и попросить заполнить такой чек-лист. Но важные выводы после этого лучше проверить по оригинальным условиям.

Платная подписка — это набор возможностей. Не сертификат безопасности ваших данных.

Российское законодательство

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

С ИИ так не работает.

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

Поэтому юридически проверяют не абстрактный «ИИ». Проверяют конкретное действие, которое компания решила с его помощью выполнять.

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

В России ключевым для работы с персональными данными остаётся 152-ФЗ. Он регулирует основания и цели обработки, обязанности оператора, безопасность, локализацию и трансграничную передачу персональных данных.

Для компании здесь важны несколько практических вещей.

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

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

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

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

Новый закон об ИИ уже принят, но пока ещё не действует

Здесь есть важное изменение буквально этого лета.

26 июля 2026 года был опубликован Федеральный закон №243-ФЗ «О поддержке развития технологий искусственного интеллекта в Российской Федерации».

Это произойдёт 1 сентября 2026 года.

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

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

Для практической работы вывод остаётся прежним:

проверять нужно конкретный ИИ-процесс, а не просто наличие слова «ИИ» в законодательстве.

Штрафы

Ответственность за нарушения в области персональных данных в последние годы заметно выросла.

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

Но я бы не строил внедрение только вокруг страха штрафа.

До штрафа можно спросить, себя (если вы владелец) или владельца (если вы внедренец):

Через какие ИИ-сервисы вы обрабатываете ваши звонки?

И внезапно выяснится, что один менеджер работает через корпоративный аккаунт, второй через личный, третий загружает записи стороннему боту, а четвёртый вообще не помнит название сервиса.

Это уже не только юридическая проблема, у вас на лицо :) отсутствие контроля.

Есть ещё вторая сторона риска: что ИИ возвращает обратно

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

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

Особенно опасно это там, где человек использует ИИ именно потому, что плохо знает предмет.

Поэтому вместе с классификацией данных нужна классификация решений.

Например:

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

Чем дороже ошибка, тем меньше автономности нужно давать модели.

Здесь человеческая проверка — это нормальная конструкция процесса.

Как это выглядит на обычных рабочих задачах

Теория становится намного понятнее, когда смотришь на конкретные процессы.

Внутренний финансовый отчёт

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

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

Коммерческое предложение

Если задача — отредактировать текст, реальное название клиента, сумма сделки, номер договора и внутренние условия чаще всего не нужны.

Замените их условными обозначениями и работайте с содержанием.

Тендерная переписка

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

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

Резюме

Для сравнения опыта кандидатов обычно не нужны ФИО, телефон, email и домашний адрес.

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

Исходный код

Нет смысла передавать целый закрытый репозиторий ради одной ошибки.

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

База клиентов

Не начинайте с загрузки таблицы.

Сначала задайте вопрос: какую закономерность мы ищем? Часто реальные ФИО, телефоны и email вообще не участвуют в ответе.

Что ещё нужно проверить самостоятельно под свой проект

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

Их стоит исследовать отдельно:

• Автоматические решения по людям. HR-скоринг, кредитные решения, страхование и другие процессы, где вывод алгоритма влияет на права человека.
• Медицина. Работа с медицинской информацией, рекомендациями и специальными категориями персональных данных.
• Банки, страхование, транспорт и государственный сектор. Здесь могут действовать дополнительные отраслевые требования.
• GDPR. Если деятельность попадает под европейское регулирование, нужен отдельный анализ обработки и передачи данных.
• Авторские права. Нужно смотреть юрисдикцию, человеческий творческий вклад и условия конкретного генератора.
• Реклама и дипфейки. Использование ИИ-контента может затрагивать требования к рекламе, достоверности и введению потребителя в заблуждение.
• Маркировка ИИ-контента. Правила в этой области продолжают развиваться, поэтому конкретный режим стоит проверять на момент публикации.
• Договоры с клиентами. Отдельно посмотреть NDA, условия обработки информации и разрешено ли подключать внешних поставщиков.
• Обучение собственных моделей. Если используются клиентские данные или большие внутренние массивы, этот процесс стоит проектировать отдельно.

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

Минимальный ИИ-регламент можно собрать на одной странице

Большой корпоративный документ на старте часто никто не читает.

Гораздо полезнее короткий регламент, который отвечает на понятные вопросы.

В нём должны быть семь вещей:

1. Разрешённые сервисы. Какие инструменты можно использовать и через какие аккаунты.
2. Типы данных. Что можно отправлять свободно, что только после очистки, а что нельзя передавать внешним сервисам.
3. Правило минимизации. Модель получает только необходимый для задачи контекст.
4. Работа с аккаунтами. Кому принадлежат ассистенты, базы знаний, API-ключи и автоматизации.
5. Человеческий контроль. Какие результаты нельзя использовать без проверки.
6. Порядок подключения новых сервисов. Кто проверяет их условия и безопасность.
7. Действия при ошибке. Кому сообщать, если уже отправили лишнее.

Последний пункт особенно важен.

Запретить любую ошибку невозможно. Можно сделать так, чтобы сотрудник не пытался её скрыть.

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

Удалить чат и сделать вид, что ничего не произошло, — не процесс реагирования.

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

Сначала проведите простой аудит.

Попросите команду перечислить всё, что она реально использует: ChatGPT, Claude, DeepSeek, Perplexity, генераторы изображений, сервисы расшифровки, ИИ для кода, Telegram-ботов, браузерные расширения, внутренних ассистентов и автоматизации.

Потом для каждого инструмента ответьте:

• кому принадлежит аккаунт;
• какие данные туда поступают;
• есть ли персональные или клиентские данные;
• подключены ли почта, CRM, Drive, Notion, репозитории или другие системы;
• где хранится история;
• кто имеет доступ;
• кто проверяет результат;
• что произойдёт при увольнении сотрудника.

Особенно полезен последний вопрос.

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

Человек уходит — и вместе с ним исчезает часть инфраструктуры компании.

Раньше бизнес терял таким образом таблицы и пароли. Теперь можно потерять целого ассистента.

Самая простая проверка

Представьте, что завтра крупный клиент спрашивает:

Какие ИИ-сервисы вы используете при работе с нашей информацией? Какие наши данные туда передаются? Где они обрабатываются? Кто имеет к ним доступ? Кто отвечает за результат?

Сможете собрать ответ за час?

Если да, у вас уже есть хотя бы базовый контроль.

Если для этого придётся писать в общий чат «кто вообще чем пользуется?» — то пу пу пуууу.

ИИ вы уже внедрили. Управление им — ещё нет.

Именно поэтому внедрение заканчивается не в момент покупки подписки и не после обучения сотрудников промптам.

Нужно понять задачу, данные, инфраструктуру, права доступа, цену ошибки и ответственность.

А уже потом решать, где нужен облачный сервис, где корпоративный API, где локальная модель, а где ИИ вообще не должен видеть исходный документ.

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

Но плохо спроектированные процессы они ускоряют ровно так же.

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

Я бы разделял процесс на четыре этапа: аудит, R&D, разработка и внедрение. Их можно объединять в одном проекте, но результат каждого этапа должен оставаться понятным.

Аудит показывает, где есть смысл работать

На аудите мы выясняем, какие задачи выполняет компания и каким способом. Для этого проводим созвоны с заказчиком и сотрудниками, собираем информацию из чатов, фиксируем действия и приводим всё к единой структуре.

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

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

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

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

R&D проверяет реализуемость

R&D (Research and Development), объединяет исследование и разработку. На этом этапе команда проверяет, может ли ИИ выполнить выбранную задачу с нужным качеством.

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

Текущий процесс называют As-Is. Это подробная схема того, как задача выполняется сейчас. Будущий процесс называют To-Be. В нём уже учитывается роль ИИ, новые точки контроля и изменения в работе сотрудников.

Для описания процессов можно использовать CJM (Customer Journey Map), BPMN (Business Process Model and Notation) или обычную Flow-схему. Конкретный формат зависит от сложности задачи. Важнее зафиксировать логику работы, чем выбрать красивое название схемы.

Например, сейчас HR получает резюме, сравнивает его с вакансией, проверяет опыт кандидата и передаёт подходящие варианты руководителю.

В будущем процессе система может извлекать требования из вакансии, сравнивать их с резюме, объяснять результат и передавать HR список кандидатов для финальной проверки.

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

R&D также помогает оценить стоимость разработки. Если этап исследования включён в проект, смету можно подготовить здесь. Если компания пропускает R&D, оценку нужно сделать перед разработкой и отдельно зафиксировать уровень неопределённости.

Разработка начинается с перевода бизнес-задачи

Фраза «автоматизировать проверку резюме» для программиста слишком общая.

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

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

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

Для уже понятного процесса ориентир может выглядеть так: около 50% усилий занимает разработка и автоматизация, около 30% сбор и подготовка данных, ещё 10% коммуникация и анализ и 10% настройка моделей.

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

В новом бизнес-процессе распределение меняется ещё сильнее. Команда тратит время на поиск методики, эксперименты, консультации с экспертами и проверку результата.

Новый процесс требует методики

Есть два разных сценария внедрения ИИ.

Первый, компания хочет автоматизировать процесс, которого у неё пока нет в устойчивом виде. Например, поручить ИИ вести переписку с клиентами, создавать эффективный контент или проверять договоры, хотя сотрудники сами не используют единую методику.

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

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

Затем методику переводят в промпты, инструкции, примеры и правила проверки.

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

Старый процесс переносится быстрее

Второй сценарий связан с уже работающим процессом.

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

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

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

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

Компания может знать, что хочет увеличить конверсию до 30%, но не понимать, какие действия приводят к такому результату. В этом случае сначала нужно найти методику. Одного целевого показателя для автоматизации недостаточно.

Инструкции для ИИ становятся частью процесса

ИИ работает устойчивее, когда получает не общее пожелание, а подробное описание методики.

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

Особенно полезно это для задач, которые специалист выполняет интуитивно.

Обратный промпт-инжиниринг

Метод позволяет восстановить скрытую логику по входным данным и готовому результату.

Возьмём работу HR с интервью. На входе есть описание вакансии, информация о компании, требования к кандидату и его будущие обязанности. На выходе находятся вопросы, которые HR задал на собеседовании.

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

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

Так можно получить первую версию методики. Затем её нужно проверить на новых примерах и показать опытному HR.

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

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

Что делать, если бизнес не понимает собственный процесс

Это одна из самых частых проблем на аудите.

Сотрудник может много лет выполнять задачу и не уметь её объяснить. В ответ появляются фразы «делаю по опыту», «смотрю по ситуации» или «обычно понимаю сразу».

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

Помогает и обратный промпт-инжиниринг. Он позволяет извлечь часть правил из уже выполненной работы.

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

Сотрудников нужно включать в проект

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

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

Полезно провести короткий мастер-класс с демонстрацией возможностей и ограничений ИИ. Программу обучения можно собрать из вопросов руководителей, запросов HR и опросов сотрудников.

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

Иначе система может быть технически готова, но не войти в ежедневный процесс.

Как оценить результат после внедрения

До начала проекта компания оценивает, сколько времени занимает задача и какой эффект даст автоматизация.

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

Затем прогноз сравнивается с фактом.

Если ожидалась экономия 40% времени, а фактическая экономия составила 25%, это не означает, что проект провалился. Возможно, сотрудники используют систему только на части процесса или тратят время на дополнительную проверку результата.

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

С чего начать первый проект

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

Затем провести небольшой R&D, проверить решение на ограниченном наборе данных и только после этого переходить к разработке.

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

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

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

Собственнику нужен ответ на четыре вопроса:

• сколько ресурсов занимает задача сейчас;
• можно ли автоматизировать её технически;
• какие риски возникнут;
• какой эффект получит бизнес.

Два типа запроса

Компании обычно приходят с одним из двух запросов.

Первый вариант: внедрить ИИ в бизнес, но пока нету понимания, какие процессы выбирать.

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

Второй вариант: автоматизировать конкретную задачу.

Например, анализировать резюме, вносить данные в CRM или расшифровывать звонки отдела продаж.

Тогда аудит начинается сразу с этой задачи, но критерии оценки остаются теми же.

Пять критериев приоритизации

1. Технологическая готовность

Сначала нужно понять, насколько задача совместима с текущими возможностями ИИ.

Проверяем:

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

Например, ИИ может предварительно оценивать резюме по требованиям вакансии. Финальное решение о найме при этом остаётся за рекрутером.

2. Инфраструктура

Следующий вопрос связан с тем, где будет работать решение.

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

Тогда потребуется оценить:

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

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

3. Стоимость внедрения

В расчёт нужно включить не только цену модели или готового сервиса.

Учитываются:

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

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

4. Риски

Ошибки ИИ могут привести к разным последствиям.

Репутационные риски: клиент получит некорректный ответ от чат-бота.

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

Финансовые риски: ИИ неправильно рассчитает скидку, изменит заказ или передаст клиенту товар по ошибочной цене.

Для каждой задачи нужно заранее определить:

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

Чем дороже ошибка, тем выше требования к контролю.

5. Бизнес-эффект

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

Собираем четыре показателя:

1. сколько сотрудников выполняют задачу;
2. сколько времени они на неё тратят;
3. сколько времени потребуется после внедрения;
4. сколько стоит час работы.

Базовая формула:

Эффект от времени = (часы до автоматизации − часы после автоматизации) × стоимость часа

Стоимость часа можно рассчитать так:

Стоимость часа = затраты на сотрудника за месяц ÷ рабочие часы за месяц

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

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

Как оценить влияние ИИ

Есть два способа.

Экспериментальный способ.

Замерить, сколько времени сотрудник тратит на задачу сейчас, затем дать ту же задачу ИИ и сравнить:

• скорость;
• качество;
• количество ошибок;
• время на проверку результата.

Это самый точный подход.

Экспертная оценка.

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

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

Пример предварительной оценки

Предположим, компания рассматривает три задачи.

Расчёт выглядит так:

• анализ рекламы: 50 сотрудников × 10 часов = 500 часов;
• ввод данных в CRM: 30 сотрудников × 5 часов = 150 часов;
• скрининг резюме: 10 рекрутеров × 20 часов = 200 часов.

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

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

Четыре варианта бизнес-эффекта

1. Экономия времени рекрутеров

Предположим:

• автоматизация экономит одному рекрутеру 3 часа в день;
• в компании 30 рекрутеров;
• 240 рабочих дней в году;
• зарплата рекрутера составляет 100 000 рублей в месяц;
• рабочее время — 160 часов в месяц.

Годовая экономия времени:

3 × 30 × 240 = 21 600 часов

Стоимость часа:

100 000 ÷ 160 = 625 рублей

Расчёт эффекта:

21 600 × 625 = 13 500 000 рублей в год

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

Стоимость ИИ-решения и его внедрения нужно вычесть отдельно.

2. Рост производительности копирайтеров

Предположим:

• один копирайтер пишет 3 статьи за 8 часов;
• после внедрения ИИ он выпускает 9 статей;
• в команде 10 копирайтеров;
• текущая зарплата — 100 000 рублей;
• после роста производительности зарплата составляет 150 000 рублей.

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

Стоимость команды после внедрения:

10 × 150 000 = 1 500 000 рублей в месяц

Стоимость команды из 30 человек при прежней производительности:

30 × 100 000 = 3 000 000 рублей в месяц

Разница:

3 000 000 − 1 500 000 = 1 500 000 рублей в месяц

Годовой эффект:

1 500 000 × 12 = 18 000 000 рублей

Расчёт работает при сохранении качества, наличии нужного объёма задач и учёте расходов на ИИ, редактуру и контроль.

3. Речевая аналитика в отделе контроля качества

Допустим:

• 20 менеджеров по продажам делают по 20 звонков в день;
• всего получается 400 звонков;
• один специалист контроля качества может прослушать 50 звонков;
• зарплата специалиста — 50 000 рублей;
• речевая аналитика стоит 100 000 рублей в месяц.

Один специалист покрывает:

50 ÷ 400 = 12,5% звонков

Чтобы проверить все звонки вручную, потребуется 8 специалистов:

8 × 50 000 = 400 000 рублей в месяц

Разница со стоимостью речевой аналитики:

400 000 − 100 000 = 300 000 рублей в месяц

Годовой эффект:

300 000 × 12 = 3 600 000 рублей

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

4. Разговорный робот для необработанных звонков

Предположим:

• компания получает 500 звонков в день;
• менеджеры не успевают обработать 10%;
• теряется 50 звонков в день;
• стоимость привлечения одного звонка — 100 рублей;
• средняя конверсия в продажу — 30%;
• средний чек — 10 000 рублей.

Количество необработанных звонков за год:

50 × 360 = 18 000 звонков

Стоимость привлечения этих звонков:

18 000 × 100 = 1 800 000 рублей

Количество потенциальных продаж:

18 000 × 30% = 5 400 продаж

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

5 400 × 10 000 = 54 000 000 рублей

В этом расчёте 54 млн рублей отражают выручку. Для оценки прибыли нужно умножить сумму на маржинальность продукта.

Итоговый эффект складывается из двух разных показателей:

• 54 млн рублей потенциальной выручки;
• 1,8 млн рублей предотвращённых расходов на привлечение потерянных звонков.

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

Как выбрать первую задачу

Для первого внедрения подходят задачи, у которых:

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

Приоритет можно распределить так:

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

Минимальная таблица для аудита

Для каждой задачи зафиксируйте:

1. название процесса;
2. сотрудников, которые его выполняют;
3. частоту и длительность;
4. используемые инструменты;
5. входные данные и результат;
6. допустимый уровень ошибок;
7. вариант внедрения: API или закрытый контур;
8. разовые и регулярные расходы;
9. бизнес-эффект;
10. риски и способ ручной проверки.

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

Система называется «спросите у человека, который всё знает». Работает до первого отпуска, больничного или увольнения.

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

Что даёт аудит

Аудит помогает разобрать процесс от начала до конца.

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

В контексте ИИ аудит отвечает на несколько практических вопросов:

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

Данные могут находиться в документах Word, таблицах Excel, CRM, мессенджерах, базах данных и внутренних системах.

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

Два сценария внедрения

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

Повышение эффективности сотрудников

В этом случае сотрудник продолжает выполнять задачу, но передаёт ИИ часть рутинной работы.

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

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

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

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

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

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

Автоматизация процессов

При автоматизации система сама принимает данные, обрабатывает их и передаёт результат дальше.

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

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

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

При этом запрос «хотим автоматизировать анализ резюме» может привести к трём разным решениям:

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

Выбор зависит от объёма операций, сложности критериев, бюджета, требований к контролю и доступных данных.

Готовый сервис или разработка

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

Готовый сервис подходит для типовой задачи, которую уже решают продукты на рынке.

Например:

• ИИ-секретарь записывает итоги встречи;
• сервис анализирует тональность отзывов;
• система отвечает на отзывы покупателей маркетплейса;
• речевая аналитика проверяет разговоры продавцов;
• сервис фильтрует входящие заявки и передаёт релевантных клиентов менеджерам.

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

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

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

Например:

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

Перед разработкой стоит изучить рынок. Отсутствие знакомого готового решения ещё ничего не говорит о рынке. Возможно, продукт уже существует, но компания о нём не знает.

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

Как провести аудит

Я бы начинал с одного конкретного процесса, в котором уже видна проблема.

Подойдут такие задачи:

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

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

1. Опишите входящие данные

Что приходит в работу, откуда сотрудники получают информацию и в каком формате она хранится.

2. Зафиксируйте действия сотрудников

Кто принимает решение, кто переносит информацию, кто проверяет результат и кто отвечает за следующий этап.

3. Найдите повторяющиеся операции

Поиск, сортировка, копирование данных, заполнение таблиц, подготовка типовых текстов и перенос информации между системами.

4. Отметьте места задержек

Где появляется очередь. На каком этапе сотрудники ждут друг друга. Какие действия приходится переделывать.

5. Посчитайте объём работы

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

6. Отделите рутину от экспертной работы

Классификацию, поиск, сравнение, подготовку черновиков и обработку больших массивов данных можно передать ИИ.

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

7. Проверьте данные

Какие документы, таблицы, записи, переписки и базы доступны. Можно ли использовать их для обработки. В каком виде они хранятся.

8. Определите критерии качества

Как понять, что ИИ справился хорошо. Что считается ошибкой. Кто проверяет результат. В каких случаях система должна передать задачу человеку.

9. Изучите готовые решения

Сравните продукты по функциям, стоимости, срокам запуска, интеграциям, ограничениям и возможностям настройки.

10. Посчитайте экономику

Сколько стоит внедрение. Сколько времени оно освободит. Как снизится нагрузка на сотрудников. Какой объём сможет обработать команда. Какие расходы можно сократить.

11. Запустите пилот

Возьмите один участок процесса и проверьте решение на реальных данных.

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

Что должно появиться на выходе

Хороший аудит заканчивается конкретным решением, а не списком модных ИИ-сервисов.

В итоговом документе должны быть:

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

Главный вопрос аудита звучит так:

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

Поэтому сначала нужно разложить процесс по шагам. Затем проверить данные, изучить рынок и сравнить варианты внедрения.

И только после этого выбирать технологию.

Гораздо важнее другие вопросы:

• Кто смотрит — человек, принимающий решение, или случайный зритель?
• Почему он смотрит — изучает тему из любопытства или прямо сейчас ищет решение?
• На каком этапе выбора он находится?
• Сколько для бизнеса стоит один клиент?

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

Самые полезные видео часто выглядят скучно

Видео, которые могут приносить клиентов в B2B, редко выглядят как эффектный развлекательный контент.

Чаще это материалы на конкретные темы:

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

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

Здесь работает не столько масштаб, сколько намерение зрителя.

Важен момент контакта

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

Большая часть маркетинга пытается привлечь внимание слишком рано. Человек пока только замечает тему или сохраняет информацию на будущее. Он ещё не готов что-либо менять.

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

Но когда человек ищет ответ на мучительно конкретный вопрос, всё меняется. Он уже:

— признал проблему;
— понял её серьёзность;
— представляет возможную стоимость решения;
— боится ошибиться;
— сравнивает подходы и подрядчиков.

В этот момент видео уже не столько убеждает его в необходимости покупки, сколько снижает риск неправильного решения.

Почему простое видео иногда работает лучше дорогого

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

Зритель оценивает не зрелищность. Он пытается понять:

• «Эти люди действительно разбираются в моей ситуации?»
• «Они уже решали похожие задачи?»
• «Понимают ли они ограничения и риски?»
• «Можно ли доверить им серьёзный бюджет?»

Возможно, именно поэтому в B2B ясность часто оказывается важнее харизмы, а конкретика — важнее визуального лоска.

Это не значит, что качество съёмки не имеет значения. Плохой звук и неаккуратная подача снижают доверие. Но техническое качество здесь усиливает содержание, а не заменяет точный ответ на проблему клиента.

Видео может заранее подготовить продажу

У таких материалов есть эффект, который сложно заметить в обычной статистике.

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

Потенциальный клиент заранее узнаёт:

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

К моменту личного разговора он может решать уже не вопрос «покупать или не покупать», а вопрос «у кого покупать».

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

Контент заменяет повторяющиеся консультации

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

— почему это столько стоит;
— почему нельзя сделать быстрее;
— какие есть риски;
— чем решение отличается от более дешёвого;
— что произойдёт после начала работы;
— какие результаты можно и нельзя обещать.

Если ответы существуют только внутри отдела продаж, компания вынуждена каждый раз объяснять всё заново.

Видео позволяет вынести эти ответы наружу. Один раз разобранное возражение продолжает работать для следующих клиентов.

Со временем из таких материалов складывается библиотека, которая показывает опыт компании ещё до первого разговора. Человек видит не заявление «мы эксперты», а признаки того, что команда действительно сталкивалась с похожими задачами.

Видео должно быть частью системы принятия решения

Вероятно, видео работает сильнее, если не воспринимать его как отдельный формат.

Один клиентский вопрос можно раскрыть в нескольких видах контента:

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

В центре находится не площадка и не формат, а вопрос покупателя.

Компания замечает, что мешает человеку принять решение, и создаёт материалы, которые снимают неопределённость.

Со временем формируется живая библиотека ответов, которая сообщает потенциальному клиенту:

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

Для дорогого B2B-продукта это может оказаться сильнее громких обещаний и общего имиджевого контента.

Один правильный зритель может быть ценнее тысяч случайных

Возможно, эффективность B2B-видео правильнее оценивать не только по просмотрам, но и по плотности доверия.

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

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

— кто его посмотрел;
— с какой проблемой пришёл;
— какую часть досмотрел;
— какие материалы изучил дальше;
— обратился ли после просмотра;
— насколько подготовленным пришёл на разговор;
— повлияло ли видео на выбор подрядчика.

Для бизнеса также важно, сколько времени такие материалы экономят экспертам и отделу продаж.

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

B2B-видео работает не только на охват

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

Не обязательно развлечь его, впечатлить сложным монтажом или собрать сотни тысяч просмотров.

Нужно точно понять его ситуацию, показать опыт, снять часть неопределённости и помочь принять решение.

Поэтому некоторые внешне «скучные» видео способны годами приводить клиентов и сокращать цикл продажи.

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

В этом материале разберём, как собрать такую систему в n8n:

С чего начать: не с n8n, а с задачи

Одна из самых частых ошибок — открыть n8n и сразу начинать соединять ноды.

В результате получается workflow, который умеет что-то делать, но непонятно зачем. Он собирает новости, генерирует тексты, отправляет сообщения, однако не решает конкретную задачу канала.

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

• Для кого канал?
• Какая у него тема?
• Что именно мы публикуем?
• Какие источники считаем полезными?
• Как часто проверяем новости?
• Нужно ли переписывать каждую новость?
• Где храним материалы?
• Кто принимает решение о публикации?
• Что происходит, если источник не отвечает или AI выдал плохой текст?

Например:

Канал для специалистов, которые следят за ИИ-инструментами. Каждый час система проверяет 10 RSS-лент, 5 Telegram-каналов и несколько источников в X. AI отбирает новости, связанные с генерацией контента и автоматизацией, переписывает их в коротком формате и сохраняет в Google Sheets. Публикация происходит только после ручного одобрения.

Это уже нормальное техническое задание.

Зачем нужен PRD

PRD (Product Requirements Document) — это описание того, что должна делать система.

Он особенно полезен, если вы собираете workflow через AI или используете вайб-кодинг. Когда дать агенту только два предложения, он часто создаёт несколько нод и считает задачу выполненной. Если сначала описать цель, логику, данные и ограничения, результат получается намного ближе к рабочему.

Минимальный PRD для новостного агрегатора может выглядеть так:

# Telegram News Aggregator

## Цель

Собирать новости из заданных источников, отбирать релевантные публикации и готовить их к публикации в Telegram-канале.

## Источники

- RSS-ленты
- Публичные Telegram-каналы
- X/Twitter через Apify или другой парсер
- Google News и другие новостные источники

## Логика

1. Проверять источники каждый час.
2. Приводить все публикации к единому формату.
3. Проверять наличие дубля.
4. Определять актуальность и релевантность.
5. Переписывать подходящие новости.
6. Сохранять результат в таблицу.
7. Отправлять на ручное одобрение.
8. Публиковать только записи со статусом approved.

## Поля записи

- uniqueId
- title
- content
- source
- url
- publishedAt
- summary
- category
- relevanceScore
- status
- telegramMessageId
- error

## Статусы

new → reviewed → approved → published

## Ограничения

- не выдумывать факты;
- не публиковать дубли;
- не отправлять посты длиннее лимита Telegram;
- при ошибке источника сохранять ошибку и переходить к следующему источнику.

Такой документ можно использовать и как основу для n8n-workflow, и как запрос для AI-агента, который помогает собрать систему.

Два контура одной контент-машины

Агрегатор может быть создан из двух контуров.

Первая часть — мониторинг:

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

Вторая часть — создание контента:

• выбираются новые материалы;
• AI анализирует их;
• отбрасывает нерелевантные публикации;
• делает краткое резюме;
• переписывает новость в стиле канала;
• сохраняет готовый текст;
• передаёт его на проверку или публикацию.

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

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

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

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

Какие источники подключать

RSS

RSS — самый простой и стабильный вариант.

Для RSS достаточно получить ленту, разобрать заголовок, описание, ссылку и дату публикации. В n8n для этого можно использовать ноду Read RSS Feed.

RSS хорошо подходит для:

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

Telegram-каналы

Можно отслеживать публичные Telegram-каналы и использовать их как источники новостей.

Можно использовать связку AI Agent + MCP-инструмент Apify. Агент получает название или ссылку на канал, сам выбирает подходящий скрапер и возвращает найденные публикации.

Это удобно, но у такого подхода есть ограничения:

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

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

Можно выбирать только активные источники, затем они распределяются по веткам через Switch.

Не стоит начинать с команды «найди все релевантные каналы». Лучше самостоятельно выбрать 5–10 источников и понять, какие из них действительно дают полезные новости.

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

X/Twitter

X полезен для мониторинга трендов и ранних сигналов, но прямое API может быть платным или требовать отдельного доступа.

На практике используют:

• официальный API;
• Apify;
• MCP-инструменты;
• готовые специализированные скраперы.

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

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

Найди публикации из источника с начала текущей недели.
Верни только посты, опубликованные после последней успешной проверки.

Нормализация и защита от дублей

Публикации из разных источников приходят в разном формате. В одном случае поле называется `title`, в другом — `name`, в третьем вообще есть только текст и ссылка.

Перед AI-анализом их нужно привести к единой структуре.

В Code node можно использовать такой вариант:

const clean = (value) => String(value ?? '').trim();

return $input.all().map((item) => {
const data = item.json;

const title = clean(data.title || data.name);
const content = clean(data.content || data.description || data.text);
const url = clean(data.url || data.link);

const normalizedUrl = url
.split('#')[0]
.replace(/\/$/, '');

const uniqueId = normalizedUrl ||
[
clean(data.source),
clean(data.publishedAt),
title,
content.slice(0, 120)
].join('|').toLowerCase();

return {
json: {
...data,
title,
content,
url: normalizedUrl,
uniqueId,
status: 'new'
}
};
});

После этого `uniqueId` используется для проверки в Data Table или Google Sheets.

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

Для Telegram-постов можно использовать комбинацию:

source + post_id

Например:

telegram:@ai_news_channel:15482

Проверку дублей можно сделать через совпадение URL или пары URL + post_id. Это хороший подход, если workflow запускается каждый час или чаще.

AI-фильтр перед рерайтом

Не каждую найденную публикацию нужно превращать в пост.

Сначала лучше попросить AI оценить новость:

Ты редактор тематического Telegram-канала.

Проанализируй публикацию и верни JSON:

{
"relevant": true,
"relevanceScore": 0,
"category": "",
"shortSummary": "",
"reason": ""
}

Правила:

- relevant — true только если новость подходит аудитории канала;
- relevanceScore — число от 0 до 100;
- shortSummary — одно-два предложения;
- не добавляй факты, которых нет в исходном тексте;
- если публикация рекламная, повторная или слишком слабая,
поставь relevant=false.
```

Дальше в n8n ставится IF:

relevant is true
AND relevanceScore >= 70

Только после этого материал отправляется в дорогой рерайт.

Если новость очень длинная, её можно сначала разделить на части с помощью ноды Summarization. Но чаще дешевле сделать короткое резюме каждой публикации сразу после получения.

Промпт для рерайта

Вот вам довольно практичная редакторская логика:

• короткий заголовок;
• 1–3 абзаца;
• понятный язык;
• сохранение фактов;
• отсутствие кликбейта;
• один релевантный хештег.

Вот адаптированный вариант:

Ты редактор Telegram-канала о технологиях и ИИ.

Перепиши новость на русском языке.

Требования:

1. Заголовок — короткий, до 8 слов.
2. Заголовок верни в поле headline.
3. Основной текст — 90–150 слов.
4. Если новость сложная, допустимо до 200 слов.
5. Сохрани: кто, что сделал, когда, где и почему это важно.
6. Не выдумывай факты и не усиливай формулировки.
7. Не используй кликбейт.
8. Добавь 1–3 уместных эмодзи.
9. В конце добавь один тематический хештег.
10. Не добавляй ссылку, если её нет во входных данных.
11. Ориентируйся на стиль последних опубликованных постов.

Верни JSON:

{
"headline": "",
"body": "",
"hashtag": ""
}

Последние три опубликованных сообщения полезно передавать в этот промпт как примеры. Это помогает сохранить консистентность канала: одинаковую длину, ритм, структуру и уровень подробности.

Подготовка текста для Telegram

Если использовать HTML-разметку Telegram, лучше не отправлять в API необработанный текст от AI.

Сначала можно собрать итоговое сообщение в Code node:

const escapeHtml = (value) => {
return String(value ?? '')
.replace(/&/g, '&')
.replace(/</g, '&lt;')
.replace(/>/g, '&gt;');
};

const headline = escapeHtml($json.headline);
const body = escapeHtml($json.body);

const hashtag = String($json.hashtag ?? '')
.replace(/[^#A-Za-zА-Яа-яЁё0-9_]/g, '');

const telegramText = [
`<b>${headline}</b>`,
'',
body,
hashtag ? `\n${hashtag}` : ''
].join('\n');

return [{
json: {
...$json,
telegramText
}
}];

Теперь в Telegram можно передавать поле `telegramText`.

Публикация через Telegram Bot API

Создаем ноду отправки поста в Telegram.

В n8n это можно сделать через HTTP Request:

Method: `POST`

URL:
https://api.telegram.org/bot{{$env.TELEGRAM_BOT_TOKEN}}/sendMessage

Body Content Type: `JSON`
{
"chat_id": "{{$env.TELEGRAM_CHANNEL_ID}}",
"text": "{{$json.telegramText}}",
"parse_mode": "HTML",
"disable_web_page_preview": true
}

Бота нужно добавить в канал и выдать ему права администратора.

Токены и идентификаторы не стоит вставлять прямо в код. Используйте credentials n8n или переменные окружения.

После успешной отправки сохраните в таблицу:

• `status = published`;
• дату публикации;
• `telegramMessageId`;
• ссылку на источник;
• текст, который был отправлен.

Если публикация завершилась ошибкой, сохраните:
status = error
error = сообщение об ошибке

Так вы сможете повторить отправку, не собирая новость заново.

Почему нужна ручная проверка

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

В таблице достаточно сделать поле `status`:

new → reviewed → approved → published

Workflow может запускаться каждые 5–10 минут и выбирать только записи:
status = approved

После публикации он меняет статус на `published`.

Это даёт возможность:

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

Такая схема особенно важна для новостных каналов.

Бот и канал — это разные элементы

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

Для этого нужен бот.

Связка выглядит так:
Канал → публикации и охват
Бот → команды, заявки, подписка, оплата, рассылки

Через бота можно:

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

Можно использовать через команду `/start` с реферальным кодом:

const message = $json.message || {};
const text = message.text || '';

if (!text.startsWith('/start')) {
return [];
}

const parts = text.split(' ');
const refCode = parts[1]?.startsWith('ref_')
? parts[1]
: null;

const referrerId = refCode
? refCode.replace('ref_', '')
: null;

return [{
json: {
userId: message.from?.id,
chatId: message.chat?.id,
username: message.from?.username || '',
firstName: message.from?.first_name || '',
refCode,
referrerId,
isReferral: Boolean(referrerId),
myRefLink: https://t.me/YOUR_BOT_USERNAME?start=ref_${message.from?.id},
timestamp: new Date().toISOString()
}
}];

Дальше можно проверить через Telegram API, подписан ли пользователь на канал, записать пользователя в Google Sheets или базу данных и посчитать рефералов.

Для обработки разных типов сообщений в n8n используется Switch:

• обычное текстовое сообщение;
• команда;
• callback после нажатия кнопки;
• фото;
• файл;
• voice;
• платёж;
• системное событие.

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

Где здесь ComfyUI и fal.ai

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

В общей контент-машине n8n выступает как координатор:

fal.ai удобен, когда нужен готовый API и упакованные workflows. ComfyUI даёт больше контроля, но требует понимания моделей, нод и окружения. Его можно запускать локально при наличии видеокарты или использовать облачный GPU.

Для добавления текста, субтитров и надписей можно использовать:

• Creatomate;
• Shotstack;
• API fal.ai;
• готовые шаблоны;
• ffmpeg.

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

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

Что даёт вайб-кодинг

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

Например, можно дать AI такой запрос:

Собери workflow для n8n.

Задача:
каждый час проверять список RSS и Telegram-источников,
убирать дубли, оценивать релевантность новостей,
переписывать подходящие публикации и сохранять их
в Google Sheets со статусом new.

Добавь:
- обработку ошибок;
- проверку даты публикации;
- фильтр по relevanceScore;
- поля для ручного одобрения;
- отдельный workflow для публикации записей со статусом approved.

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

После генерации нужно проверить:

• все ли credentials подключены;
• заполнены ли ID таблиц и каналов;
• не остались ли `YOUR_*` и тестовые значения;
• правильно ли указаны даты;
• не пустая ли таблица источников;
• есть ли ветка публикации в Telegram;
• что происходит при ошибке API;
• не отправляется ли один и тот же пост несколько раз.

Самый надёжный подход — запускать workflow по частям:

1. один RSS-источник;
2. нормализация;
3. проверка дубля;
4. AI-фильтр;
5. рерайт;
6. запись в таблицу;
7. ручная публикация;
8. автоматическая публикация после проверки.

Частые ошибки

Подключить слишком много источников

Большой список не означает качественный контент.

Начните с нескольких источников и посмотрите:

• сколько новостей они дают;
• сколько из них реально подходят;
• сколько дублей появляется;
• какие источники чаще ошибаются.

Отправлять весь контент одному агенту

Большой корпус быстро увеличивает стоимость и ухудшает качество.

Лучше использовать несколько этапов:

Сбор → короткое резюме → фильтр → финальный рерайт

Не сохранять историю

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

Нужна таблица или база с уникальным идентификатором и статусом обработки.

Не учитывать стиль канала

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

Передавайте AI несколько последних публикаций или заранее опишите:

• длину;
• структуру;
• уровень эмоциональности;
• допустимые эмодзи;
• отношение к ссылкам;
• формат заголовков.

Полностью довериться агенту

AI Agent может сам выбрать инструмент, но иногда выбирает неподходящий скрапер или возвращает устаревшие данные.

Для критичных источников лучше явно указать, какой API или парсер нужно использовать.

Сразу включить автопубликацию

На старте это почти всегда приводит к ошибкам, дублям и странным формулировкам.

Сначала соберите очередь постов и несколько дней проверяйте её вручную.

Как запустить первую версию

Практический порядок такой:

1. Выберите одну узкую тему.
2. Опишите читателя и тип публикаций.
3. Составьте PRD на одну страницу.
4. Создайте Telegram-канал и бота.
5. Добавьте бота администратором.
6. Создайте таблицу источников и материалов.
7. Добавьте 3–5 RSS-лент.
8. Импортируйте workflow в n8n.
9. Заполните credentials, ID таблиц и канала.
10. Проверьте один источник вручную.
11. Добавьте проверку дублей.
12. Подключите AI-фильтр и рерайт.
13. Настройте статус `approved`.
14. Добавьте публикацию через Telegram Bot API.
15. Опубликуйте первые 5–10 постов вручную.
16. Только после этого включайте расписание.

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

Что можно монетизировать

Telegram-канал может зарабатывать через:

- рекламные размещения;
- платную подписку;
- закрытое сообщество;
- партнёрские ссылки;
- собственные услуги и продукты;
- ботов и мини-приложения;
- платный доступ к аналитике или подборкам.

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

Финальное решение о том, что именно увидит аудитория, всё равно должно оставаться у человека.

Пробуйте :)

На практике всё немного прозаичнее. Сам по себе аватар ничего не решает. Он только ускоряет производство видео или становится интерфейсом для общения. Польза появляется тогда, когда понятно, какую конкретную задачу он выполняет.

Как всё начиналось

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

Это уже работало, но процесс занимал много времени и плохо подходил для регулярного производства контента.

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

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

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

Дальше аватар стал интерактивным. Ему можно дать базу знаний, подключить голосовое общение, встроить на сайт, в чат или в видеозвонок. Теоретически такой персонаж может быть консультантом интернет-магазина, тренером, преподавателем или помощником службы поддержки.

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

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

Какие виды аватаров существуют

Условно можно выделить несколько вариантов.

Говорящая голова

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

Такой вариант хорошо подходит для:

- коротких новостей;
- экспертных видео;
- рекламных сообщений;
- ответов на вопросы;
- регулярных публикаций в социальных сетях;
- обучающих роликов.

Для этого не обязательно создавать полноценного цифрового двойника. Можно использовать готового персонажа или один раз записать собственное видео и сделать на его основе персональный аватар.

Цифровой двойник

Это аватар, похожий на конкретного человека. Он воспроизводит его внешность, голос, мимику и манеру подачи.

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

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

Интерактивный аватар

Такой персонаж не просто говорит заранее подготовленный текст, а реагирует на пользователя.

Его можно использовать как:

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

Интересно, что для интерактивности сейчас часто лучше подходят не суперреалистичные лица, а облегчённые анимированные модели. Например, VRM-персонажи выглядят менее реалистично, зато быстрее реагируют и лучше подходят для живого диалога.

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

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

Маскот

Маскот — это персонаж бренда, который живёт в контенте и постепенно становится узнаваемым.

У Duolingo есть сова, у GitHub — осьминог, у McDonald’s — клоун. Но цифровой маскот может быть не только картинкой или логотипом. Он может вести социальные сети, отвечать на комментарии, появляться в коротких видео и участвовать в рекламных историях.

Здесь важно различать два подхода.

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

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

Универсального ответа нет. Это нужно проверять на практике.

Где аватары уже приносят пользу

Новости и регулярный экспертный контент

Один из самых очевидных сценариев — выпускать короткие видео по заранее подготовленному сценарию.

Так можно делать:

- новости;
- обзоры;
- разборы;
- дайджесты;
- образовательные посты;
- комментарии к событиям.

Вместо того чтобы каждый раз записывать себя, автор готовит текст, а аватар превращает его в видео.

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

Подкасты и диалоги

Один говорящий аватар — это только начало. Можно создавать диалоги между двумя или несколькими персонажами.

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

Такой подход особенно хорошо подходит для:

- сложных обучающих тем;
- финансов;
- разборов книг;
- мини-курсов;
- подкастов;
- сериализованного контента.

Сухой текст иногда тяжело воспринимать. Разговор двух персонажей добавляет динамику и помогает удерживать внимание.

Онлайн-обучение

Цифровой аватар может быть ведущим курса, преподавателем или отдельным персонажем внутри урока.

Его можно использовать для:

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

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

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

Электронная коммерция

В e-commerce аватары используют для демонстрации товаров, примерки и консультаций.

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

Но самый яркий бизнес-кейс сейчас связан не только с примеркой.

В китайском Douyin и TikTok Shop цифровые ведущие могут практически круглосуточно продавать товары в прямом эфире. Они рассказывают о продукте, показывают его характеристики и отвечают на вопросы.

Это уже не эксперимент ради красивой демонстрации. В некоторых рынках такая модель работает в больших объёмах.

Повторить её можно не везде. Нужны подходящая платформа, развитая онлайн-торговля, доступ к нужным API и товар, который действительно можно продавать через такой формат.

Просто сделать аватара и поставить его продавать всё подряд — рабочая бизнес-модель из этого не получится.

Ответы на комментарии

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

Например, под длинным видео на YouTube накопились вопросы. Вместо того чтобы отвечать на каждый вопрос текстом, можно:

1. получить комментарии через API;
2. сохранить их в таблицу;
3. отфильтровать уже обработанные;
4. передать новые вопросы агенту;
5. сгенерировать короткий ответ;
6. превратить ответ в видео с аватаром;
7. сохранить ссылку на готовый ролик;
8. запланировать публикацию.

Такой формат особенно популярен в Instagram и TikTok, где ответ на комментарий часто становится отдельным видео.

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

Главное — заранее проверить доступность API. На некоторых площадках доступ к данным ограничен или требует статуса продавца.

Персональное приветствие

Ещё один хороший кейс — автоматическое приветствие нового пользователя.

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

Это может быть:

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

Сам по себе такой ролик не заменит хороший продукт, но создаёт ощущение персонального контакта и может быть полезен в закрытых сообществах, онлайн-школах и сервисах с платной подпиской.

Какой сервис выбрать

В практической работе чаще всего рассматривались HeyGen, D-ID и Synthesia.

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

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

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

Также появляются новые сервисы вроде Hedra и других платформ. Но выбирать инструмент только по красивому демо не стоит. Нужно проверить конкретный сценарий:

- насколько хорошо он говорит по-русски;
- как работает с вашим голосом;
- насколько естественно двигается лицо;
- сколько времени занимает генерация;
- есть ли API;
- можно ли использовать аватар в автоматическом workflow;
- сколько стоит минута готового видео.

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

Как правильно записать собственного аватара

Большинство проблем начинается ещё до загрузки видео в сервис.

Для исходной записи нужны:

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

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

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

Некоторые платформы также просят отдельное видео, где человек подтверждает согласие на использование своего изображения. Это важная часть процесса, особенно если аватар создаётся не для личного эксперимента, а для коммерческого контента.

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

Главная проблема — голос

С лицами ситуация развивается быстро, а вот с голосом всё сложнее, особенно на русском языке.

Аватар может выглядеть убедительно, но неправильно расставлять ударения, делать странные паузы и неестественно произносить отдельные слова.

В английском многие сервисы уже работают заметно лучше. На русском качество зависит от конкретного голоса, текста и модели.

Есть несколько вариантов:

- использовать готовый голос из библиотеки;
- загрузить собственную запись;
- попробовать клонирование голоса;
- обучить или дообучить отдельную модель;
- использовать внешний сервис синтеза речи.

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

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

Не забывайте про субтитры

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

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

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

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

Как выглядит рабочая контентная фабрика

В простейшем варианте workflow выглядит так:

1. Источник даёт тему или комментарий.
2. Агент готовит сценарий.
3. Текст передаётся в сервис аватаров.
4. Сервис генерирует видео.
5. Результат сохраняется в базе.
6. Видео отправляется на проверку или публикацию.
7. После публикации сохраняются дата, ссылка и статус.

Для хранения удобно использовать таблицу или базу вроде Airtable. В ней можно держать:

- текст комментария;
- ID комментария;
- ID исходного видео;
- сценарий ответа;
- ID аватара;
- ссылку на готовый ролик;
- статус обработки;
- дату публикации.

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

Следующий слой — планирование публикаций. Если контент выходит сразу в Telegram, YouTube, LinkedIn, Instagram и другие каналы, таблица быстро превращается в хаос.

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

В результате получается не просто «аватар, который умеет говорить», а полноценная цепочка:

идея → сценарий → видео → проверка → публикация → аналитика.

Именно эта цепочка представляет основную ценность.

Что пока не работает идеально

У цифровых аватаров есть несколько ограничений, которые лучше учитывать заранее.

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

Русская речь часто звучит хуже английской. Особенно страдают ударения и интонации.

Собственный аватар может генерироваться дольше публичного. Иногда тестовое видео создаётся за минуты, а персональный персонаж заметно задерживается.

API тоже не всегда хорошо документированы. В некоторых сервисах ID группы аватаров не совпадает с ID конкретного аватара, а нужные параметры приходится искать через API.

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

Поэтому не стоит строить проект на сегодняшней цене как на постоянной. Но и считать, что всё автоматически подешевеет и станет выгодным, тоже не нужно. Экономику всё равно надо проверять на своём объёме контента.

С чего начать

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

Например:

- отвечать на комментарии под длинными видео;
- приветствовать новых подписчиков;
- выпускать короткие экспертные новости;
- объяснять один тип учебного материала;
- показывать товары;
- вести одного персонажа бренда.

После этого нужно сделать небольшой тест: 10–20 роликов, посмотреть качество, время производства, стоимость и реакцию аудитории.

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

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

А начинать лучше с самого простого: одного персонажа, одного типа видео и одной измеримой задачи.

Когда говорят про рост в Instagram, почти всегда вспоминают Reels. Снимайте короткие ролики, цепляйте первые секунды, монтируйте динамичнее, попадайте в рекомендации.

Всё это работает, но есть один формат, который многие недооценивают: текстовые карусели.

Это не новый инструмент, но для многих он всё ещё выглядит странно. Вроде бы Instagram — визуальная площадка. Люди должны смотреть фото, видео, сторис, рилсы. А потом выясняется, что есть отдельный тип аудитории, который спокойно листает текстовые карточки.

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

Главное — не воспринимать карусель как «красивые карточки». Это упаковка мысли в формат, который удобно листать.

Почему карусели вообще работают

У карусели есть несколько сильных сторон.

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

Во-вторых, карусели хорошо удерживают внимание. Человек листает слайд за слайдом. Каждое перелистывание — маленькое действие, которое удерживает его внутри материала.

В-третьих, карусели часто сохраняют. Особенно если внутри есть полезная схема, список, разбор, инструкция, чек-лист или мысль, к которой хочется вернуться.

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

В каких нишах карусели особенно сильны

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

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

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

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

С чего начинать

Главная ошибка — открывать Figma и думать: «Что бы такое написать?»

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

Рабочий порядок такой:

1. Найдите конкурентов или авторов в своей нише.
2. Посмотрите их самые сильные посты, Reels, Shorts, видео, треды или статьи.
3. Выпишите темы, которые уже собрали хороший отклик.
4. Превратите эти темы в заголовки для каруселей.
5. Из каждого заголовка соберите отдельную серию слайдов.

Как использовать AI

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

Хороший процесс выглядит так:

Сначала вы даёте AI исходный материал: сценарий видео, текст поста, расшифровку, тему конкурента, свою заметку или список тезисов. Потом просите разложить материал по слайдам.

Пример запроса:

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

После генерации нельзя сразу переносить текст в дизайн. Его нужно отредактировать.

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

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

Рабочая структура карусели

У карусели должна быть драматургия.

Самая простая структура:

Слайд 1. Обложка.
Здесь нужен сильный заголовок. Не красивый, а точный. Человек должен сразу понять, зачем листать дальше.

Слайд 2. Проблема.
Покажите узнаваемую ситуацию. Человек должен подумать: «Да, у меня так же».

Слайд 3. Причина.
Объясните, почему проблема возникает. Не уходите в общие слова.

Слайд 4. Ошибка.
Покажите, что люди обычно делают неправильно.

Слайд 5. Решение или принцип.
Дайте понятную механику, как смотреть на задачу иначе.

Слайд 6. Пример или схема.
Закрепите мысль на конкретике.

Слайд 7. Вывод и действие.
Спросите, предложите сохранить, написать кодовое слово, перейти в профиль или подписаться, если человеку нужна эта тема.

Главное правило: один слайд — одна мысль. Не надо пытаться засунуть статью на 10 000 знаков в семь карточек. Карусель должна читаться легко.

Как писать заголовки для каруселей

Заголовок решает, откроют ли карусель. Если заголовок слабый, всё остальное почти не имеет значения.

Рабочие формулы:

«Почему [действие] не даёт [результат]»
Например: «Почему Reels не продают, хотя собирают просмотры».

«Где вы теряете [важный ресурс]»
Например: «Где бизнес теряет деньги в контенте».

«Как из [сырья] сделать [результат]»
Например: «Как из одного созвона сделать 10 постов».

«Что не так с [привычным действием]»
Например: «Что не так с вашим контент-планом».

«[Инструмент] не спасёт, если нет [системы]»
Например: «AI не спасёт контент, если у вас нет процесса».

Сильный заголовок не обязан быть истеричным, но он должен содержать напряжение. Если в нём нет проблемы, конфликта, пользы или узнавания, человек не видит причины листать.

Дизайн: не надо быть дизайнером, но надо быть аккуратным

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

Минимальный набор:

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

Смысл шаблона в том, чтобы не собирать каждый пост с нуля. Один раз делаете 7–8 слайдов, настраиваете отступы, заголовки, текстовые блоки, подпись, а дальше просто меняете содержание.

Это можно делать в Figma, Canva, Photoshop или любом редакторе, где вам удобно. Инструмент не так важен. Важна повторяемость.

Хороший шаблон экономит время и делает контент серийным. А серийность важна, потому что карусели лучше тестировать не одной публикацией, а пачкой.

Как быстро собрать карусель в рабочем процессе

Процесс можно поставить на поток.

1. Соберите список из 20–30 тем.
2. Для каждой темы сделайте 3–5 вариантов заголовка.
3. Выберите самые сильные.
4. Сгенерируйте или напишите структуру слайдов.
5. Отредактируйте текст вручную.
6. Перенесите в шаблон.
7. Проверьте читаемость с телефона.
8. Экспортируйте слайды в правильном порядке.
9. Опубликуйте в Instagram.
10. Отдельно адаптируйте текст под Threads, если используете эту площадку.

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

Но скорость не должна убивать качество. Самые важные места — заголовок, первый слайд и финальное действие.

Что делать при публикации

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

Можно добавить вопрос в конце. Например:

«У вас сейчас больше ломается идея, упаковка или регулярность?»

Можно добавить кодовое слово. Например:

«Напишите “КАРУСЕЛЬ”, если нужен шаблон структуры».

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

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

Какие метрики смотреть

У каруселей надо смотреть не только лайки.

Важнее:

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

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

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

Частые ошибки

Первая ошибка — делать карусель на случайную тему. Если тема не опирается на боль аудитории, формат не спасёт.

Вторая ошибка — писать слишком много текста. Карусель должна листаться, а не превращаться в PDF на маленьком экране.

Третья ошибка — полностью доверять AI. Нейросеть может собрать черновик, но финальный текст должен пройти человеческую редактуру.

Четвёртая ошибка — копировать чужой визуал без понимания аудитории. Вы можете случайно притянуть не тех людей.

Пятая ошибка — делать каждый раз новый дизайн. Так вы тратите время и не строите узнаваемость.

Шестая ошибка — забывать про финальное действие. Человек прочитал, согласился и ушёл. Нужно дать ему следующий шаг: сохранить, ответить, перейти, написать, подписаться.

Седьмая ошибка — сделать две карусели и решить, что формат не работает. Его нужно тестировать серией. Хотя бы 10–15 публикаций, чтобы увидеть закономерности.

Как встроить карусели в контент-систему

Карусель не должна жить отдельно от остального контента. Это один из элементов контент-завода.

Один длинный ролик можно превратить в несколько каруселей. Один созвон — в карусель с выводами. Один пост — в серию карточек. Один разбор — в короткое видео, статью, карусель и тред.

Рабочая логика такая:

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

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

Главное

Вирусная карусель — это понятная система:

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

Если делать это регулярно, карусели могут стать отдельным каналом роста как ещё один формат в контент-системе.

И в этом их главная ценность: они позволяют быстро превращать идеи, сценарии, созвоны, заметки и экспертные мысли в материалы, которые люди листают, сохраняют и пересылают.

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

После того как вы сделаете предсказуемый вариант "руками", карусели можно автоматизировать.

Практичный гайд для тех, кто хочет удерживать внимание с первых секунд

Крючок — это первые 2–6 секунд, где зритель должен быстро понять тему, почувствовать личную пользу или интерес и захотеть досмотреть. Если в начале видео нет ясности, движения, контраста и согласованности между картинкой, текстом, речью и звуком, ролик теряет зрителя ещё до основной части.

Почему первые секунды решают больше, чем кажется

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

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

На первые секунды стоит закладывать отдельное время. Хороший ориентир — отдавать на крючок до трети всей работы над коротким видео: придумать несколько заходов, проверить визуал, переписать текст, убрать лишнее, пересобрать первую фразу, посмотреть начало без звука и со звуком.

Из чего состоит сильный крючок

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

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

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

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

Словесный крючок отвечает за развитие любопытства. Это первая фраза или несколько коротких фраз, которые дают контекст и открывают вопрос в голове зрителя.

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

Главное правило: все части крючка должны говорить об одном

Слабый крючок часто разваливается из-за рассогласования. Автор говорит про одно, текст на экране обещает второе, визуал показывает третье, а музыка создаёт четвёртое настроение. Зритель не будет разбираться, что именно вы имели в виду. Он уйдёт.

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

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

Две задачи крючка: попасть в интерес и открыть любопытство

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

Быстрый контекст отвечает на вопрос: «О чём это видео и почему мне стоит задержаться?» Чем быстрее зритель понимает тему, тем выше шанс, что он останется. Если крючок начинается с туманной фразы, личного вступления, долгой подводки или эмоционального шума без темы, зритель не успевает понять ценность.

Петля любопытства отвечает на другой вопрос: «Что здесь такого, что мне нужно узнать?» Она появляется, когда в голове зрителя возникает напряжение между тем, что он уже знает, и тем, что вы обещаете раскрыть.

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

Как дать быстрый контекст

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

Чтобы дать контекст, нужно ответить себе на несколько вопросов до съёмки:

1. Какую проблему, желание или интерес зрителя закрывает это видео?
2. Какой результат человек должен ожидать после просмотра?
3. Какие слова он точно поймёт без дополнительного объяснения?
4. Что можно показать на экране уже в первую секунду, чтобы тема стала очевидной?
5. Какая часть темы должна быть вынесена в текст на экране?

Хороший крючок не заставляет зрителя расшифровывать вашу мысль. Он экономит его внимание. Чем меньше усилий нужно для понимания, тем выше шанс удержания.

Почему лучше говорить через зрителя, а не через себя

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

Для крючка сильнее работают формулировки через зрителя: «если вы хотите», «у вас может быть», «ваш контент теряет», «вы делаете ошибку», «вам стоит проверить». Такие фразы быстрее создают ощущение личной значимости. Зритель считывает, что видео касается его, а не только опыта автора.

Это не значит, что личный опыт нельзя использовать, но в первые секунды лучше вывести наружу пользу для зрителя, а личную историю оставить для развития ролика.

Контраст — главный двигатель любопытства

Любопытство появляется там, где есть разрыв между ожиданием и новой реальностью. Зритель думает, что всё устроено одним образом, а вы показываете, что есть другой взгляд, способ, ошибка, результат, причина или скрытая связь.

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

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

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

Рабочие структуры крючков

Для коротких видео можно использовать несколько базовых структур. Их не нужно копировать механически. Лучше понимать, какую задачу решает каждая.

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

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

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

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

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

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

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

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

Как писать словесный крючок

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

Словесный крючок должен быть коротким, но не примитивным. Убирать нужно всё, что не помогает пониманию или любопытству: вводные слова, самоунижение, оправдания, долгие подводки, фразы «на мой взгляд», «мне кажется», «сейчас расскажу одну историю». В начале видео каждая лишняя секунда стоит дорого.

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

Как делать текст на экране

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

Правила простые:

1. Пишите крупно.
2. Не перегружайте экран.
3. Используйте короткие формулировки.
4. Размещайте текст там, где его легко считать.
5. Не закрывайте лицо, действие или важный объект.
6. Следите, чтобы текст не попадал под элементы интерфейса площадки.
7. Не ставьте на экран несколько равносильных мыслей одновременно.

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

Как собирать визуальный крючок

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

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

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

Как использовать звук

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

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

Процесс создания крючка за 10 минут

Начинайте не с монтажа, а с замысла.

Первый шаг — проверьте, какие визуальные материалы у вас уже есть. Возможно, у вас есть сильный кадр, экран, действие, фрагмент съёмки, предмет или результат. Если визуал сильный, крючок можно строить вокруг него.

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

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

Четвёртый шаг — напишите текст на экран. Он должен быть короче речи и быстрее считываться. Не пытайтесь поместить весь тезис в заголовок.

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

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

Проверка перед публикацией

Перед публикацией задайте себе вопросы:

1. Понятно ли за первые 2–3 секунды, о чём видео?
2. Есть ли у зрителя причина смотреть дальше?
3. Видно ли, для кого это видео?
4. Нет ли лишних слов в первой фразе?
5. Совпадают ли речь, текст, визуал и звук?
6. Работает ли начало без звука?
7. Работает ли начало без картинки?
8. Не перегружен ли экран?
9. Достаточно ли движения в кадре?
10. Не обещает ли крючок больше, чем даёт видео?
11. Можно ли усилить контраст?
12. Можно ли сократить первую фразу без потери ясности?

Если хотя бы на несколько вопросов ответ слабый, крючок лучше пересобрать до публикации.

Как искать рабочие крючки в своей нише

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

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

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

Фиксируйте не фразы, а механику. Какая тема вынесена в начало? Как создан контраст? Где появляется вопрос? Что показано в первую секунду? Какой текст стоит на экране? Насколько быстро меняется визуал?

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

Главные ошибки в крючках

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

Вторая ошибка — делать крючок слишком общим. Фразы без конкретной темы не помогают зрителю решить, смотреть дальше или нет.

Третья ошибка — путать интригу с мутностью. Интрига возникает, когда понятна тема, но не раскрыт ответ. Мутность возникает, когда непонятно даже направление.

Четвёртая ошибка — показывать слабый визуал при сильном обещании. Если вы говорите о впечатляющем результате, но картинка не подтверждает его, доверие падает.

Пятая ошибка — перегружать экран. Много текста, стрелок, мелких деталей и лишних объектов мешают пониманию.

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

Седьмая ошибка — растягивать начало. В коротком видео нельзя долго разгоняться. Первый удар должен быть быстрым и понятным.

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

Как понять, что крючок сработал

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

Не оценивайте крючок только по личному вкусу. Иногда автору кажется, что начало слишком прямое, а зрителю именно это и нужно. Иногда автору нравится красивая интрига, но зритель её не понимает. Смотрите на данные и сравнивайте ролики между собой.

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

Практическая формула сильного крючка

Перед каждым коротким видео проходите один и тот же маршрут:

1. Определите, какую ценность получит зритель.
2. Сформулируйте тему так, чтобы её нельзя было понять двояко.
3. Найдите контраст: ожидание аудитории против вашей новой мысли.
4. Напишите первую фразу на 1–2 предложения.
5. Сократите всё, что не помогает пониманию.
6. Подберите визуал, который мгновенно подтверждает тему.
7. Напишите короткий текст на экран.
8. Проверьте согласованность речи, текста, картинки и звука.
9. Запишите несколько дублей.
10. Посмотрите начало без звука, со звуком и целиком.
11. После публикации сравните удержание с обычными показателями.
12. Сохраните удачные решения в свою базу крючков.

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