Бесплатный фрагмент - AI для продакт-менеджера: PRD, требования и контроль качества

Глава 1. Эра «бесшовных» спецификаций: почему человек больше не лучший аудитор

Еще недавно качество требований держалось на дисциплине: аналитик писал документ, команда обсуждала его на встречах, архитектор задавал уточняющие вопросы, тестировщик добавлял сценарии, а менеджер пытался зафиксировать договоренности. Эта модель работала, пока скорость изменений была умеренной, а продуктовая логика помещалась в голове нескольких ключевых людей. Сейчас требования живут в потоке: правки прилетают из поддержки, продаж, маркетинга, комплаенса, дизайна, разработки, из изменений внешних API и инфраструктуры. Документ перестал быть статичным «текстом на согласование» и стал движущейся системой. В этой реальности аудитор требований в лице человека почти всегда проигрывает не по компетенциям, а по биологии: внимание, память, усталость, когнитивные искажения и эффект «замыленного глаза». ИИ как инструмент контроля качества возвращает в процесс то, чего ему давно не хватало: быстрый, повторяемый, формализуемый и масштабируемый аудит, который не зависит от настроения и загруженности.

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

Цена ошибки в тексте: почему исправление требования на этапе кода стоит в разы дороже

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

Критически важно, что ошибка в требовании редко выглядит как «очевидная ошибка». Чаще это туман: «быстро», «удобно», «по возможности», «достаточно надежно», «система должна», без чисел, без условий, без границ ответственности. Или это неполнота: нет обработки ошибок, нет прав доступа, нет логики удаления данных, нет статусов, нет исключений, нет ролей. Такие «мягкие» дефекты почти всегда переходят в «жесткие» дефекты уже в коде, когда выясняется, что варианты поведения могут быть трактованы иначе. И чем позже обнаруживается расхождение интерпретаций, тем больше объем переделок.

ИИ позволяет перенести обнаружение большинства таких дефектов из поздней стадии (когда уже написан код) в раннюю (когда это всего лишь текст). Это дает бизнес-эффект не магией, а обычной экономикой: дешевле уточнить абзац, чем переписать модуль, перерисовать макеты и заново прогнать регрессию.

ИИ как «холодный рецензент»: отсутствие замыленного глаза и предвзятости

Автор требований неизбежно находится внутри контекста. Он знает, «как должно быть», и мозг автоматически достраивает недосказанное. Эта достройка полезна в общении, но вредна в документе: читатель документа не обязан знать то, что знает автор. Команда разработки читает требования буквально. Тестировщик строит проверки из того, что написано. Поддержка ориентируется на описанные правила. Продуктовая команда сравнивает ожидания со сформулированными критериями.

«Холодный рецензент» — это роль, в которой ИИ работает особенно эффективно. Он не был на ваших встречах, не слышал «ну вы поняли», не держит в голове историю конфликтов между отделами. Он смотрит на текст как на спецификацию: что определено, что не определено, что противоречит само себе, что не имеет условий применимости, где нет критериев приемки, где отсутствует ответственность и границы.

Важно, что ИИ не подвержен типичным командным перекосам: «давайте быстрее», «и так понятно», «потом уточним». Он возвращает процесс к дисциплине формулировок. При правильной настройке (контекст проекта, глоссарий, ограничения стека, цели и роли) он стабильно поднимает вопросы, которые человеку в моменте «не хочется» поднимать, потому что это тормозит. Но именно эти вопросы и экономят время на дистанции.

Проблема «информационной плотности»: когда объем документа превышает возможности удержания внимания

У требований есть неприятное свойство: они растут. Любая новая фича добавляет роли, статусы, исключения, интеграции, согласования, требования к логированию, аналитике, безопасности. В итоге документ становится настолько плотным, что его уже невозможно прочитать целиком с одинаковой внимательностью. Человек начинает читать выборочно, сканировать, опираться на предположения, «проскальзывать» через длинные блоки текста. Это нормальная защитная реакция мозга на перегруз.

ИИ снимает часть этой проблемы, потому что он способен обрабатывать документ целиком и находить слабые места даже в «незаметных» местах: в примечаниях, в условиях мелким шрифтом, в пересечениях разделов. Кроме того, ИИ легко строит перекрестные проверки: сопоставляет определения из глоссария с употреблением терминов, сопоставляет описанные роли с их правами доступа, сопоставляет нефункциональные требования с функциональными сценариями.

Для команды это означает смену режима работы: вместо «прочитать все и ничего не упустить» появляется режим «получить отчет о рисках, пройтись по ним, закрыть критические разрывы». То есть внимание тратится не на поиск иголок в стоге сена, а на принятие решений по найденным дефектам.

Автоматизация против рутины: освобождение системного аналитика для проектирования смыслов

Качественные требования требуют времени. Но значительная часть этого времени уходит на рутину: вычитка формулировок, поиск неопределенных слов, проверка, что везде есть роли и статусы, что одинаковые термины используются одинаково, что критерии приемки измеримы, что исключения перечислены, что не забыта обработка ошибок. Это механическая работа, которую люди делают плохо не потому, что не умеют, а потому, что это монотонно и утомительно.

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

В результате повышается не только качество текста, но и качество продукта. Аналитик начинает выступать как проектировщик системы, а не как человек, который «успевает оформить документ». И это ключевой сдвиг: реальная ценность аналитика — в логике, ясности и ответственности, а не в количестве написанных страниц.

ИИ-детектор неопределенности: как нейросеть считывает «туман» в формулировках

Неопределенность в требованиях имеет узнаваемые формы. Это прилагательные без метрик («быстро», «удобно», «понятно»), наречия без критериев («оперативно», «корректно»), модальные конструкции («должна иметь возможность», «желательно», «по возможности»), неуказанные субъекты («система отправляет», но кто инициирует), отсутствие условий («если… то…» без полного набора вариантов), отсутствие границ («все пользователи», «всегда», «никогда» без уточнений).

ИИ способен системно подсвечивать такие места и предлагать уточняющие вопросы. Практический смысл не в том, чтобы переписать текст «красивее», а в том, чтобы сделать проверяемым и однозначным. Неопределенность нужно превращать в критерии: время отклика в миллисекундах или секундах, нагрузка в запросах, допустимые форматы, лимиты, статусы, исключения, роли и права.

