Требования через примеры: 5 ситуаций, чтобы ИИ не додумывал

Почему ИИ начинает додумывать требования

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

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

Как неопределенность превращается в лишние функции

Если не задать границы, ИИ добавляет «на всякий случай». Это особенно заметно, когда вы собираете продукт через vibe-coding платформу вроде TakProsto: модель легко предлагает полный набор экранов, таблиц и обработчиков, потому что так устроен типовой проект.

Чаще всего лишнее нарастает в одних и тех же зонах. В формах появляются дополнительные проверки, подсказки и автосохранение. В оплате всплывают статусы, возвраты, промокоды и сценарий «платеж не прошел». В ролях и доступах внезапно вырастает админка, модераторы, аудит действий. В уведомлениях добавляются email, SMS, пуши и настройки отписки. А в «крайних случаях» возникают лимиты, блокировки, таймауты и повторные попытки.

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

Почему помогают ситуации, а не «умные» формулировки

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

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

Когда достаточно двух ситуаций? Если фича линейная, без ролей и без денег: простой поиск по списку или экран настроек с парой переключателей.

Когда лучше дать пять? Когда есть разные типы пользователей, платежи, статусы, ручная модерация, отмены, возвраты или жесткие ограничения. Именно «пятая ситуация» часто ловит то, что ломает продукт в реальности.

Что такое техника «вот 5 реальных ситуаций»

Техника «вот 5 реальных ситуаций» - это способ описать задачу не абстрактно, а через пять жизненных эпизодов, где человеку нужно сделать конкретное действие и получить понятный результат. Вы показываете, как фича должна работать в реальности, а не как она должна называться.

Ситуация - это небольшой сценарий на 3-5 фраз. В нем есть контекст (кто и где), действие (что человек делает) и ожидаемый итог (что должно получиться). Чем конкретнее входные данные и ограничения, тем меньше ИИ будет додумывать.

Что именно считается «ситуацией»

Хорошая ситуация отвечает на три вопроса:

• Кто пользователь и в каких условиях он действует (роль, устройство, доступы).
• Что он делает одним-двумя шагами (кнопка, форма, поиск, оплата).
• Как выглядит правильный результат (что видно на экране, что сохранилось, какое сообщение показано).

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

Какие вопросы техника снимает заранее

Пять ситуаций обычно закрывают самые частые «дыры», из-за которых ИИ ошибается:

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

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

Как подготовиться: выбрать фичу и собрать ситуации

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

Выберите фичу, которую реально описать за пару минут без длинных вводных. Например: «форма заказа», «вход по коду», «список задач», «поиск по каталогу». Если вы работаете в TakProsto, это может быть один экран будущего приложения, который вы хотите быстро собрать через чат.

Дальше зафиксируйте, кто пользователь и зачем он это делает, одной фразой. Не нужен портрет на страницу, достаточно смысла действия. Например: «Курьер хочет быстро отметить доставку, чтобы закрыть заказ и не ошибиться адресом». Эта фраза становится фильтром: все ситуации должны крутиться вокруг одной цели.

Где взять 5 ситуаций

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

Соберите пять ситуаций так, чтобы они были разными по рискам:

• две «нормальные» (самый частый путь без сюрпризов);
• две «крайние» (ошибка, пустые данные, нет связи, невалидный ввод);
• одна «важная редкость» (случается не каждый день, но дорого стоит, если сломается).

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

Быстрая проверка покрытия

Чтобы требования через примеры действительно работали, убедитесь, что в ваших пяти ситуациях есть как минимум:

• успешный исход (что считается «готово»);
• один отказ/ошибка и что показываем пользователю;
• вариант с пустыми или частично заполненными данными;
• ограничения по времени/сети/повтору (например, двойной клик или повторная отправка).

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

Пошагово: как писать одну ситуацию так, чтобы ИИ понял

Одна ситуация должна быть маленькой и проверяемой. Не «пользователь работает с задачами», а конкретный эпизод: кто человек, что он хочет сделать прямо сейчас, и по каким признакам вы поймете, что все сработало.

