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

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

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

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

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

Трассировка здесь — не таблица ради таблицы. Это способ удержать одну линию от бизнес-проблемы до наблюдаемого действия системы.

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