Полезный прием — воспринимать отчет ИИ как список мест, где документ допускает разные трактовки. Любая двойная трактовка — потенциальный конфликт на реализации. И если конфликт не решен в тексте, он будет решен на практике, обычно в спешке и с потерями.

Переход от «написания» к «валидации»: новая роль автора требований

В современной разработке ценность не в том, чтобы «написать документ», а в том, чтобы гарантировать его пригодность для реализации. Это другая логика работы. Автор требований становится владельцем качества: он отвечает за ясность, полноту, непротиворечивость, трассируемость к целям и проверяемость.

ИИ помогает сместить фокус именно в эту сторону. Требования начинают жить как объект контроля: есть вход (потребность, цель, ограничения), есть процесс (формулировка, согласование, аудит), есть выход (Ready for Dev). У выхода должны быть свойства качества, и эти свойства должны быть измеримы хотя бы в виде чек-листа и метрик: сколько неопределенных формулировок, сколько конфликтов, сколько неописанных исключений, сколько терминов не из глоссария.

Когда валидировать становится проще, снижается соблазн «быстро набросать и потом уточнить». Уточнение всегда дороже, когда уже началась реализация. Поэтому зрелый процесс строится вокруг ранней валидации, а ИИ делает эту валидацию регулярной и дешевой.

Скорость обратной связи: аудит за минуты вместо многочасовых встреч

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

ИИ сокращает цикл обратной связи. Он позволяет получить первичный аудит до встречи: список проблем, вопросы, рекомендации по уточнениям. Встреча становится короче и конкретнее: обсуждаются не «все подряд», а точки риска. Это повышает качество согласования и снижает эмоциональное напряжение между отделами, потому что спор идет вокруг конкретных формулировок и недостающих данных, а не вокруг «ты меня не понял».

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

Прозрачность качества: введение объективных метрик для оценки текста ТЗ

Качество требований часто воспринимается субъективно: «мне понятно», «вроде нормально», «так всегда писали». Это плохая база для управления. Нужны признаки, по которым можно сравнивать документы и отслеживать прогресс.

ИИ позволяет ввести простые метрики, которые реально использовать в работе: количество неопределенных формулировок на страницу; количество терминов, отсутствующих в глоссарии; количество требований без критериев приемки; количество сценариев без обработки ошибок; количество конфликтов между разделами; доля требований без указания ролей и прав; доля требований без указания данных (источник, формат, хранение, удаление); количество «висячих» зависимостей (упомянуто, но не описано).

Метрики не нужны ради отчета. Они нужны, чтобы команда видела улучшения и понимала, где именно проседает качество. Особенно полезно использовать их как ворота готовности: документ не может считаться готовым, если превышены пороги по критическим дефектам, например по неопределенности и отсутствию критериев приемки.

Культура «Ready for Dev»: как ИИ гарантирует, что задача понятна разработчику

Состояние Ready for Dev — это не «аналитик закончил писать». Это состояние, когда разработчик может реализовать функциональность без постоянных уточняющих вопросов, а тестировщик может построить проверку результата. В этом состоянии у требования есть: четко описанные сценарии; роли и права; состояния и переходы; данные и их жизненный цикл; интеграции и контракты; обработка ошибок; нефункциональные параметры там, где они критичны; критерии приемки, которые можно проверить.

ИИ выступает как фильтр перед тем, как задача попадет в разработку. Он подсвечивает, где задача еще не готова. Это дисциплинирует процесс не через давление, а через прозрачность. Команда перестает надеяться на «в процессе разберемся» и начинает строить привычку «сначала доведем до ясности».

При этом важно: ИИ не должен быть «карателем». Он должен быть помощником. Его отчеты должны быть встроены в работу как нормальный этап: черновик — аудит — правки — повторный аудит — готовность. Тогда качество начинает расти естественно, без героизма и конфликтов.

Артефакт. Карта «10 уровней зрелости требований: взгляд ИИ»

Ниже — практическая шкала, по которой удобно оценивать зрелость требований. Она помогает не спорить о «хорошо/плохо», а понимать текущий уровень и следующий шаг.

Уровень 1. Намерение. Есть идея или просьба, но нет описания поведения системы, ролей и границ. Уровень 2. Сценарий в общих чертах. Описано, что должно произойти, но без условий, исключений и критериев приемки. Уровень 3. Термины и объекты. Определены ключевые сущности (объекты данных) и термины, но их использование в тексте еще не единообразно. Уровень 4. Роли и права. Указано, кто что может делать, но не покрыты пограничные случаи и не проверена безопасность доступа. Уровень 5. Состояния и переходы. Описан жизненный цикл объекта и ключевые переходы, но не все переходы проверены на непротиворечивость. Уровень 6. Данные и интеграции. Указаны источники данных, форматы, точки передачи, но не описаны ограничения, ошибки и ретраи. Уровень 7. Обработка ошибок и исключения. Есть негативные сценарии, сообщения, правила восстановления, но еще не все критичные места покрыты. Уровень 8. Проверяемость. Критерии приемки измеримы, однозначны, покрывают основные и негативные сценарии. Уровень 9. Трассируемость к целям. Понятно, какую бизнес-цель закрывает каждое требование, нет лишних требований, изменения оцениваются по влиянию. Уровень 10. Готовность к масштабированию. Документ стандартизирован, метрики качества соблюдены, аудит повторяем, изменения контролируются, команда доверяет процессу.

Итоги

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

Глава 2. Как сделать ИИ полезным аудитором: контекст, правила и «язык требований»

Если в первой главе мы честно признали неприятный факт, что человек больше не лучший аудитор требований по причинам, не связанным с компетентностью, то во второй главе нужно признать другой факт: ИИ тоже не станет полезным аудитором сам по себе. Он становится полезным ровно в той мере, в какой вы даете ему рамки. Без рамок он будет делать то, что умеет лучше всего: говорить общими словами, предлагать «хорошие практики» без привязки к вашей системе и, самое опасное, пытаться заполнить пробелы догадками. Аудит требований не терпит догадок. В требованиях либо сказано, либо не сказано. Либо определено, либо не определено. Либо измеримо, либо нет.

