TL;DR
Когда просишь модель "извлеки все требования из документа" — она зависает на очевидном и пропускает скрытое. PEGS-промптинг решает это структурно: вместо одного общего запроса ты задаёшь четыре конкретных угла разбора — Проект, Среда, Цели, Система. Модель не гадает что искать, а идёт по заданным категориям последовательно.
Главная находка: модели склонны "западать" на очевидные требования и концентрироваться в одной зоне. При общем запросе "извлеки требования" — ~60% категорий в документе остаются неохваченными. Модель фокусируется на явных технических спецификациях и игнорирует контекст (кто заказчик, какие внешние ограничения, какие цели стоят за задачей).
PEGS-промптинг переключает модель из режима "ищи то, что похоже на требование" в режим "пройди по четырём чётким измерениям". Каждое измерение — отдельный узконаправленный запрос с чёткой семантической границей. Охват категорий вырастает с 61% до 92% — то есть практически нет пропущенных зон.
Схема метода
Работает в одном промпте с четырьмя секциями-линзами:
ЛИНЗА 1: Проект (P) → стейкхолдеры, бюджет, сроки, организационный контекст
ЛИНЗА 2: Среда (E) → внешние системы, регуляторные требования, операционные условия
ЛИНЗА 3: Цели (G) → бизнес-цели, критерии успеха, ожидания пользователей
ЛИНЗА 4: Система (S) → функциональные требования, нефункциональные (скорость, безопасность, надёжность)
Каждая линза даёт модели конкретный поисковый прицел. Не "найди всё", а "найди вот это конкретное".
Пример применения
Задача: Фрилансер получил бриф от клиента — стартап хочет запустить сервис для управления командировками сотрудников. Документ на 4 страницы, написан хаотично. Нужно понять что вообще строить.
Промпт:
Вот бриф клиента. Проанализируй его по четырём категориям — пройди каждую отдельно
и не переходи к следующей, пока не закончил текущую.
КАТЕГОРИЯ P — ПРОЕКТ:
Кто заказчик и что за компания? Кто пользователи? Какие ограничения: бюджет, сроки,
команда? Что организационно важно учесть?
КАТЕГОРИЯ E — СРЕДА:
С какими внешними системами нужно интегрироваться (бухгалтерия, авиабилеты, банки)?
Какие регуляторные или юридические требования упомянуты? Какие операционные условия
(мобильные устройства, офлайн-режим)?
КАТЕГОРИЯ G — ЦЕЛИ:
Какие бизнес-цели стоят за продуктом? Что считается успехом? Что хочет получить
пользователь в итоге? Какие боли решаем?
КАТЕГОРИЯ S — СИСТЕМА:
Что именно должна делать система (функции)? Какие нефункциональные требования
(скорость, безопасность, масштаб, надёжность)?
В каждой категории: оформи находки списком. После всех четырёх — укажи, какие
требования пересекаются или противоречат друг другу.
БРИФ:
[вставь текст брифа]
Результат: Модель пройдёт все четыре секции последовательно. В каждой — структурированный список. В секции G появятся вещи, которых нет в явном виде в брифе — модель выведет их из контекста. В секции E — интеграции и ограничения, которые клиент не назвал прямо. В финале — список противоречий, которые нужно уточнить на созвоне. Из одного хаотичного документа выходит четырёхблочная структура готовая к оценке.
Почему это работает
Слабость модели: LLM генерирует текст по наиболее вероятному паттерну. При запросе "найди требования" — она генерирует то, что выглядит как типичные требования: явные технические спецификации. Имплицитные ограничения, бизнес-контекст, внешние зависимости — они выглядят иначе и модель их "не видит" как требования.
Сила модели: зато она хорошо работает с чётко ограниченным поисковым пространством. Когда написано "смотри только на регуляторные и операционные ограничения" — модель буквально сужает область поиска и находит то, что при широком запросе тонуло.
Как метод использует это: PEGS превращает один сложный размытый запрос в четыре узких прицельных. Каждая категория — отдельный контекст с ясными примерами того, что туда попадает. Модель не гадает, а следует маршруту.
Рычаги управления: - Добавь примеры внутрь категории — напиши после названия категории "например: требование к времени ответа, требование к нагрузке". Даёт модели образец, от которого она плясует - Добавь категорию "Риски" — четыре категории PEGS можно расширить пятой под свою задачу - Измени формат вывода — вместо списка попроси таблицу с колонками "Требование / Приоритет / Источник в документе" - Добавь запрос на конфликты — "после всех категорий укажи противоречия" — это встроенная верификация
Шаблон промпта
Проанализируй {документ/текст/бриф} по четырём категориям.
Проходи каждую категорию отдельно и полностью, прежде чем переходить к следующей.
КАТЕГОРИЯ P — ПРОЕКТ:
Кто участвует? Какие организационные ограничения (сроки, бюджет, команда)?
Какой контекст важен для понимания задачи?
КАТЕГОРИЯ E — СРЕДА:
Какие внешние системы, сервисы, инструменты задействованы или упомянуты?
Какие регуляторные, юридические или операционные ограничения есть?
КАТЕГОРИЯ G — ЦЕЛИ:
Какие бизнес-цели стоят за задачей? Что считается успехом?
Что в итоге должен получить пользователь или заказчик?
КАТЕГОРИЯ S — СИСТЕМА:
Что конкретно должно делать (функции)?
Какие нефункциональные требования: скорость, безопасность, надёжность, масштаб?
По каждой категории: {формат — список / таблица / абзацы}.
В конце: укажи пересечения и противоречия между категориями.
{документ/текст}
Плейсхолдеры:
- {документ/текст/бриф} → что анализируем: ТЗ, договор, описание проекта, письмо клиента
- {формат} → как оформить результат: список, таблица, нумерация
🚀 Быстрый старт — вставь в чат:
Вот шаблон PEGS-промптинга. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM уточнит что анализировать и в каком формате нужен результат — потому что метод адаптируется под любой тип документа и под любой желаемый формат вывода. Она возьмёт четырёхкатегорийную структуру и настроит под твою задачу.
Ограничения
⚠️ Короткие и простые тексты: Для письма на абзац или простого запроса PEGS избыточен — часть категорий окажется пустой. Метод раскрывается на объёмных, многосоставных документах.
⚠️ Категория "Среда" — самая сложная: Внешние ограничения и регуляторный контекст часто написаны как фоновый текст, а не как явные требования. Модель пропускает их чаще, чем другие категории — даже с PEGS. Стоит пройти эту секцию отдельным уточняющим запросом.
⚠️ Имплицитные требования через ссылки: Если документ ссылается на другой стандарт или документ ("должно соответствовать ГОСТ Р 57235") — модель не знает содержания этого документа и не вытащит скрытые там требования.
⚠️ Метод заточен под документы: Хорошо работает для анализа текстов. Для творческих, субъективных или открытых задач структура четырёх категорий не подходит.
Ресурсы
Статья: ReqFusion: A Multi-Provider Framework for Automated PEGS Analysis Across Software Domains
PEGS-методология: Bertrand Meyer, оригинальный фреймворк Project-Environment-Goals-System
Авторы: Muhammad Khalid, Manuel Oriol, Yilmaz Uygun — Constructor University Bremen, Germany
Демо системы: https://re-engineer-app-khalid.replit.app