Душните на здоровье - не жалко. Я тоже люблю душнить. Часто занимаюсь этим при разработке или ревью спецификаций на разработку, учебных курсов, юридических документов, статей для научных журналов. Там где это важно.
Добрый день! Это же не я, это результат запроса: "Найди недостатки промпта. Предложи более эффективный промпт для данной задачи." Да, пропустил контекст) Я в другом чате предложил Егору использовать еще один шаг: Просить ИИ проанализировать исходный промпт, найти в нем недостатки и предложить более совершенный. Здесь я привел результат, который выдал 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 лет после возникновения системы стандартов документирования процесса проектирования ПО некоторые люди вдруг поняли, что проектировать и разрабатывать ПО, не записывая проектные решения, трудно.
Душните на здоровье - не жалко. Я тоже люблю душнить. Часто занимаюсь этим при разработке или ревью спецификаций на разработку, учебных курсов, юридических документов, статей для научных журналов. Там где это важно.
Спасибо за реакцию. Да, правильнее было бы написать "кластер ИИ-агентов с MCP-обвязкой", но я не настолько душный :)
Добрый день!
Это же не я, это результат запроса: "Найди недостатки промпта. Предложи более эффективный промпт для данной задачи."
Да, пропустил контекст) Я в другом чате предложил Егору использовать еще один шаг: Просить ИИ проанализировать исходный промпт, найти в нем недостатки и предложить более совершенный. Здесь я привел результат, который выдал 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 лет после возникновения системы стандартов документирования процесса проектирования ПО некоторые люди вдруг поняли, что проектировать и разрабатывать ПО, не записывая проектные решения, трудно.
Хороший пример системного мышления. Спасибо.