Поэтому главный сдвиг мышления на этом этапе такой: вы не «просите нейросеть проверить ТЗ», вы строите среду, в которой нейросеть вынуждена проверять ТЗ по вашим правилам. Это похоже на то, как устроена проверка качества в промышленности. Не достаточно иметь хорошего инспектора. Нужны стандарты, критерии, калибровка, классификация дефектов и процедура, которая делает результат повторяемым.

Дальше будет много практики. Мы разберем, какой контекст ИИ необходим, чтобы не превращаться в генератор общих фраз. Какие правила и ограничения нужно зафиксировать. Как устроить «язык требований» внутри команды, чтобы аудит был точным. И главное — как сделать так, чтобы ИИ не заменял мышление, а усиливал дисциплину.

Почему ИИ «ломается» на требованиях без контекста

Когда люди говорят: «ИИ плохо проверяет требования», они обычно имеют в виду одну из трех ситуаций.

Первая: требования написаны так, как привыкли писать люди в переписках. Там много «понятно по контексту», много намеков, много недосказанного. ИИ пытается догадаться, что имели в виду, и делает вид, что понимает. В результате он либо пропускает дефекты, либо предлагает исправления, которые не соответствуют реальной системе.

Вторая: требования противоречат друг другу, но противоречие скрыто в разных местах документа. Человек тоже это может пропустить, но ИИ без явной задачи «проверить согласованность по всему документу» часто будет реагировать локально, а не системно. Он видит один абзац, делает выводы по нему, не сверяя с другим разделом.

Третья: вы просите ИИ «оценить качество», но не описываете, что именно является качеством. Для одной команды качество — это лаконичность. Для другой — максимальная формализация. Для третьей — наличие user story. Для четвертой — наличие сценариев. ИИ будет пытаться угодить «вообще всем» и выдаст усредненный набор советов, который в итоге раздражает, а не помогает.

Из этого следует простой вывод: ИИ не может быть вашим аудитором, если у вас нет стандарта требований. Или если стандарт есть, но он не описан словами. В голове он не работает. Его нужно материализовать.

Минимальный «паспорт проекта» для ИИ: что ему нужно знать всегда

Чтобы ИИ проверял требования не абстрактно, а по делу, ему нужен паспорт проекта. Это короткий, но плотный блок информации, который определяет реальность: что за продукт, для кого, в каких ограничениях, как устроена система и какие правила принятия решений.

Практический минимум включает:

Цель продукта и цель конкретного изменения. Коротко: зачем это делаем, какую метрику или проблему закрываем, что считается успехом. Не «улучшить UX», а «снизить долю обращений в поддержку по X» или «увеличить конверсию шага Y» или «сократить время операции Z».
Платформа и контур. Это веб, мобильное приложение, бэкенд-сервис, админка, интеграция, витрина данных. ИИ должен понимать, где происходят действия пользователя, где происходят действия системы, и кто является клиентом функциональности.
Участники и роли. Список ролей с короткими описаниями: кто инициирует, кто подтверждает, кто администрирует, кто читает, кто имеет ограниченный доступ. Если ролей много, нужен хотя бы базовый список и ссылка на глоссарий ролей внутри документа.
Ключевые сущности данных. Что является объектом изменения: заказ, заявка, пациент, визит, платеж, карточка, документ, комментарий, статус. ИИ должен уметь сверять, что эти сущности описаны одинаково в разных местах.
Источники правды. Где хранится основной набор данных, какие системы являются первичными, какие вторичными, где возникают конфликты синхронизации. Даже если вы не раскрываете архитектуру полностью, ИИ должен знать, что «источник истины» для X — система A, а не B.
Ограничения и запреты. Здесь важны «не делаем». Например: нельзя менять схему БД на этом этапе; нельзя менять публичный API; нельзя вводить новые зависимости; нельзя ломать обратную совместимость; нельзя трогать платежный контур без отдельного согласования. ИИ должен проверять требования с учетом этих ограничений.
Формат требований. Вы заранее говорите: требования должны содержать сценарии, обработку ошибок, роли, критерии приемки, нефункциональные параметры там, где это важно. Тогда ИИ понимает, что именно искать.

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

Глоссарий как фундамент: без него у вас не требования, а литературный текст

Большинство дефектов в требованиях на практике начинаются с терминов. Команда использует слова, которые похожи, но означают разные вещи: заявка и обращение; заказ и бронь; визит и консультация; пользователь и клиент; подтверждение и согласование; отмена и возврат; блокировка и деактивация. Пока это обсуждается устно, кажется, что «вроде понятно». Но как только эти слова превращаются в код, в базу данных и в интерфейс, различия становятся реальными и болезненными.

Поэтому глоссарий — это не бюрократия. Это способ зафиксировать смысл, чтобы система не расползлась.

Хороший глоссарий для требований включает: определение термина одним предложением; атрибуты сущности, если это сущность; допустимые статусы, если это объект со статусами; отличие от похожих терминов; примеры использования в тексте требований (не про выдуманных людей, а про формулировки: «в тексте используем так-то»).

ИИ умеет проверять глоссарий очень полезным образом: он может находить места, где термин используется не по определению; где вместо одного термина используется другой; где один термин используется как два разных; где появляется новый термин без определения. Это и есть «язык требований» — когда слова означают одно и то же для всех.

Важно: глоссарий должен быть частью процесса, а не музейным экспонатом. Если вы внедряете новую сущность или новый статус, глоссарий обновляется вместе с требованиями. ИИ может выступать как «сторож глоссария»: он напоминает, что вы ввели новый термин и не определили его.

Таксономия дефектов: как превратить «непонятно» в конкретный тип проблемы

Чтобы аудит был управляемым, недостаточно сказать: «тут плохо написано». Нужно уметь классифицировать, что именно не так. Это дисциплина, которая резко повышает скорость исправлений, потому что вы не спорите о вкусе, а устраняете дефекты по типам.

Минимальная таксономия дефектов требований, которую полезно встроить в аудит ИИ:

