AI-агент для проверки ТЗ: пошаговый разбор архитектуры и промптов от аналитика

ТЗ, ошибки и потерянные часы: зачем аналитику AI-агент?

Представь. Уже полночь. Ты - аналитик. Перед тобой - 50-страничное техническое задание на новую систему. Глаза слипаются, а в голове только одна мысль: "Пропущу ли я сегодня критичную неконсистентность?" Завтра с этим ТЗ пойдут работать 15 разработчиков, и каждая ошибка обернется десятками часов переделок, скандалами на демо и техническим долгом, который будет преследовать проект годами.

Знакомо? Я провел так сотни ночей. Пока не понял: человек для такой работы не создан. Мы устаем, теряем концентрацию, пропускаем мелочи. Но LLM (Large Language Model) - не устает. Идея родилась сама: создать AI-агента, который будет моим персональным ревьюером для ТЗ. Не просто чат-бот, а полноценного агента с памятью, контекстом и четкой логикой проверок. За два года экспериментов я выжал из этой идеи все, и сегодня покажу архитектуру, которая работает в продакшене.

Решение: не просто LLM, а агент с костями и мышцами

Главная ошибка - думать, что достаточно скормить ТЗ GPT-5 (или любой другой актуальной на 2026 год модели, вроде Claude 4 Opus или Gemini Ultra 2.0) и попросить "проверить". Реальные ТЗ - это сложные документы со структурой, требованиями, нефункциональными характеристиками, ограничениями. Агент должен понимать контекст домена, уметь строить трассировку требований, находить противоречия даже на 40-й странице.

Поэтому наш агент - это система из нескольких специализированных модулей. Вдохновлялся я архитектурой из статьи про State-of-the-Art Research Agent, но перепрофилировал ее под задачи аналитика.

1 Определяем scope: что агент проверяет на самом деле

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

• Логическая целостность: Противоречат ли требования друг другу?
• Полнота: Есть ли обязательные разделы (ограничения, нефункциональные требования, глоссарий)?
• Трассируемость: Можно ли от бизнес-требования пройти к конкретной функции системы?
• Тестопригодность: Сформулировано ли требование так, что его можно протестировать?
• Ясность: Используются ли субъективные термины ("быстрый", "удобный") без количественных метрик?

2 Выбираем модель: хватит ли контекстного окна?

На 2026 год выбор огромен. Но для работы с объемными ТЗ критичен размер контекста. Мои фавориты:

Лично я использую GPT-5 Turbo для основной проверки и Claude для валидации спорных моментов. Экономично и эффективно.

3 Архитектура агента: из каких модулей он состоит

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

# Упрощенная структура классов агента
class TZValidationAgent:
    def __init__(self, llm_client):
        self.parser = DocumentParser()
        self.consistency_checker = ConsistencyChecker(llm_client)
        self.traceability_builder = TraceabilityBuilder(llm_client)
        self.report_generator = ReportGenerator(llm_client)
        self.knowledge_base = KnowledgeBase()  # Хранит шаблоны, стандарты, глоссарии

    async def validate(self, tz_document_path: str) -> ValidationReport:
        # 1. Парсинг и структурирование
        structured_doc = await self.parser.parse(tz_document_path)
        
        # 2. Проверка согласованности
        consistency_issues = await self.consistency_checker.check(structured_doc)
        
        # 3. Построение матрицы трассировки
        trace_matrix = await self.traceability_builder.build(structured_doc)
        
        # 4. Генерация отчета
        report = await self.report_generator.generate(
            structured_doc, 
            consistency_issues, 
            trace_matrix
        )
        return report

Ключевой модуль - TraceabilityBuilder. Он строит матрицу трассировки требований, связывая бизнес-цели, пользовательские истории и функциональные требования. Это то, что человек делает с трудом, а агент - за секунды.

4 Сердце системы: промпты, которые действительно работают

Вот где большинство падает. Общие промпты дают общие результаты. Нужна специфика. Я выработал формат "Роль-Контекст-Задача-Ограничения-Формат вывода".

Ты - старший системный аналитик с 15-летним опытом. Твоя специализация - выявление логических противоречий в технической документации.

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

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

