Перестаньте учить менеджеров промптингу: им нужны готовые сценарии, а не курсы по prompt engineering

Почему курсы по prompt engineering для менеджеров проваливаются

Корпоративные L&D-практики 2025-2026 годов фиксируют устойчивую закономерность: значительная часть сотрудников, прошедших курс по промптингу, через несколько недель возвращаются к привычным инструментам. Slack, Excel, пересылка задач руководителю. Как будто курса не было.

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

Менеджер по продажам не думает утром: "Как бы мне улучшить свои промпты?" Он думает: "Мне нужно подготовить отчёт для совета директоров, и у меня на это два часа, которых нет." У него конкретная боль с конкретным дедлайном. А курс предлагает ему изучить chain-of-thought, few-shot prompting и role prompting. Это словарь продуктовой команды. Не его.

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

С AI та же история, но курсы упорно идут в сторону архитектуры.

Исследования 2025-2026 годов указывают на так называемый Curiosity Gap: адаптация AI-инструментов нередко срывается ещё до тренинга, потому что сотрудники не понимают, зачем им это именно в их роли. Финдиру непонятно, как промптинг поможет ему закрыть квартальную отчётность быстрее. HR-директору непонятно, где именно в его рабочем дне появляется этот инструмент. Без ответа на "зачем мне лично" любой тренинг превращается в обязательную галочку.

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

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

Что такое сценарий и чем он отличается от промпта

Промпт это инструкция модели. Текст, который ты пишешь в чат и надеешься, что LLM правильно поймёт. Хороший промпт получается у того, кто разбирается в формулировках, ролях, форматах вывода и умеет тестировать варианты. Это навык AI-инженера, не РОПа.

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

Конкретный пример. РОПу нужен недельный pipeline-обзор. В сценарном подходе он жмёт кнопку "Weekly pipeline review" в дашборде Copilot, выбирает свою команду и период, получает готовый слайд с разбивкой по стадиям, рисками и просроченными сделками. Под капотом сценарий вытянул данные из CRM по фильтру, прогнал через утверждённый шаблон, проверил, что цифры сходятся с источником, и собрал PPTX. РОП промпт не видел и не писал.

// Структура сценария вместо обучения промптингу
{
  "id": "weekly-pipeline-review",
  "trigger": "button:dashboard",
  "inputs": ["crm_filter:my_team", "period:7d"],
  "prompt_template": "...закрытый шаблон, поддерживается AI-командой...",
  "output": "pptx + email",
  "owner": "revops-team",
  "version": "2.4.1"
}

Обрати внимание на три поля: owner, version, prompt_template. У сценария есть хозяин (revops-team), он версионируется как обычный код, и шаблон промпта это внутренний артефакт, а не пользовательский интерфейс. Когда модель обновляется или формулировка ломается на регрессионных тестах, владелец катит версию 2.4.2. Менеджер этого даже не замечает, у него та же кнопка с тем же результатом.

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

Сценарий же это продукт. У него есть SLA, тесты, история изменений, метрики использования. Менеджер выбирает сценарий из каталога ровно так же, как выбирает отчёт в Power BI или Tableau. Он не пишет SQL для отчёта, он его потребляет. С AI логика та же.

Именно по этой парадигме построены платформы 2026 года: Microsoft Copilot Studio с его topics и actions, Salesforce Agentforce с агентскими сценариями поверх Data Cloud, внутренние корпоративные GPT-агенты на базе Azure OpenAI или Bedrock. Везде свободный промптинг отодвинут на задний план для разработчиков сценариев, а конечный пользователь работает с каталогом готовых задач. Учить РОПа промпт-инжинирингу в этой архитектуре примерно так же осмысленно, как учить его писать VBA-макросы в Excel.

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

Реальная экономика: курс на 40 часов vs библиотека из 20 сценариев

Посчитаем честно. Корпоративный курс по prompt engineering для отдела из 50 менеджеров включает прямую стоимость обучения плюс скрытые затраты: десятки часов рабочего времени каждого участника по ставке менеджера в B2B-компании. Суммарно это ощутимые вложения. А на выходе, люди, которые "умеют писать промпты". Что это означает в конкретных операциях, не скажет никто.

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

