Фиксация намерений пользователя в AI-воркфлоу двумя вопросами

Почему свободный текст даёт плохой старт

Свободный текст кажется простым. Для AI-воркфлоу он часто создаёт плохую отправную точку.

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

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

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

Формат создаёт ту же проблему. Если в promptе не указано «таблица», «маркированный список», «черновик письма» или «короткий отчёт», модель выбирает формат сама. Этот выбор меняет результат. Неформальный абзац и обновление для совета директоров не будут содержать одинаковых деталей, даже если исход один и тот же.

Это видно в повседневных запросах:

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

Структурированные вопросы на этапе intake исправляют это до того, как воркфлоу начнёт работать. Они вытаскивают настоящую цель из неаккуратного языка рано. Это и есть задача при фиксировании намерений пользователя для AI-воркфлоу: не дать системе гадать и дать достаточно направления, чтобы получить полезный результат с первой попытки.

Что спросить до начала воркфлоу

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

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

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

Простая пара часто работает хорошо:

• Какой результат вы хотите получить?
• В каком формате должен быть ответ?

Этого достаточно во многих случаях. Люди отвечают быстро, а воркфлоу получает два решения, которые чаще всего меняют выход.

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

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

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

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

Когда достаточно одного вопроса, а когда нужны два

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

Один вопрос работает лучше, когда воркфлоу остаётся фиксированным после этого ответа. Внутренний инструмент может спросить: «Что нужно сделать?» и предложить варианты «суммировать заметки», «написать ответ» или «вытянуть задачи». Этот единственный выбор даёт AI достаточно направления для чистого старта.

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

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

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

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

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

Как формулировать вопросы

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

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

Расплывчатые слова вызывают дрейф. Слова вроде «лучше», «срочно» или «подробно» означают разное для разных людей. Заменяйте их вариантами, которые указывают на разные выходы.

Например:

• Вместо «Насколько подробно?» спросите «Вам нужно 5 пунктов или полный план?"
• Вместо «Это срочно?» спросите «Нужно сегодня, на этой неделе или когда будет время?"
• Вместо «Какую помощь вы хотите?» спросите «Вам нужен диагноз, черновик или рекомендация?"

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

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

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

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

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

Простой процесс настройки

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

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

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

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

1. Перечислите каждое решение, которое меняет итоговый результат.
2. Уберите выборы, которые система может принимать безопасно каждый раз.
3. Оставьте только те решения, которые пользователи действительно должны контролировать.
4. Превратите эти решения в один или два коротких вопроса.
5. Сопоставьте каждый ответ с конкретной веткой, шаблоном или следующим действием.

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

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

Небольшие правки решают многое. Замените «Что вам нужно?» на «Какой результат вы хотите?». Замените открытый текст на короткое меню, когда варианты известны. Добавляйте второй вопрос только если он меняет следующий шаг. Если не меняет — убирайте.

Часто этого достаточно, чтобы быстро взять под контроль запутанный воркфлоу.

Реалистичный пример

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

Простой шаг intake решает это. Перед запуском воркфлоу форма задаёт два коротких вопроса. Первый спрашивает цель пользователя: «С чем вам нужна помощь?» Второй — формат ответа: «Как мы должны ответить?"

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

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

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

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

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

Ошибки, которые срывают фиксацию намерений

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

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

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

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

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

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

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

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

Быстрая проверка перед запуском

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

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

Хорошая проверка проста:

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

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

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

Ещё одна важная проверка: может ли воркфлоу заметить пробел до запуска? Если пользователь выбрал «ответ клиенту», но не указал проблему клиента, остановите и запросите эту деталь. Ловить пробелы заранее намного дешевле, чем позволять AI угадывать и выдавать неверный результат.

Следующие шаги

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

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

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

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

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

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

Что делать после первого теста

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

Если нужен второй взгляд, Oleg Sotnikov at oleg.is работает со стартапами и небольшими командами по AI-first разработке, дизайну воркфлоу и поддержке в формате Fractional CTO. Короткий внешний обзор может сэкономить много времени, когда реальная проблема — в шаге intake, а не в prompt'е.