TL;DR
Schema-First Staged Prompting — техника построения промптов, где каждый запрос содержит явную схему желаемого вывода, а сложная задача разбивается на уровни абстракции: сначала цели → потом планы → потом исполнение. На каждом уровне человек проверяет результат перед переходом к следующему.
Главная боль: когда просишь LLM сгенерировать структурированный контент "за раз", модель выдаёт разношёрстные форматы, придумывает несуществующие переменные и поля, игнорирует ограничения. Попросишь "составь тест-план" — получишь 5 пунктов в произвольной структуре, половина из которых нерелевантна или выдумана.
Метод решает это двумя ходами. Первый: в промпт вшивается строгая схема вывода (JSON-структура, конкретные поля, допустимые значения) — модель не изобретает формат, а заполняет шаблон. Второй: задача разбивается на уровни абстракции — каждый уровень генерирует только то, что нужно для следующего, не перепрыгивая вперёд.
Схема метода
ШАГ 1 (один промпт): Извлечь ограничения из документа
→ Вывод: JSON со списком переменных, их диапазонами, единицами
ШАГ 2 (один промпт): Сгенерировать абстрактные цели в формате Given-When-Then
→ Вывод: JSON с целями в формате {given, when, then, rationale}
→ Человек проверяет: удаляет нереалистичные цели
ШАГ 3 (один промпт): Превратить каждую цель в конкретный план
→ Вывод: JSON с числовыми параметрами и условиями проверки
→ Человек проверяет: корректирует нереалистичные числа
ШАГ 4: Исполнение (уже вне чата — требует код/инфраструктуру)
Шаги 1–3 — отдельные запросы. Каждый следующий промпт получает вывод предыдущего как входные данные.
Пример применения
Задача: Нужно систематически проверить новый B2B SaaS-продукт — систему автоматизации закупок для малого бизнеса. Есть только описание функциональности и список параметров. Надо сгенерировать сценарии использования для пользовательского тестирования.
Промпт (Шаг 1 — извлечь ограничения):
1. Роль:
Ты — эксперт по анализу требований к продукту.
2. Задача:
Из документа ниже извлеки все входные и выходные параметры системы,
их допустимые диапазоны и ограничения.
3. Правила:
- Используй только то, что явно указано в документе
- Если диапазон не указан — поставь null
- Не придумывай параметры, которых нет в тексте
4. Строгая схема вывода:
Верни ТОЛЬКО JSON в таком формате:
{
"inputs": [
{"name": "...", "type": "...", "min": ..., "max": ..., "description": "..."}
],
"outputs": [
{"name": "...", "type": "...", "description": "..."}
]
}
5. Правило вывода:
Только JSON — никакого текста до или после.
6. Документ:
{описание_продукта}
Промпт (Шаг 2 — сгенерировать сценарии):
1. Роль:
Ты — QA-специалист, планирующий сценарии для системы {название_системы}.
2. Входные ограничения (используй ТОЛЬКО имена из этого списка):
{json_из_шага_1}
3. Задача:
Сгенерируй набор сценариев в формате Given-When-Then.
Каждый сценарий: что есть изначально (given),
что меняется (when), что ожидаем (then).
4. Правила:
- НЕ используй конкретные числа — только качественные описания
- НЕ придумывай параметры вне списка выше
- Каждый then — ОДНО конкретное ожидаемое поведение
5. Строгая схема вывода:
{
"scenarios": [
{
"id": "S001",
"given": "...",
"when": "...",
"then": ["...", "..."],
"rationale": "Краткое обоснование"
}
]
}
6. Правило вывода:
Только JSON, без пояснений.
Результат:
На Шаге 1 модель вернёт структурированный список параметров из документа — только то, что там реально есть, ничего лишнего. На Шаге 2 — набор сценариев в формате JSON: каждый с контекстом, триггером и списком ожидаемых результатов. Сценарии будут качественными (без чисел), что удобно для ревью: можно быстро удалить нереалистичные и передать оставшиеся на Шаг 3.
Почему это работает
Слабость LLM: Модель не знает, что "правильный" формат вывода — это именно тот, который нужен тебе. Без явной схемы она генерирует то, что встречала чаще всего в обучении. Результат непредсказуем по структуре.
Сильная сторона LLM: Модель отлично заполняет заданную структуру. Когда схема вывода явно прописана в промпте, модель следует ей почти без отклонений. Задача трансформируется из "придумай формат и заполни" в "заполни вот этот формат" — и это принципиально разные задачи по сложности.
Как метод использует это: Schema-first вшивает строгий шаблон прямо в промпт. Дополнительно — правило "Верни ТОЛЬКО JSON" убирает обёртку в виде комментариев и объяснений. Staged generation добавляет второй слой надёжности: каждый промпт работает с небольшим, уже проверенным контекстом из предыдущего шага — это снижает накопление ошибок.
Рычаги управления: - Секция "Правила" — добавляй запреты под свою задачу: "НЕ изменяй фиксированные параметры", "НЕ придумывай данные вне списка" - Уровни абстракции — можно убрать один уровень (сразу цели → конкретные планы), если задача проще - Секция "Success criteria" — добавь явные критерии качественного ответа, и модель будет самопроверяться - Few-shot exemplars — 1–2 примера правильно заполненной схемы сильно повышают точность структуры
Шаблон промпта
1. Роль:
Ты — {специализация_эксперта} для системы/задачи "{название}".
2. Контекст:
{описание_системы_или_документ}
3. Ограничения (используй ТОЛЬКО имена из этого списка):
{список_параметров_или_переменных}
4. Задача:
{что_нужно_сгенерировать} в формате {структура}.
Каждый элемент должен содержать: {список_обязательных_полей}.
5. Строгие правила:
- НЕ используй имена/значения вне списка ограничений
- НЕ включай числа там, где требуется качественное описание
- Каждый {элемент} = ровно {одно_условие_или_действие}
6. Строгая схема вывода:
{json_схема_с_точными_именами_полей}
7. Правило вывода:
Верни ТОЛЬКО JSON-объект, без пояснений и комментариев.
8. Примеры (1-2 заполненных элемента правильной структуры):
{few_shot_пример}
Что подставлять:
- {специализация_эксперта} — конкретная роль: "эксперт по требованиям", "QA-инженер", "аналитик данных"
- {список_параметров_или_переменных} — вывод предыдущего шага или явный список допустимых значений
- {json_схема} — точная структура с именами полей, типами, допустимыми значениями
- {few_shot_пример} — 1–2 примера правильно заполненной схемы
🚀 Быстрый старт — вставь в чат:
Вот шаблон Schema-First Staged Prompting.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про специализацию роли, какой формат вывода нужен и есть ли список допустимых значений — потому что без этого схема не работает. Она возьмёт паттерн из шаблона и адаптирует структуру под твою задачу.
Ограничения
⚠️ Требует инфраструктуры для финального шага: Генерация целей и планов в чате работает. Автоматическое исполнение сценариев и проверка результатов — только с кодом.
⚠️ Схему нужно проектировать заранее: Если не знаешь, какие поля нужны — сначала поговори с LLM в свободном формате, выясни структуру, потом переходи к schema-first.
⚠️ Человеческая проверка — не опция: Без ревью на каждом шаге ошибки первого уровня размножаются на втором. Метод рассчитан на то, что ты смотришь на вывод перед передачей дальше.
⚠️ Температура — только через API: Совет из статьи "выше температура для целей, ниже для планов" в обычном чате ChatGPT/Claude не применишь напрямую. Компенсируй через инструкции: "Генерируй разнообразные, нестандартные варианты" для дивергентной фазы.
Ресурсы
Using Large Language Models for Black-Box Testing of FMU-Based Simulations Abdullah Mughees, Gaadha Sudheerbabu, Tanwir Ahmad, Dragos Truscan (Åbo Akademi University, Finland), Mikael Manngård (Novia University of Applied Sciences, Finland), Kristian Klemets (University of Turku, Finland)
Принято на European Control Conference (ECC) 2026, Рейкьявик.
Связанные техники: Given-When-Then (Gherkin), Chain-of-Thought, Few-shot prompting, Schema-first prompting.