Шаг 1. Опишите контекст

Начните с 1-2 предложений: кто пользователь, где он находится (в приложении/разделе), и с чем он пришел (какая цель или проблема).

Пример: «Менеджер заходит в веб-кабинет и хочет быстро найти последний счет клиента, потому что клиент звонит и ждет ответ».

Шаг 2. Дайте действие пользователя по шагам (1-2-3)

Опишите только то, что делает человек, без надежды, что «система сама догадается». Обычно хватает 3-5 шагов.

• Открывает раздел «Счета».
• Вводит ИНН клиента в поиск.
• Выбирает клиента из списка.
• Нажимает «Показать последний счет».

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

Шаг 3. Зафиксируйте ожидаемый результат и критерии «готово»

Это самая важная часть, она и убирает додумывание. Пишите так, чтобы можно было проверить.

Пример: «Показывается карточка последнего счета: номер, дата, сумма, статус оплаты. Если счетов нет, показывается понятное сообщение и кнопка “Создать счет”».

Шаг 4. Добавьте ограничения и исключения (если есть)

Ограничения сокращают варианты решения. Исключения объясняют, что делать в неудобных случаях.

Примеры: «Пользователь видит только счета своей компании». «Если сервис недоступен, показываем ошибку и даем повторить запрос». «Если найдено 20+ клиентов, просим уточнить запрос».

Шаг 5. Укажите данные и обязательные поля

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

Пример: «Для поиска обязателен ИНН или название. Для создания счета обязательны: клиент, сумма, дата, валюта. Статус оплаты подтягивается автоматически и вручную не меняется в этой форме».

Если вы работаете в TakProsto, такие ситуации удобно сразу превращать в экраны, поля и проверки, а дальше переходить к плану работ без лишних догадок.

Какие 5 ситуаций чаще всего дают лучший результат

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

Вот набор, который почти всегда полезно описать (коротко, по 3-5 строк на ситуацию):

• Нормальный успешный сценарий. Шаги, ожидаемый результат, обязательные поля, что появляется на экране после успеха.
• Ошибка ввода и проверка данных. 1-2 типовые ошибки и как их показывать: где сообщение, можно ли отправить форму повторно.
• Нет прав или другая роль. Что видит гость/пользователь/админ, можно ли открыть страницу, какие действия скрыты.
• Сбой сервиса или недоступность. Таймаут, 500-я, нет сети: что показываем, можно ли повторить, что происходит с введенными данными.
• Отмена и откат. Пользователь передумал: нужно ли подтверждение, можно ли отменить действие, как вернуть состояние.

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

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

Мини-примеры: как одна и та же идея звучит по-разному

Одна и та же фича может быть описана так, что ИИ начнет заполнять пробелы за вас. Или так, что ему просто нечего додумывать. Ниже - короткие пары «плохо/хорошо» на теме регистрации.

Пример 1: «Сделай регистрацию»

Плохо: «Сделай регистрацию пользователя на сайте. Чтобы было удобно и красиво».

Хорошо: «Экран регистрации: поля Email, Пароль, Повтор пароля. Кнопка “Создать аккаунт”. Проверки: Email должен содержать “@”, пароль минимум 8 символов. Если email неверный - показываем текст ошибки под полем: “Введите корректный email”. Если пароли не совпали - “Пароли не совпадают”. При успехе показываем сообщение “Аккаунт создан” и переносим на экран профиля».

Критерий приемки: «Если ввести неверный email, система не отправляет форму и показывает ошибку “Введите корректный email” под полем Email».

Пример 2: «Добавь подсказки»

Плохо: «Сделай подсказки и тексты в форме дружелюбными».

Хорошо: «Тексты интерфейса на русском, тон нейтральный, без шуток. Формат - короткие фразы до 60 символов. Плейсхолдеры: Email - “name@company.ru”, Пароль - “Минимум 8 символов”. Подсказка под паролем: “Используйте буквы и цифры”. Ошибки - только по делу, без восклицаний».

Критерий приемки: «Все сообщения об ошибках на русском, нейтральные, без “!” и длиннее 60 символов не встречаются».

