Диалог с AI-помощником нужно проектировать не как набор красивых реплик, а как управляемый путь от задачи пользователя до проверяемого результата. На каждом шаге система должна понимать, что уже известно, какой информации не хватает, можно ли ответить сразу, нужно ли обратиться к базе или внешнему сервису и имеет ли она право выполнить следующее действие самостоятельно.
Поэтому хороший сценарий AI-помощника начинается не с приветствия и даже не с системного промпта. Сначала определяют результат пользователя и условия, при которых его можно считать достигнутым. Уже после этого проектируют вопросы, контекст, инструменты, подтверждения и обработку ошибок.
Сам промпт остается важной частью системы, но он отвечает прежде всего за инструкции модели. Если нужно отдельно разобраться с его структурой, на Postolog есть материал о том, как писать промпты для ChatGPT. В продуктовой системе к инструкции добавляются состояние диалога, данные, инструменты и правила выполнения действий.
- Что именно нужно проектировать в диалоге с AI-помощником?
- С чего начинать проектирование AI-помощника?
- Как описать состояние задачи AI-помощника?
- Как AI-помощнику выбрать следующий ход?
- Когда AI-помощник должен задавать уточняющий вопрос?
- Как работать с контекстом и не заставлять пользователя повторяться?
- Когда AI-помощнику нужна база знаний, а когда инструмент?
- Когда AI может выполнять действие без подтверждения пользователя?
- Почему вызов инструмента еще не означает успешный результат?
- Как проектировать ошибки и передачу задачи человеку?
- Как выглядит хороший сценарий от первого запроса до результата?
- Как тестировать диалог с AI-помощником до запуска?
- Как превратить сценарий в рабочее ТЗ?
Что именно нужно проектировать в диалоге с AI-помощником?
Проектировать нужно не последовательность реплик, а правила движения задачи между состояниями. Пользователь может сообщить параметры в любом порядке, изменить решение посреди разговора или сразу дать почти все необходимые сведения. Поэтому жесткое дерево сообщений быстро становится неудобным.
Классический сценарный бот и AI-помощник могут выглядеть одинаково в окне чата, но управляются по-разному.
| Что происходит | Сценарный чат-бот | AI-помощник |
|---|---|---|
| Понимание запроса | Сопоставляет его с заранее заданной веткой. | Извлекает цель и параметры из свободной формулировки. |
| Порядок вопросов | Обычно определяется заранее. | Зависит от того, каких данных реально не хватает. |
| Работа с контекстом | Хранит предусмотренные сценарием переменные. | Может учитывать историю разговора, найденные факты и изменение условий. |
| Действия | Запускаются конкретным переходом сценария. | Модель может выбирать подходящий инструмент внутри заданных ей границ. |
| Нестандартный запрос | Часто уходит в fallback или меню. | Может перестроить путь к цели, если это разрешено архитектурой. |
Свободный диалог при этом не означает отсутствие сценария. Наоборот: чем больше вариантов формулировки допускает интерфейс, тем точнее должны быть определены цель, обязательные данные, доступные источники, допустимые действия и стоп-условия.
С чего начинать проектирование AI-помощника?
Начинайте с результата пользователя. Формулировка "помогать клиентам" слишком широкая: невозможно понять, какие данные нужны, когда задача закончена и что считать ошибкой. Формулировка "подобрать доступный тариф и показать его окончательные условия" уже задает проверяемый результат.
Для одного сценария сначала зафиксируйте четыре вещи: исходный запрос, нужный результат, данные для принятия решения и допустимый следующий шаг. Это помогает отделить пользовательскую задачу от бизнес-цели вроде сбора контакта или заявки.
| Что определить | Вопрос к проектировщику |
|---|---|
| Результат пользователя | Что человек должен получить или реально сделать? |
| Критерий готовности | По какому факту можно доказать, что задача закончена? |
| Обязательные данные | Без каких параметров нельзя получить правильный результат? |
| Источники | Откуда берутся факты, цена, наличие, статус или другие изменяемые сведения? |
| Действия | Что помощник может только предложить, а что способен выполнить? |
| Границы | Когда требуется подтверждение пользователя или участие сотрудника? |
Такой подход особенно важен, когда ИИ становится частью постоянного рабочего процесса. В отдельном материале Postolog разобрана автоматизация задач с помощью ИИ и выбор процессов, где ее разумно начинать с узкого проверяемого сценария.
Как описать состояние задачи AI-помощника?
Состояние задачи должно отвечать на простой вопрос: что система уже знает и чего ей не хватает, чтобы приблизиться к результату. Это надежнее, чем пытаться заранее перечислить все возможные реплики пользователя.
Для проектирования можно использовать такую карточку:
Цель пользователя:
Критерий готового результата:
Уже подтвержденные данные:
Предположения, которые еще нужно проверить:
Обязательные недостающие данные:
Источник фактов:
Доступные инструменты:
Разрешенные действия:
Действия без подтверждения:
Действия только после подтверждения:
Что уже выполнено:
Что должен сделать следующий шаг:
Условия передачи человеку:
Стоп-условие:
Разделение подтвержденных данных и предположений принципиально. Если пользователь написал "желательно вечером", система не должна без дополнительного основания превращать это в жесткое условие "только после 18:00". Аналогично найденный вариант еще не равен выбранному, а попытка создать заказ не равна успешно созданному заказу.
После каждого значимого сообщения или результата инструмента карточка состояния меняется. Благодаря этому следующий ход определяется текущей задачей, а не номером сообщения в сценарии.
Как AI-помощнику выбрать следующий ход?
Следующий ход выбирают по состоянию задачи. Практически почти любой пользовательский сценарий можно свести к пяти решениям: ответить, уточнить, получить данные, выполнить действие либо остановиться и передать задачу дальше.
| Состояние | Следующий ход |
|---|---|
| Информации достаточно и действие не требуется. | Дать ответ или показать результат. |
| Не хватает параметра, который изменит решение. | Задать уточняющий вопрос. |
| Ответ зависит от актуальных или пользовательских данных. | Обратиться к нужному источнику или инструменту. |
| Нужно изменить состояние внешней системы. | Проверить полномочия и необходимость подтверждения, затем выполнить действие. |
| Система не может надежно продолжить сценарий. | Сообщить об ограничении и предложить безопасный следующий путь или передачу человеку. |
Это правило помогает избежать одной из самых частых проблем разговорного интерфейса: модель продолжает беседу, хотя ей уже пора либо проверить данные, либо выполнить действие. Красивый ответ в таком случае лишь маскирует незавершенную задачу.
Когда AI-помощник должен задавать уточняющий вопрос?
Уточняющий вопрос нужен тогда, когда ответ пользователя способен изменить результат, способ выполнения задачи или допустимость действия. Если параметр ни на что не влияет, спрашивать его только ради полноты анкеты не нужно.
Представим условный сервис бронирования переговорных. Пользователь пишет: "Нужна переговорная на восемь человек завтра с 14:00 до 16:00, обязательно с проектором".
Из одной реплики уже известны вместимость, дата, время и обязательное оборудование. Повторно спрашивать эти параметры бессмысленно. Если сервис работает в нескольких городах и местоположение нельзя определить из контекста, именно город или офис становится следующим действительно необходимым уточнением.
Перед вопросом полезно проверять три условия:
- ответ действительно необходим для следующего шага;
- нужного значения еще нет в текущем контексте или надежном источнике;
- система не подменяет уточнение догадкой, которая может изменить результат.
Несколько тесно связанных параметров можно запросить вместе, если пользователю так проще. Но длинная анкета из вопросов "на всякий случай" возвращает разговорный интерфейс к неудобству обычной формы.
Как работать с контекстом и не заставлять пользователя повторяться?
Контекст должен хранить данные, необходимые для продолжения текущей задачи, но не превращаться в бесконтрольный архив всего разговора. Особенно важно различать то, что пользователь подтвердил, то, что система только предположила, и сведения, полученные из внешних источников.
Полезно отдельно отслеживать:
- текущую цель пользователя;
- подтвержденные параметры;
- непроверенные предположения;
- последнее решение пользователя;
- результаты обращений к базе или инструментам;
- выполненные действия и их фактический статус;
- данные, которые больше не действуют после изменения условий.
Если пользователь сначала выбрал первый вариант, а затем написал "нет, давайте второй", актуальным состоянием становится второй вариант. Нельзя продолжать оформление первого только потому, что он раньше находился в истории разговора.
То же относится к ошибкам инструмента. Запись "попытались забронировать" не должна сохраняться как "забронировано". Для выполнения задачи важен подтвержденный внешний результат.
Когда AI-помощнику нужна база знаний, а когда инструмент?
База знаний нужна для получения фактов, а инструмент - когда требуется прочитать актуальное состояние внешней системы или изменить его. Эти функции нельзя смешивать: инструкция модели не должна заменять каталог товаров, календарь свободных слотов, CRM или платежную систему.
Для проектирования удобно разделять инструменты как минимум на две группы.
- Чтение данных. Проверка наличия, расписания, статуса заявки, сведений из CRM, базы знаний или другого источника.
- Действие. Создание заявки, бронирование, изменение записи, отправка сообщения, обновление карточки или другая операция, меняющая состояние системы.
Если значение быстро меняется, источник с актуальным состоянием должен иметь приоритет перед старой репликой или статическим описанием. Например, свободный слот необходимо подтверждать по системе бронирования, а не по тексту, где перечислено обычное расписание.
После вызова инструмента AI-помощник должен обработать не только полезный результат, но и отсутствие данных, ошибку, неоднозначность или отказ в доступе. Сценарий "инструмент обязательно вернет то, что мы ожидаем" ненадежен уже на уровне проектирования.
Когда AI может выполнять действие без подтверждения пользователя?
Чем серьезнее последствия действия и сложнее его отменить, тем меньше оснований выполнять его без явного контроля пользователя. Поиск информации и создание необязательного черновика требуют одного уровня контроля, а платеж, отмена заказа или удаление данных - другого.
Для сценария можно использовать следующую матрицу.
| Характер действия | Пример | Режим |
|---|---|---|
| Не меняет внешнее состояние. | Найти тарифы или проверить свободные слоты. | Можно выполнять автоматически. |
| Меняет состояние, но легко отменяется и прямо запрошено. | Подготовить черновик заявки или добавить вариант в подборку. | Допустима ограниченная автономность с понятным статусом. |
| Создает значимое обязательство. | Оформить заказ или окончательно забронировать услугу. | Перед действием нужно убедиться, что пользователь выбрал именно эти условия. |
| Имеет серьезные или трудно обратимые последствия. | Платеж, удаление, отмена важной операции. | Нужно явное подтверждение либо дополнительный контроль. |
| Намерение пользователя неоднозначно или прав недостаточно. | Непонятно, просит ли человек узнать условия или уже оформить действие. | Остановиться и уточнить. |
Подтверждение должно содержать существенные параметры операции. Фраза "Продолжить?" хуже формулировки, из которой пользователь понимает, что именно сейчас произойдет.
При этом подтверждение не нужно превращать в ритуал перед каждым безопасным шагом. Если AI спрашивает разрешение даже на поиск информации, диалог становится медленнее, но не безопаснее.
Почему вызов инструмента еще не означает успешный результат?
Задача считается завершенной только тогда, когда внешняя система подтвердила нужное состояние. Решение модели вызвать инструмент, отправленный запрос и успешный результат - три разных события.
Например, AI-помощник сформировал параметры бронирования и отправил их сервису. Возможны как минимум три исхода: бронь создана, сервис вернул ошибку или нужный слот уже занят. Сообщать пользователю "готово" можно только в первом случае.
После значимого действия проверяйте:
- приняла ли внешняя система операцию;
- совпали ли фактически сохраненные параметры с выбранными;
- есть ли идентификатор, статус или другой признак результата;
- не требуется ли еще один шаг для окончательного завершения;
- что должен увидеть пользователь, если операция не выполнена.
Это особенно важно для AI-агентов: языковая модель может правильно выбрать действие, но ошибку API, потерянный параметр или отказ внешней системы нельзя превращать в вымышленный успех.
Как проектировать ошибки и передачу задачи человеку?
Ошибка должна оставлять пользователю понятный следующий ход. Сообщение "что-то пошло не так" фиксирует проблему, но не помогает продолжить задачу.
При сбое полезно сохранить уже подтвержденные параметры, объяснить, какой именно шаг не удалось выполнить, и предложить доступный вариант: повторить попытку, выбрать другой путь, вернуться к предыдущему шагу или передать обращение сотруднику.
Передача человеку тоже является частью сценария, а не аварийным выходом. Оператору желательно передать:
- исходную цель пользователя;
- уже собранные и подтвержденные параметры;
- какие проверки выполнил помощник;
- какое действие не удалось выполнить;
- последний актуальный выбор пользователя;
- что именно требуется от сотрудника.
Тогда человеку не приходится начинать разговор заново, а пользователь не повторяет информацию, которую система уже получила.
Как выглядит хороший сценарий от первого запроса до результата?
Рассмотрим условный пример с сервисом бронирования переговорных. Пользователь пишет: "Нужна переговорная на восемь человек завтра с 14:00 до 16:00, обязательно с проектором".
- Помощник определяет задачу: подобрать и при необходимости забронировать переговорную.
- Извлекает уже известные параметры: восемь человек, завтра, 14:00–16:00, нужен проектор.
- Проверяет обязательные поля. Если местоположение неизвестно и влияет на поиск, задает один необходимый вопрос.
- Обращается к системе доступности, а не придумывает свободные варианты из общих знаний.
- Показывает подходящие варианты и существенные различия между ними.
- После выбора пользователя формирует точные параметры бронирования.
- Если бронирование создает обязательство, получает необходимое подтверждение и вызывает инструмент.
- Сообщает об успехе только после ответа системы и показывает подтвержденные детали брони. При ошибке сохраняет контекст и предлагает следующий возможный шаг.
Обратите внимание: заранее не пришлось писать отдельные ветки под десятки формулировок вроде "хочу комнату", "найдите переговорку", "есть что-нибудь на восемь человек" или "нужно место для встречи". Неизменным остается состояние задачи и критерий следующего шага.
Как тестировать диалог с AI-помощником до запуска?
Тестировать нужно не одну идеальную переписку, а поведение системы при разных состояниях задачи. Критерием служит не совпадение текста с эталонной фразой, а правильность решения и фактический результат.
| Тестовый сценарий | Что должно произойти |
|---|---|
| Все обязательные данные есть сразу. | Помощник не задает повторных вопросов и переходит к следующему полезному шагу. |
| Не хватает критичного параметра. | Запрашивает именно его, а не начинает угадывать. |
| Запрос сформулирован неоднозначно. | Уточняет намерение до действия с последствиями. |
| Пользователь изменил решение. | Обновляет состояние и не продолжает старую ветку. |
| В источнике нет нужных данных. | Не выдумывает факт и предлагает допустимый следующий путь. |
| Внешний инструмент вернул ошибку. | Не сообщает об успехе и сохраняет подтвержденный контекст. |
| Операция имеет серьезные последствия. | Применяет предусмотренный уровень подтверждения или контроля. |
| Запрос выходит за пределы возможностей. | Честно обозначает границу и не создает ложных ожиданий. |
| Несколько попыток не приблизили задачу к результату. | Останавливает бесполезный цикл и предлагает передачу человеку или другой путь. |
После запуска полезно оценивать не только удовлетворенность ответом. Для продуктового сценария важнее понять, завершилась ли задача, правильно ли использованы источники и инструменты, сколько ненужных уточнений было задано и не совершал ли помощник действия без достаточного основания.
Как превратить сценарий в рабочее ТЗ?
Финальное ТЗ должно описывать поведение системы, а не пытаться предсказать каждую будущую фразу. Рабочая последовательность выглядит так:
- Сформулируйте конкретную задачу пользователя.
- Определите проверяемый результат и стоп-условие.
- Перечислите обязательные параметры и надежные источники каждого из них.
- Опишите состояние задачи и правила его обновления.
- Для каждого состояния задайте допустимые следующие ходы.
- Разделите чтение информации и действия, меняющие внешние системы.
- Установите границы автономности, подтверждения и передачи человеку.
- Соберите тесты для успешного маршрута, неоднозначностей, изменений и сбоев.
После этого промпт становится одной из частей уже спроектированной системы: в нем можно зафиксировать роль, правила поведения, порядок использования доступных инструментов и ограничения. Но слабую архитектуру невозможно полностью исправить более длинной инструкцией.
Хороший AI-помощник не обязан вести длинный разговор. Его задача - сокращать путь от свободно сформулированного запроса к достоверному и подтвержденному результату. Чем яснее состояние задачи, источник фактов, права на действие и критерий завершения, тем меньше системе приходится угадывать - и тем предсказуемее становится диалог для пользователя.
