Инструкции вокруг UX: анонс App, отказ от App и поведение в диалоге

1. Зачем вообще управлять UX через инструкции

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

В одном случае GPT игнорирует App и пытается “решить всё словами”. Пользователь просит подобрать подарок, а модель вместо запуска GiftGenius выдаёт длинное текстовое эссе с рекомендациями “от себя”. Иногда это неплохо, но вы App писали не для того, чтобы он пылился на полке.

Во втором случае GPT, наоборот, злоупотребляет App. На любой чих вроде “Что умеет ваш сервис?” она запускает виджет, рендерит мутную форму, пользователь пугается и закрывает всё это великолепие. С UX‑точки зрения получается очень навязчиво.

Поэтому логика простая: поведение нужно зафиксировать явно, так же, как вы фиксируете JSON‑схему инструмента или пропсы React‑компонента. System‑prompt (и сопутствующие инструкции) здесь — ваш “протокол UX”. В нём вы описываете, когда и как ассистент:

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

Всё это не про маркетинг и не про стиль общения. Это реально влияет на то, как часто ваш App будет вызываться, и насколько комфортно себя будет чувствовать пользователь.

Дальше по шагам разберём: как ассистент должен анонсировать запуск App, в каких случаях лучше сознательно не предлагать виджет, как вести себя после того, как приложение отработало, как уважать явные просьбы пользователя о формате диалога и как аккуратно оформить все эти правила в system‑prompt.

2. Анонс App: как модель должна “предупреждать” о виджете

Когда ChatGPT решает использовать App, интерфейс меняется: в чате появляется карточка виджета, иногда в полноэкранном виде, появляются кнопки и прочие элементы UI. Если ассистент просто без объяснений покажет виджет, пользователь может вообще не понять, что произошло и откуда взялся этот блок.

Поэтому хороший тон — сначала текстом объяснить, что сейчас произойдёт, и только потом запускать App. Это похоже на то, как браузер спрашивает: “Открыть новое окно?” или как мобильное приложение предупреждает: “Сейчас мы попросим у вас разрешение на камеру”.

Типы анонсов

Можно условно выделить три стиля анонса.

Первый — мягкое предложение. Ассистент говорит что‑то вроде: “Я могу открыть для вас приложение GiftGenius, которое подберёт подарки по вашим параметрам. Открыть его?” и ждёт ответ “да/нет”. Это хорошо работает в сценариях, где пользователь только знакомится с сервисом или может быть чувствителен к смене интерфейса.

Второй — уверенная рекомендация. Если ваш App — основной интерфейс продукта, вы можете писать: “Сейчас запущу приложение GiftGenius и покажу несколько вариантов подарков в виде карточек.” Ассистент всё равно может учесть отказ, но по умолчанию действует более решительно.

Третий — нейтральное уведомление. В этом случае ассистент просто сообщает: “Запускаю приложение GiftGenius для подбора подарков…”, без длинных объяснений. Такой стиль уместен, когда пользователь уже много раз видел ваш App и ожидает его появления.

Важно, что все эти варианты можно и нужно зашить в system‑prompt. Модель не придумывает UX‑фразы с нуля, если вы заранее даёте ей скелет.

Мини‑пример кода: секция про анонс в system‑prompt

Представьте, что в вашем Next.js‑шаблоне есть файл appDefinition.ts, где вы задаёте system‑prompt для App:

// app/appDefinition.ts
export const systemPrompt = `
# Роль
Ты — ChatGPT App GiftGenius, помогаешь подбирать подарки.

# Диалог и UX — Анонс приложения
Если решаешь запустить виджет GiftGenius,
сначала одним-двумя предложениями объясни,
что сейчас откроется приложение с подборкой подарков
и чем оно поможет пользователю.
`;

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

Когда анонс особенно важен

