В прошлой статье мы подробно разбирали, как автоматизировать создание чек-листов и ускорить рутинные проверки с помощью нейросетей. Эта практика отлично прижилась на наших проектах: инженеры получили удобный инструмент, который за считанные секунды выдает готовую базу для тестирования задачи и освобождает от необходимости писать первый черновик с нуля. Но со временем вылезла ожидаемая проблема. AI не всегда находил все требования по задаче, иногда додумывал связь между документами, а к части источников у него вообще не было доступа.
В результате следующий промпт получал неполный контекст, а сформированный чек-лист тоже оказывался неполным. И это неприятный случай, потому что внешне чек-лист выглядит аккуратно и уверенно, но какого-то бизнес-правила там просто нет.
При этом цель осталась прежней – сократить время QA на анализ требований. Раньше приходилось руками собирать всё по ссылкам, искать недостающую информацию, проверять версии файлов, находить таблицы с калькуляциями, файлы с эмуляторами и иногда просто выяснять, какой документ сейчас считается актуальным. Поэтому мы пошли на уровень раньше и начали отдельно собирать корпус требований в Codex (но это уже следующая статья). А в данном материале покажу общий подход и несколько правил из промптов, возможно кому-то они пригодятся.
Что именно можно поручить AI
Полезная роль на этом этапе – не придумать недостающее поведение, а выполнить повторяемые операции с требованиями: собрать связанные источники, отделить релевантные документы от общей документации, проверить актуальность ранее собранных материалов, извлечь явно сформулированные требования, сохранить ссылки и точные цитаты, сопоставить правила из разных источников, показать противоречия и отсутствующий контекст, а также зафиксировать недоступные или запрещённые документы.
Если не указан срок возврата средств, агент не подставляет типичные три или пять рабочих дней. Если Jira и кредитная политика задают разные ограничения, агент не выбирает «правильный» вариант, он делает расхождение видимым.
Как AI-агент формирует корпус требований: источники, scope, актуальность и доказательная база
От Jira-задачи к корпусу требований
Результатом работы агента может быть единый артефакт – корпус требований. Это не новая спецификация и не пересказ задачи, а структурированное представление требований, подтверждённых найденными источниками.
Jira-задача → Связанные страницы и разрешённые вложения → Определение границ задачи → Проверка актуальности источников → Извлечение требований → Трассируемый корпус требований
Боль в выборе версии GPT для корпуса требований
Отдельная боль AI-ментора была в выборе версии GPT: 5.4, 5.4 mini, 5.5 и другие. Каждая версия по-разному собирала корпус требований, и довольно быстро стало понятно, что последняя версия не обязательно будет лучшей. Проверено на практике.
Плюс задачи тоже очень разные по сложности и домену. Где-то изменение только на UI, где-то только на бэкенде, где-то затрагиваются калькуляции и база данных, а иногда ещё кредитная политика, интеграции и несколько связанных процессов. Поэтому каждую версию GPT приходилось сравнивать сразу на разных задачах. Иначе модель могла отлично показать себя на простой задаче, но потерять половину условий в сложных.
Начинать с уже сохранённого состояния
Повторный анализ не всегда должен начинаться с полного обхода Jira и Confluence. Если задача уже обрабатывалась, полезно проверить, существует ли ранее созданный корпус, какие документы изменились и требуется ли повторное извлечение.
For any task tied to a concrete Jira issue:
Load the previously persisted requirements state.
Check cache actuality and stale sources.
Reuse unchanged documents.
Refresh only sources that are no longer current.
Rebuild the corpus when its evidence has changed.
Для финтех-продуктов актуальность особенно важна. Изменение коэффициента, лимита, правила округления или категории риска может сделать старый корпус формально полным, но фактически неверным.
Ограничить область исследования
Конечно, не малое значение в промпты было уделено безопасности спецификаций проекта. Одна из главных проблем автоматического сбора требований – бесконтрольное следование по ссылкам. Чтобы не получить контекст из архивных, нерелевантных или конфиденциальных документов, источники классифицируются по scope.
К PRIMARY относятся сама Jira-задача и acceptance criteria, ссылки из описания, явно указанные документы, вложения задачи и конкретная версия расчётной модели, которая указана в требованиях.
К SECONDARY относятся документы, без которых невозможно правильно понять основное требование: кредитная политика, правила расчёта комиссий, методика округления, таблица состояний, матрица прав, API-контракт, правила обработки ошибок и маппинг данных.
В OUT OF SCOPE попадают архивные версии, политики другого продукта или юридического лица, расчётные модели не по этой задаче, документы за границами разрешённого доступа и файлы с необезличенными клиентскими данными, если они не предназначены для обработки агентом.
Every discovered artifact must be classified as:
PRIMARY
SECONDARY
OUT_OF_SCOPE
Collect all requirement-bearing PRIMARY artifacts.
Traverse into SECONDARY artifacts only when required to interpret a PRIMARY requirement.
Do not crawl the entire documentation space.
Do not use restricted or unrelated financial documents.
Может ли агент смотреть в кредитную политику
Сам факт существования кредитной политики не означает, что агент должен автоматически её читать. Доступ определяется правилами процесса. Документ должен быть связан с текущей Jira-задачей, необходим для интерпретации требования, использоваться в актуальной и разрешённой версии, входить в допустимый scope, а у технического процесса должны быть права на его получение.
Если Jira указывает, что минимальная сумма кредита определяется разделом 4.2 кредитной политики, без этого раздела требование невозможно интерпретировать. Но агенту не нужно читать всю политику целиком, если задача касается одного лимита.
source: credit-policy-v7
status: not_retrieved
reason: restricted_access
impact: |
Credit eligibility rules cannot be fully verified
against the available evidence.
Как агент работает с финансовыми калькуляциями
Расчётные правила часто находятся не в текстовой спецификации, а в таблицах или формулах: проценты, полная стоимость кредита, комиссии, график платежей, досрочное погашение, лимиты, коэффициенты риска и правила округления.
Агент может использовать калькуляцию как источник требований, если файл явно относится к задаче, версия определена, формулы доступны для чтения и документ не содержит запрещённых данных.
type: data_rule
text: |
Ежемесячный платёж округляется до двух знаков
после запятой по математическим правилам.
source:
key: attachment:loan-calculation-v3.xlsx
location: "Sheet: Calculation Rules > Row 18"
quote: |
Monthly payment: ROUND(result, 2)
При этом агент не должен объявлять формулу корректной с точки зрения законодательства. Он может зафиксировать формулу, извлечь параметры, сопоставить её с текстовыми требованиями и показать расхождение между версиями.
Какие данные агенту нельзя использовать
Агент не должен обрабатывать реальные клиентские анкеты, паспортные данные, номера счетов и карт, кредитные истории конкретных клиентов, выгрузки с персональными данными, секретные ключи и production-токены, внутренние модели без разрешения и данные, полученные не через предусмотренные инструменты.
Ниже пример правила промпта:
Use only authorized requirement-bearing sources.
Do not retrieve or process customer personal data,
production credentials, account identifiers,
or unrelated confidential artifacts.
If a required source is restricted,
record it as unresolved and do not bypass access controls.
Как агент находит проблемы в финтех-требованиях
Разные лимиты
Jira может указывать максимальную сумму кредита 1 000 000 рублей, а кредитная политика – максимум 500 000 рублей для сегмента NEW_CUSTOMER. Это может быть не прямое противоречие, а дополнительное условие. Агент сохраняет оба правила и показывает зависимость от сегмента.
Разные ставки и правила округления
Если Jira указывает ставку 14,9%, а XLSX использует 15,2%, агент фиксирует конфликт. Аналогично, если API округляет после каждой операции, а расчётная модель только после итогового результата.
Недоступная политика
Если Jira ссылается на кредитную политику, но агент не имеет к ней доступа, правила принятия решения нельзя считать полностью извлечёнными. Это ограничение доказательной базы должно быть явно отражено в GAP-листе.
Как это влияет на последующий QA-чек-лист
Корпус требований передаётся следующему специализированному промпту, который формирует QA-покрытие. Здесь зависимость довольно простая: качество чек-листа ограничено качеством и полнотой корпуса требований.
Если spec-researcher корректно извлёк лимиты, сегменты, формулы, порядок вычислений, правила округления, разрешённые состояния и кредитные ограничения, следующий промпт сможет учитывать эти правила при подготовке проверок.
Если же кредитная политика не была получена или агент пропустил важный раздел, следующий этап не сможет надёжно восстановить отсутствующее правило. Поэтому в корпусе важно явно сохранять unresolved и влияние недоступного источника.
unresolved:
source: confluence:credit-policy-4-2
reason: missing_access
impact: |
Segment-specific credit limits are not available.
Проверка полноты корпуса
Перед завершением работы агент должен проверить не только наличие выходного файла. Каждый обработанный источник должен либо дать требования, либо быть отмечен как не содержащий их. Каждый недоступный источник должен попасть в unresolved. У каждого требования должен быть источник и точная цитата. В корпус не должны попадать материалы из OUT_OF_SCOPE, должны быть указаны версии финансовых документов, сохранён порядок вычислений и исключены чувствительные данные.
corpus_status:
retrieval_complete: true
extraction_complete: true
processed_sources: 8
requirements: 41
unresolved_sources: 1
contradictions_found: 4
restricted_sources_skipped: 2
Подведем итог
Агент для работы с требованиями – это не генератор спецификаций и не замена бизнес-аналитика. Его практическая задача конкретнее: собрать контекст, удержать границы задачи, проверить актуальность источников, извлечь подтверждённые требования, безопасно обработать разрешённые финансовые документы, сохранить доказательства и показать противоречия.
В финтехе такой подход особенно полезен. Ошибка в ставке, лимите, порядке расчёта или версии кредитной политики может оказаться значительно дороже обычного UI-дефекта. Чем точнее собран корпус, тем полнее и надёжнее будет последующее тестовое покрытие.
Конечно, бывают галлюцинации AI. Агент может не дообработать документ, потерять часть условия или вообще не найти какое-то требование. Тогда следующий промпт получит неполный контекст, и чек-лист тоже будет неполным. Эти риски мы покрываем уже на уровне внедрения Codex в процессы QA: контрольными точками, проверками артефактов, трассируемостью и обязательным ревью. Но это уже следующая статья.
ссылка на оригинал статьи https://habr.com/ru/articles/1062390/