Разница не в деньгах. Разница в том, как измеряется окупаемость.

Сценарий экономит 20 минут на операции, которую менеджер делает 15 раз в неделю. Это 5 часов в неделю, это 250 часов в год, это конкретная строчка в таблице. Курс экономит... что? Никто в L&D не может ответить на этот вопрос, и это не претензия к конкретным тренерам, а структурная проблема жанра.

Показательный подход из практики 2025 года: команда продаж в одной B2B SaaS-компании отказалась от тренинга по ChatGPT. Вместо этого интегрировала кнопки прямо в Salesforce, каждая запускает готовый сценарий под конкретный этап воронки. Менеджеры не учились "работать с ИИ". Они нажимали кнопку и получали черновик. Экономия на рутинных задачах оказалась измеримой и попала в квартальный отчёт.

L&D-бюджеты в 2026 году смещаются именно в эту сторону. Не "обучить сотрудников пользоваться ИИ", а "встроить ИИ-операции в рабочий процесс так, чтобы пользоваться было нечему: всё уже работает". Это другая логика закупки, другой отдел-заказчик (Operations, не Training), другой KPI.

Курс даёт знание. Сценарий даёт результат. Компании всё реже готовы платить за первое, когда второе дешевле и измеримо.

Разработка одного ролевого сценария с ИИ обходится в 8-12 раз дешевле найма внешнего тренера на аналогичную тему.

Какие сценарии реально нужны менеджерам в 2026 году

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

Продажи. Три вещи, которые работают каждый день. Первая: подготовка к встрече по аккаунту, когда модель вытаскивает из CRM последние касания, собирает свежие новости по компании клиента и формирует один лист с гипотезами. Вторая: разбор записи звонка через Gong или Chorus, причём не пересказ "о чём говорили", а конкретно, где клиент возражал, какие триггеры он называл, что осталось без ответа. Третья: follow-up письмо по шаблонам компании, не сгенерированное с нуля, а собранное из утверждённых блоков с подстановкой деталей встречи. Менеджер тратит на это 3 минуты вместо 25.

Финансы и операции. Сверка отчётов между системами (BI выгрузка против ручной таблицы из филиала), самый частый запрос от финансовых контролёров. Дальше идёт объяснение отклонений в P&L человеческим языком: модель смотрит на цифры и формулирует гипотезы, почему маржа в апреле просела на 2.3 пункта, а финдир уже выбирает, какие проверять. И комментарии к бюджету для борда, где из десяти страниц цифр надо собрать полстраницы текста по фиксированной структуре.

HR и тимлиды. Здесь три устойчивых сценария. Суммаризация 1-on-1 за квартал, что повторяется, где человек буксует, какие обещания я ему дал и не выполнил. Подготовка performance review на основе истории задач из Jira или Linear плюс фидбэков из Lattice: это не финальная оценка, это черновик, который руководитель потом правит руками. И job description, собранный по корпоративному фреймворку грейдов, а не по абстрактному "напиши вакансию senior PM".

Маркетинг. Бриф на креатив строго по фреймворку компании (если у вас есть свой шаблон с полями audience, insight, RTB, tone, модель должна заполнять именно его). Адаптация одного материала под несколько каналов: один и тот же запуск разворачивается в пост LinkedIn, email, два варианта для Telegram и сценарий для короткого видео. Анализ кампании по фиксированному набору метрик, который команда согласовала заранее, чтобы каждый раз не переизобретать таблицу.

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

Общее правило, которое повторяется на каждом внедрении: рабочий сценарий привязан к существующему артефакту и существующему процессу. Если в компании нет шаблона follow-up письма, AI его не создаст осмысленно. Если нет чек-листа рисков по договорам, разбор договора превратится в красивую воду. Сначала артефакт и процесс, потом ассистент поверх них. В обратном порядке не работает, проверено десятками пилотов, которые тихо закрылись в 2024-2025.

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

