UX-паттерны для ИИ-функций

Часть названий ниже — из статьи Виталия Фридмана «Design Patterns for AI Interfaces» (Smashing Magazine, 2025) и его воркшопа об ИИ-интерфейсах. Daemons — идея Мэгги Эпплтон, style lenses — Амелии Ваттенбергер. Остальные названия рабочие: единого словаря для таких паттернов пока нет. Здесь они пересказаны своими словами и привязаны к задачам дизайнера.

Quiet AI vs Visible AI. Quiet AI работает незаметно, встроенным улучшением обычного действия: автодополнение, умная сортировка, тихая подсказка. Пользователь может вообще не осознавать, что за этим стоит модель. Visible AI — явно выделенная функция («Сгенерировать с ИИ», отдельный чат-помощник), которую пользователь сознательно вызывает. Это дизайнерское решение, а не техническое. Чем выше цена ошибки и чем важнее, чтобы пользователь понимал источник результата (принцип Explainability из темы «Принципы дизайна ИИ-продуктов»), тем больше смысла делать ИИ видимым, а не прятать его в фоне.

Индикатор силы промпта (prompt strength indicator). Живой индикатор рядом с полем ввода, который ещё до отправки подсказывает пользователю, достаточно ли деталей в запросе для хорошего результата. Похоже на шкалу сложности пароля при регистрации. Снижает число промптов «одной строкой», против которых построена анатомия промпта из темы «Фундамент».

Модификаторы (modifiers). Готовые управляемые параметры вместо текстового промпта: переключатель тона («короче» / «формальнее»), кнопка «ещё вариант». Это широкая категория: любой элемент управления, который меняет поведение ИИ без слов.

Precision knobs. Более узкий, точный подвид модификатора: явный численный или визуальный регулятор («консервативно ↔ смело», ползунок 0–100%). Он даёт ощутимый, измеримый контроль над степенью вмешательства ИИ. Простой переключатель «включено/выключено» или пресет из готового списка даёт несколько положений, а precision knob — непрерывный диапазон.

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

Forced ranking. Модель выдаёт не один ответ, а несколько вариантов, и явно просит пользователя выбрать или ранжировать лучший. Это одновременно улучшает непосредственный результат для пользователя и собирает данные о предпочтениях, которые можно использовать для улучшения системы дальше (принцип Data Collection + Evaluation).

Style lenses. Заранее заготовленные пресеты стиля или тона, которые применяются к результату одним кликом. Это предметный аналог стайл-гайда из темы «Персонажи и стиль», только вынесенный в готовый переключатель внутри продукта, а не составляемый каждый раз заново вручную.

Daemons. Фоновые «персонажи», которые без запроса подсвечивают твою работу с разных позиций — скептик, редактор, читатель — и молчат, пока им нечего сказать. Главный дизайнерский вопрос для daemon-паттерна: как обозначить, что что-то уже подготовлено в фоне, не создавая ощущения слежки или потери контроля.

Верификационные шаги (verification steps) и consensus meter. Перед тем как результат ИИ применяется необратимо (особенно для agentic-действий, см. ниже), интерфейс явно останавливается и просит подтверждения. Consensus meter — более тонкий инструмент калибровки доверия. Это визуальный индикатор того, насколько уверенно или согласованно система пришла к этому результату: например, несколько прогонов модели сошлись на одном ответе или разошлись. Чем ниже согласованность, тем очевиднее должна быть просьба проверить результат вручную.

Библиотека Эмили Кэмпбелл Shape of AI (лицензия CC BY-NC-SA) раскладывает паттерны на шесть категорий:

• wayfinders (галерея примеров, подсказки, подталкивания);
• inputs, они же prompt actions (развернуть, inpainting, сводка);
• tuners (вложения, фильтры, параметры);
• governors (план действий, цитаты, верификация);
• trust builders (оговорка, раскрытие, следы);
• identifiers (аватар, цвет, характер).

Это даёт словарю Фридмана вторую систему координат: его паттерны про ввод и управление, а Shape of AI — ещё и про доверие и идентичность.

Отдельной строкой идут компоненты Vercel AI Elements как словарь интерфейса агента: Reasoning, Sources, Confirmation, Plan, Task, Checkpoint, Inline Citation, Tool, Chain of Thought. Если прототип собирается на Vercel AI SDK, названия паттернов и компонентов совпадают.

Чтобы паттерны не оставались только словами, вот как несколько из них могут выглядеть вместе на одном гипотетическом экране «Сгенерировать email-рассылку с ИИ». Пользователь заполняет task builder: тема письма, аудитория, тон, вместо пустого поля промпта. Справа от поля темы виден индикатор силы промпта («добавь пример прошлой рассылки — результат будет точнее»). После генерации показываются три варианта через forced ranking с просьбой выбрать лучший. У выбранного варианта есть переключатель style lenses («формальнее» / «дружелюбнее») без повторной генерации с нуля. И перед реальной отправкой всей базе подписчиков — обязательный verification step: «Проверь текст и подтверди отправку 12 400 адресам». Цена ошибки здесь — разослать неудачный текст всей базе, поэтому это явно Visible AI с обязательным подтверждением, а не Quiet AI, работающий в фоне. Рядом с выбранным вариантом по правилам Apple HIG стоят Изменить, Отменить, Повторить и Настроить, а строка прогресса говорит «Собираю три варианта по вашему брифу», а не «Загрузка».

