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

> Методика систематического поиска edge cases в PRD с помощью LLM: восемь промптов по категориям и adversarial review. Реальные находки и приоритизация.
> Author: Roman Belov · Published: 2026-07-14 · Source: https://futurecraft.pro/ru/blog/edge-cases-prd-ai/

Большинство багов в продакшене связаны с 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 с `+` (alice+test@gmail.com) | Валидация на фронте отклоняет валидный 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](/ru/blog/context-engineering-guide/) — правильное структурирование контекста для LLM увеличивает полноту находок. Если в промпт вместе с PRD попадают API-спецификация, диаграмма состояний и список известных багов, модель находит межсистемные edge cases, которые пропускает при анализе одного документа.

Для критичных фичей стоит прогнать edge case review через [мультиагентный code review](/ru/blog/claude-concilium-multi-agent-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](https://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, где продуктовые паттерны склонны повторяться.