AI для код-ревью требований: как LLM находит противоречия, пропуски и неоднозначности в ТЗ

Если вы когда-нибудь перечитывали своё ТЗ в десятый раз и всё равно находили дыру на этапе тестирования — добро пожаловать в клуб. Человеческий мозг блестяще умеет достраивать недостающую информацию и игнорировать то, что идёт вразрез с уже сложившейся картиной. Мы читаем не то, что написано, а то, что ожидаем увидеть. Языковая модель этим недостатком не страдает — именно поэтому она не заменяет аналитика, а дополняет его там, где тот слеп. Этот пост — практическое руководство: какие ошибки LLM вылавливает из требований, как писать промпты для ревью и где проходит граница между «полезно» и «галлюцинация».

Почему человек пропускает ошибки в требованиях

Аналитик составляет требования и вычитывает их. Разработчик читает и задаёт вопросы. Тестировщик пишет кейсы и находит нестыковки. Казалось бы, тройной фильтр. При этом в реальных проектах противоречия всплывают на демо, а то и в проде.

Причина не в компетенции. Мозг устроен так: после третьего прочтения одного и того же документа он перестаёт видеть текст и начинает видеть свою модель этого текста. Пропущенное слово в предложении мозг достраивает сам — и вы не замечаете, что требования к авторизации вообще не упоминают роль «Гость». Противоречие между разделом 3.2 и 7.1? Вы помните, что «так не задумывалось», и строки сливаются в непротиворечивую картину.

Это не баг, а фича эволюции. Просто для код-ревью требований она вредна.

Как LLM видит то, что пропустил аналитик

Языковая модель не устаёт, не достраивает контекст из головы и не испытывает пиетета перед автором ТЗ. Она читает текст как есть — и если в разделе 2 сказано «списание происходит мгновенно», а в разделе 5 — «списание может занимать до 3 рабочих дней», модель укажет на противоречие. Не потому что умнее человека. А потому что ей всё равно, кто и зачем это написал.

Примечательно, что LLM работает с требованиями так же, как статический анализатор с кодом: проходит по дереву и ищет несогласованность. Разница в том, что код формален, а требования на естественном языке — здесь нужен семантический анализ.

graph TD
  A["ТЗ / Спецификация требований"] --> B["LLM-анализ"]
  B --> C["Поиск противоречий"]
  B --> D["Поиск пропусков"]
  B --> E["Поиск неоднозначностей"]
  B --> F["Проверка прослеживаемости"]
  C --> G["Отчёт о проблемах"]
  D --> G
  E --> G
  F --> G
  G --> H["Рекомендации по доработке"]
  
  style A fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style B fill:#f0a500,stroke:#c88400,color:#fff
  style C fill:#7b68ee,stroke:#5a4db2,color:#fff
  style D fill:#7b68ee,stroke:#5a4db2,color:#fff
  style E fill:#7b68ee,stroke:#5a4db2,color:#fff
  style F fill:#7b68ee,stroke:#5a4db2,color:#fff
  style G fill:#50c878,stroke:#3a9a5c,color:#fff
  style H fill:#50c878,stroke:#3a9a5c,color:#fff

Схема выше показывает общий пайплайн: вы подаёте на вход спецификацию, LLM прогоняет её через четыре проверки, собирает проблемы в отчёт и выдаёт рекомендации. Дальше разберём, что стоит за каждым блоком.

Что именно проверять: чек-лист для AI-ревью

Выделим четыре категории проблем, которые модель способна обнаружить. По опыту, это покрывает 80% багов требований, найденных слишком поздно.

1. Противоречия (contradictions)

Два утверждения, которые не могут быть истинными одновременно. Классика: в разделе про права доступа написано «администратор может удалить любой заказ», а в разделе бизнес-правил — «удаление заказа требует согласования с владельцем». LLM находит такие пары даже если они разнесены по разным страницам документа.

Ещё пример: «интерфейс оптимизирован под мобильные устройства с шириной экрана от 320px», а через десять страниц — «таблица с шестью колонками отображается в полный размер на всех устройствах».

2. Пропуски (gaps)

Сценарии, которые не описаны вообще. Модель ищет знакомые ей паттерны неполноты: упомянуты три роли, а права описаны только для двух; описана обработка успешного ответа от внешнего API, но не описана обработка таймаута; есть требование к производительности, но нет данных о целевой нагрузке.

Пропуски — самая опасная категория. Человек их не видит, потому что не знает, что надо искать. LLM видит, потому что знает типовые паттерны систем.

3. Неоднозначности (ambiguities)

Формулировки, у которых больше одной интерпретации. «Система должна быстро обрабатывать запрос» — что такое «быстро»? 100 мс или 30 секунд? «Пользователь получает уведомление» — push, email, SMS или всё сразу? «Отчёт формируется по требованию» — автоматически или по кнопке?

Стоит отметить, что именно неоднозначности — любимая почва для споров «ну я же имел в виду…» через три спринта.

4. Нарушения прослеживаемости (traceability gaps)

Требование ссылается на сущность, которая нигде не определена: «проверка происходит согласно правилам валидации» — каким правилам? «Данные передаются в формате, утверждённом архитектурным комитетом» — где этот формат описан?

graph LR
  A["Требование: списание средств"] --> B{"Проверка на противоречие"}
  C["Требование: возврат средств"] --> B
  B -->|"Противоречие"| D["Списание при нулевом балансе<br/>— не описано поведение"]
  B -->|"Пропуск"| E["Не указан таймаут<br/>платёжного шлюза"]
  B -->|"Неоднозначность"| F["«Быстро» — это 1 секунда<br/>или 30 секунд?"]
  
  style A fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style C fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style B fill:#f0a500,stroke:#c88400,color:#fff
  style D fill:#e0e0e0,stroke:#999,color:#333
  style E fill:#e0e0e0,stroke:#999,color:#333
  style F fill:#e0e0e0,stroke:#999,color:#333

