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

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

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

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

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

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

Причина обычно здравая. Без правил каждый пишет запросы как умеет. Одни получают полезный черновик, другие — общий текст, который нельзя отдать в работу. Руководителю кажется, что протокол снизит разброс: все будут делать «правильно».

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

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

Исследование Microsoft и Gap (arxiv 2604.08678v1) разбирает как раз этот разрыв: формально правильный протокол не равен пользе на месте. Люди следуют шагам, но результат не становится лучше автоматически. На части задач он даже хуже, потому что сценарий отнимает внимание и не оставляет места для исключения.

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

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

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

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

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

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

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

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

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

Проверку строят как короткий эксперимент, а не как обучение «правильно промптить».

1. Выбирают один процесс с понятным входом и тем, кто принимает результат.
2. Оставляют контрольную группу или хотя бы сопоставимые старые примеры.
3. Смотрят не «следуют ли люди шагам», а «стал ли результат пригоднее и быстрее».
4. Отдельно разбирают случаи, где протокол пришлось нарушить.
5. Только после этого решают: оставить как помощь, сделать обязательным на узком типе задач или не внедрять.

Отдельный критерий: если польза не объясняется без ссылки на «так правильнее работать с ИИ», протокол еще не готов. Польза должна быть видна в работе процесса.

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

• [ ] Процесс выбран один, с владельцем и понятным результатом.
• [ ] Есть с чем сравнивать: старый способ работы, а не только впечатление от демо.
• [ ] Считают пригодность результата и время, а не долю заполненных полей.
• [ ] Зафиксированы случаи, где шаблон нужно обойти.
• [ ] Протокол можно оставить необязательным, если польза не подтвердилась.
• [ ] Решение не принимают по удобству интерфейса или аккуратности промптов.
• [ ] Команда готова сузить область, а не «внедрить ИИ для всех».

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

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