Пример 3: «Пусть пишет понятные сообщения»

Плохо: «Сделай нормальные сообщения, чтобы пользователь понял, что не так».

Хорошо: «Сообщения должны говорить: что произошло, что сделать, где исправить. Примеры: “Email уже зарегистрирован. Войдите или используйте другой email”. “Слишком короткий пароль. Минимум 8 символов”. Не используем технические слова вроде “валидировать”, “500”, “exception”».

Критерий приемки: «В ошибках нет технических терминов и кодов; каждое сообщение содержит действие для пользователя (“введите”, “исправьте”, “используйте другой”)».

Пример 4: «Покажи состояние загрузки»

Плохо: «Добавь лоадер, когда отправляем форму».

Хорошо: «После нажатия “Создать аккаунт” кнопка становится неактивной, текст меняется на “Создаем аккаунт...”. Появляется индикатор загрузки рядом с кнопкой. Повторный клик не отправляет запрос второй раз. Если сервер отвечает ошибкой, кнопка снова активна, показываем сообщение вверху формы: “Не удалось создать аккаунт. Попробуйте еще раз”».

Критерий приемки: «Во время отправки формы повторное нажатие на кнопку не запускает вторую отправку».

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

Частые ошибки и ловушки при описании ситуаций

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

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

Часто не хватает чисел и границ. «Быстро», «много», «иногда», «удобно» звучит по-человечески, но для ИИ это пустые слова. Нужны рамки: лимиты, сроки, форматы, языки, допустимые статусы. Не «пользователь загружает файл», а «PDF до 10 МБ, максимум 3 файла за раз, при превышении лимита показываем ошибку».

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

И наконец - противоречия между ситуациями. Например:

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

ИИ попытается склеить несовместимое, и результат будет непредсказуемым.

Как быстро исправить описание

Перед отправкой в чат (в TakProsto или в другой инструмент) проверьте каждую ситуацию по простым вопросам:

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

Мини-пример: вы пишете «пользователь меняет тариф». Плохой вариант: «сделай как у конкурента, чтобы было красиво». Нормальный вариант: «Пользователь на тарифе Free нажимает “Перейти на Pro”. Если оплаты нет, показываем форму оплаты. Если оплата прошла, тариф меняется сразу, в истории появляется запись. При ошибке платежа показываем понятный текст и кнопку “Повторить”».

Короткий чеклист перед отправкой требований в ИИ

Перед тем как отправлять требования, проверьте, что вы описали не только «что сделать», но и «как это работает в реальных случаях». Требования через примеры помогают ИИ не додумывать, но только если примеры собраны аккуратно.

1) Каждая ситуация оформлена одинаково

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

Если формулировки расплывчатые («пользователь вводит данные, система проверяет»), ИИ начнет выбирать варианты проверки и реакции сам. Лучше конкретнее: «вводит email, нажимает “Продолжить”, видит сообщение…».

2) Есть хотя бы один «плохой ввод» и один «нет доступа»

Минимальный набор для любой фичи:

• одна ситуация с ошибкой ввода (пустое поле, неверный формат, слишком длинное значение);
• одна ситуация с отказом доступа (не авторизован, нет роли, заблокирован, закончилась подписка).

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

3) Обязательные данные и форматы указаны явно

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

Форматы лучше фиксировать словами, а не надеждой: телефон (в каком виде), email (допускаем ли кириллицу), дата (дд.мм.гггг или другой вид), пароль (минимальная длина, требования к символам). Если формат не важен, так и напишите: «любой валидный email».

4) Сообщения об ошибках описаны хотя бы по смыслу

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

• Плохо: «показываем ошибку».
• Хорошо: «объясняем, что поле email заполнено неверно, и просим исправить; данные в других полях сохраняем».

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

5) Понятно, что считать «готово» без догадок

В конце набора ситуаций добавьте 1-2 предложения, которые фиксируют результат: что именно должно работать, чтобы вы сказали «сделано». Например: «Все пять ситуаций воспроизводятся без расхождений. Ошибки показываются понятным сообщением. При отказе доступа пользователь не видит защищенные данные».

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