Отдельный, более сложный случай: не просто «модель сгенерировала контент», а «агент сам выполняет цепочку действий внутри продукта». По смыслу это перекликается с темой «CLI и терминальные ИИ-агенты», но теперь ты смотришь с позиции того, кто проектирует это для конечного пользователя, а не сам этим пользуется. Здесь работает тот же принцип «режимов одобрения», который уже встречался в терминальных агентах. Только теперь его нужно спроектировать самому:

• Постепенное наращивание автономности. Не давай агенту сразу полный доступ ко всем действиям. Начинай с режима, где агент только предлагает план и ничего не делает без подтверждения. Расширяй автономию только для узкого класса заведомо безопасных, легко обратимых действий, по мере того как накапливается доверие к конкретному сценарию.
• Уровни риска и разные пороги подтверждения. Не все действия агента одинаково опасны. Перекрасить кнопку и списать деньги со счёта не должны требовать одинакового уровня подтверждения. Дизайн agentic-функции явно классифицирует действия по цене ошибки и назначает порог подтверждения под каждый уровень отдельно, а не единое правило на всё сразу.
• Guardrails — жёсткие ограничения того, что агент не может делать вообще, ни при каком запросе пользователя. Это аналог «нельзя» из AGENTS.md в теме «AI-first дизайн-системы», только теперь ограничение для агента внутри продукта, а не для агента, который этот продукт собирает.
• Permissions — какие именно действия и данные разрешены агенту для конкретного пользователя или роли. Тот же принцип авторизации из темы «Технический фундамент», применённый к самому агенту, а не только к человеку.
• Approval flow — явный экран «вот что я планирую сделать, подтверди» перед выполнением необратимого или дорогого действия. Это прямое отражение «режимов одобрения» из терминальных агентов, только спроектированное для конечного пользователя продукта, который может вообще не знать слова «агент».
• Human-in-the-loop — осознанное решение держать финальное решение по определённому классу действий за человеком всегда, без опции полной автономии. Не потому что технология не может. Цена ошибки или этическая значимость решения (принцип Accountability) требует этого как принципа продукта, а не временного ограничения.

Пять уровней автономности по Фэну, Макдональду и Чжану:

• L1 оператор — пользователь управляет всегда;
• L2 соавтор — планируют и выполняют вместе;
• L3 консультант — агент берёт инициативу и спрашивает направление;
• L4 утверждающий — пользователь вмешивается только на блокерах и значимых действиях;
• L5 наблюдатель — только аварийный выключатель.

Уровень — осознанное дизайнерское решение, независимое от того, что модель технически может. У Нильсена та же мысль: «автономность надо заслужить, а не выдать сразу», а пользователь переходит «из оператора в супервайзера».

Практическое правило из Smashing Magazine (январь 2026): четыре режима — наблюдать и предлагать, планировать и предлагать, действовать с подтверждением («пользователь подтверждает результат, а не стратегию»), действовать автономно. Метрики там же: доля вмешательств, нежелательные действия на 1000 задач, доля откатов, время до решения.

Где ставить подтверждение в многошаговом сценарии, проверяли Чжоу и коллеги. Подтверждение только в конце хрупко, на каждом шаге утомительно. Промежуточные точки подтверждения по схеме «подтверждение → диагностика → исправление → переделка» в их эксперименте предпочли 81% участников, и задачи решались быстрее. Anthropic в «Building effective agents» советует то же: останавливаться за обратной связью на контрольных точках и при блокерах и задавать условия остановки, например максимум итераций.

Пример: напоминания и автосписание в «Сплите» (вымышленное приложение из темы «Процесс с ИИ: Double Diamond и Design Sprint»). В теме «Синтез интервью и качественных данных» участники разошлись: одни хотят автоматические напоминания, другие боятся, что напоминание от приложения «будет выглядеть как претензия». Уровни автономности дают ответ не «да или нет», а «какой уровень для какого действия» (пример условный):

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

Наш продукт даёт ИИ-агенту право самому редактировать данные пользователя. Распиши, какие действия можно доверить полной автономии, а какие обязательно требуют approval flow, и почему

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

Предложи, где в этом сценарии [описать] уместнее Quiet AI, а где — явно видимая ИИ-функция, и обоснуй разницу

Собери экран, где сочетаются task builder, forced ranking и verification step, для функции [описать] — распиши, что видит пользователь на каждом шаге

Объясни разницу между обычным модификатором (переключатель тона) и precision knob (числовой ползунок) — когда какой уместнее для функции редактирования фото в нашем продукте

Наш агент делает [цепочка действий]. Назначь ему уровень автономности от L1 до L5 по Feng и др. и обоснуй. Затем разложи шаги цепочки по четырём режимам: наблюдать и предлагать, планировать и предлагать, действовать с подтверждением, действовать автономно. Для каждого шага: цена ошибки, обратимость за день, порог подтверждения

Вот многошаговый сценарий агента: [шаги]. Предложи, где поставить промежуточные точки подтверждения по схеме "подтверждение → диагностика → исправление → переделка", так чтобы пользователь не подтверждал каждый шаг, но мог исправить ошибку до того, как она размножится. Для каждой точки — что именно пользователь видит и что может изменить

Собери экран результата генерации для функции [описать] по правилам Apple HIG: пометка "сгенерировано", рядом Изменить, Отменить, Повторить, Настроить, конкретный текст прогресса, альтернативный вариант и путь без ИИ. Распиши, что видит пользователь в каждом состоянии: ожидание, успех, частичный результат, ошибка ограничителя