ОГРАНИЧЕНИЯ:
1. Не интерпретируй требования слишком широко. Противоречие должно быть прямым и очевидным.
2. Учитывай только информацию из предоставленного документа. Не добавляй внешних знаний.
3. Если требование сформулировано неоднозначно, отмечай это как проблему ясности, а не как противоречие.

ФОРМАТ ВЫВОДА:
Верни строго JSON-массив объектов. Каждый объект должен иметь поля:
- "requirement_id_a": ID первого требования,
- "requirement_id_b": ID второго требования,
- "conflict_description": четкое описание сути противоречия на русском языке,
- "severity": "HIGH" | "MEDIUM" | "LOW".
Если противоречий нет, верни пустой массив [].

ДОКУМЕНТ ДЛЯ ПРОВЕРКИ:
{structured_requirements}

А вот промпт для построения трассировки. Он сложнее, потому что требует понимания иерархии.

Ты - архитектор требований. Твоя задача - построить матрицу трассировки между бизнес-требованиями (BR), пользовательскими историями (US) и функциональными требованиями (FR).

ИНСТРУКЦИЯ:
1. Извлеки все BR, US и FR из документа. Их ID уже обозначены в тексте.
2. Для каждого FR определи, к какой US он относится.
3. Для каждой US определи, к какому BR она относится.
4. Если FR или US не могут быть явно связаны с верхнеуровневым требованием, пометь их флагом "ORPHAN".

ВЫХОД:
Сгенерируй CSV-строку для каждой связи. Формат:
BR_ID, US_ID, FR_ID
Если связь не найдена, используй NULL.
Пример:
BR-001, US-012, FR-045
BR-001, US-012, FR-046
BR-001, NULL, FR-047 (если FR-047 - сирота)

ДОКУМЕНТ:
{document_text}

Такие промпты дают структурированный, машиночитаемый вывод, который легко интегрировать в отчет или Jira. Это не просто текст "мне кажется, здесь проблема".

5 Интеграция и оценка: как не сломать процесс

Агент живет не в вакууме. Он должен встраиваться в Confluence, Google Docs, или хотя бы принимать Word/PDF. Я сделал простой веб-интерфейс на FastAPI, который загружает документ и возвращает интерактивный отчет с возможностью отметки ложных срабатываний.

Самое важное - оценка. Как понять, что агент стал лучше? Нужна система метрик, как в статье про оценку AI-агентов. Я отслеживаю:

• Precision/Recall для найденных ошибок: Сравниваю вывод агента с разметкой, которую делаю я вручную (выборочно).
• Скорость обработки: Не должна превышать 2-3 минут на 100 страниц.
• Количество "сиротских" требований: Показывает, насколько ТЗ целостно.

Где ломается: нюансы, которые не пишут в туториалах

1. Форматирование убивает контекст. Если ТЗ в виде скана PDF или с кучей таблиц, парсер может потерять структуру. Решение: использовать мультимодальные модели (как Gemini) или предобработку OCR с инструментами вроде Azure Document Intelligence.

2. LLM ненавидят считать. Проверка числовой согласованности ("максимум 100 пользователей" vs "обрабатывает 200 транзакций в секунду на пользователя") требует отдельного логического модуля, а не промпта. Я добавил простой rule-based движок для таких проверок.

3. Устаревание знаний. Агент должен знать актуальные стандарты (например, GDPR, PCI DSS 4.0). Я подключил RAG (Retrieval-Augmented Generation) систему, которая подтягивает свежие документы из внутренней базы знаний перед проверкой.

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

Вопросы, которые мне задают чаще всего

Что дальше? Агент становится инженером требований

Мой следующий шаг - научить агента не только находить ошибки, но и предлагать исправления. И даже генерировать фрагменты ТЗ для типовых модулей, следуя нашему внутреннему стандарту. Это уже граничит с Agent Engineering.

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

Совет напоследок: начните не с архитектуры, а с боли. Возьмите одно конкретное, часто повторяющееся действие в проверке ТЗ (например, поиск нефункциональных требований без метрик) и автоматизируйте только его. Получите feedback. Затем масштабируйте. Так вы построите инструмент, который решает реальные проблемы, а не еще одну игрушку в портфолио.

Подписаться на канал