На этой диаграмме — конкретный пример: два связанных требования (списание и возврат средств) прогоняются через проверку, и каждая ветка находит свой тип проблемы. Реальный кейс из банковской сферы, где платёжный модуль описывали три разных аналитика — и никто не заметил, что возврат при нулевом балансе вообще не предусмотрен.

Промпты для AI-ревью требований

Теперь к практике. Промпты ниже оттестированы на Claude 4 и GPT-4o. Порядок важен: сначала даём роль и контекст, потом инструкцию, потом сам текст требований.

Базовый промпт: поиск противоречий

1
Ты — старший системный аналитик с 15-летним опытом. Твоя задача — провести ревью технического задания на противоречия.
2

3
Инструкция:
4
1. Прочитай весь документ.
5
2. Найди все пары утверждений, которые противоречат друг другу.
6
3. Для каждого противоречия укажи:
7
   - номера разделов или цитаты утверждений;
8
   - почему они не могут быть истинными одновременно;
9
   - какой из вариантов, скорее всего, правильный (если можешь предположить).
10
4. Не выдумывай противоречия. Если их нет — скажи об этом прямо.
11

12
Текст требований:
13
---
14
[вставьте ТЗ сюда]
15
---

Промпт: поиск пропусков

1
Ты — системный аналитик. Проанализируй документ с требованиями и найди пропущенные сценарии.
2

3
Проверь по следующим направлениям:
4
- Для каждой роли пользователя описаны ли все операции?
5
- Для каждого внешнего API описана ли обработка ошибок (таймаут, 4xx, 5xx)?
6
- Для каждого действия пользователя описан ли сценарий отмены / возврата?
7
- Описаны ли граничные условия (пустой список, нулевая сумма, максимальная длина)?
8
- Есть ли требования к производительности и безопасности?
9

10
Для каждого пропуска укажи, в каком разделе должна быть эта информация.

Промпт: поиск неоднозначных формулировок

1
Ты — технический писатель с опытом ревью спецификаций. Найди в тексте требований все неоднозначные формулировки.
2

3
Неоднозначной считается формулировка, которая:
4
- содержит оценочные прилагательные без количественной метрики («быстро», «удобно», «красиво», «много»);
5
- использует местоимения или отсылки без явного указания объекта («оно отправляется», «система решает»);
6
- не specifies формат данных, единицы измерения или допустимые значения;
7
- описывает поведение через «может» вместо «должен» / «должна».
8

9
Для каждой найденной формулировки предложи конкретный вариант уточнения.

Промпт: комплексное ревью (всё сразу)

1
Ты — старший системный аналитик. Проведи полное ревью требований.
2

3
Проверь:
4
1. Противоречия — утверждения, которые конфликтуют.
5
2. Пропуски — сценарии, которые не описаны.
6
3. Неоднозначности — формулировки с множественной интерпретацией.
7
4. Прослеживаемость — ссылки на неопределённые сущности.
8

9
Формат ответа: таблица с колонками «Тип проблемы», «Раздел ТЗ», «Описание», «Рекомендация».

Важный нюанс: никогда не отправляйте LLM стопку требований из Confluence одним куском, если они превышают 30 страниц. Модель либо устанет к середине, либо начнёт галлюцинировать. Разбейте ТЗ на логические блоки и прогоняйте по одному.

Подводные камни AI-ревью

Никакая модель не делает работу аналитика за него. Три вещи, о которых надо помнить.

1. Ложные срабатывания. LLM иногда находит «противоречия» там, где их нет: просто потому, что не поняла контекст или специфику предметной области. Например, «списание возможно только после подтверждения» и «списание происходит автоматически» — не противоречие, если подразумевается, что автоматически — после подтверждения. Модель этого не вывела. Каждую находку надо перепроверять.

2. Модель не знает ваш домен. Если вы проектируете систему для расчёта страховых резервов по методике Solvency II, LLM не в курсе, какие там регуляторные требования. Она проверит логику, но не соответствие стандартам. Это остаётся на аналитике.

3. Конфиденциальность. Не загружайте реальные ТЗ в публичные облачные API, если этого не разрешает ваш NDA. Используйте self-hosted модели (локальный Llama, корпоративный Claude через API с подписанным соглашением) либо обезличивайте текст перед отправкой.

Заключение

AI-ревью требований — это не замена аналитику и не магический детектор багов. Это инструмент, который бесстрастно перечитывает документ в пятый раз, когда ваши глаза уже замылились. Противоречия, пропуски, неоднозначные формулировки — LLM вытаскивает их из текста методично и без эмоций. Вы решаете, какие находки действительно проблемы, а какие — ложные тревоги.

Если вы ещё не пробовали прогнать своё ТЗ через LLM — попробуйте сегодня. Возьмите любой документ с требованиями, который уже в работе, скормите базовый промпт из этого поста и посмотрите на результат. Скорее всего, вы удивитесь тому, что найдётся. Более глубокие разборы по функциональным и нефункциональным требованиям и по структуре и типичным ошибкам ТЗ — в соответствующих постах.

PS. Если модель нашла 47 проблем в вашем безупречном ТЗ — не расстраивайтесь. Лучше найти их сейчас, чем на проде в пятницу вечером.