TL;DR
Исследователи разобрали 2163 промпт-шаблона из реальных LLM-приложений (включая инструменты от Uber и Microsoft) и выделили 7 ключевых компонентов, из которых строятся эффективные промпты: роль (Profile/Role), инструкция (Directive), рабочий процесс (Workflow), контекст (Context), примеры (Examples), формат вывода (Output Format/Style) и ограничения (Constraints). Оказалось, что 86.7% промптов содержат чёткую инструкцию, 56.2% — контекст, 39.7% — требования к формату, 35.7% — ограничения.
Главная находка: порядок компонентов имеет значение. Роль и инструкция чаще всего стоят в начале промпта (с вероятностью 0.87 и 0.65 соответственно). Контекст обычно идёт после роли, затем инструкция, потом рабочий процесс и примеры, а в конце — формат вывода и ограничения. Также выяснилось, что инструкции работают лучше вопросов — более 90% промптов в реальных приложениях используют императивный стиль ("Проанализируй текст") вместо вопросительного ("Можешь проанализировать?").
Для JSON-вывода (самого популярного формата после обычного текста) исследование выделило 3 уровня детализации: (1) просто указать "выведи JSON", (2) указать названия атрибутов, (3) добавить описание каждого атрибута. Третий паттерн — самый частый (44% случаев), потому что снижает ошибки при обработке ответов в приложениях. Среди ограничений (Constraints) лидируют "исключения" (46%) — что модели НЕ должна делать, затем "включения" (35.6%) — на чём фокусироваться, и "лимиты по словам" (10.5%).
Схема метода
Это не техника, а фреймворк для построения промптов. Исследование выделяет структуру:
КОМПОНЕНТЫ (7 типов):
1. Profile/Role — кто или что модель (28.4% промптов)
2. Directive — основная инструкция (86.7%)
3. Context — фоновая информация (56.2%)
4. Workflow — пошаговый процесс (27.5%)
5. Examples — примеры ожидаемого результата (19.9%)
6. Output Format/Style — тип/формат вывода (39.7%)
7. Constraints — ограничения и правила (35.7%)
ОПТИМАЛЬНЫЙ ПОРЯДОК:
Profile/Role → Context → Directive → Workflow → Examples →
→ Output Format/Style ⟷ Constraints
(последние две пары гибко меняются местами)
Пример применения
Задача: Нужен промпт для анализа идей стартапов — модель должна оценить жизнеспособность, выделить риски и дать рекомендации в структурированном виде для дальнейшей обработки.
Промпт (следуя найденной структуре):
Ты — опытный venture-аналитик, который оценивает стартапы
для российских фондов.
Проанализируй бизнес-идею стартапа: {описание_идеи}.
Контекст:
- Российский рынок, B2C сегмент
- Стадия: pre-seed, команда 2-3 человека
- Бюджет на MVP: до 3 млн рублей
Выполни анализ по шагам:
1. Оцени размер рынка и конкуренцию
2. Определи ключевые риски (минимум 3)
3. Предложи метрики для валидации гипотез
4. Дай рекомендацию: зелёный свет / доработать / отклонить
Не используй абстрактные формулировки. Называй конкретных
конкурентов, цифры рынка, реальные метрики.
Формат ответа — JSON:
{
"market_size_rub": "оценка объёма рынка в рублях",
"competition_level": "низкая/средняя/высокая",
"key_risks": ["риск 1", "риск 2", "риск 3"],
"validation_metrics": ["метрика 1", "метрика 2"],
"recommendation": "зелёный свет/доработать/отклонить",
"reasoning": "краткое обоснование рекомендации"
}
Результат:
Модель выдаст структурированный JSON с заполненными атрибутами: оценкой рынка в рублях, уровнем конкуренции, списком конкретных рисков, метриками для проверки и финальной рекомендацией с обоснованием. Формат позволяет автоматически обработать ответ — например, отфильтровать идеи с "зелёным светом" или построить таблицу по рискам.
Почему это работает
LLM лучше работает со структурой, чем с "напиши что-нибудь про стартап". Исследование показало, что промпты в реальных приложениях используют чёткие компоненты неспроста — каждый выполняет функцию:
Роль (Profile/Role) активирует у модели определённый стиль мышления — venture-аналитик думает иначе, чем маркетолог. Контекст (Context) даёт модели ограничения реальности — российский рынок, бюджет 3 млн, pre-seed. Без этого модель выдаст общие рассуждения "на глобус". Инструкция (Directive) в императивном стиле ("Проанализируй") работает лучше вопросов ("Можешь проанализировать?") — так делают 90%+ реальных приложений, потому что это однозначнее.
Рабочий процесс (Workflow) разбивает задачу на шаги — модель идёт последовательно, не пропускает важное. Ограничения (Constraints) отсекают галлюцинации — "не используй абстрактные формулировки" заставляет модель быть конкретной. Формат вывода с описанием атрибутов (Pattern 3 из исследования) — самый надёжный: модель понимает не только ЧТО выдать ("key_risks"), но и КАК ("список из минимум 3 рисков").
Порядок компонентов влияет на качество. Когда роль и контекст идут в начале, модель "настраивается" на задачу, затем получает инструкцию и выполняет её в заданных рамках. Если формат и ограничения в конце — они работают как финальный чек-лист перед генерацией ответа.
Рычаги управления промптом:
- Детализация JSON — уровень 1 (просто "JSON") для простых задач, уровень 3 (с описанием атрибутов) для сложных → точнее структура, меньше ошибок
- Тип ограничений — "исключения" (что НЕ делать) сильнее "включений" (на чём фокус) → используй оба для баланса
- Стиль инструкции — императив ("Проанализируй") vs вопрос ("Можешь?") → императив чётче, используется в 90%+ случаев
- Workflow — добавь шаги для сложных задач, убери для простых → контроль глубины обработки
Шаблон промпта
Базовый фреймворк (7 компонентов):
Ты — {роль_специалиста}.
Контекст:
{описание_ситуации}
{ключевые_ограничения_реальности}
{основная_инструкция}.
Выполни задачу по шагам:
1. {шаг_1}
2. {шаг_2}
3. {шаг_3}
Ограничения:
- {что_НЕ_делать}
- {на_чём_фокус}
- {лимиты_по_объёму}
Формат ответа — JSON:
{
"{атрибут_1}": "{описание_что_здесь}",
"{атрибут_2}": "{описание_что_здесь}",
"{атрибут_3}": ["{формат_если_список}"]
}
Что подставлять:
- {роль_специалиста} — кто модель: аналитик, редактор, эксперт в домене
- {описание_ситуации} — контекст задачи: для кого, зачем, какие данные
- {основная_инструкция} — императив: "Проанализируй", "Создай", "Оцени"
- {шаг_1, шаг_2...} — декомпозиция задачи (опционально для простых задач)
- {что_НЕ_делать} — исключения: "не используй абстракции", "без галлюцинаций"
- {атрибут_X} — поля JSON с описанием типа и содержания
Упрощённая версия (4 обязательных компонента):
Ты — {роль}.
{инструкция}: {задача}.
Ограничения: {что_НЕ_делать}.
Формат: {структура_вывода}.
Используй полную версию для сложных задач (анализ, многошаговые процессы), упрощённую — для быстрых запросов (переформулировка, извлечение данных).
Ограничения
⚠️ Это фреймворк, не готовая техника: Исследование даёт структуру компонентов и их порядок, но не показывает КАК конкретно писать каждый компонент для разных типов задач. Нужно адаптировать под свою задачу.
⚠️ Паттерны основаны на частоте, не на A/B тестах: То, что 90% приложений используют инструкции вместо вопросов — это корреляция, а не доказательство причинно-следственной связи. Исследование показывает что ДЕЛАЮТ разработчики, но не всегда почему это ЛУЧШЕ работает.
⚠️ JSON-фокус: Анализ формата вывода сильно сосредоточен на JSON (самый популярный структурированный формат), но слабо покрывает другие форматы — Markdown, таблицы, код. Если твоя задача не про JSON, придётся экстраполировать принципы.
⚠️ Порядок компонентов — общий паттерн: Оптимальная последовательность выведена статистически и может не подходить для специфичных задач. Например, для creative writing роль в начале может ограничивать креативность.
Как исследовали
Команда взяла датасет PromptSet — коллекцию промптов из реальных open-source проектов на GitHub по состоянию на январь 2024. Отфильтровали репозитории с минимум 5 звёздами и активностью в последний год, чтобы оставить только качественные приложения. Из 14,834 промптов после чистки (удаление дубликатов, коротких промптов <5 токенов) получили 2,163 уникальных промпт-шаблона от 1,525 репозиториев. Среди них — инструменты от Uber (2.3k звёзд, используют 200+ разработчиков), Microsoft (5.4k звёзд), Weaviate (6.5k звёзд) и LAION-AI (37.1k звёзд).
Для анализа исследователи синтезировали список из 7 компонентов, объединив определения из документации Google Cloud, фреймворков Elavis Saravia, CRISPE и LangGPT. Например, компоненты Profile, Capacity, Role и Persona слили в один — Profile/Role. Затем использовали llama3-70b-8192 для автоматической разметки компонентов в каждом шаблоне, а точность проверили вручную на 5% выборке — precision 86% на уровне компонентов, 66% полного совпадения и 99% частичного на уровне промптов.
Почему результаты получились такими: Оказалось, что Directive (инструкция) есть в 86.7% промптов — это логично, потому что без чёткой инструкции модель не понимает что делать. Context (56.2%) и Output Format (39.7%) тоже частые — приложениям нужна предсказуемость: они обрабатывают ответы автоматически, поэтому формат критичен. Интересный инсайт: более 90% инструкций написаны в императивном стиле ("Проанализируй"), а не в форме вопроса ("Можешь проанализировать?") — разработчики эмпирически пришли к тому, что императив работает чётче.
Для анализа порядка компонентов построили матрицу вероятностей: какой компонент чаще всего следует за каким. Выяснилось, что Profile/Role и Directive почти всегда в начале (вероятность 0.87 и 0.65), Context обычно идёт после Profile, а Output Format и Constraints — в конце. Это не случайность: такой порядок логичен — сначала настроить модель (роль + контекст), потом дать задачу (инструкция + шаги), в конце задать формат. Разработчики интуитивно пришли к этой структуре через практику.
Удивительная находка: JSON как формат вывода оказался самым популярным после обычного текста (особенно в темах "Coding & Debugging" и "Information Seeking"). Исследователи выделили 3 паттерна детализации JSON: от простого "верни JSON" до полного описания атрибутов. Самый детальный паттерн (Pattern 3) используется в 43.97% случаев — это говорит о том, что разработчики жертвуют краткостью промпта ради надёжности структуры в ответах.
Адаптации и экстраполяции
💡 Адаптация для итеративной работы
Исследование показывает структуру одного промпта, но в реальной работе часто нужна итерация. Адаптируй фреймворк для цепочки промптов:
Промпт 1 — Генерация:
Ты — {роль}.
Создай {что}: {описание_задачи}.
Контекст: {ограничения_реальности}.
Формат: {структура}.
Промпт 2 — Критика (в том же чате):
Теперь ты — критик.
Оцени предыдущий результат по критериям:
1. {критерий_1}
2. {критерий_2}
Формат: JSON с оценками по каждому критерию и рекомендациями.
Промпт 3 — Доработка:
Вернись к роли {исходная_роль}.
Доработай результат с учётом критики. Сохрани формат.
Принцип: каждый промпт в цепочке следует фреймворку 7 компонентов, но роль и инструкция меняются.
🔧 Техника: Динамические ограничения → адаптация под сложность
Исследование показывает, что Constraints (35.7%) — частый компонент, но ограничения можно регулировать по ходу диалога:
Для первого запроса (разведка):
Ограничения:
- Фокус на главном
- Без деталей реализации
Для уточнения (углубление):
Ограничения:
- Конкретные примеры
- Цифры и метрики
- Технические детали приветствуются
Меняя тип ограничений (исключения → включения, общее → детальное), управляешь глубиной ответа без переписывания всего промпта.
🔧 Техника: Роль как линза → множественные перспективы
Компонент Profile/Role (28.4%) можно использовать для получения разных взглядов на одну задачу:
Контекст: {описание_бизнес_идеи}
---
Взгляд 1 — Ты инвестор:
Оцени идею с точки зрения рисков и возврата инвестиций.
Взгляд 2 — Ты целевой пользователь:
Оцени удобство и ценность для себя.
Взгляд 3 — Ты конкурент:
Как бы ты атаковал эту идею?
Формат каждого взгляда: JSON с ключевыми мыслями.
Один промпт → три роли → три перспективы. Принцип из исследования (роль влияет на стиль мышления) + техника multi-agent prompting.
Ресурсы
From Prompts to Templates: A Systematic Prompt Template Analysis for Real-world LLMapps — Yuetian Mao, Junjie He, Chunyang Chen (Technical University of Munich, Germany). Датасет доступен: https://github.com/RedSmallPanda/FSE2025
Упоминаемые фреймворки и документация:
- Google Cloud prompt engineering guide
- Elavis Saravia framework
- CRISPE framework
- LangGPT framework
Датасет PromptSet (основа исследования) — коллекция промптов из open-source GitHub проектов.