Можно снять смешной ролик, который посмотрят сотни тысяч человек. Люди посмеются, поставят лайк, отправят его друзьям, напишут «жиза» — и на этом всё закончится. Просмотров много, а заявок нет.

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

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

Вирусный ролик как бизнес-инструмент

Что такое вирусный ролик

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

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

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

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

Почему вирусность стала бизнес-инструментом

Раньше в маркетинговой системе отдельно существовали реклама, сайт, отдел продаж и социальные сети «для присутствия». Сейчас короткие видео могут стать верхним и средним этажом воронки.

Вирусность должна быть связана с бизнесом

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

Какие задачи может решать короткое видео

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

Поэтому не каждый ролик должен сразу продавать.
Один ролик может помочь человеку впервые узнать о вас.
Другой — объяснить, почему у него возникает проблема.
Третий — показать ваш подход.
Четвёртый — привести к комментариям или покупке.

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

Начинайте с конкретного зрителя

Недостаточно написать: «моя аудитория — женщины от 25 до 45» или «владельцы бизнеса». Для ролика нужно понять ситуацию человека.

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

Что он пытается сделать?
Что уже пробовал?
Что у него не получается?
Чего он хочет?
Какими словами он описывает проблему?
Где он сомневается и что сравнивает перед решением?

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

Проверяйте тему четырьмя вопросами

Перед сценарием полезно проверить будущую тему по четырём направлениям:

• Выгода. Что человек получит к концу ролика: ответ, понимание, решение или новый способ посмотреть на ситуацию?
• Интрига. Какой конкретный вопрос останется открытым в начале и будет раскрыт дальше?
• Срочность. Почему хочется разобраться сейчас? Не нужно придумывать искусственный дедлайн, если его нет.
• Причастность. По какой ситуации человек поймёт, что это видео про него?

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

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

Массовая и нишевая вирусность

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

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

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

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

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

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

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

Что делать экспертам с серьёзными темами: психологам, методологам и специалистам, которые не хотят снимать танцы и повторять тренды?

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

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

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

Как видео получает внимание

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

Вирусный ролик обычно проходит несколько этапов.

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

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

На каждом этапе человек может остановиться. Поэтому большой охват сам по себе ещё не означает, что человек дойдёт до заявки.

Как работают рекомендации

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

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

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

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

Первый кадр и первые секунды

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

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

Плохое начало выглядит так: «Всем привет, меня зовут Марина, сегодня я хочу рассказать вам о том…» За это время человек уже может пролистать видео.

Лучше начать с вопроса или мысли, на которую человек хочет получить ответ. Например: «Почему одни музыканты поют в баре за пиво, а другие собирают миллионы?»

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

Боль и внутренний конфликт

Вирусный ролик часто строится на внутреннем напряжении. Человек должен подумать: «Это про меня» или «Наконец-то кто-то сказал это вслух».

Хорошо работают несколько типов конфликтов:

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

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

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

Эмоциональная реакция

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

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

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

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

Алгоритмы и внимание

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

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

Форматы, которые помогают удержать внимание

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

Для бизнеса хорошо работают понятные форматы:

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

Формат — помогает подать смысл так, чтобы человек понял, зачем смотреть дальше.

Как собрать сценарий

Один ролик — один сильный смысл

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

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

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

Простая структура сценария

Когда непонятно, как собрать ролик, можно разложить его на несколько частей:

1. Начало: вопрос, случай или фраза, на которой зритель остановится.
2. Ситуация: что происходит.
3. Проблема: что не получается или что удивляет.
4. Поворот: новая деталь, сравнение или объяснение.
5. Вывод: что стало понятно.
6. Действие: что зритель может сделать дальше, если это подходит ролику.

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

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

Обещание должно совпадать с видео

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

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

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

Призыв к действию

Для холодной аудитории, которая видит вас впервые, подойдут более простые действия:

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

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

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

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

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

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

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

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

Как снять ролик

Что нужно для начала съёмки

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

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

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

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

Свет, фон и базовая техника

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

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

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

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

Как выбрать площадку

Площадку выбирают под аудиторию

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

Instagram, YouTube, ВК, Rutube, TikTok, Pinterest и другие площадки нельзя выбирать только потому, что там сейчас модно публиковаться. Сначала нужно понять, где находится нужная аудитория.

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

Rutube по механике рекомендаций похож на YouTube. Но аудитория там пока меньше и отличается по составу. Поэтому ролики можно дублировать с YouTube и наблюдать, как они работают на новой площадке.

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

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

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

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

Отдельно о TikTok

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

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

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

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

У TikTok есть отдельная особенность: даже новый аккаунт может получить большой охват, если ролик хорошо удерживает внимание.

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

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

Как ролики работают вместе

Ролики без системы и ролики в системе

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

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