Чем сложнее ваш UI, тем важнее заранее проговаривать его запуск. Если виджет просто показывает три карточки подарков — это относительно мягкая смена контекста. Если же вы открываете целый многошаговый мастер с фильтрами, бюджетом, категориями и т.д., пользователь должен понимать, почему диалог внезапно превратился в “маленькое веб‑приложение внутри чата”.

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

3. Когда сознательно не предлагать App

Самая частая ошибка на ранних этапах разработки App — классический эффект «если в руках молоток, всё кажется гвоздями». Раз у нас есть красивый GiftGenius, модель начинает тянуть его в каждый диалог. Пользователь спрашивает: “А что вообще умеет ваше приложение?”, а ChatGPT уже: “Запускаю GiftGenius…”, хотя человеку хотелось просто две строчки объяснения.

Чтобы этого избежать, в system‑prompt нужно описать ситуации, когда App лучше не предлагать. Ниже — несколько типичных сценариев.

• Во‑первых, ознакомительные вопросы. Если человек пишет что‑то вроде “Что делает GiftGenius?” или “Как вы работаете?”, инструкции должны требовать сначала дать краткое текстовое объяснение, без запуска UI. Виджет здесь только отвлекает.
• Во‑вторых, слишком общий или размытый запрос. Пользователь пишет “Расскажи про подарки на Новый год” — это скорее образовательный вопрос, чем конкретный подбор. Ассистент может кратко объяснить общие принципы, задать уточняющие вопросы, и только когда появятся конкретные параметры (бюджет, получатель, категория), предложить App.
• В‑третьих, запросы вне домена App. Если человек говорит: “Помоги написать резюме”, а ваш App заточен под подарки, правильное поведение — честно ответить как обычный ChatGPT и ничего не запускать. Иногда можно аккуратно упомянуть, для чего предназначен App, но не нужно навязывать его, когда он явно нерелевантен.
• В‑четвёртых, явный отказ от UI. Если пользователь пишет: “Только не открывай никаких приложений, просто объясни текстом”, модель обязана подчиниться, даже если видит идеальный сценарий для App.

Таблица: тип запроса и поведение ассистента

Дополняем system‑prompt правилами отказа от App

Продолжим тот же systemPrompt, добавив блок про то, когда App не запускать:

export const systemPrompt = `
# Роль
Ты — ChatGPT App GiftGenius, помогаешь подбирать подарки.

# Когда НЕ запускать виджет
Если пользователь спрашивает только о том, что умеет сервис,
или задаёт общий теоретический вопрос о подарках,
сначала ответь текстом и не запускай приложение.

Если запрос не связан с подбором подарков,
отвечай как обычный ChatGPT и не предлагай GiftGenius.

Если пользователь явно просит не использовать приложения,
обязательно уважай это и работай только в чате.
`;

Такой текст превращается в конкретные решения модели в пограничных ситуациях, где иначе она могла бы “перетянуть одеяло” в сторону UI. Мы зафиксировали, когда App не нужен. Теперь важно описать обратную сторону: что делать ассистенту, когда виджет уже отработал и пользователь видит результат.

4. Поведение после использования App: follow‑up и завершение сценария

В модуле про виджет вы уже видели, как follow‑up‑сообщения помогают продолжать диалог после того, как UI отработал. Виджет показывает карточки, а под ним ассистент пишет что‑то вроде: “Я нашёл такие‑то варианты подарков для коллеги в бюджете до $50. Хотите, покажу более дешёвые или изменю категорию?” и предлагает кнопки с популярными действиями.

Теперь наша задача — зафиксировать это поведение в инструкциях, а не полагаться на “интуицию” модели.

Что должен делать ассистент после виджета

В идеальном сценарии происходит несколько вещей.

