Поиск edge cases в PRD с помощью Claude: 23 пропущенных сценария за один промпт

Большинство багов в продакшене связаны с edge cases, которые не были описаны в требованиях. Не с ошибками в коде, не с плохой архитектурой. С пропущенными сценариями в PRD. Исследования в software engineering стабильно показывают: стоимость исправления дефекта, найденного на этапе требований, в 5–10 раз ниже, чем на этапе тестирования. На этапе продакшена разрыв достигает 100x.

LLM меняет экономику этого процесса. Один промпт, направленный на систематический поиск edge cases в PRD, находит десятки сценариев за минуты. Не потому что модель умнее продакт-менеджера. Потому что у неё нет когнитивных искажений, которые заставляют автора документа считать «очевидные» сценарии покрытыми.

Статья описывает методику, промпты и категоризацию edge cases на реальном PRD фичи управления подписками в travel-приложении.

Почему PRD пропускает edge cases

PRD пишет человек, который знает контекст. Это преимущество и ловушка одновременно. Автор держит в голове «нормальный» сценарий использования и неосознанно строит требования вокруг happy path.

Три системных причины пропусков:

Проклятие знания. Автор PRD знает, как система работает изнутри. Новый пользователь не знает. PRD описывает «пользователь нажимает кнопку подписки» и подразумевает, что пользователь авторизован, имеет валидный платёжный метод и находится в поддерживаемом регионе. Ни одно из этих условий не гарантировано.

Линейное мышление. Требования описывают последовательность шагов. Реальное использование нелинейно. Пользователь открывает форму оплаты, переключается на другое приложение, возвращается через 40 минут. Токен сессии истёк. Что происходит?

Фокус на функциональности, не на границах. PRD отвечает на вопрос «что система делает». Edge cases отвечают на вопрос «что система делает, когда что-то идёт не так». Второй вопрос требует другого режима мышления, и переключение между ними когнитивно затратно.

LLM не страдает ни одной из этих проблем. У модели нет «нормального» сценария. Каждый путь для неё равновероятен.

Базовый промпт для поиска edge cases

Первый промпт, который даёт результат на любом PRD:

Проанализируй PRD ниже. Найди все edge cases, которые не описаны
в требованиях. Для каждого edge case укажи:

1. Категория (input validation / state transitions / concurrency /
   permissions / external dependencies / data boundaries)
2. Сценарий — конкретная ситуация, а не абстрактное описание
3. Ожидаемое поведение, если edge case не обработан
4. Рекомендация — что добавить в PRD

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

PRD:
<вставить текст PRD>

На PRD фичи управления подписками (2 400 слов, 14 user stories) Claude с этим промптом нашёл 23 edge case. Из них 19 были реальными пропусками, 4 уже были покрыты в других частях документации (бэкенд-спецификация, API-контракт).

Но 23 неструктурированных находки сложно приоритизировать. Следующий шаг — категоризация.

Категоризация edge cases: 6 типов

Все edge cases в PRD попадают в одну из шести категорий. Каждая категория требует отдельного промпта, потому что модель находит больше сценариев при узком фокусе.

Input validation

Что происходит, когда входные данные выходят за ожидаемые границы.

Промпт:

Для каждого поля ввода и параметра в PRD определи:
- Минимальное и максимальное допустимое значение
- Поведение при null / undefined / пустой строке
- Поведение при спецсимволах и Unicode (эмодзи, RTL-текст)
- Поведение при значении, превышающем лимит хранилища

Формат: таблица [Поле | Граничное значение | Текущее поведение
по PRD | Рекомендация]

Находки на PRD подписок:

Поле	Граничное значение	Проблема
Промокод	256+ символов	PRD не указывает max length. Бэкенд принимает любую строку, база обрежет до 50 символов без ошибки
Имя в платёжной форме	Кириллица + латиница	Payment provider отклоняет смешанные алфавиты, PRD не описывает валидацию
Email для чека	Email с + ([email protected])	Валидация на фронте отклоняет валидный RFC 5321 адрес

Каждая из этих находок без обработки приводит к молчаливой ошибке. Пользователь не понимает, почему промокод «не работает». Саппорт не может воспроизвести, потому что тестирует с короткими кодами.

State transitions

Что происходит при переходе между состояниями, особенно при нелинейных и прерванных переходах.

Промпт:

Построй полную диаграмму состояний для основной сущности в PRD.
Для каждого перехода между состояниями определи:
- Возможен ли обратный переход
- Что происходит при прерывании перехода (потеря связи, закрытие
  приложения, таймаут)