Неопределенность. Есть слова или конструкции без измеримости и границ. Неполнота. Не описаны важные сценарии: ошибки, исключения, альтернативные пути, ограничения. Противоречие. В разных местах документа описано разное поведение для одного и того же случая. Несогласованность терминов. Термины не совпадают с глоссарием или используются по-разному. Отсутствие критериев приемки. Нет проверки результата в форме, пригодной для тестирования. Неопределенные роли и права. Не ясно, кто имеет доступ, кто может выполнять действие, кто видит данные. Непроясненные данные. Нет источника, формата, валидаций, хранения, удаления, маскирования. Неопределенные интеграции. Нет контрактов, ошибок, таймаутов, ретраев, идемпотентности. Смешение уровней. В одном месте перемешаны пользовательские сценарии, техническая реализация и организационные договоренности так, что невозможно понять, что является требованием. Нефункциональные провалы. Требование предполагает нагрузку, скорость, надежность или безопасность, но не содержит параметров и ограничений.

Если вы даете ИИ такую классификацию, он начинает работать иначе. Он не просто «комментирует текст», он строит отчет с типами дефектов, а вы можете расставлять приоритеты и закрывать дефекты целевыми правками.

Кроме того, у таксономии появляется еще одна польза: вы можете учить команду. Когда люди видят, что их правки стабильно попадают в «неопределенность» или «неполнота», они начинают писать лучше заранее. Аудит становится не наказанием, а обучающей петлей.

Правило «ИИ не заполняет пробелы»: как защититься от самой опасной ошибки

Главная опасность при работе с ИИ в требованиях — это когда он начинает заполнять пробелы «разумными предположениями». Иногда это выглядит полезно: он предлагает варианты, он «дописывает» критерии, он «придумывает» обработку ошибок. Но в аудиторе это смертельно.

Аудитор должен отличать два режима: режим выявления дефектов и вопросов; режим проектирования решений.

Если вы смешиваете режимы, вы теряете контроль над смыслом. У вас появляется текст, который «звучит правильно», но не подтвержден бизнесом, не согласован с архитектурой и не отражает реальных ограничений.

Поэтому в стандарте работы с ИИ должно быть жесткое правило: ИИ не имеет права утверждать, что система должна делать X, если в документе это не указано. Он может только задавать вопрос: «что должно происходить в случае X?» и предлагать варианты как гипотезы, помеченные как варианты. Это делает процесс безопасным.

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

Как построить «инструкцию аудитора»: единый промпт, который действительно работает

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

Инструкция аудитора обычно состоит из пяти частей.

Первая часть: роль и цель. Например: «Ты аудитор требований. Твоя цель — находить дефекты требований по таксономии и задавать уточняющие вопросы. Ты не дописываешь требования, не придумываешь логику, не выбираешь архитектуру».

Вторая часть: контекст проекта. Сюда вставляется паспорт проекта.

Третья часть: стандарт требований. Как должны выглядеть требования: какие разделы обязательны, какие элементы должны быть для каждого сценария. Здесь полезно перечислить минимальный набор: роли, условия, основной сценарий, альтернативы, ошибки, данные, интеграции, критерии приемки.

Четвертая часть: таксономия дефектов. С описанием и примерами того, что считать дефектом каждого типа.

Пятая часть: формат результата. Это важно. Если вы не задаете формат, вы получите «эссе». Вам нужен отчет: список дефектов, каждый дефект — с указанием места в тексте, типом дефекта, риском, вопросом и предложением формулировки уточнения (именно уточнения, а не окончательного решения). И отдельно — краткий итог: критические риски, блокеры, что обязательно исправить до передачи в разработку.

Формат результата — это половина успеха. Когда отчет структурирован, его можно использовать в работе. Его можно копировать в задачу, в комментарии, в чек-лист. Его можно сравнивать между версиями документа. ИИ становится не «собеседником», а инструментом контроля качества.

Сценарная дисциплина: почему аудит требований всегда должен начинаться со сценариев, а не с «описания функции»

Многие команды начинают требования с описания функции: «нужно добавить кнопку», «нужно сделать фильтр», «нужно интегрировать API». Это удобный язык для постановки задач, но плохой язык для требований, потому что он сразу загоняет вас в реализацию. Вы обсуждаете интерфейс, не определив поведение. Вы обсуждаете «как», не определив «что» и «почему».

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

Когда требования написаны сценариями, ИИ проверяет их точнее, потому что у него есть опорная структура: шаги, условия, ожидаемые результаты. Ему проще обнаружить разрывы: «а что если…», «а кто имеет право…», «а что происходит при ошибке…». В тексте без сценариев это превращается в абстракцию.

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

Критерии приемки как договор: почему «готово» должно быть проверяемым

Пока критерии приемки не измеримы, «готово» — это мнение. А мнение всегда будет разным у разных людей. Один считает готовым, когда кнопка появилась. Другой — когда сценарий работает. Третий — когда учтены ошибки. Четвертый — когда аналитика фиксируется. Пятый — когда закрыты требования безопасности.

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

Слабые критерии приемки выглядят так: «должно быть удобно», «должно работать корректно», «ошибки должны обрабатываться», «страница должна быстро загружаться», «уведомления должны приходить». Это не критерии, это пожелания.

Сильные критерии приемки отвечают на вопрос «как проверить»: какие условия; какие шаги; какой ожидаемый результат; какие данные; какие статусы; какие сообщения; какие ограничения.

ИИ может превращать слабые формулировки в список уточняющих вопросов. Например: «что считать быстрым? какая метрика? при какой нагрузке? для каких операций?». Но, повторю, он не должен сам выбирать числа. Он должен заставить вас их определить.

Роли и права: самая частая скрытая дыра в требованиях

Одна из самых дорогих категорий дефектов — это неописанные права доступа. Потому что когда вы их не описали, разработка либо делает слишком широко, либо слишком узко. Слишком широко — риск безопасности и комплаенса. Слишком узко — риск поломки бизнес-процесса и роста ручных обходов.

В зрелых требованиях любое действие связано с ролью. Любой просмотр данных связан с правом. Любое изменение статуса связано с ответственностью.

ИИ здесь полезен не тем, что он «знает безопасность», а тем, что он методично спрашивает: кто это делает? кто это видит? кто не должен видеть? что происходит при попытке без прав? как фиксируется событие? нужно ли логирование?

Если вы встроите этот блок вопросов в инструкцию аудитора, вы резко снизите вероятность того, что в релиз уйдет функциональность с дырой доступа просто потому, что «никто не подумал».

Данные и их жизненный цикл: требования заканчиваются не на экране