• Сначала ассистент коротко резюмирует результат работы App словами. Даже если виджет показал десять карточек, полезно написать: “Я подобрал 4 варианта подарков для коллеги в бюджете до $50. Среди них есть кружка с индивидуальным принтом, настольное растение, набор хорошего кофе и стильная тетрадь.”
• Затем он предлагает следующие шаги. Здесь помогают заранее продуманные follow‑up‑фразы: “Хотите увидеть более дешёвые варианты?”, “Нужно сузить выбор по интересам?”, “Показать только те, что доступны в вашем регионе?”. Именно эти фразы вы можете использовать в sendFollowUpMessage в виджете, а также рекомендовать модели в system‑prompt.
• И наконец, если пользователь явно завершает сценарий (“Спасибо, этого достаточно”), ассистент аккуратно “закрывает” тему: признаёт, что задача решена, и предлагает помочь с чем‑то ещё.

Диаграмма потока: вопрос → виджет → follow‑up

Для наглядности можно представить поведение ассистента как простой автомат состояний.

flowchart TD
    U[Пользователь задаёт задачу] --> G[GPT решает: запускать App?]
    G -->|Да| A[Анонсирует запуск App]
    A --> W[Виджет GiftGenius подбирает варианты]
    W --> S[Ассистент резюмирует результат]
    S --> F[Ассистент предлагает follow-up варианты]
    F -->|Пользователь выбирает действие| G
    G -->|Нет, не запускать App| T[Текстовый ответ без UI]
    F -->|"Пользователь говорит \"Спасибо\""| E[Ассистент завершает сценарий и предлагает другую помощь]

Такой поток мы фактически описываем словами в system‑prompt.

Пример кода: follow‑up из виджета

С UI‑стороны вы уже умеете отправлять follow‑up‑сообщения. Для полноты здесь простой пример компонента, который после нажатия кнопки просит модель “расширить бюджет”:

// components/ExpandBudgetButton.tsx
export function ExpandBudgetButton() {
    const onClick = () => {
        window.openai?.sendFollowUpMessage(
            "Покажи варианты с чуть большим бюджетом"
        );
    };

    return <button onClick={onClick}>Хочу дороже варианты</button>;
}

Теперь мы добавим в system‑prompt текст, который подскажет модели, как обрабатывать такие follow‑up‑сообщения.

// продолжение systemPrompt
const followUps = `
# Поведение после запуска приложения
После того как виджет показал список подарков,
кратко опиши результат текстом.

Затем предложи 1–3 понятных следующих шага
(например: показать более дешёвые, изменить бюджет, сменить категорию).
Если виджет отправляет follow-up‑сообщение,
используй его как подсказку для следующего шага.
`;

С технической точки зрения это обычная строка. А с точки зрения UX — основа предсказуемого сценария.

5. Уважение к намерениям пользователя

Всё, что мы обсуждали выше, — это ваши продуктовые ожидания от поведения App. UX‑инструкции будут работать плохо, если модель не умеет “слушать” пользователя. Даже идеально спроектированный App должен уступать, если человек явно просит не менять формат взаимодействия.

Есть несколько характерных ситуаций.

• Если пользователь прямо говорит, что не хочет запускать приложения (“Никакого UI, просто объясни, что мне купить”), ассистент должен воспринимать это как жёсткое ограничение и не пытаться обойти его. Можно вежливо сказать: “Окей, буду отвечать только текстом”, и дальше действительно держать слово.
• Если пользователь боится, что что‑то запустится автоматически, полезно дать ему ощущение контроля. Например: “Я могу открыть приложение для подбора подарков, но если вы предпочитаете, можем обсудить варианты просто в чате. Как вам удобнее?” Здесь вы явно даёте выбор.
• Если пользователь пишет “Я с телефона, не запускай сложные формы” — это тоже часть контекста. Ассистент должен принять его и, например, ограничиться коротким списком идей и уточняющих вопросов.

Вшиваем уважение в контракт

Всё это можно компактно отразить в system‑prompt:

export const respectBlock = `
# Приоритет намерений пользователя
Всегда учитывай явные просьбы пользователя
о формате общения.

Если он просит не запускать приложения или виджеты,
не предлагай и не запускай GiftGenius,
даже если это помогло бы решить задачу.
Вместо этого помогай текстом.
`;

Таким образом вы чётко фиксируете “кто главный” в диалоге. И спойлер: это не ваша гордость за красивый UI, а живой человек с той стороны экрана.

6. Как оформлять UX‑инструкции внутри system‑prompt и в документации

Мы уже накидали довольно много правил поведения — от анонса App до follow‑up‑сообщений и уважения формата диалога. Теперь важно не только что мы говорим модели, но и как это оформлено в system‑prompt и документации.

System‑prompt в реальном App быстро разрастается. Если писать его как сплошной литературный текст, через неделю там уже никто ничего не найдёт. Поэтому относитесь к нему как к технической спецификации или README: структурируйте.

Хорошая практика — разбить prompt на несколько логических секций с заголовками. Например, “Роль и зона ответственности”, “Когда использовать App”, “Когда не использовать App”, “Диалог и UX”, “Безопасность и ограничения”. Внутри каждой секции писать простыми, однозначными фразами.

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

Пример организации system‑prompt в коде

Один из вариантов — хранить части prompt’а в отдельных строках и собирать в одно целое:

// app/prompt/role.ts
export const roleSection = `
# Роль
Ты — ChatGPT App GiftGenius.
Помогаешь пользователю подобрать подарки под задачу и бюджет.
`;

// app/prompt/ux.ts
export const uxSection = `
# Диалог и UX
Перед запуском виджета GiftGenius
коротко объясни, что сейчас откроется приложение с карточками подарков.
Не запускай приложение для общих или теоретических вопросов,
если пользователь явно не просит подбора.
После работы виджета резюмируй результат текстом
и предложи 1–3 следующих шага.
`;

// app/appDefinition.ts
import { roleSection } from "./prompt/role";
import { uxSection } from "./prompt/ux";

export const systemPrompt = `
${roleSection}
${uxSection}
`;

Такое разбиение помогает думать об инструкциях как об отдельных модулях: UX‑часть, безопасность, работа с инструментами и т.д. Это особенно пригодится, когда вы будете добавлять новые возможности и придётся согласовывать поведение с несколькими командами.

Кроме того, документацию по App (внутренний README, Confluence, Notion) имеет смысл синхронизировать с этими секциями. Там вы можете человеческим языком описать, почему именно так анонсируете App и почему не запускаете его для пробных запросов. Отдельно зафиксируйте, какими должны быть follow‑up‑реплики. Тогда новые люди в команде не будут пытаться “починить” промпт, не понимая, что вы делали.

7. Практика: переписываем UX‑часть для нашего GiftGenius

Давайте соберём всё вместе в один более‑менее цельный пример system‑prompt’а. Предположим, у нас был очень скромный system‑prompt:

export const systemPrompt = `
Ты — приложение GiftGenius.
Подбирай подарки пользователю.
`;

Такой текст ничего не говорит о том, когда запускать App, как его анонсировать и что делать после виджета. Добавим UX‑инструкции шаг за шагом.

Сначала чётко обозначим зону ответственности и формат работы:

const role = `
# Роль
Ты — ChatGPT App GiftGenius.
Твоя задача — помогать пользователю подобрать 3–7 релевантных подарков
под заданный бюджет, получателя и повод.
Ты можешь использовать виджет GiftGenius для визуального подбора.
`;

Затем опишем, как анонсировать запуск:

const announce = `
# Анонс приложения
Если считаешь, что виджет GiftGenius поможет лучше,
сначала объясни в одном-двух предложениях,
что сейчас откроется приложение с карточками подарков
и что пользователь сможет их просмотреть и отфильтровать.
Только после этого запускай приложение.
`;

Добавим правила, когда не запускать App:

