Перейти к содержимому
PD
Разработка MVP 8 мин чтения

Хватит выкатывать пустое поле для промпта: дизайн ввода в AI MVP, который реально конвертит

Большинство AI MVP умирают не на модели, а на вводе. Шесть паттернов, которыми я заменяю пустую textarea на структурированную форму, компилирующуюся в промпт - плюс план ретрофита на два дня.

PD

Pavel Duglas

AI Automation & MVP Architect

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

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

Пустая textarea - это экзамен, на который пользователь не записывался

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

Провал происходит молча. Человек пишет что-то короткое и расплывчатое, получает посредственный результат, делает вывод “ну да, AI-шлак” и уходит. В аналитике это выглядит как сессия с одной генерацией и без второй. Если вы вообще что-то считаете, считайте именно это соотношение - первый запуск к повторному. Это самая диагностичная метрика в AI MVP.

На одном инструменте генерации документов пустое поле давало медианный ввод в 9 слов. Девять. Системный промпт на 600 слов аккуратно настроенных инструкций стоял поверх девяти слов пользовательского интента. Модель там была ни при чём.

Считайте воронку до того, как трогать модель

Арифметика убеждает клиентов быстрее любых аргументов про UX.

Допустим, до экрана генерации доходит 1000 человек. С пустым полем 62% получают пригодный первый результат (это измеренная цифра на том же инструменте). Из них примерно половина доходит до второй генерации, а платная конверсия живёт где-то ещё ниже.

Теперь поднимаем успех первого запуска до 90% за счёт структурированного ввода. Вы не тронули модель, не меняли прайс, не докупали трафик. Вы просто перевели 280 человек из состояния “не работает” в состояние “работает”. В недельном спринте валидации MVP это разница между “сигнала нет” и “продолжаем делать”.

Есть и сторона расходов. Плохой ввод даёт плохой выход, плохой выход даёт ретраи, ретраи - это токены. Я видел, как редизайн ввода срезал расходы на inference примерно на треть просто потому, что люди перестали жать “сгенерировать заново” наугад.

Паттерн 1: компилируйте промпт из формы

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

Конкретно, для генератора холодных писем вместо “опишите, что вам нужно” вы спрашиваете:

  • Кому пишем? (должность, free text, обязательно)
  • Что вы продаёте? (одна строка, обязательно, максимум 120 символов)
  • Какое одно действие нужно от получателя? (select: созвон / ответ / триал / другое)
  • Тон (select: прямой / тёплый / формальный)
  • Что нельзя упоминать? (опционально)

А дальше компиляция:

const InputSchema = z.object({
  recipientRole: z.string().min(3).max(80),
  offer: z.string().min(10).max(120),
  cta: z.enum(["book_call", "reply", "free_trial", "other"]),
  ctaOther: z.string().max(80).optional(),
  tone: z.enum(["direct", "warm", "formal"]),
  avoid: z.string().max(200).optional(),
});

function compile(input: z.infer<typeof InputSchema>) {
  const lines = [
    `Должность получателя: ${input.recipientRole}`,
    `Оффер: ${input.offer}`,
    `Целевое действие: ${ctaLabel(input)}`,
    `Тон: ${TONE_GUIDE[input.tone]}`,
  ];
  if (input.avoid) lines.push(`Не упоминать: ${input.avoid}`);
  return lines.join("\n");
}

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

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

Паттерн 2: три пресета вместо тридцати опций

У структурированного ввода есть своя болезнь: форма из 14 полей - это тоже стена. Лечится пресетами, которые заполняют всё, оставляя пользователю одно обязательное поле.

В ассистенте онбординга для одного SaaS на экране генерации было ровно три карточки: “Серия welcome-писем”, “Анонс фичи”, “Реактивация”. Клик по карточке заполнял семь полей разумными дефолтами и ставил курсор в единственное поле, где реально нужны знания пользователя. Время до первого результата упало с примерно 90 секунд до 15.

Пресеты ещё и делают за вас маркетинг. Это самое внятное описание того, что умеет продукт. Пустое поле говорит “что угодно”, а пользователь совершенно справедливо читает это как “ничего конкретного”.

Паттерн 3: показывайте собранную инструкцию и давайте править её последней

Не прячьте промпт. Уберите его под свёрнутый блок “Дополнительно”, где видно точный текст, который вы собираетесь отправить. Две причины.

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

Вторая - это бесплатный ресёрч. Логируйте дифы между собранным промптом и отредактированным. Эти дифы - ваш роадмап, написанный руками пользователей. Когда пятеро дописывают “на русском” или “не больше 100 слов”, вы уже знаете следующие два поля формы. Из дифов правок промпта я вытащил больше пользы для роадмапа, чем из большинства кастдевов.

Паттерн 4: валидируйте до того, как потратили токен

Дешёвые проверки на клиенте и на сервере отсекают почти все обречённые генерации до inference. Мой стандартный набор:

  • Обязательные поля заполнены и не мусорные (отклоняем “asdf”, один символ, только пробелы).
  • Минимальная длина, а не только максимальная. Описание продукта в три слова не даст нормального текста. Скажите об этом прямо.
  • Санити-чек файлов и ссылок. Неверный тип файла, пустой CSV, URL с 404 - всё это ловится меньше чем за секунду.
  • Проверка на инъекции и враждебный контент во всём, что спарсено или загружено. Вставленный текст - это недоверенный ввод в момент попадания в промпт.

Формулировка отказа важнее самого правила. “Слишком короткое описание” бесполезно. “Добавьте деталей: какую проблему решаете и для кого? Например: ‘Выставление счетов для фрилансеров-дизайнеров, которые ненавидят выбивать оплату’” - это учит пользователя форме хорошего ввода за одну строку.

Паттерн 5: первый результат - точка отсчёта, а не приговор

Даже при хорошем вводе первый выход иногда мимо. Ошибка - подавать результат как финальный, с единственной кнопкой “Сгенерировать заново”. Regenerate - это игровой автомат. Пользователь дёргает ручку дважды и уходит.

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

Это ещё и экономика ретраев. Точечное “сделай короче” можно гонять на более дешёвой модели с узким промптом. Слепой regenerate прогоняет весь пайплайн заново.

Паттерн 6: схема ввода - это ваш харнесс для эвалов

Главный бонус, который обычно упускают. Как только ввод стал типизированным объектом, вы можете собрать набор фикстур: 20-40 реалистичных объектов, покрывающих ваши настоящие сегменты, включая уродливые пограничные случаи. Прогоняйте их на каждое изменение промпта, смену модели или новый тариф и смотрите выходы рядом.

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

Когда свободное поле - это правильный ответ

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

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

План ретрофита на два дня

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

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

День второй, утро: соберите форму с одним пресетом, сообщения валидации с примерами и свёрнутый advanced-блок с собранным промптом.

День второй, вечер: возьмите 20 реальных вводов из логов, превратите в фикстуры, прогоните, глазами посмотрите выходы. Дальше выкатывайте на 50% трафика и следите за одной метрикой: доля сессий со второй генерацией.

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

Вопросы и ответы

У меня уже есть работающий продукт со свободным полем. Не сломаю ли я опыт опытных пользователей, заменив его формой?

Не сломаете, если оставите редактируемый advanced-блок. Схема идёт первой, собранный промпт виден и правится под свёрнутым блоком. Опытные пользователи открывают его один раз, видят, что логика адекватная, и дальше чаще всего пользуются формой. А дифы их правок вы логируете и превращаете в новые поля.

Сколько полей должно быть в форме, чтобы она не превратилась в стену?

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

Как быстро понять, что проблема именно во вводе, а не в модели?

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

Похожие статьи