Как собрать библиотеку сценариев: процесс на 6-8 недель

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

Неделя 1-2. Интервью. Берём 8-12 менеджеров из разных ролей: финансы, HR, продажи, операционка, юристы. Главная ошибка спрашивать "где бы вы применили ИИ". На этот вопрос отвечают мусором: пересказывают статьи из LinkedIn или говорят "ну, для аналитики". Правильный вопрос звучит иначе: "какие повторяющиеся задачи у тебя занимают больше 30 минут и делаются по шаблону". Сразу всплывает реальное: подготовка еженедельного отчёта по пайплайну, ответы на типовые запросы от подрядчиков, сводка по тикетам за неделю.

Чек-лист для интервьюера:

# Чек-лист интервью для выявления сценариев
1. Какие 3 задачи ты делаешь каждую неделю по шаблону?
2. Сколько минут уходит на каждую?
3. Что является входом (письмо, отчёт, тикет)?
4. Что является выходом (документ, сообщение, число)?
5. Кто проверяет результат?
6. Где ты сейчас тратишь время на форматирование, а не на мышление?

Шестой вопрос самый ценный. Если человек тратит 40 минут на копирование цифр из дашборда в слайды, это идеальный кандидат.

Неделя 3. Приоритизация. Сводим всё в таблицу: задача, частота в неделю, средняя длительность, количество людей с такой же болью. Сортируем по произведению частота × длительность × охват. Топ-15-20 идут в работу, остальное в бэклог с пометкой "вернуться через квартал". Не пытайтесь обработать всё сразу, это убьёт пилот.

Неделя 4-5. Прототипирование. Рабочий стек зависит от инфраструктуры заказчика: Copilot Studio, когда уже есть M365, OpenAI Assistants, когда нужна гибкость, внутренняя платформа, если в неё вложились. На каждый сценарий фиксируется четыре вещи: системный промпт, источники данных (какой SharePoint, какая БД, какой API), формат вывода (markdown-таблица, JSON, текст письма), и критерий "готово" (что должно быть в ответе, чтобы пользователь не переделывал).

Неделя 6. Пилот. 5-10 человек, не больше. Метрики три:

• время выполнения задачи до и после
• количество правок, которые пользователь внёс в вывод модели
• NPS конкретного сценария по шкале 0-10 после каждого использования

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

Неделя 7-8. Докрутка и запуск. На каждый сценарий пишу одностраничную карточку: что делает, когда использовать, что обязательно проверить руками перед отправкой. Одна страница, не десять. Если не помещается, значит сценарий слишком сложный и его надо резать на два.

Дальше, операционка. Без неё библиотека сгниёт за квартал. Нужны три вещи: владелец каждого сценария (конкретный человек, не "команда AI"), ежемесячный аудит качества по логам и фидбеку, и канал обратной связи, где пользователи кидают жалобы и идеи. Обычно это отдельный Teams-канал плюс форма с обязательным полем "что пошло не так". Без обязательного поля приходят только лайки, а нужны баги.

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

Что всё-таки стоит давать менеджерам вместо курса по промптингу

Тридцать минут онбординга. Не лекция про архитектуру трансформеров, не разбор параметра temperature. Просто: вот каталог сценариев, вот кнопка, вот куда писать, когда что-то сломалось. Всё. После этого менеджер может работать.

Второй блок: AI-гигиена. Это единственная "теория", которую реально нужно передать. Какие данные нельзя вставлять в публичные модели (персональные данные клиентов, NDA-материалы, внутренние финансовые показатели). Как распознать галлюцинацию: если ИИ называет конкретную цифру или имя, её нужно проверить в источнике, точка. Не "скорее всего проверьте", а обязательно. Модели уверенно врут про даты, должности, ссылки.

Про ответственность стоит говорить прямо. ИИ готовит черновик. Решение принимает человек. Это не философская оговорка, это юридический и репутационный факт. Ряд исследований 2025-2026 годов фиксирует закономерность: когда аудитория узнаёт, что письмо или аналитику написал ИИ без редактуры, доверие к отправителю снижается. Причём не к ИИ, а к конкретному человеку, который подписался. Менеджерам полезно это знать до, а не после.

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