Доверие

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

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

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

Почему контент помогает платному трафику

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

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

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

Система контента

Система контента состоит из четырёх элементов:

1. Цель — что мы продаём в этом месяце.
2. Смыслы — что клиент должен понять, почувствовать и узнать, чтобы принять решение.
3. Рубрикатор — постоянные темы, через которые мы доносим эти смыслы.
4. План — что, когда, в каком формате и с какой целью выходит.

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

Как организовать производство

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

Работу можно организовать по циклу.

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

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

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

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

В пятый день опубликовать ролики и проверить первые показатели.

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

Как понять, сработал ли ролик

Что проверять после публикации

После выхода ролика естественно смотреть на просмотры. Но одних просмотров недостаточно.

Проверьте:

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

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

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

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

Просмотры не всегда показывают результат

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

Что делать после публикации

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

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

Итоговая формула

Формулу вирусного ролика можно записать так:

крючок + боль + смысл + удержание + CTA.

Крючок останавливает внимание. Боль помогает человеку узнать себя. Смысл объясняет, что происходит. Удержание ведёт через ролик до конца. CTA показывает, что делать дальше.

Главное

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

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

Что дальше

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

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

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

Что дальше

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

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

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

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

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

Начни с чернового монтажа

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

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

ИИ может найти и удалить:

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

Лучше перечислять требования прямо. Например:

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

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

Точные таймкоды

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

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

Это особенно заметно в коротких видео для Reels, Shorts и TikTok. Там важны доли секунды.

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

Проверяй три вещи:

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

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

Как скрывать склейки

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

Такой переход называют jump cut, или резкой склейкой.

Скрыть его можно несколькими способами:

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

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

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

Можно дать модели такую инструкцию:

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

Начало видео должно быстро объяснить, зачем смотреть дальше

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

В начале можно использовать:

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

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

У приближения есть несколько вариантов.

Push in, постепенное приближение к объекту.

Pull back, постепенное отдаление.

Cut in, резкая смена крупности без плавной анимации.

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

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

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

Перебивки должны объяснять мысль

B-roll, или перебивка, — это дополнительный визуальный материал поверх основной речи.

В качестве перебивки можно использовать:

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

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

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

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

Музыку нужно описывать конкретно

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

В запросе стоит указать:

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

Например:

Добавь спокойную электронную музыку без вокала. Используй её только в интро и переходах. Громкость музыки должна быть около 10 процентов от громкости основной речи. Во время объяснений музыка должна оставаться на заднем плане.

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

Для видео о продукте держи простую структуру

Короткий ролик о функции или продукте обычно длится от 30 секунд до минуты с небольшим.

Ему достаточно четырёх частей:

1. Крючок.
2. Проблема или контекст.
3. Демонстрация решения.
4. Следующий шаг.

Например:

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

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

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

Начинай с раскадровки

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

Раскадровка показывает:

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

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

Можно написать:

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

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

Используй референсы, но не копируй их целиком

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

Модель может разобрать, из чего состоит визуальный приём:

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

После этого попроси применить принцип к твоему материалу.

Например:

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

Есть три рабочих способа использовать референсы:

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

Референс задаёт направление. Твои материалы и бренд должны остаться основой видео.

Зафиксируй фирменный стиль

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

Чтобы этого избежать, подготовь бренд-кит:

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

Одной фразы «сделай в моём стиле» мало. Модель сама начнёт додумывать, и результат может уйти в случайные цвета и декоративные решения.

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

Для длинных видео работай сегментами

Длинный ролик лучше разделить на части. Например:

• интро;
• первая тема;
• вторая тема;
• демонстрация;
• финал.

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

При работе сегментами проще:

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

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

Можно попросить:

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

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

После первого варианта почти всегда появляются замечания.

В текстовом чате приходится писать:

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

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

Хорошая правка состоит из трёх частей:

1. Где изменить.
2. Что изменить.
3. Какой результат нужен.

Например:

На 00:18 замени белый текст на жёлтый. Размер и положение оставь прежними.

Чем конкретнее комментарий, тем меньше повторных итераций.

Сохраняй удачные процессы

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

После удачного проекта зафиксируй:

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

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

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

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

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

Так видео собирается быстрее, а контроль над содержанием остаётся у автора.

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

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

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

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

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

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

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

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

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

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

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

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

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

Поиск тоже может сразу показать готовую сводку вместо списка источников для сравнения. Это удобно, но важно не забывать проверять, откуда взялся ответ и какие мнения остались за его пределами. Google описывает такие сводные ответы в своих функциях AI Overviews и AI Mode

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

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

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-канал может зарабатывать через:

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

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

Финальное решение о том, что именно увидит аудитория, всё равно должно оставаться у человека.

Пробуйте :)