- Что происходит при попытке перехода из невалидного состояния
- Есть ли race condition при одновременном переходе из двух клиентов

Выведи список переходов, которые не описаны в PRD.

Находки:

Подписка в состоянии «cancellation pending». PRD описывает два состояния: active и cancelled. В реальности payment provider обрабатывает отмену асинхронно. Между нажатием «отменить» и фактической отменой проходит от 0 до 72 часов. PRD не описывает промежуточное состояние и поведение системы в нём. Может ли пользователь в этом состоянии изменить план? Может ли он отменить отмену?

Downgrade с активными фичами premium-плана. Пользователь на premium-плане создал 15 маршрутов (лимит бесплатного плана: 5). При downgrade PRD указывает «доступ к premium-функциям прекращается». Не указывает, что происходит с 15 маршрутами. Удаляются? Становятся read-only? Пользователь выбирает, какие оставить? Потеря данных без предупреждения — прямой путь к churn.

Истечение trial при offline-использовании. Trial закончился, пока пользователь в горах без связи. Приложение кэширует premium-контент локально. При восстановлении связи система обнаруживает истёкший trial. PRD не описывает, блокируется ли доступ мгновенно или пользователь получает grace period.

Concurrency

Что происходит, когда несколько процессов или пользователей взаимодействуют с одними данными одновременно.

Промпт:

Определи все сущности в PRD, к которым возможен одновременный доступ.
Для каждой сущности:
- Может ли один пользователь работать с ней с нескольких устройств?
- Могут ли несколько пользователей работать с ней одновременно?
- Что происходит при одновременном редактировании?
- Что происходит при одновременном удалении и редактировании?

Для платёжных операций дополнительно:
- Что при double-submit (два нажатия на кнопку оплаты)?
- Что при retry от payment provider после таймаута?

Находки:

Double-submit оплаты. Пользователь нажимает «оплатить», интерфейс подвисает на 3 секунды, пользователь нажимает повторно. Два запроса на списание уходят на payment provider. PRD не описывает идемпотентный ключ и механизм дедупликации. Результат: двойное списание, разбирательство через саппорт, chargeback.

Изменение плана с двух устройств. Пользователь открывает страницу подписки на телефоне и планшете. На телефоне выбирает upgrade до Premium. На планшете нажимает «отменить подписку». Оба запроса уходят с разницей в секунды. Без оптимистичной блокировки или версионирования финальное состояние зависит от порядка обработки запросов на бэкенде.

Webhook от payment provider после таймаута. Запрос на оплату ушёл, бэкенд выставил таймаут 30 секунд, payment provider обработал за 35. Бэкенд пометил транзакцию как failed. Через 5 секунд приходит webhook с успешным статусом. PRD не описывает reconciliation-логику.

Permissions

Что происходит при попытке действий без достаточных прав или с изменёнными правами.

Промпт:

Для каждого действия в PRD определи:
- Какие роли имеют доступ
- Что видит пользователь без доступа (404 vs 403 vs редирект)
- Что происходит, если права изменились во время выполнения операции
- Что происходит с данными, созданными пользователем, при смене его роли
- Есть ли разница между "нет доступа" и "функция не существует"

Проверь: утечка информации через сообщения об ошибках.

Находки:

Shared-маршрут после downgrade автора. Пользователь А поделился маршрутом с пользователем Б, используя premium-функцию sharing. Пользователь А перешёл на бесплатный план. PRD не описывает: остаётся ли shared-доступ у Б? Может ли Б редактировать маршрут? Видит ли Б premium-элементы маршрута (кастомные POI, офлайн-карты)?

API-ключ team-аккаунта при удалении администратора. Team-подписку оформил сотрудник, который уволился. Его аккаунт деактивирован. API-ключи привязаны к его аккаунту. PRD описывает передачу владения подпиской, но не описывает миграцию API-ключей и связанных интеграций.

External dependencies

Что происходит, когда внешние сервисы ведут себя не по спецификации.

Промпт:

Перечисли все внешние зависимости в PRD (API, payment providers,
auth providers, CDN, email, push notifications).
Для каждой зависимости:
- Что если сервис недоступен (timeout 30s)?
- Что если сервис возвращает ошибку 500?
- Что если сервис возвращает данные в неожиданном формате?
- Что если сервис изменил API без уведомления?
- Есть ли fallback? Описан ли он в PRD?

Для payment providers дополнительно:
- Какие валюты поддерживаются?
- Что при конвертации валют и расхождении курсов?

Находки:

