Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 11
Вот здесь:
ChatGPT, Алиса и GigaChat с барского плеча предлагают сразу вывести пользователю список ВСЕХ его заказов, тем самым при наличии долгой истории покупок намертво повесив ЛК или отвалившись по timeout.
Вы не правы. Критерий отработан чётко, строго по UC. Большая история покупок - это уже другой UC и с другими ЗИ.
Однако «живой» аналитик чаще всего совместит два данных AC в одном первом, написав примерно следующее
Ну то есть Вы сознательно написали UC так, чтобы посмотреть разворачивание контекста машиной ? Не этично.
Следующее
Все ИИ, кроме Алисы, в некоторых AC фантазируют и додумывают детали, о которых не указано в исходных данных.
Вы не избавитесь от этого. Галлюцинации - базовое свойство векторного поиска, оснобенно с учетом следующего:
Важно.
Вы дико перегрузили входной промпт прилагательными. "отличными", "исключительными", не хватает разве что "божественными". Это реальный оверпромптинг.
Вы пытаетесь добиться от LLM каких-то космических компетенций, сдвигая вектора поиска в сторону экспертных комплексных решений, но ради чего ? Критериев приёмки по простенькому кейсу ? Ну не удивительно, что они начинают фантазировать и/или цеплять смежные кейсы. Вы их сами об этом попросили.
Андрей, спасибо большое за комментарий!
Согласен, что User Story может быть более детальной, включая, например, информацию о том, что у пользователя больше 1000 заказов, но сама идея User Story и Acceptance Criteria, как раз и заключается в том, что история формулируется как обсуждаемая (Negotiable) и отражающая выгоду для пользователя (Valuable), а через критерии приемки мы её детализируем.
Как часто среднестатистический заказчик приходит к аналитику с запросом: «мне нужна форма отзыва, где текст может быть длиной 7000 символов и можно прикрепить 15 фотографий»?
Чаще всего это выглядит как: «нам нужна форма отзывов с возможностью загрузки фотографий», на основе этого мы формулируем примерно следующую пользовательскую историю: «Я, как покупатель, хочу иметь возможность оставить отзыв о товаре и приложить к нему фото, чтобы оставить образную связь для продавца.», а уже через критерии приемки мы напишем, что длина до 7000 символов и не больше 15 фото.В статье мы обсуждаем все-таки формат документирования требований User Story, при использовании Use Case все эти моменты будут учтены в основном и альтернативных сценариях, но это другой формат документирования требований и там будут свои особенности, про промты для Use Case будет отдельная статья.
User Story написана так, как она формулировалась среднестатистическим заказчиком, владельцем продукта, аналитиком в тех коммерческих и учебных проектах в которых я участвовал. Если у вас есть примеры других подходов, буду рад их изучить!
Про галлюцинации – полностью с вами согласен! Цитата про попугая из эпиграфа статьи именно об этом и говорит =) Я бы даже сказал, это в некотором смысле преимущество ИИ, так как даже если ему давать максимально четкие инструкции, он все равно остается не зашоренным.
Про оверпромптинг – да, эти прилагательные были призваны максимально повысить качество выдаваемого результата, и, возможно, с ними получился некоторый перебор. А как бы вы видоизменили данный промт, могли бы написать свой пример?
Давайте начнём с конца.
Для данной конкретно задачи достаточно старта "Ты - старший бизнес-аналитик на проекте "...". Твоя задача:
Всё. Модель поняла кто она и её не носит по разным кластерам за "экспертизой". То есть на наоборот, группирую всё в один вектор. Меня устраивает результат
Второе
Сама по себе сторя написана может быть в общем как угодно. Но если в ней не хватает данных - я обычно просто "подкладываю" некие общие требования, релевантные для всех кейсов этого модуля.
Так у меня получается стабильнее.
Ну и к базе статьи.
Я в общем довольно часто использую LLM, но обычно лишь в качестве самопроверки "не забыл ли что-то". Редко как первоисточник
Ниже — краткий разбор и готовый улучшенный промпт, который можно копировать и использовать.
Недостатки исходного промпта
Не зафиксированы термины: какая дата фильтрации (создание/оплата/доставка), включительность границ, часовой пояс.
Не определён формат даты/времени и правила интерпретации дат без времени.
Не ограничена область: допускает добавление несвязанных функций (экспорт, доп. фильтры).
Нет явных дефолтов UI/UX (сортировка, пагинация, размеры страниц, состав полей строки заказа).
Нет конкретных бизнес‑ограничений (макс. длина периода, запрет будущих дат).
Слабая проработка ошибок: нет требований к точным текстам сообщений.
Не задана обязательная охватность по категориям (доступ/валидация/границы/результаты/ошибки/NFR).
Нет нефункциональных метрик (время ответа, таймауты, объём данных).
Не закреплены требования к безопасности (доступ только к своим заказам, поведение по прямым ссылкам).
Нет запрета на размытые слова («корректно», «должна»), что снижает проверяемость.
Более эффективный промпт (для этой задачи)
Роль: ты — системный и бизнес‑аналитик e‑commerce.
Цель: составь проверяемые критерии приемки для User Story:
«Я как покупатель интернет‑магазина хочу видеть историю своих заказов за заданный период, чтобы найти информацию о ранее заказанных товарах».
Определения и правила:
• Ключевая дата фильтрации: дата создания заказа.
• Границы периода: включительно.
• Часовой пояс: профиль пользователя; даты без времени интерпретировать как 00:00:00 для начала и 23:59:59 для конца.
• Формат дат: ДД.ММ.ГГГГ.
• Бизнес‑ограничения: макс. длина периода — 24 месяца; дата окончания не в будущем.
Область (scope):
• Только просмотр списка заказов за период и просмотр деталей заказа.
• Не добавляй функции вне области (нет экспорта/доп. фильтров/изменения заказов).
UI/UX дефолты:
• Сортировка по умолчанию: дата создания ↓.
• Пагинация: 20 записей на страницу.
• Поля строки заказа: номер, дата/время создания, статус, итоговая сумма, ссылка на детали.
• Поля деталей заказа: наименование, артикул (если есть), количество, цена за единицу, сумма по позиции.
Безопасность:
• Показывать только заказы текущего пользователя; чужие заказы по прямой ссылке — 403/404.
Ошибки (тексты обязательны):
• «Укажите период», «Неверный формат даты», «Дата начала не может быть позже даты окончания», «Дата окончания не может быть в будущем», «За период заказы не найдены», «Сервис истории недоступен, попробуйте позже».
Нефункциональные требования:
• ≤ 10 000 заказов в периоде — 95‑й перцентиль времени ответа ≤ 2 с; таймаут — 5 с.
Покрытие критериев (обязательно):
1) Доступ/безопасность
2) Форма и валидация дат
3) Границы и часовые пояса
4) Результаты/поля/сортировка/пагинация
5) Детали заказа
6) Пустые результаты
7) Отказоустойчивость/ошибки
8) НФ‑метрики
Формат каждого критерия:
• Строго «При условии..., когда..., то система...».
• Без слов «должна/корректно»; только наблюдаемое поведение и точные значения.
Вывод:
• Таблица с колонками «номер» и «критерий приемки»; 22–30 уникальных критериев.
• Никаких разделов, примечаний и пояснений — только критерии.
Самопроверка перед выводом:
• Каждый критерий связан только с данной User Story.
• Нет дубликатов и размытых формулировок; при выявлении — исправь и пересчитай нумерацию.
Николай, добрый день.
Вы подаёте ряд бизнес-правил и НФТ прямо в промпте. Неужто так делаете в реальности или это просто для примера ?
Я обычно весь контекст держку сбоку и "подкладываю"
Добрый день!
Это же не я, это результат запроса: "Найди недостатки промпта. Предложи более эффективный промпт для данной задачи."
Да, пропустил контекст) Я в другом чате предложил Егору использовать еще один шаг: Просить ИИ проанализировать исходный промпт, найти в нем недостатки и предложить более совершенный. Здесь я привел результат, который выдал gpt 5 pro
Приведенный более эффективный промт очень хорошо, и точно даст более качественные критерии приемки, но он уже более глубоко заточен именно под данную User Story, то есть время на его подготовку больше и требует более глубокого предварительного обдумывания.
Выделил жирным элементы в промте, которые специфичны для конкретной User Story:
Роль: ты — системный и бизнес‑аналитик e‑commerce. Цель: составь проверяемые критерии приемки для User Story: «Я как покупатель интернет‑магазина хочу видеть историю своих заказов за заданный период, чтобы найти информацию о ранее заказанных товарах». Определения и правила:• Ключевая дата фильтрации: дата создания заказа. • Границы периода: включительно. • Часовой пояс: профиль пользователя; даты без времени интерпретировать как 00:00:00 для начала и 23:59:59 для конца. • Формат дат: ДД.ММ.ГГГГ. • Бизнес‑ограничения: макс. длина периода — 24 месяца; дата окончания не в будущем.Область (scope):• Только просмотр списка заказов за период и просмотр деталей заказа.• Не добавляй функции вне области(нет экспорта/доп. фильтров/изменения заказов).UI/UX дефолты:• Сортировка по умолчанию: дата создания ↓. • Пагинация: 20 записей на страницу. • Поля строки заказа: номер, дата/время создания, статус, итоговая сумма, ссылка на детали. • Поля деталей заказа: наименование, артикул (если есть), количество, цена за единицу, сумма по позиции.Безопасность:• Показывать только заказы текущего пользователя; чужие заказы по прямой ссылке — 403/404.Ошибки (тексты обязательны):• «Укажите период», «Неверный формат даты», «Дата начала не может быть позже даты окончания», «Дата окончания не может быть в будущем», «За период заказы не найдены», «Сервис истории недоступен, попробуйте позже».Нефункциональные требования:• ≤ 10 000 заказов в периоде — 95‑й перцентиль времени ответа ≤ 2 с; таймаут — 5 с.Покрытие критериев (обязательно): 1) Доступ/безопасность 2) Форма и валидация дат 3) Границы и часовые пояса 4) Результаты/поля/сортировка/пагинация 5)Детали заказа6) Пустые результаты 7) Отказоустойчивость/ошибки 8) НФ‑метрики Формат каждого критерия: • Строго «При условии..., когда..., то система...». • Без слов «должна/корректно»; только наблюдаемое поведение и точные значения. Вывод: • Таблица с колонками «номер» и «критерий приемки»; 22–30 уникальных критериев. • Никаких разделов, примечаний и пояснений — только критерии. Самопроверка перед выводом: • Каждый критерий связан только с данной User Story. • Нет дубликатов и размытых формулировок; при выявлении — исправь и пересчитай нумерацию.
Если делать его более универсальным для массового применения, то изменил бы его следующим образом:
Роль: ты — системный и бизнес‑аналитик [ОТРАСЛЬ].
Цель: составь проверяемые критерии приемки для User Story:
[ВАША USER STORY]
Определения и правила:
[ОПЦИОНАЛЬНО ЕСЛИ НЕТ КОНКРЕТНЫХ ТРЕБОВАНИЙ УБРАТЬ]
Область (scope):
Не добавляй функции вне области User Story
UI/UX дефолты:
[ОПЦИОНАЛЬНО ЕСЛИ НЕТ КОНКРЕТНЫХ ТРЕБОВАНИЙ УБРАТЬ]
Покрытие критериев (обязательно):
Доступ/безопасность
Форма и валидация вводимых данных
Результаты/поля/сортировка/пагинация
Пустые результаты
Отказоустойчивость/ошибки
НФ‑метрики
Формат каждого критерия:
Строго «При условии..., когда..., то система...».
Без слов «должна/корректно»; только наблюдаемое поведение и точные значения.
Вывод:
Таблица с колонками «номер» и «критерий приемки»; 20–30 уникальных критериев.
Никаких разделов, примечаний и пояснений — только критерии.
Самопроверка перед выводом:
Каждый критерий связан только с данной User Story.
Нет дубликатов и размытых формулировок; при выявлении — исправь и пересчитай нумерацию.
Самый главный вопрос где провести границу между временем подготовки качественного и детального промта и временем на последующее ревью его результатов. Ведь даже в рамках этой конкретной задачи по подготовке критериев приемки в зависимости от опыта специалиста она будет сильно плавать.
Я склоняюсь к тому что лучше быстрее получить результат и провести его ревью и корректировку, чем уделять существенное время детализации промта, при том что не зависимо от того детализируешь ты промт или проводишь ревью, если ты забыл или ни когда не сталкивался с проблемой формата ввода даты, то ты все равно пропустишь это требование не важно в промте или при ревью критериев =)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ИИ-инструменты бизнес и системного аналитика: промт для создания критериев приёмки User Story