const noApp = `
# Когда не использовать приложение
Если пользователь спрашивает только о том, что умеет сервис,
или хочет общую теоретическую информацию о подарках,
ответь текстом и не запускай GiftGenius.

Если запрос не относится к подаркам (например, про резюме или код),
отвечай как обычный ChatGPT и не предлагай приложение.

Если пользователь просит не использовать приложения,
считай это обязательным ограничением.
`;

И завершим поведением после использования виджета:

const afterWidget = `
# Поведение после виджета
После того как виджет показал варианты подарков,
кратко опиши результат своими словами.
Предложи пользователю 1–3 следующих шага
(например: изменить бюджет, фильтровать по интересам,
показать только более дешёвые варианты).

Если виджет отправил follow-up‑сообщение,
используй его как основной сигнал для следующего шага.
`;

Финальный system‑prompt может выглядеть так:

export const systemPrompt = `
${role}
${announce}
${noApp}
${afterWidget}
`;

Это уже похоже на спецификацию поведения, а не на “пожелание вселенной”. В следующих модулях вы будете дополнять этот контракт инструкциями про безопасность, галлюцинации, коммерцию и прочие радости взрослой жизни App, но UX‑часть уже лежит фундаментом.

8. Типичные ошибки при настройке UX‑инструкций

Ошибка №1: “App всегда лучше текста”.
Иногда разработчики так гордятся своим виджетом, что требуют от модели вызывать его при любом удобном случае. В результате пользователь получает App даже там, где хотел просто спросить “что это вообще такое?”. Модель становится навязчивой, и люди начинают игнорировать приложение. Правильный подход — явно прописывать сценарии, когда App не нужен, и уважать такие кейсы.

Ошибка №2: отсутствие явного анонса перед запуском App.
Если ассистент молча запускает виджет, пользователь не понимает, откуда взялся блок UI и что с ним делать. Гайдлайны OpenAI и практический опыт показывают: одна-две фразы “сейчас открою приложение, которое сделает X” резко улучшают UX и уменьшают растерянность.

Ошибка №3: слишком агрессивное повторное предложение App.
Бывает, что App после каждого ответа снова предлагает запустить виджет: “Хотите ещё раз открыть приложение? А сейчас? А теперь?”. Это быстро превращается в спам. Лучше зафиксировать в инструкциях, что после первого использования App нужно смотреть на контекст: предлагать его повторно только если пользователь явно меняет параметры задачи или сам просит “показать ещё”.

Ошибка №4: игнорирование явного отказа от приложений.
Фразы вроде “только без приложений, пожалуйста” или “мне неудобно с телефона работать с формами” должны восприниматься как жёсткие ограничения. Если модель продолжает навязывать App, пользователь теряет доверие и к ассистенту, и к вашему продукту. В system‑prompt это легко фиксируется двумя‑тремя предложениями, но многие забывают это сделать.

Ошибка №5: отсутствие резюме и follow‑up‑сообщений после виджета.
Иногда виджет честно показывает варианты, а ассистент после этого молчит. Пользователь видит UI, но не понимает, что дальше. Никакого текста, никакого вопроса, никаких кнопок с популярными действиями. Такой сценарий выглядит незавершённым и ломает связность диалога. Всегда прописывайте в инструкциях, что после виджета должен идти краткий текстовый итог и 1–3 понятных следующих шага.

Ошибка №6: смешивание продуктового UX и “общего стиля ChatGPT” в одном абзаце.
Иногда system‑prompt превращается в длинный художественный текст: “Будь дружелюбным, используй эмодзи, иногда шути, если уместно. И да, может быть, когда‑нибудь запускай App.” В таком тексте очень сложно заметить реальные UX‑правила. Лучше выделять отдельные секции с чёткими заголовками: “Роль”, “Диалог и UX”, “Когда использовать App”, “Когда не использовать App”. Это помогает и модели, и людям, которые будут с этим промптом работать после вас.