Currency mismatch при смене региона. Пользователь оформил подписку в USD, переехал в страну с EUR. Apple/Google автоматически конвертирует валюту при renewal. Конвертированная сумма не совпадает с ценой, отображённой в приложении. PRD показывает цену в «локальной валюте пользователя», но не описывает, чья валюта приоритетнее: App Store или профиля пользователя.

Push-уведомление о renewal без доставки. Push notification service обычно доставляет 85–95% уведомлений. До пользователей, чьи уведомления не дошли, напоминание о предстоящем списании не доберётся. PRD полагается на push как единственный канал. Нет fallback на email или in-app notification.

Data boundaries

Что происходит на границах объёмов данных, временных диапазонов и форматов.

Промпт:

Для каждой сущности в PRD определи:
- Максимальное количество записей на пользователя
- Поведение при достижении лимита (ошибка, очередь, удаление старых)
- Максимальный размер одной записи
- Поведение при дате в прошлом, далёком будущем, 29 февраля
- Поведение при смене часового пояса пользователя
- Поведение при миграции между версиями формата данных

Находки:

Смена часового пояса при активном trial. Trial 14 дней. Пользователь начал trial в UTC+12 (Новая Зеландия), через неделю прилетел в UTC-10 (Гавайи). Разница 22 часа. PRD не указывает, фиксируется ли timezone при старте trial или пересчитывается динамически. В зависимости от реализации пользователь получает от +22 часов до -22 часов trial.

Годовая подписка через 29 февраля. Пользователь оформил годовую подписку 29 февраля 2024. Дата renewal 29 февраля 2025 не существует. PRD не указывает: 28 февраля или 1 марта?

Продвинутый промпт: adversarial review

После прохождения всех шести категорий финальный промпт ищет сценарии, которые пропустили предыдущие проходы:

Ты — adversarial QA engineer с задачей сломать систему, описанную
в PRD. Твоя цель — найти сценарии, при которых:
1. Пользователь теряет деньги
2. Пользователь теряет данные
3. Система переходит в inconsistent state
4. Возникает security vulnerability
5. Нарушается compliance (GDPR, PCI DSS)

Для каждого сценария опиши конкретную последовательность действий,
которая воспроизводит проблему. Не описывай абстрактные риски.

Этот промпт нашёл два сценария, которые не попали ни в одну из шести категорий:

GDPR right to deletion + активная подписка. Пользователь запрашивает удаление аккаунта по GDPR Article 17. У пользователя активная годовая подписка с оставшимися 8 месяцами. PRD не описывает: удаляется ли подписка? Происходит ли автоматический refund? Как payment provider обрабатывает renewal для удалённого аккаунта?

Gift-подписка от заблокированного пользователя. Пользователь А подарил годовую подписку пользователю Б. Пользователь А заблокирован за нарушение ToS. PRD не описывает, аннулируется ли gift-подписка Б.

Методика: порядок применения промптов

Порядок имеет значение. Каждый следующий промпт уточняет контекст и строит на находках предыдущего.

1. Базовый промпт — общий скан, 5-10 минут. Даёт обзор и первичный список.
2. Input validation — границы данных. Самый быстрый способ найти «тихие» баги.
3. State transitions — диаграмма состояний. Находит нелинейные пути, которые не видны в user stories.
4. Concurrency — параллельный доступ. Критичен для платёжных фичей и collaborative-функций.
5. Permissions — права доступа. Особенно важен для multi-tenant и team-планов.
6. External dependencies — внешние сервисы. Находит single points of failure.
7. Data boundaries — граничные значения. Даты, timezone, лимиты.
8. Adversarial review — финальная проверка. Compliance, security, потеря данных.

Полный цикл на PRD из 2 000-3 000 слов занимает 30-40 минут. За это время Claude обработает документ 8 раз с разных ракурсов. Сравнение: ручной review в формате threat modeling workshop с 4-5 участниками занимает 2-4 часа на PRD аналогичного объёма.

Интеграция в рабочий процесс

Edge case review через LLM встраивается в три точки:

До review командой. Прогнать PRD через полный цикл промптов, дополнить документ найденными сценариями. Команда на review получает PRD с уже обработанными edge cases. Обсуждение сфокусировано на приоритизации, не на поиске.

При оценке задач. Разработчик получает user story, прогоняет через промпт input validation + state transitions. Уточняет оценку с учётом edge cases до начала работы, а не после обнаружения в процессе.

При написании тестов. QA-инженер берёт PRD и результаты adversarial review, преобразует в тест-кейсы. Промпт для этого шага:

На основе списка edge cases ниже сгенерируй test cases
в формате Given-When-Then. Для каждого test case укажи:
- Preconditions (состояние системы перед тестом)
- Steps (конкретные действия)
- Expected result
- Priority (P0-P3)
- Тип теста (unit / integration / e2e)

Подход работает ещё эффективнее в связке с context engineering — правильное структурирование контекста для LLM увеличивает полноту находок. Если в промпт вместе с PRD попадают API-спецификация, диаграмма состояний и список известных багов, модель находит межсистемные edge cases, которые пропускает при анализе одного документа.

Для критичных фичей стоит прогнать edge case review через мультиагентный code review. Несколько LLM-агентов с разными ролями (QA, Security, Backend) анализируют один PRD и агрегируют находки. Дублирование находок между агентами подтверждает их валидность, уникальные находки каждого агента расширяют покрытие.

Ограничения подхода

LLM не заменяет доменную экспертизу. Модель не знает, что в конкретной юрисдикции refund при GDPR-deletion регулируется иначе. Модель не знает, что конкретный payment provider обрабатывает webhook с задержкой до 72 часов, а не 30 секунд.

Три ограничения, с которыми стоит считаться:

1. Галлюцинации в приоритетах. Модель может оценить edge case как critical, хотя на практике он возникает у 0.001% пользователей. Приоритизация остаётся за командой.
2. Пропуск доменно-специфичных кейсов. Без контекста индустрии модель не найдёт edge cases, специфичные для travel (визовые требования влияют на booking flow), fintech (settlement periods) или healthcare (HIPAA-specific states).
3. Ложные срабатывания. 15-20% находок при проверке оказываются уже покрытыми в других документах или нерелевантными для конкретной реализации. Фильтрация обязательна.

Результат

19 валидных edge cases из одного PRD. 7 из них были классифицированы как P0-P1 (потеря данных или денег пользователя). 4 попали в backlog как P2. 8 были задокументированы как known limitations с планом на следующие итерации.

Два кейса (double-submit оплаты и downgrade с активными premium-данными) были бы обнаружены только на этапе QA или, хуже, в продакшене. Стоимость исправления на этапе PRD: обновить документ и добавить acceptance criteria. Дойди они до продакшена — это был бы hotfix, refund’ы затронутым пользователям и негативные отзывы в App Store.

Промпты из статьи работают на любом PRD. Скопировать, вставить текст документа, получить список edge cases. Тридцать минут на полный цикл. Ноль причин этого не делать.

---

Нужна помощь с проработкой PRD? Я помогаю стартапам внедрять AI-решения и строить продукты — belov.works.

FAQ

Как приоритизировать, что из 30+ находок реально исправлять?

Применяйте двухосевой фильтр: влияние (приводит ли к потере данных, денег или уязвимости безопасности?) и вероятность (может ли это реально произойти в продакшене или требует маловероятной последовательности событий?). Высокое влияние попадает в спринт независимо от вероятности — edge case с двойным списанием при частоте 0.1% всё равно критичен. Низкое влияние и низкая вероятность уходят в документ «known limitations» с пометкой на будущие итерации. Промпт adversarial review помогает с первичной оценкой серьёзности; финальная приоритизация требует доменного знания о реальных паттернах использования и регуляторных рисках.

Работает ли методология на user stories или эпиках, а не на полных PRD?

Да, но результативность меняется. На user story (обычно 1–3 предложения) базовый промпт выдаёт 3–5 edge cases против 15–25 на полном PRD. Промпт state transitions наиболее ценен для отдельных историй — он вынуждает артикулировать, что происходит до, во время и после happy path. Промпт concurrency часто оказывается самым неожиданным для атомарных историй: даже «простая» история «пользователь обновляет аватар» имеет concurrency-импликации при одновременной авторизации с двух устройств. Полный цикл из 8 промптов на одну историю занимает 10–15 минут вместо 30–40.

Как не повторять одни и те же находки цикл за циклом для одного продукта?

Ведите реестр edge cases — общий документ, фиксирующий каждую находку: категорию, PRD-источник, решение (исправлено, принятый риск, будущий backlog) и добавленные acceptance criteria. Перед запуском цикла на новую фичу передавайте реестр как контекст: «Вот список уже обнаруженных edge cases этого продукта. Исключи покрытые и сосредоточься на том, что ново с учётом этого PRD.» Это устраняет дублирование и направляет модель на действительно новое, особенно на уровнях concurrency и external dependencies, где продуктовые паттерны склонны повторяться.