Чего в программе нет совсем: chain-of-thought, top-p, контекстные окна, few-shot примеры. Это не снобизм. Просто менеджеру среднего звена с загруженным календарём не нужно знать, как работает нейросеть. Ему нужно знать, как работает инструмент на его рабочем столе. Это разные вещи.

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

Я видел, как хорошие сценарии умирают одинаково. Бизнес-аналитик замечает, что AI-ассистент отвечает по устаревшей процедуре. Он пишет тикет в IT. Тикет висит три недели. Потом ещё две на согласование. К тому моменту сценарий уже никто не использует, потому что люди нашли обходной путь руками.

Это не проблема технологии. Это проблема владения.

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

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

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

В 2026 году именно эту операционную модель продвигают Salesforce с его Agentforce, Microsoft с Copilot Studio и крупные консалтинговые дома. Deloitte и BCG, судя по публичным материалам, активно развивают практики в этом направлении. Они не делают ставку на курсы по промптингу, это выяснилось нежизнеспособным. Они продают операционный слой: кто владеет, кто меняет, кто несёт ответственность за результат.

Без этого слоя AI-инструменты превращаются в брошенные пилоты.

Когда за сценарии отвечает конкретный человек, а не «все сразу», качество контента растёт быстрее и обновления выходят регулярно.

Где AI-консалтинг действительно полезен, а где это продажа воздуха

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

Полезный AI-консалтинг начинается с аудита процессов. Не с "видения", не с roadmap на 40 слайдов, а с конкретного разбора: где в вашей операционке есть повторяемые сценарии с предсказуемым вводом и выводом. Это скучная работа с Visio, регламентами и интервью с линейными сотрудниками. После этого консультант помогает построить операционную модель под агентов, то есть кто что делегирует, кому, с каким контролем. Дальше идёт настройка платформы: Copilot Studio, Agentforce, кастомный стек на LangGraph или аналогах. И отдельная история, которую многие игнорируют: регулярный red-teaming сценариев. Проверка, как агент себя ведёт при нетипичных запросах, при попытке prompt injection, при граничных данных. Это не разовая задача, это операционный процесс.

Теперь про воздух.

Тренинг по промпт-инжинирингу для топ-менеджмента за 8 тысяч долларов в день. Я видел эти программы. CEO два дня учится писать системные промпты и уходит с сертификатом. Никакого операционного выхода нет, только ощущение, что компания "занимается AI". Сертификаты "Prompt Engineer Level 2" от различных вендоров в 2026 году не значат ничего для реального внедрения. Библиотека из 500 универсальных промптов без привязки к вашим процессам, CRM и регламентам, это просто файл в Notion, который через месяц никто не открывает.

Хороший консультант в первой встрече спрашивает: какая у вас CRM, на каком ERP работаете, есть ли задокументированные регламенты для процессов, которые хотите автоматизировать. Если вместо этого разговор начинается с "какое у вас видение AI-трансформации", это сигнал.

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

По деньгам скажу прямо. Компании на 500 человек, которая хочет реально внедрить агентов в 2-3 процесса, нужно закладывать существенный бюджет на старт: аудит, архитектура, интеграции, первые сценарии в продакшене. После этого операционная поддержка требует выделенных людей внутри: как правило, это гибрид из одного-двух своих специалистов плюс частичная поддержка от консультанта. Кто обещает "внедрить AI" под ключ за минимальный бюджет, продаёт демо, а не систему.

Возражения: "но менеджеры должны понимать, как работает ИИ"

Должны. Я не спорю с этим тезисом. Вопрос в том, что значит "понимать".

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

Для ИИ эквивалент выглядит так: модель уверенно выдаёт неверный факт и не маркирует его как ошибку. Контекст ограничен, и длинный разговор "портится". Один и тот же запрос в двух сессиях может дать два разных ответа. Всё это объясняется за 20 минут онбординга, и этого хватает для осознанного использования.

Это не 40-часовой курс по трансформерным архитектурам.

Даль

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