Частая ошибка мышления: требования описывают интерфейс и забывают про данные. Но продуктовая система — это прежде всего данные: создание, изменения, хранение, отображение, удаление, перенос между системами.

Поэтому аудит требований должен включать вопросы о данных: какие поля используются; откуда они берутся; кто их вводит; какие валидации; какие форматы; что считается пустым значением; как обрабатываются ошибки; где хранится; как долго хранится; кто имеет доступ; как удаляется или обезличивается; как происходит экспорт; как фиксируются изменения.

Если это звучит как слишком много, это потому что мы привыкли «допридумывать на реализации». Но когда вы разворачиваете требования в сторону данных, вы снижаете хаос. ИИ помогает именно тем, что системно напоминает о жизненном цикле данных, который люди часто пропускают из-за спешки.

Интеграции: то место, где даже хорошие требования ломаются

Интеграции сложны тем, что у вас всегда есть внешняя сторона: она может быть недоступна, она может отдавать ошибки, она может менять поведение, она может отвечать медленно, она может прислать невалидные данные. Внутри продукта вы можете контролировать многое. Снаружи — почти ничего.

Поэтому зрелое требование по интеграции обязано содержать не только «запрос-ответ», но и: таймауты; повторные попытки; идемпотентность; обработку дублей; поведение при частичном успехе; логирование; мониторинг; деградацию функциональности; сообщения пользователю; правила очередей, если они есть.

ИИ может проверить, что эти элементы хотя бы упомянуты и что поведение не противоречит бизнес-логике. Он не выберет правильный таймаут, но он спросит: «какой таймаут? что делаем при превышении?». И это уже огромная помощь, потому что большинство проблем интеграций — это не «плохой код», а «неоговоренное поведение».

Два контура: аудит до разработки и аудит после правок

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

Поэтому аудит должен быть циклом: черновик требований; аудит; правки; повторный аудит; фиксация готовности.

В повторном аудите ИИ особенно полезен как «детектор разъехавшихся частей». Он сравнивает документ со стандартом и находит, что после правок появились новые пробелы.

Если вы хотите, чтобы аудит реально экономил время, вам нужно привыкнуть к этой петле. Это не «лишняя работа». Это способ закончить документ в состоянии, когда он не развалится при реализации.

Где заканчивается аудит и начинается проектирование

В зрелом процессе вы разделяете две активности.

Аудит: выявить дефекты, задать вопросы, определить, что не определено. Проектирование: выбрать вариант, согласовать с бизнесом и архитектурой, зафиксировать решение.

ИИ может помогать и там, и там, но режимы должны быть разными. В аудиторе вы запрещаете ему «решать». В проектировщике вы можете просить варианты и компромиссы, но тогда вы осознанно включаете режим генерации.

Почему это важно: если вы смешали режимы, вы рискуете сделать документ, который формально выглядит полным, но на самом деле содержит решения, которые никто не принимал. Это создает иллюзию готовности. А иллюзия готовности опаснее, чем честная неполнота.

Как встроить аудит в командную привычку, чтобы это не стало «проверкой ради проверки»

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

Есть несколько практических принципов.

Первый: аудит начинается с автора и помогает автору. То есть отчет ИИ сначала идет аналитику или владельцу требования, чтобы он сам внес правки. А уже потом документ идет на командное обсуждение.

Второй: отчет используется как повестка встречи. Не «почитаем документ», а «разберем 12 вопросов по критическим дефектам».

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

Четвертый: фиксируются улучшения. Если через месяц число дефектов «неопределенность» падает, это успех. Его видно. Команда учится.

Пятый: глоссарий и стандарт — живые. ИИ помогает поддерживать их в актуальном состоянии, но ответственность остается у команды.

Именно так ИИ превращается из игрушки в часть процесса.

Итоги

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

Глава 3. Машина проверок: чек-листы, правила и автоматический отчёт по качеству требований

Когда команда впервые пробует аудит требований через ИИ, обычно происходит одно и то же. Первый отчёт выглядит впечатляюще: много замечаний, много вопросов, кажется, что «вот оно, наконец-то». Но уже на второй-третий раз начинается разочарование. Замечания повторяются. Тон отчёта меняется. Вопросы то слишком общие, то слишком придирчивые. И становится понятно, что без системы это не инструмент, а лотерея.

На этом этапе и начинается взрослая работа: построить «машину проверок». Не разовый запрос нейросети, а набор стабильных правил, чек-листов и форматов отчёта, которые можно применять к любому документу требований. Машина проверок нужна не ради красоты и не ради контроля. Она нужна, чтобы у качества требований появилась воспроизводимость. Чтобы разные аналитики писали по одному стандарту. Чтобы разработка доверяла документу. Чтобы тестирование не превращалось в гадание. И чтобы у руководителя продукта было понимание, что задача действительно готова.

В этой главе мы разберём, как устроить проверку требований как технологический процесс. Какие типы проверок должны быть. Как сделать отчёт «коротким для руководителя» и «детальным для автора». Как бороться с повторяющимися замечаниями. И как превратить аудит из «субъективных комментариев» в понятный контроль качества.

Почему чек-лист важнее «умного текста»

Умный текст — это хорошо. Но любой умный текст превращается в мусор, если его нельзя применить одинаково два раза подряд. Чек-лист хорош тем, что он не спорит с настроением. Он не зависит от того, кто читает документ. Он состоит из вопросов «да/нет/не применимо» и из правил, которые можно проверять.

В требованиях это критично, потому что качество здесь — это не эстетика и не литературность. Это пригодность к реализации. Если в требовании не указаны роли — это дефект. Если нет критериев приёмки — дефект. Если не описана обработка ошибок — дефект. Это не «вкусовщина». Это функциональная неполнота.

ИИ нужен не для того, чтобы «красиво переписать». Он нужен, чтобы прогонять требования через чек-листы быстро и системно, а затем выдавать отчёт в одном и том же формате. Чем жёстче ваш стандарт, тем меньше хаоса.

Два уровня проверок: базовые ворота и глубокий аудит

Ошибочно пытаться проверять всё одинаково глубоко. В реальной работе у вас будут десятки задач в спринте, и невозможно для каждой делать аудит на уровне «идеальной спецификации». Нужна стратификация.

Уровень 1 — базовые ворота качества (Gate). Это минимальный набор проверок, без которых задача не может уйти в разработку. Он должен быть коротким, но жёстким. Обычно это 10–20 пунктов.

