Добрый день! Это же не я, это результат запроса: "Найди недостатки промпта. Предложи более эффективный промпт для данной задачи." Да, пропустил контекст) Я в другом чате предложил Егору использовать еще один шаг: Просить ИИ проанализировать исходный промпт, найти в нем недостатки и предложить более совершенный. Здесь я привел результат, который выдал gpt 5 pro
Ниже — краткий разбор и готовый улучшенный промпт, который можно копировать и использовать.
Недостатки исходного промпта
Не зафиксированы термины: какая дата фильтрации (создание/оплата/доставка), включительность границ, часовой пояс.
Не определён формат даты/времени и правила интерпретации дат без времени.
Не ограничена область: допускает добавление несвязанных функций (экспорт, доп. фильтры).
Нет явных дефолтов 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.
• Нет дубликатов и размытых формулировок; при выявлении — исправь и пересчитай нумерацию.
Есть. Например на сайте techinvestlab можно посмотреть .15926 Editor - для моделирования данных по ИСО 15926. Но как показывает практика, самый мощный и гибкий метод - моделирование с помощью электронных таблиц. Их можно потом в любой формат конвертировать при необходимости и визуализировать.
Зависит от цели создания и способа использования. От ручки и бумаги, до специализированных моделеров. Можно использовать, например, любой инструмент, поддерживающий UML.
Я даже не знаю - кто-нибудь разрабатывал ли более-менее целостные онтологии на основе базовых объектов Партриджа и Веста или нет - мне такие неизвестны. У Веста в приложениях есть диаграммы и псевдокод только для базовых объектов, отдельно как его объекты соотносятся с базовыми объектами ISO 15926, которые довольно близки (он принимал участие в его разработке).
Удивительно. Через 50 лет после возникновения системы стандартов документирования процесса проектирования ПО некоторые люди вдруг поняли, что проектировать и разрабатывать ПО, не записывая проектные решения, трудно.
Добрый день!
Это же не я, это результат запроса: "Найди недостатки промпта. Предложи более эффективный промпт для данной задачи."
Да, пропустил контекст) Я в другом чате предложил Егору использовать еще один шаг: Просить ИИ проанализировать исходный промпт, найти в нем недостатки и предложить более совершенный. Здесь я привел результат, который выдал gpt 5 pro
Ниже — краткий разбор и готовый улучшенный промпт, который можно копировать и использовать.
Недостатки исходного промпта
Не зафиксированы термины: какая дата фильтрации (создание/оплата/доставка), включительность границ, часовой пояс.
Не определён формат даты/времени и правила интерпретации дат без времени.
Не ограничена область: допускает добавление несвязанных функций (экспорт, доп. фильтры).
Нет явных дефолтов UI/UX (сортировка, пагинация, размеры страниц, состав полей строки заказа).
Нет конкретных бизнес‑ограничений (макс. длина периода, запрет будущих дат).
Слабая проработка ошибок: нет требований к точным текстам сообщений.
Не задана обязательная охватность по категориям (доступ/валидация/границы/результаты/ошибки/NFR).
Нет нефункциональных метрик (время ответа, таймауты, объём данных).
Не закреплены требования к безопасности (доступ только к своим заказам, поведение по прямым ссылкам).
Нет запрета на размытые слова («корректно», «должна»), что снижает проверяемость.
Более эффективный промпт (для этой задачи)
https://chatgpt.com/share/68f62fc2-fb28-8003-af88-b9814c82e3ff gpt 5 pro
Вам спасибо. Возможно это не надолго, учитывая своеобразие здешней системы рейтинга)
Есть. Например на сайте techinvestlab можно посмотреть .15926 Editor - для моделирования данных по ИСО 15926. Но как показывает практика, самый мощный и гибкий метод - моделирование с помощью электронных таблиц. Их можно потом в любой формат конвертировать при необходимости и визуализировать.
Зависит от цели создания и способа использования. От ручки и бумаги, до специализированных моделеров. Можно использовать, например, любой инструмент, поддерживающий UML.
Я даже не знаю - кто-нибудь разрабатывал ли более-менее целостные онтологии на основе базовых объектов Партриджа и Веста или нет - мне такие неизвестны. У Веста в приложениях есть диаграммы и псевдокод только для базовых объектов, отдельно как его объекты соотносятся с базовыми объектами ISO 15926, которые довольно близки (он принимал участие в его разработке).
Примеры можно посмотреть в книгах, ссылки на которые указаны в конце поста.
Удивительно. Через 50 лет после возникновения системы стандартов документирования процесса проектирования ПО некоторые люди вдруг поняли, что проектировать и разрабатывать ПО, не записывая проектные решения, трудно.
Хороший пример системного мышления. Спасибо.