Проверьте требования к продукту на двусмысленность и отсутствующие решения
Автор: AILesson9 мин на настройкуПроверено на:ChatGPTПроверено: 2026-08-28
Быстрый ответ
Найдите формулировки, допускающие несовместимые реализации, и определите ответственного и данные, необходимые для решения. Укажите: Документ с требованиями, Контекст продукта и системы, Объём проверки и управление решениями. Ожидаемый результат: Проверка требований с указанием двусмысленных мест, пробелов в решениях, конфликтов, рисков, уточняющих вопросов и статуса готовности.
1
Добавьте контекст
ваш текст остаётся в этом браузере. AILesson Prompts не отправляет его ни в модель, ни на сервер.
2
Ваш промпт
Незаполненные поля остаются видимыми как заполнители, поэтому вы всё равно можете скопировать и отредактировать промпт
Проверьте точные требования к продукту на двусмысленность, конфликты и отсутствующие решения.
PRD, истории, критерии, схемы, термины, ссылки, версии, комментарии и журнал решений:
[requirements]
Пользователи, процессы, текущее поведение, платформы, состояния, роли, данные, интеграции, ограничения, риски и политики:
[context]
Выпуск, команды, ответственные, проверки, серьёзность, готовность, среды и допустимый объём переписывания:
[review]
Сохраняйте точные выдержки и указатели на их местоположение. Отмечайте субъективные прилагательные и наречия, неопределённые существительные и действующих лиц, расплывчатые количественные выражения, скрытые значения по умолчанию, пассивный залог, скрывающий ответственность, местоимения с несколькими возможными референтами, непоследовательно используемые термины, описания решений без потребности, примеры, ошибочно принятые за исчерпывающие правила, и такие слова, как «простой», «быстрый», «интуитивный», «бесшовный», «гибкий», «безопасный», «поддерживать», «в реальном времени», «обычно», «подходящий» и «и так далее». Для каждой проблемы перечислите не менее двух существенно различающихся реализаций, допускаемых формулировкой, последствия для пользователя или системы, серьёзность, затронутое требование, ответственного за решение, если он указан, необходимые доказательства и один нейтральный уточняющий вопрос. Также проверьте границы объёма, предварительные условия, триггеры, состояния и переходы, разрешения, источник и жизненный цикл данных, поведение при пустом состоянии, ошибке, загрузке, отсутствии сети и повторной попытке, параллельность и идемпотентность, локализацию, доступность, конфиденциальность, безопасность, аналитику, производительность, совместимость, миграцию, откат, зависимости и критерии приёмки. Выявите противоречия между артефактами и решения, отсутствующие в журнале. Не выдумывайте ответы и не переписывайте нерешённые вопросы как факты. В конце разделите блокирующие и неблокирующие пробелы, составьте очередь решений по зависимостям и риску и укажите готовность к реализации и тестированию.
Конфиденциально по умолчаниюПромпт собирается локально в вашем браузере. Не вводите конфиденциальную информацию в сервисы ИИ, если ваша организация этого не разрешает.
От исходных данных к результату
Разобранный пример
Посмотрите, как конкретный контекст превращает этот рецепт в полезный результат
Реальный ввод
Документ с требованиями
PRD v0.7, раздел 2: «Сделать ответственность за приёмку легко видимой для всех пользователей. Инициаторы должны иметь возможность быстро назначить подходящего человека. Система должна надлежащим образом уведомлять их и обновляться в реальном времени. Поддерживать случаи без назначения и так далее». История AC-4: «Если передача находится в состоянии Ready, когда владелец выбирает принимающего, изменение сохраняется». На схеме D2 принимающего выбирает инициатор; в комментарии C18 сказано, что координатор может редактировать. Журнал решений: только веб-прототип; в этом выпуске уведомлений нет; только активные участники рабочего пространства; точная формулировка ещё не определена. В другой истории сказано, что при наличии принимающего статус становится Assigned, но текущая модель содержит только Draft, Active, Ready и Accepted.
Контекст продукта и системы
Роли: инициатор создаёт; владелец выполняет работу; принимающий разрешает приёмку; координатор администрирует рабочее пространство. Утверждено: инициатор или координатор может указать необязательного принимающего; владелец может только просматривать. Журнал аудита записывает действующее лицо, старое и новое значение и время. Используются существующие идентификаторы участников; срок хранения не меняется. Только веб. Доступность требует управления с клавиатуры, программно определяемой метки и обозначения состояния не только цветом. Проверка конфиденциальности завершена. Названия событий аналитики и целевой показатель производительности не определены.
Объём проверки и управление решениями
Выпуск прототипа для тестирования удобства использования. Продуктовая команда отвечает за решения о процессе, дизайн — за текст, инженерная команда — за состояния и поведение при ошибках, специалист по доступности проверяет взаимодействие, исследовательская команда отвечает за сценарий теста. Серьёзность: B блокирует реализацию/тестирование; M позволяет разработку, но создаёт риск несогласованности; L — редакционная проблема. Готовность требует отсутствия пробелов B, проверяемых критериев, утверждённого дизайна, рабочего прототипа, модульных проверок и проверок доступности. Только диагностика; не переписывать окончательные требования.
Пример вывода
Готовность: не готово; остаются шесть блокирующих решений и несколько пробелов средней серьёзности.
B1 — конфликт действующих лиц. В AC-4 сказано «выбирает владелец», на D2 — инициатор, в C18 — координатор, тогда как утверждённый контекст разрешает действие инициатору или координатору, а владельцу оставляет только просмотр. Это допускает несовместимые реализации авторизации и тесты безопасности. Владелец продукта должен подтвердить утверждённое правило во всех артефактах; доказательством служат журнал решений и контекст.
B2 — конфликт состояний. Одна история вводит Assigned, но в утверждённой модели состояния Assigned нет. Реализация может добавить новый переход процесса или сохранить Ready с индикатором поля, что повлияет на хранение, аналитику, миграцию и тесты. Решение принадлежит продуктовой команде: меняет ли назначение принимающего состояние процесса или только отображение поля?
B3 — противоречие уведомлений. «Надлежащим образом уведомлять» допускает электронную почту, push-уведомление, сообщение внутри продукта или отсутствие уведомлений, а журнал решений говорит, что в этом выпуске их нет. Также не определены получатель, триггер, повторение и отказ от уведомлений. Продуктовая команда должна удалить уведомления из этих границ или явно исключить их; никто не должен выдумывать поведение.
B4 — допустимость кандидата и неверные данные. «Подходящий человек» может означать любого пользователя, активного участника, участника с нужной ролью или рекомендованного человека. Утверждённая граница — активный участник рабочего пространства, но критерии приёмки не описывают отправку неактивного участника или постороннего и параллельную деактивацию. Продуктовая и инженерная команды должны определить наблюдаемое отклонение и восстановление; дизайн позднее отвечает за текст.
B5 — поведение без назначения. «Поддерживать случаи без назначения и так далее» не определяет, допустимо ли пустое значение при создании, можно ли позднее снять назначение, кто может это сделать, как оно отображается и может ли продолжаться состояние Ready. Решения принадлежат продуктовой команде; «и так далее» невозможно протестировать.
B6 — сохранение, ошибки и параллельность. «Сохраняется» может означать оптимистичное локальное отображение или подтверждённое сохранение на сервере. Не определены загрузка, сбой, повторная попытка и отправка, два редактора, устаревшее представление, аудит и откат. Инженерная команда предлагает варианты; продуктовая утверждает видимое пользователю правило.
Пробелы средней серьёзности: для «легко», «быстро» и «в реальном времени» нет показателей; точный текст и названия событий аналитики явно не определены; нужны критерии порядка клавиатурной навигации, программно определяемой метки, фокуса после ошибки и нецветового индикатора. «Все пользователи» конфликтует с разрешениями на редактирование по ролям; следует разделить просмотр и редактирование.
Порядок решений: действующее лицо/состояние/уведомления → отсутствие назначения и допустимость кандидата → сохранение/параллельность/ошибки → доступное взаимодействие/текст → аналитика/производительность. Готовность к тестированию наступит только после преобразования пунктов B в наблюдаемые критерии.
Почему это работает
1
Примеры конкурирующих реализаций делают абстрактную двусмысленность конкретной для ответственных за решения.
2
Упорядочивание пробелов по зависимостям не позволяет командам шлифовать критерии вокруг нерешённого основного поведения.
Проверьте результат
Содержит ли каждый случай двусмысленности точную формулировку и два существенно разных толкования?
Назначены ли отсутствующие решения только известным ответственным и не разрешены ли они молча?
Охватывает ли оценка готовности состояния, разрешения, данные, сбои, доступность, конфиденциальность, тестирование и откат?
Используйте уверенно
Часто задаваемые вопросы
Практические ответы о том, когда использовать этот рецепт, что нужно предоставить и где по-прежнему важна проверка человеком
Что подготовить перед использованием «Проверьте требования к продукту на двусмысленность и отсутствующие решения»?
Для «Проверьте требования к продукту на двусмысленность и отсутствующие решения» подготовьте документ с требованиями, контекст продукта и системы, а также объём проверки и правила управления решениями. Заменяйте заполнители только проверяемой информацией. Если какая-либо деталь неизвестна, явно сохраните эту неопределённость и не просите модель делать выводы самостоятельно.
Когда результат «Проверьте требования к продукту на двусмысленность и отсутствующие решения» ещё не готов к использованию?
Результат не готов, если на основе предоставленных доказательств он ещё не даёт заявленный итог — проверку требований с указанием двусмысленных мест, пробелов в решениях, конфликтов, рисков, уточняющих вопросов и статуса готовности — либо опирается на неразрешённые предположения, отсутствующие согласования или вымышленные подробности. Используйте контрольные вопросы как критерии допуска: исправьте исходные данные или назначьте конкретного уполномоченного рецензента вместо того, чтобы шлифовать неподтверждённый результат.
Для каких инструментов ИИ зафиксированы тесты «Проверьте требования к продукту на двусмысленность и отсутствующие решения»?
В опубликованном журнале тестирования «Проверьте требования к продукту на двусмысленность и отсутствующие решения» по состоянию на 2026-08-28 указан ChatGPT. Это подтверждает только зафиксированные запуски, но не гарантирует совместимость или одинаковые результаты в последующих версиях продукта. При использовании другого инструмента или версии оставьте все ограничения явными и перед применением повторите проверку результата.
Преобразуйте подтверждённые потребности пользователей и бизнеса в ограниченные по объёму истории и наблюдаемое поведение, не выдумывая продуктовых решений
Преобразуйте исследовательские вопросы в реалистичные ненаводящие задания со свидетельствами успеха, наблюдениями, подсказками и ограничениями прототипа
Преобразуйте наблюдения сеансов в проблемы удобства использования с подсчётом доказательств, не обвиняя участников и не преувеличивая распространённость
Перейдите от понимания ИИ к выполнению задач. Практикуйтесь в составлении запросов, проверке и улучшении результатов с помощью интерактивных уроков для работы и повседневной жизни.
ChatGPT