Уровень 2 — глубокий аудит (Deep). Это расширенный набор проверок для задач с риском: интеграции, платежи, персональные данные, критические процессы, сложные сценарии, большие изменения. Здесь чек-лист может быть 40–80 пунктов, и это нормально, потому что цена ошибки выше.

ИИ позволяет сделать оба уровня удобными. Для Gate — быстрый отчёт, который показывает блокеры. Для Deep — детальный отчёт с классификацией дефектов, рисками и списком уточняющих вопросов.

Если вы этого не разделите, вы получите либо бюрократию на всё подряд, либо поверхностность на критичных задачах.

Конструкция «правило → симптом → вопрос → исправление»

Чтобы отчёт ИИ был полезным, каждое замечание должно быть оформлено не как «мне кажется», а как стандартная конструкция. Тогда автор требований не спорит с тоном, а исправляет.

Правило — что должно быть по стандарту. Симптом — что именно отсутствует или противоречит в тексте. Вопрос — что нужно уточнить, чтобы закрыть пробел. Исправление — как именно дописать/переформулировать, но в форме шаблона или примера формулировки, а не в виде выдуманного решения.

Важно: исправление здесь — это не «придумать бизнес-правило». Это показать структуру формулировки. Например: «Добавьте критерий приёмки в формате: условия → шаги → ожидаемый результат». Или: «Укажите статус до и после действия, а также условия перехода».

Такая структура резко повышает практическую ценность отчёта. Автор не тонет в философии и не тратит время на интерпретации. Он видит конкретный шаг.

Базовый Gate-чек-лист: 16 проверок, которые закрывают 80% проблем

Ниже — компактный, но жёсткий набор. Его можно применять к большинству продуктовых задач и требовать прохождения перед стартом разработки.

Цель изменения сформулирована. Что улучшаем и как поймём успех.
Область изменения ясна. Какие экраны/сервисы/процессы затронуты.
Роли перечислены. Кто выполняет действия и кто видит результат.
Основной сценарий описан шагами. Триггер → действия → результат.
Альтернативные сценарии перечислены. Что происходит при иных условиях.
Негативные сценарии описаны. Ошибка, отказ, недоступность, неверные данные.
Правила доступа указаны. Кто не должен иметь доступ и что при попытке.
Статусы и переходы описаны (если применимо). До → после → условия.
Данные определены. Какие поля, откуда, формат, валидации.
Интеграции перечислены (если есть). Какие внешние системы и контуры.
Поведение при сбое интеграции описано (если есть интеграция).
Критерии приёмки есть для ключевых сценариев. Проверяемые, однозначные.
Логирование/аудит действий упомянуты (если требуется регуляторика/безопасность).
Аналитика событий упомянута (если изменение влияет на воронку или метрики).
Ограничения и допущения зафиксированы. Что «не делаем» в рамках задачи.
Термины соответствуют глоссарию. Нет новых терминов без определения.

Этот Gate-чек-лист не делает требования идеальными. Он делает их пригодными для старта разработки без постоянных уточнений.

Глубокий Deep-чек-лист: что добавляется для сложных и рискованных задач

Deep-аудит расширяет Gate и добавляет проверки, которые часто всплывают слишком поздно.

Нефункциональные требования. Время отклика, нагрузка, ограничения по данным, SLA, устойчивость, деградация, кэширование, ограничения на частоту операций.

Безопасность и персональные данные. Маскирование, хранение, сроки, удаление, обезличивание, права на экспорт, ограничения доступа в логах, требования комплаенса.

Идемпотентность и повторы. Что происходит, если пользователь повторит действие; что происходит, если запрос придёт дважды; как система отличает дубль.

Конкурентные изменения. Что если два пользователя меняют один и тот же объект; конфликт статусов; блокировки; правила разрешения конфликтов.

Согласованность данных. Где источник истины; что является производным; как происходит синхронизация; как обрабатываются расхождения.

Миграции и обратная совместимость. Если меняются форматы; если меняются статусы; как живут старые данные; как работает функциональность на старых версиях клиента.

Мониторинг. Какие метрики и алерты нужны; какие ошибки должны попадать в мониторинг; какие показатели считаются нормой.

UX-детали, которые критичны для поведения. Тексты ошибок; подтверждения; предупреждения; пустые состояния; ограничения по вводу.

Управление доступом и аудит действий. Кто может делать массовые операции; кто может отменять; какие операции требуют подтверждения; журнал событий.

Deep-аудит не должен применяться ко всем задачам. Его нужно применять по признакам риска. Это тоже часть машины проверок: классификатор риска.

Классификатор риска: когда нужен Deep, а когда достаточно Gate

Чтобы команда не спорила каждый раз, нужен простой классификатор. Например, Deep обязателен, если выполняется хотя бы одно условие:

изменение затрагивает платежи/финансы; затрагивает персональные данные или медицинские данные; затрагивает авторизацию/права доступа; включает новую интеграцию или меняет контракт существующей; меняет критические статусы (заказ, заявка, запись); затрагивает массовые операции; затрагивает юридически значимые документы; имеет потенциальный ущерб от ошибки выше заданного порога (по деньгам/репутации).

Если условий нет, достаточно Gate. Если есть — Deep.

Так машина проверок становится управляемой и не превращается в бюрократию.

Отчёт по качеству: два слоя, чтобы всем было удобно

Большая проблема отчётов ИИ в том, что они либо слишком длинные, либо слишком короткие. Чтобы отчёт реально жил в команде, он должен иметь два слоя.

Слой 1 — Summary для руководителя/продакта. 5–10 пунктов: блокеры, критические риски, сколько дефектов по типам, готовность (Ready/Not Ready), что обязательно исправить до разработки.

Слой 2 — Detail для автора требований. Полный список дефектов, сгруппированный по таксономии, с указанием места в тексте, вопросами и шаблонами формулировок.

Это не «красивое оформление». Это способ внедрить инструмент. Руководителю нужен сигнал. Автору нужен список действий. Разработчику нужен список неопределённостей. Тестировщику нужны критерии приёмки и сценарии.

Если отчёт один и он «для всех», в итоге он не для никого.

Как бороться с повторяющимися замечаниями: библиотека правил и авто-обучение процесса