Реалистичный пример: одна фича и 5 ситуаций на практике

Возьмем понятную фичу: «Запись на прием» (или «Заявка на услугу»). Цель простая: человек выбирает услугу и время, оставляет контакты, получает подтверждение. Если дать ИИ только эту фразу, он начнет угадывать: какие поля нужны, что делать при ошибках, как вести отмены.

Ниже - пять ситуаций, которые закрывают основные развилки и почти не оставляют места фантазии:

1. Новый пользователь впервые заходит, выбирает услугу «Консультация», видит доступные слоты, вводит имя и телефон, подтверждает запись.
2. Повторный пользователь уже записывался, телефон есть в системе, форма подставляет имя и телефон, остается выбрать услугу и слот.
3. Ошибка телефона: вводит номер в неверном формате, система не создает запись, подсвечивает поле и показывает понятное сообщение.
4. Нет подходящего слота: пользователь выбирает день, а свободного времени нет, система предлагает альтернативы (другие дни/специалисты) или ожидание.
5. Отмена: пользователь хочет отменить запись, система просит подтверждение, меняет статус и показывает итоговое сообщение.

Когда у ИИ есть такие ситуации, он обычно уверенно предлагает структуру формы (имя, телефон, услуга, дата, время, комментарий), статусы заявки (черновик, подтверждена, отменена), а также тексты сообщений для каждого шага. В TakProsto это удобно превращать в рабочую логику: страницы, состояния, базовые проверки и понятные экраны.

Но даже с ситуациями остаются места, где нужны уточнения, иначе ИИ снова начнет додумывать. Например: нужно ли отправлять уведомления и куда (SMS, мессенджер, email), кто видит список записей (админ, оператор, специалист), сколько времени хранить данные, можно ли редактировать запись, нужна ли авторизация, и что считать «повторным» пользователем (телефон, email, аккаунт).

Если добавить эти уточнения рядом с ситуациями, ИИ сможет собрать более точное ТЗ: какие поля обязательны, какие правила валидации, какие переходы статусов и какие тексты показывать человеку.

Следующие шаги: превратить ситуации в понятное ТЗ и план работ

Когда у вас готовы 5 ситуаций, не размазывайте их по переписке. Соберите в одном сообщении, чтобы ИИ видел картину целиком и меньше угадывал. Можно прямо написать: «Это мои требования через примеры. Сначала задай вопросы, только потом предлагай решение».

Попросите ИИ начать с уточнений. Хороший признак - он спрашивает про границы (что считается успехом), исключения (что делать в странных случаях) и роли (кто и что видит). Плохой - он сразу уходит в реализацию, не проверив детали.

Дальше просите результат не эссе, а короткую и проверяемую структуру. Например: «Сформулируй 10-15 требований, найди конфликты между ситуациями и предложи, какие правила приоритетнее».

Процесс можно держать простым:

• Отправьте 5 ситуаций одним блоком и попросите 5-10 уточняющих вопросов.
• После ответов попросите список требований + таблицу “ситуация -> ожидаемое поведение”.
• Попросите выделить спорные места и минимум 2 варианта решений с последствиями.
• Попросите черновой план работ: шаги, порядок, что можно отложить.

Закрепляйте результат версиями. Введите правило: каждая итерация имеет номер (v0.1, v0.2), и вы отдельно фиксируете, что изменилось: «добавили правило», «убрали исключение», «поменяли приоритет». Так вы не потеряете договоренности и сможете откатиться к предыдущей логике.

Если вы собираете приложение в TakProsto, начните в режиме планирования: пусть ИИ соберет требования, экраны, роли, основные сценарии и критерии готовности. Затем переходите к сборке по шагам и регулярно сохраняйте снимки, чтобы можно было спокойно откатываться, если новая итерация сломала логику или тексты. На практике это хорошо сочетается с техникой «5 ситуаций»: сначала вы фиксируете поведение, потом уже позволяете системе превращать его в интерфейс и логику без лишних догадок.