Нажмите «Развернуть ответ», чтобы увидеть полное решение по каждому заданию.
Ольга — project-менеджер, которая запускает внутренний продукт на пилотной группе из 20 сотрудников. Обратная связь приходит из форм, рабочих чатов, писем и заметок со встреч. Ольге приходится вручную переносить отзывы в общий реестр, кратко формулировать их суть, распределять по категориям, находить возможные повторы и определять, какие проблемы требуют внимания в первую очередь.
Цель автоматизации — не передать принятие решений ИИ, а сократить ручную обработку входящих сообщений. Система готовит структурированный черновик, а project-менеджер проверяет и подтверждает результат.
Вход: новый отзыв участника пилота из формы, таблицы или рабочего чата.
Обработка:
Условия:
Выход: обновлённый реестр обратной связи с краткими описаниями, категориями, предполагаемой критичностью и отметками о возможных повторах.
Контроль: project-менеджер подтверждает классификацию, объединение дублей и приоритет. Только после этого проблема может попасть в рабочий бэклог.
В этом сценарии ИИ выполняет вероятностную смысловую работу: понимает текст, сокращает его и предлагает классификацию. No-code-сценарий выполняет детерминированные действия: получает данные, заполняет поля, проверяет условия, меняет статусы и отправляет уведомления.
| Уровень | Действие студента | Результат |
|---|---|---|
| Рутинная задача 1 | Передаёт модели набор отзывов и просит кратко сформулировать суть каждого | Таблица с краткими описаниями |
| Рутинная задача 2 | Создаёт справочник категорий и составляет инструкцию для классификации отзывов | Промпт-классификатор |
| Рутинная задача 3 | Добавляет правила определения критичности и условия обязательной ручной проверки | Матрица приоритетов и исключений |
| Мидл-задача 1 | Настраивает автоматическое добавление новых отзывов в единый реестр | Автоматизированный реестр |
| Мидл-задача 2 | Добавляет ветвления для блокирующей ошибки, возможного дубля и неизвестной категории | Сценарий обработки исключений |
| Финальная задача | Собирает цепочку: новый отзыв → обезличивание → анализ ИИ → реестр → ручная проверка → передача подтверждённой проблемы | Рабочий прототип системы обработки обратной связи |
Студент учится сначала определять структуру результата, затем применять ИИ только для смыслового анализа текста, а строгие правила автоматизации — для дальнейших действий. Та же архитектура переносится на другие задачи:
Важно, что модель не получает право самостоятельно менять бэклог или принимать управленческие решения. Она готовит предложение, которое проверяет ответственный сотрудник.
Тот же учебный принцип можно показать на другом частом сценарии: расшифровка встречи поступает в систему, модель выделяет решения, задачи, ответственных, сроки и открытые вопросы, а автоматизация раскладывает результат по полям. Записи с пропущенным сроком, неясным ответственным или неоднозначной формулировкой получают статус «Требует уточнения». Project-менеджер сверяет черновик с расшифровкой и только после проверки переносит задачи в трекер.
Этот вариант проще для новичка, но менее оригинален. Он хорошо подходит для первого знакомства со схемой «неструктурированный текст → структурированный результат → проверка → действие».
Анна руководит образовательным проектом — франшизой робототехники для детей от двух лет. После каждого занятия преподаватели отправляют родителям фотографии и короткий отчёт: что дети собирали, какое физическое явление изучали и какие эксперименты проводили. Такие отчёты помогают родителям видеть ценность занятий и влияют на удержание клиентов.
Основная часть преподавателей — стажёры, которые хорошо работают с детьми, но им сложно быстро переработать методические материалы в понятный и содержательный текст. Подготовка одного отчёта вручную занимала около 40 минут. В реальном эксперименте руководительница настроила чат языковой модели на нескольких удачных примерах, готовила через него пять отчётов примерно за 40 минут вместо предполагаемых трёх часов, редактировала результат и постепенно передала этот способ работы преподавателям.
Цель учебной автоматизации — превратить проверенный ручной процесс в управляемый сценарий: преподаватель указывает тему и факты занятия, система готовит черновик по методическим материалам, а человек проверяет его перед отправкой родителям.
Вход: преподаватель заполняет короткую форму: дата и тема занятия, возраст группы, собранная модель, изученное явление, проведённый эксперимент и ссылка на фотографии.
Обработка:
Условия:
Выход: черновик отчёта в едином стиле с понятным описанием занятия, изученного принципа и эксперимента, а также ссылка на подготовленные фотографии.
Контроль: преподаватель проверяет соответствие реальному занятию, методическую корректность, понятность для родителей и отсутствие выдуманных деталей. После подтверждения обычная автоматизация публикует или отправляет отчёт по выбранному каналу.
Здесь ИИ преобразует факты и методический материал в понятный родителям текст. No-code-сценарий собирает данные, находит нужный источник, проверяет обязательные поля, управляет статусами и отправкой. Человек остаётся источником фактов и отвечает за финальную проверку.
| Уровень | Действие студента | Результат |
|---|---|---|
| Рутинная задача 1 | Сравнивает несколько хороших отчётов и выделяет их общую структуру, тон и обязательные элементы | Шаблон качественного отчёта |
| Рутинная задача 2 | Передаёт модели факты одного занятия и составляет инструкцию для подготовки текста по шаблону | Первый черновик и рабочий промпт |
| Рутинная задача 3 | Проверяет промпт на разных темах и создаёт чек-лист фактической и методической проверки | Набор тестов и чек-лист контроля |
| Мидл-задача 1 | Настраивает форму, таблицу и автоматическую передачу данных в модель | Прототип генерации черновиков |
| Мидл-задача 2 | Подключает методические материалы и добавляет ветвления для пропущенных данных, неизвестной темы и ручного согласования | Сценарий обработки исключений |
| Финальная задача | Собирает цепочку: форма преподавателя → поиск методического контекста → генерация → проверка → подтверждение → отправка родителям | Рабочий прототип системы подготовки отчётов |
Студент учится автоматизировать подготовку регулярного контента, не отдавая модели право придумывать исходные факты. Для этого нужно отделить данные от формы подачи, определить надёжный источник контекста, задать шаблон результата и встроить человеческую проверку.
Та же схема переносится на другие задачи:
Сильная сторона этого варианта — реальный подтверждённый кейс с измеримым сокращением времени и последующим внедрением в команду. Ограничение — исходный процесс был не полной автоматизацией, а работой человека с ИИ. Поэтому в учебном фрагменте важно явно показать переход от ручного эксперимента к no-code-сценарию, а не выдавать первоначальный опыт за готовую автоматизированную систему.
Урок формирует опасную иллюзию, что подключение языковой модели к почте автоматически создаёт полноценную службу поддержки. Студенту предлагают собрать линейную цепочку без правил, проверки и обработки ошибок, а затем сразу разрешить ей отправлять сообщения клиентам.
Студент учится соединять кнопки конкретных сервисов, но не проектировать автоматизацию. Корректный результат урока:
Студент создаёт прототип системы, которая классифицирует входящие письма, готовит черновики ответов по заданным правилам и передаёт их сотруднику на проверку.
| Проблема | Почему это ошибка | Как исправить |
|---|---|---|
| Завышенное обещание результата | Один сценарий не заменяет поддержку и не гарантирует отсутствие ошибок | Ограничить кейс подготовкой черновиков для типовых обращений |
| Нет входных требований | Не определены типы писем, правила ответа и источник достоверной информации | Сначала описать категории обращений и допустимые действия |
| Дана последовательность кнопок | Студент повторит сценарий, но не поймёт принцип его построения | Объяснить схему: событие → данные → ИИ-операция → проверка → действие |
| Слишком общий промпт | У модели нет контекста, базы знаний, ограничений и формата результата | Добавить правила, источники, запреты и структуру ответа |
| ИИ и автоматизация смешаны | Не объясняется, где нужна модель, а где достаточно условия или поиска | Разделить вероятностную обработку текста и строгую логику |
| Нет промежуточной проверки | Первая версия сразу взаимодействует с реальными клиентами | Начинать с тестовых писем и сохранения результата в черновики |
| Практика проверяет наличие сценария | Скриншот не показывает качество результата и понимание логики | Проверять решение на тест-кейсах, включая исключения |
| Нет критериев успешности | Непонятно, когда прототип можно считать рабочим | Задать критерии качества и безопасности |
| Урок привязан к одному стеку | При смене сервиса навык перестаёт работать | Строить обучение вокруг общей архитектуры автоматизации |
Промпт «Ты — служба поддержки. Отвечай на письма клиентов» не содержит: информации о компании, правил возврата и доставки, допустимого тона, источника фактов, запрета на выдумывание и критериев передачи обращения человеку. Модель может убедительно придумать статус заказа, срок возврата или скидку. Письмо клиента — недоверенный текст с возможными попытками prompt injection.
ИИ не «подтягивает данные из таблицы» самостоятельно. Получение данных — отдельный шаг: извлечь идентификатор → проверить формат → найти запись → передать модели только нужные поля → обработать случай «заказ не найден».
Автоотправка допустима только для заранее определённых низкорисковых ситуаций после отдельного тестирования. Претензии, возвраты, юридические вопросы и нестандартные обращения — всегда к сотруднику.
Полный доступ к таблице противоречит принципу минимальных привилегий. API-ключи нельзя помещать в промпты, письма, скриншоты и открытые таблицы.
До подключения внешнего сервиса нужно определить: какие данные нужны модели, где они обрабатываются, разрешено ли это политикой организации, можно ли их обезличить.
После урока студент должен уметь:
Результат: студент соберёт прототип коммуникации интернет-магазина, который:
Учебный стек: Яндекс Почта + Albato + учебная таблица заказов + YandexGPT (или GigaChat + n8n).
Если ответ однозначно определяется событием и данными, используем обычную автоматизацию. Если нужно понять свободный текст, подключаем ИИ. Решение с риском для клиента передаём человеку.
Студент создаёт только учебный почтовый ящик. Остальные исходные материалы он скачивает с Яндекс Диска:
Студент не придумывает состав заказов и тексты писем: цель урока — научиться подключать источник данных, выбирать нужный шаблон, подставлять переменные и настраивать маршруты автоматизации. Реальные персональные и платёжные данные в учебных файлах не используются.
В файле «Шаблоны писем интернет-магазина» находятся пять шаблонов:
Вместо реальных данных в шаблонах используются переменные: {{order_id}}, {{items}}, {{total}}, {{delivery_method}}, {{delivery_address}}, {{tracking_url}}, {{ticket_id}}. Студент не формулирует тексты с нуля и не просит нейросеть написать их: его задача — выбрать нужный шаблон и настроить подстановку достоверных данных из учебной таблицы.
Для проверки сценария студент использует пять тестовых ситуаций:
| Маршрут | Пример | Нужен ИИ? | Действие |
|---|---|---|---|
| Системное уведомление | Заказ создан, отправлен, доставлен | Нет | Собрать и отправить письмо по шаблону |
| Простой входящий запрос | «Где мой заказ?» | Только как классификатор | Найти заказ и отправить статусный шаблон |
| Сложное обращение | Претензия, возврат, недостаток данных | Не для решения | Зарегистрировать, отправить отбивку, передать сотруднику |
Главное правило: ИИ не должен придумывать статус, сумму, адрес или условия возврата. Источник фактов — CRM или таблица заказов.
Первый сценарий запускается при изменении статуса. Он находит запись в таблице и выбирает шаблон: для created — письмо с составом, суммой, доставкой и трек-ссылкой; для shipped, delivered, received — остальные готовые шаблоны. ИИ не нужен: текст утверждён, значения берутся из системы.
Второй сценарий запускается при новом письме клиента. Сначала система исключает собственные автоуведомления, чтобы не создать почтовый цикл, затем определяет маршрут обращения.
Для фраз вроде «Где заказ?», «Когда привезут?» или «Пришлите трек-номер» можно начать с обычных правил и ключевых фраз. Если формулировки клиентов разнообразны и правил становится слишком много, ИИ используется только как классификатор.
Пример инструкции:
Определи тип обращения клиента.
Допустимые категории:
- order_status — клиент спрашивает, где заказ или как его отследить;
- complex — претензия, возврат, юридический вопрос, запрос изменения;
- unknown — намерение неясно или данных недостаточно.
Не отвечай клиенту и не придумывай факты.
Верни только название категории.
Письмо клиента:
{{текст письма}} Если order_status: сценарий извлекает номер заказа → проверяет формат → находит запись → проверяет совпадение адреса отправителя → подставляет статус и трек-ссылку в шаблон → отправляет ответ. Если номер отсутствует, заказ не найден или адреса не совпадают — данные не раскрываются, обращение уходит к сотруднику.
Для категорий complex и unknown сценарий создаёт обращение в очереди поддержки и присваивает ему номер. Клиент сразу получает автоматическую отбивку:
Мы получили ваше обращение № {{ticket_id}}. Специалист поддержки свяжется с вами в установленный срок.
Этот текст студент также не составляет самостоятельно: сценарий использует пятый шаблон из учебного файла и подставляет в него номер обращения. После этого исходное письмо и номер обращения передаются сотруднику. Ответ по существу отправляет человек. Такая отбивка подтверждает получение запроса, но не обещает решение, которого система пока не может гарантировать.
| Тест | Ожидаемый маршрут | Ожидаемый результат |
|---|---|---|
| Заказ создан | Без ИИ | Письмо с составом, суммой и доставкой |
| Заказ отправлен | Без ИИ | Письмо со статусом и трек-ссылкой |
| «Где мой заказ?» с корректным номером | Правила или ИИ-классификация → шаблон | Актуальный статус из таблицы |
| «Товар повреждён, требую возврат» | Сотрудник | Отбивка с номером обращения |
| Вопрос без номера заказа | Сотрудник | Отбивка без раскрытия данных |
| Номер чужого заказа | Сотрудник | Данные заказа не отправлены |
| Ошибка доступа к таблице | Сотрудник | Клиенту не отправлена выдуманная информация |
Студент прикладывает:
Скриншот сценария можно приложить, но сам по себе он не подтверждает корректность решения.
Модели, почтовые сервисы и платформы автоматизации можно заменить, но архитектура останется прежней:
Событие с однозначным результатом → обычное правило и шаблон. Свободный текст → ИИ для узкой смысловой задачи. Риск или неопределённость → человек.
Студент должен вынести из урока не расположение кнопок в Albato, а умение выбирать минимально сложный и достаточно безопасный способ автоматизации.
Обычная автоматизация похожа на почтового робота, который действует по чёткой инструкции: если заказ отправлен, он подставляет в готовый шаблон номер заказа, статус и ссылку для отслеживания. Для такого действия ИИ не нужен, потому что системе не приходится разбираться в смысле сообщения или придумывать ответ. ИИ стоит подключать, когда клиент пишет вопрос своими словами и сначала нужно понять, чего он хочет: узнать статус заказа, оформить возврат или сообщить о проблеме. Но ИИ может ошибиться в определении запроса или добавить сведения, которых нет в базе. Поэтому простые запросы лучше обрабатывать готовыми правилами, а сложные обращения — передавать сотруднику, при необходимости сохраняя ответ ИИ только как черновик. Перед настройкой сценария нужно спросить себя: здесь достаточно условия и шаблона или действительно требуется понять свободный текст?
Готова обсудить задания и ответить на любые вопросы