Когда ИИ повторяет одни и те же замечания, это не проблема ИИ. Это сигнал о системной слабости процесса. Значит, команда не встраивает исправления в стандарт.

Практическое решение — «библиотека правил» и шаблонов. Если у вас постоянно не хватает критериев приёмки, вы создаёте стандартный блок «как писать критерии приёмки» и добавляете его в шаблон требований. Если постоянно забывают роли, вы добавляете обязательный раздел «Роли и права». Если постоянно забывают негативные сценарии, вы добавляете раздел «Ошибки и исключения».

ИИ в этом контуре становится инструментом выявления повторяемых дефектов. Вы раз в месяц смотрите статистику: какие типы дефектов встречаются чаще всего, и улучшаете шаблон и стандарт. Через 2–3 итерации качество растёт само, потому что «правильная форма» встроена в документ.

Важно: это не абстрактный совет. Это реально работающий механизм: каждая повторяемая ошибка превращается в правило и обязательный блок шаблона. ИИ перестаёт «ругаться» на одно и то же, потому что команда перестаёт это допускать.

Трассируемость: как связать требования с целями и тестами

Один из признаков зрелой системы требований — трассируемость. Это когда можно ответить на вопросы: зачем это требование; какую цель закрывает; как проверить, что оно выполнено.

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

ИИ может проверять трассируемость как дефект: «есть требование без цели» или «есть цель, но нет требований, которые её закрывают» или «есть сценарий без критериев приёмки». Это очень полезно для больших проектов, где требования расползаются и начинают жить собственной жизнью, теряя смысл.

Даже если вы не вводите сложные системы управления требованиями, вы можете ввести минимальные идентификаторы: например, C-01 для целей и A-01 для критериев приёмки. ИИ легко подхватит такую структуру и будет проверять, что ничего не потерялось.

Техническая реализация машины проверок без кода: как настроить процесс в реальной команде

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

Единый шаблон требований. Документ с обязательными разделами: цель, контекст, роли, сценарии, данные, интеграции, ошибки, критерии приёмки, ограничения.
Единый «паспорт проекта». Короткий файл или блок текста, который вставляется в начало промпта аудитора.
Единый промпт аудитора Gate. Короткий, направленный на блокеры.
Единый промпт аудитора Deep. Длиннее, с таксономией дефектов и форматом отчёта.
Регламент: когда Gate, когда Deep. Классификатор риска в явном виде.
Процедура: черновик → аудит → правки → повторный аудит → Ready. И это фиксируется в чек-листе задачи в вашей системе управления (какая бы она ни была).
Хранилище отчётов. Просто чтобы видеть прогресс и повторяемые дефекты. Это может быть папка, таблица, комментарии к задачам.

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

Итоги

Машина проверок требований строится не из «умных ответов», а из стандартов: двух уровней проверок (Gate и Deep), чек-листов, таксономии дефектов и фиксированного формата отчёта. Отчёт должен иметь два слоя: краткий summary для руководителя и детальный список дефектов для автора требований. Каждое замечание оформляется как правило → симптом → вопрос → шаблон исправления, чтобы устранение было быстрым. Deep-аудит включается по классификатору риска, иначе процесс превращается в бюрократию. Повторяемые замечания лечатся не спором с ИИ, а улучшением шаблона требований и библиотеки правил. Когда это внедрено, качество требований становится воспроизводимым, задача реально становится Ready for Dev, а стоимость ошибок снижается за счёт раннего выявления дефектов.

Глава 4. Никаких «угадываний»: как запретить ИИ галлюцинировать и не потерять пользу

В требованиях есть жестокий парадокс. Чем больше в документе пробелов, тем сильнее у команды желание, чтобы ИИ «помог дописать». И чем сильнее ИИ «помогает дописать», тем выше риск, что в документе появятся решения, которые никто не принимал. Получается красивый, гладкий текст, который создаёт ощущение завершённости, но на деле вшивает в систему случайные предположения. Это самый опасный вид ошибки, потому что он не выглядит как ошибка. Он выглядит как «аккуратно оформленная спецификация».

Поэтому одна из ключевых задач при внедрении ИИ-аудита — научиться запрещать нейросети угадывать, но при этом не убить её полезность. Эта глава о том, как сделать так, чтобы ИИ оставался строгим аудитором: выявлял дефекты, формулировал вопросы, предлагал варианты как гипотезы, но никогда не подменял собой принятие решений.

Что такое галлюцинация в контексте требований и почему она встречается чаще, чем кажется

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

Типовые формы галлюцинаций в требованиях:

Добавление новой бизнес-правила. Например, появляется лимит, штраф, условие, порядок действий, которого никто не обсуждал. Подмена источника данных. ИИ «решает», что данные берутся из конкретной системы, потому что так обычно бывает. Выбор технического решения. ИИ начинает описывать кэширование, очередь, базу данных, формат хранения, не имея архитектурного контекста. Неверное расширение ролей. Он предполагает, что роль X имеет права Y, потому что «логично», но это может противоречить комплаенсу. Смена терминов. ИИ заменяет слова на синонимы, ломая глоссарий. Добавление «красивых» критериев приёмки с числами. Он подставляет метрики «на глаз», и это превращается в ложный договор.

Эти вещи редко вскрываются сразу. Они вылезают уже на реализации: «почему мы вообще так сделали?» или «а кто сказал, что так должно быть?» В итоге — переделки, конфликты и потеря доверия к документу.

Почему ИИ вообще угадывает: механика «закрытия гештальта»

ИИ устроен так, что он пытается завершить мысль. Когда он видит текст, который «как будто не закончен», он естественным образом стремится сделать его законченным: добавить условия, добавить обработку ошибок, добавить правила. Для литературного текста это благо. Для требований — риск.

Если вы не ставите ограничение «не дополняй», ИИ будет дополнять. Не потому что «обманывает», а потому что такова его нормальная стратегия: строить связный, правдоподобный ответ.

Значит, запрет угадывания — это не просьба «пожалуйста, не фантазируй». Это инженерное ограничение, которое вы встраиваете в промпт, в формат отчёта и в процесс работы.

Золотое правило аудита: ИИ утверждает только то, что прямо есть в тексте

