TL;DR
Agent4RE — это цепочка из пяти ролей, которая превращает абзац с идеей проекта в полное ТЗ. Сначала «интервьюер» задаёт вопросы, а «заказчик» (тоже модель) отвечает, пока не наберётся достаточно сведений. Потом из протокола интервью собирается документ по стандартному шаблону. Затем «рефакторщик» проверяет черновик по критериям (однозначность, полнота, согласованность) и отправляет его на доработку.
Главная боль: если сказать модели «напиши ТЗ по этой идее», она берёт общие слова и заполняет разделы шаблона водой. Деталей, которые нужны разработчикам, в документе нет. Причина простая: из одного абзаца их неоткуда взять. Модель не задаёт вопросов, а сразу пишет. Поэтому даже сильный промпт с шаблоном и контекстом домена даёт слабый результат.
Метод решает это двумя вставками. Перед генерацией модель сама «выспрашивает» недостающее (до 10 раундов, интервьюер сам решает, когда хватит). После генерации отдельная роль критикует документ по заданным критериям. Все три варианта системы обошли сильный промпт-baseline примерно на 8% по текстовым метрикам. Версии с самодоработкой и с короткими подсказками человека получили у судей и экспертов оценки примерно на 0,8 балла выше (по четырёхбалльной шкале), чем два готовых подхода для сравнения.
Схема метода
ШАГ 0 (Оркестратор): краткая идея → сводка проекта S
ШАГ 1 (Интервьюер ⇄ Заказчик): цикл вопрос-ответ, до 10 раундов,
интервьюер сам вызывает «выход из цикла» → протокол интервью R
ШАГ 2 (Генератор): R + шаблон ТЗ (IEEE 830 / 29148) → черновик D0
ШАГ 3 (Оркестратор): проверка черновика, при дырах — возврат на доработку
ШАГ 4 (Рефакторщик): D + критерии качества [+ подсказки человека]
→ список правок
ШАГ 5 (Генератор): D + правки → D1 (цикл 4–5 можно повторять)
Три режима: без обратной связи (шаги 0–3), с самодоработкой (+4–5 от модели), с человеком (+4–5 после коротких подсказок эксперта).
Пример применения
Задача: Вы запускаете интернет-магазин обжарщика кофе из Казани. Есть абзац идеи: подписка на кофе, оплата через ЮKassa, доставка СДЭК, личный кабинет. Нужно ТЗ для подрядчика, чтобы он не переспрашивал каждый день.
Промпт:
Ты работаешь как команда из четырёх ролей. Выполняй этапы строго по порядку.
Идея проекта: Интернет-магазин небольшой обжарки кофе из Казани.
Основная фишка — подписка: клиент выбирает сорт, помол и частоту
(раз в 2 или 4 недели). Оплата через ЮKassa, доставка СДЭК по России,
личный кабинет с историей заказов и возможностью поставить подписку
на паузу. Команда: 3 человека, запуск через 3 месяца.
ЭТАП 1. СВОДКА (роль «Оркестратор»)
Кратко опиши проект: цель, пользователи, границы. Это сводка S.
ЭТАП 2. ИНТЕРВЬЮ (роли «Интервьюер» и «Заказчик»)
Интервьюер задаёт 5–8 вопросов за раунд: про пользователей, сценарии,
платежи, доставку, ограничения, риски. Заказчик отвечает, опираясь
на сводку S и знания о подобных проектах; если не знает — так и пишет.
Повторяй раунды, пока Интервьюер не решит, что информации достаточно.
Максимум 10 раундов. После каждого раунда Интервьюер пишет:
ВЫХОД: да/нет и причину. Когда «да» — составь отчёт R по интервью.
ЭТАП 3. ГЕНЕРАЦИЯ (роль «Генератор»)
По отчёту R составь ТЗ строго по структуре IEEE 29148
(разделы: назначение, область применения, заинтересованные стороны,
функциональные требования, нефункциональные требования, ограничения,
интерфейсы, критерии приёмки). Пустые разделы помечай «нет данных».
ЭТАП 4. ПРОВЕРКА (роль «Оркестратор»)
Проверь черновик D0: все ли разделы на месте, нет ли противоречий
с отчётом R. Перечисли дефекты.
ЭТАП 5. РЕФАКТОРИНГ (роль «Рефакторщик»)
Оцени D0 по критериям: однозначность (нет «быстро», «удобно» без
цифр), полнота, согласованность. Выдай список конкретных правок
в формате «раздел → что исправить → как».
ЭТАП 6. ДОРАБОТКА (роль «Генератор»)
Внеси правки и выдай итоговую версию D1.
Результат: Модель покажет сводку проекта и несколько раундов интервью с вопросами и ответами. В каждом раунде будет пометка «ВЫХОД: да/нет». Дальше идёт ТЗ по структуре стандарта и дефекты черновика. После них следует список правок в формате «раздел → проблема → исправление» и итоговая версия. Всё придёт одним длинным ответом.
Почему это работает
Слабость модели. Получив короткую идею и просьбу «сделай ТЗ», модель сразу пишет документ. Деталей в промпте нет, поэтому она заполняет разделы общими фразами. Кроме того, модель редко критикует свой первый вариант, если её об этом не просят.
Сильная сторона. Модель хорошо знает типовые проекты и умеет задавать уточняющие вопросы. Она хорошо проверяет текст по явным критериям: «найди неоднозначные формулировки». Роль «заказчика» подтягивает из её знаний типовые детали: что обычно нужно подписочному магазину, какие бывают статусы доставки, какие юридические моменты.
Как метод это использует. Интервью превращает одну идею в набор конкретных фактов, и генератору есть что писать. Шаблон стандарта в инструкции удерживает структуру. Отдельная роль с жёсткими критериями находит расплывчатые места, которые автор текста не видит. Короткие подсказки человека (маркированные пункты, а не готовые правки) направляют рефакторинг точнее, чем самопроверка.
Рычаги: - Лимит раундов (10) → уменьшайте для простых проектов, экономите токены. - Критерии рефакторинга → замените на свои: «проверяемость», «трассируемость», «соответствие 152-ФЗ». - Шаблон документа → подставьте свой формат (PRD, ТЗ по ГОСТ 34, бриф). - Температура (в API или настройках агента) → в оригинале у интервьюера и заказчика 1,0 (чтобы больше исследовали), у генератора 0,8, у оркестратора 0,5, у рефакторщика 0,2 (чтобы критика была стабильной). В обычном чате этим не управляйте. - Число циклов рефакторинга → в эксперименте один, для честного сравнения. На практике можно два-три.
Шаблон промпта
Оригинальные промпты агентов лежат в репозитории авторов. Шаблон ниже собран по описанию метода в статье.
Ты ведёшь процесс подготовки ТЗ. В процессе пять ролей:
Оркестратор, Интервьюер, Заказчик, Генератор, Рефакторщик.
Играй каждую роль по очереди, не смешивай их голоса.
Идея проекта: {краткое_описание_проекта}
Шаблон документа: {шаблон_например_IEEE_29148_или_свой}
Критерии качества: {критерии_например_однозначность_полнота_согласованность}
Макс. раундов интервью: {число_раундов}
Оркестратор:
S = сводка_проекта(Input.идея)
Интервьюер и Заказчик:
t = 0
While t < {число_раундов}:
Интервьюер.вопросы(S, прошлые_ответы) → список вопросов
Заказчик.ответы(вопросы, S) → ответы (если не знает — «не знаю»)
t = t + 1
Интервьюер.выход() → да/нет + причина
If выход == да: break
R = Интервьюер.отчёт(вся_переписка)
Генератор:
D0 = Генератор.написать(R, {шаблон}); пустые разделы = «нет данных»
Оркестратор:
дефекты = Оркестратор.проверить(D0, R)
Рефакторщик:
правки = Рефакторщик.критика(D0, {критерии}, {подсказки_человека})
формат правки: раздел → проблема → как исправить
Генератор:
D1 = Генератор.доработать(D0, правки)
Что подставлять:
- {краткое_описание_проекта} — абзац с идеей, целями, сроками и командой.
- {шаблон} — структура документа. Для ТЗ можно указать разделы списком.
- {критерии} — 3–5 свойств хорошего документа.
- {подсказки_человека} — 3–5 коротких пунктов от вас («не хватает требований к безопасности платежей»). Если подсказок нет, напишите «нет».
🚀 Быстрый старт — вставь в чат:
Вот шаблон Agent4RE. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про суть проекта, нужный формат документа, критерии качества и ограничения (сроки, бюджет, юридические рамки). Эти вопросы нужны, чтобы интервью и рефакторинг опирались на ваш контекст, а не на общие места. Паттерн ролей и циклов модель возьмёт из шаблона.
Ограничения
⚠️ «Заказчик» — тоже модель: она отвечает из общих знаний, а не из ваших реальных обстоятельств. Может уверенно придумать требования, которых у вас нет. Результат нужно сверять с живыми заинтересованными сторонами.
⚠️ Нужна доработка для автоматизации: в статье система собрана на Google ADK (код). В чате вы получите симуляцию ролей в одном окне. Это проще, но раздельные температуры и настоящий инструмент выхода из цикла недоступны.
⚠️ Слабые модели: маленькие открытые модели (4–8 млрд параметров) в этой роли работают заметно хуже. Авторы даже не использовали их как судей: те ошибаются в оценке.
⚠️ Проверка качества шаткая: текстовые метрики сравнивают документ с эталоном по словам, а не по пригодности. Судья-модель ставила идеальные 4,0 нескольким вариантам. Люди-оценщики были теми же, кто размечал данные, и видели эталон.
⚠️ Узкая область: проверено только на ТЗ для программных систем. Перенос на другие документы логичен, но в статье не проверен. Доступная часть текста обрывается на результатах, анализ цикла интервью (раздел 4.6) в ней отсутствует.
Как исследовали
Исследователи собрали набор из 50 реальных ТЗ, написанных практикующими инженерами: 30 по стандарту IEEE 830 и 20 по IEEE 29148. Для каждого ТЗ люди вручную написали краткое описание проекта, как будто это идея от заказчика. Задача системы была такой: из короткой идеи получить ТЗ, максимально близкое к настоящему.
Сравнивали три версии Agent4RE (без обратной связи, с самодоработкой, с подсказками человека) с двумя baseline. Первый — промптинг с готовыми шаблонами для этапов RE, второй — мультиагентный фреймворк iReDev. Прогоняли на восьми моделях: GPT-5, GPT-4.1, GPT-4o, Gemini-3-flash и четырёх маленьких открытых. Качество измеряли метриками сходства текста (METEOR, BLEU, ROUGE), семантическими метриками, судьёй-LLM и тремя инженерами.
Результат: версия с подсказками человека лидировала по текстовым метрикам. Самодоработка с GPT-5 чуть опередила её у судьи-LLM. У людей лучшей стала версия с человеком: 3,29 из 4 против 2,22 и 2,87 у baseline. Эксперимент ограничили одним циклом рефакторинга, потому что у обратной связи человека нет естественного потолка, и сравнение было бы нечестным.
Практический вывод: важна не одна хитрая формулировка, а процесс. Сначала добыть недостающие факты, потом критиковать результат по явным критериям. Короткие подсказки человека дают дополнительный выигрыш.
Адаптации и экстраполяции
🔧 Техника: убрать симулированного заказчика → вы сами отвечаете на вопросы
Замените роль «Заказчик» на себя:
Интервьюер задаёт вопросы. Не отвечай за заказчика — остановись
и жди моих ответов. Когда информации хватит, сам скажи «ВЫХОД: да».
Это снимает главный риск метода: выдуманные ответы. Вы тратите 10 минут на ответы, но получаете ТЗ, основанное на ваших фактах.
🔧 Техника: подсказки человека перед рефакторингом → точнее правки
Перед этапом 5 добавьте:
Мои подсказки для Рефакторщика:
- {подсказка_1: например, «мало про сценарии возврата»}
- {подсказка_2}
Учти их при составлении списка правок.
В статье это дало лучшие оценки людей. Подсказки не должны быть подробными исправлениями, достаточно указать направление.
Экстраполяция: тот же каркас для других документов (в статье не проверялось):
Идея: {идея_коммерческого_предложения_или_брифа}
Шаблон: {структура_КП}
Критерии: {конкретика_цифры_без_воды_УТП_понятно_клиенту}
Интервью → черновик → критика по критериям → правка. Подходит для брифов, PRD, коммерческих предложений и регламентов.
Ресурсы
- Agent4RE: A Self-Refining Multi-agent Framework for End-to-End Software Requirements Engineering and Benchmarking
- Код, датасет RE-E2E и полные промпты агентов: https://github.com/markustyj/Agent4RE_ASE-2026
- Авторы: Yongjian Tang (Siemens AG, Technical University of Munich), Linhan Li (Technical University of Munich), Thomas Runkler (Siemens AG, Technical University of Munich)
- Для сравнения: iReDev (мультиагентный фреймворк для RE), Prompt Patterns for RE; шаблоны стандартов IEEE 830 и IEEE 29148