В режиме аудитора ИИ должен жить по принципу юридической экспертизы: он не интерпретирует «как правильно», он фиксирует «что написано» и «чего не хватает».

Практическая формула: если поведение описано в документе — ИИ может проверить его на непротиворечивость и ясность; если поведение не описано — ИИ задаёт вопрос и предлагает варианты только как варианты, без утверждения, что так и будет.

Это правило лучше всего работает, если вы заставляете ИИ отвечать в структуре, где физически невозможно «дописать требования». Например: «Дефект → место → почему дефект → вопрос → варианты уточнения». В такой структуре «варианты» автоматически воспринимаются как гипотезы, а не как решение.

Три режима работы с ИИ и почему их нельзя смешивать

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

Режим 1. Аудит (Audit). Цель: найти дефекты и пробелы. Запрет: нельзя предлагать окончательные решения, нельзя вводить новые факты. Выход: список дефектов и вопросов.

Режим 2. Проектирование вариантов (Design Options). Цель: предложить несколько вариантов решения, описать компромиссы, риски, влияние на метрики, сложность внедрения. Ограничение: варианты должны быть явно помечены как варианты и требовать выбора команды. Выход: набор вариантов и критерии выбора.

Режим 3. Редактура текста (Rewrite). Цель: переписать уже принятые решения в ясной форме, по стандарту требований, без изменения смысла. Ограничение: запрещено добавлять новую логику, можно только переформулировать и структурировать. Выход: улучшенный текст требования.

Когда команды жалуются, что ИИ «фантазирует», почти всегда они смешали режимы: попросили аудит и редактуру одновременно или аудит и проектирование одновременно. В результате ИИ пытается быть полезным везде и начинает дополнять.

Правило внедрения простое: на каждую задачу вы чётко выбираете режим. И фиксируете это в промпте.

Как писать антигаллюцинационные ограничения в промпте так, чтобы они работали

Слова «не фантазируй» работают плохо. Ограничение должно быть операционным, то есть описывать, что делать вместо фантазии.

Рабочие ограничения выглядят так:

«Если информация отсутствует в тексте, пометь её как Missing и задай уточняющий вопрос».
«Не добавляй числовые значения, сроки, лимиты, SLA, если их нет в документе. Вместо этого сформулируй вопрос: какие значения принять?»
«Не вводи новые сущности и термины. Если встречается термин, отсутствующий в глоссарии, пометь как Glossary gap».
«Не менять термины на синонимы. Используй только термины из глоссария».
«Не выбирать архитектурные решения. Если требование предполагает выбор, задай вопрос или перечисли варианты без предпочтения».

И обязательно: «В конце дай список предположений, которые ты был вынужден сделать. Если предположений больше нуля — отчёт считается неполным». Это сильный механизм, потому что он заставляет ИИ не прятать догадки, а вытаскивать их наружу.

Если вы видите, что ИИ пишет «система должна…» в местах, где в документе этого нет, значит, вы не закрепили запрет в формате результата.

Метод «красных флажков»: слова и конструкции, после которых почти всегда начинается фантазия

Есть категории фраз, которые провоцируют ИИ на дописывание. Их полезно явно обозначить как красные флажки, которые нужно подсвечивать, а не заполнять.

«по возможности», «желательно», «должно быть удобно», «быстро», «надёжно», «корректно», «при необходимости», «система должна иметь возможность», «предусмотреть», «интегрировать», «обеспечить», «сделать защиту», «учесть безопасность».

В хорошем процессе ИИ не пытается «раскрыть» эти слова. Он помечает их как неопределённость и задаёт вопросы, которые превращают туман в критерии. Например: «что считать быстрым? какие операции? какая нагрузка?».

Если вы видите, что вместо вопросов ИИ выдаёт готовые числа и правила, вы поймали галлюцинацию в моменте.

Метод «проверка на источники»: требование «покажи откуда это в тексте»

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

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

Этот же приём полезен для команды: разработчик видит, что замечание не «в воздухе», а привязано к конкретному месту, которое нужно переписать. В итоге исправления становятся точечными.

Метод «двойного прохода»: сначала выявить пробелы, потом только структурировать

Ещё один практический механизм — разделить проверку на два прохода.

Проход 1 — только выявление пробелов и дефектов. Без переписывания, без предложений решений. Только список «где непонятно» и «что противоречит».

Проход 2 — структурирование текста после того, как команда дала ответы на вопросы. Здесь ИИ уже может помочь переписать требования в стандартизированной форме, но по жёсткому правилу: не добавлять новую логику, только переносить ответы команды в документ.

Если вы делаете всё в одном проходе, ИИ будет стремиться «закрыть гештальт» сразу. Два прохода убирают это желание, потому что в первом проходе ему запрещено завершать текст.

Метод «контрольный список предположений»: если предположений много — требование сырое

Сильный показатель качества входного документа — количество предположений, которые приходится делать аудитору. В идеале в режиме Audit предположений должно быть ноль. Если ИИ вынужден делать предположения, значит, документ не даёт достаточной определённости.

Поэтому полезно в конце отчёта требовать от ИИ блок: «Предположения (Assumptions):…». Если блок не пустой, это автоматический сигнал, что задача не готова.

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

Как сохранять пользу: «варианты» вместо «решения»

Запрет фантазии не означает, что ИИ становится бесполезным. Он остаётся очень полезным, если вы правильно формулируете его помощь.

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

То есть ИИ помогает структурой и полнотой вопросов, но не подменяет реальность решениями. Это и есть безопасная польза.

Как обнаружить галлюцинацию в уже написанном документе: ревизия «новых фактов»

Иногда документ уже переписан ИИ, и вы подозреваете, что он что-то добавил. Тогда нужен режим ревизии.

Принцип ревизии простой: «найди в тексте утверждения, которые выглядят как конкретные решения, и проверь, есть ли на них основания в исходных требованиях». Это можно делать даже без исходника, если хотя бы часть решений не была обсуждена.

Типовые зоны риска: цифры и лимиты; правила распределения; порядок обработки ошибок; права доступа; «по умолчанию» значения; таймауты; сроки хранения; текст уведомлений, которые могут быть юридически значимыми.

Если вы видите такие элементы, и не помните, что они были утверждены, значит, это кандидат на галлюцинацию. Его нужно либо подтвердить, либо удалить/заменить вопросом.

Итоги