Промты для трёх людей: как собирать запросы, которые понимают модель, заказчик и проверяющий

Методология

Промты для трёх людей: заказчика, модели и проверяющего

Разбираем, почему один и тот же запрос даёт разный результат у трёх участников процесса — и как написать промт, который удовлетворит всех сразу.

Три роли в одном запросе Структура, которая работает Шаблон для копирования

Проблема одного промта

Большинство команд пишут запрос «для нейросети». Но промт читают три субъекта: заказчик, который формулирует задачу, модель, которая исполняет, и проверяющий, который принимает результат. У каждого — свой контекст, свои критерии качества и свои слепые зоны.

Расходимость ожиданий

Заказчик думает категориями бизнеса («увеличить конверсию»), модель — категориями токенов и паттернов («продолжить последовательность»), проверяющий — категориями чек-листа («есть ли призыв к действию»). Промт, не учитывающий все три языка, рождает переделки.

Решение — трехслойная структура

Грамотный промт — это не одна инструкция, а документ из трёх блоков: контекст заказчика (зачем и что ожидается), директивы модели (как именно генерировать) и критерии приёмки (по каким признакам результат готов). Ниже — как это собрать.

Слой 1. Контекст заказчика: переводим бизнес-задачу в язык промта

Цель, а не действие

Плохо: «Напиши письмо про скидку». Хорошо: «Вернуть спящих клиентов: показать ценность обновлённого тарифа и дать безрисковый способ попробовать». Модель получит вектор, а не шаблон.

Ограничения как параметры

Тон, длина, формат, запрещённые фразы, обязательные элементы — выносите в явный список. Модель не «поймёт саму», ей нужны жёсткие границы. Заказчик видит их и соглашается заранее.

Примеры «хорошо/плохо»

Два-три пары образцов закрывают 80% неоднозначностей. Заказчик подтверждает вкус, модель копирует паттерн, проверяющий имеет эталон. Без примеров — игра в угадайку.

Контекст продукта и аудитории

Кто читает? Какая боль? Какой этап воронки? Один абзац вводных экономит часы правок. Это единственный блок, который заказчик пишет сам — остальное может оформить промт-инженер.

Образец: блок контекста заказчика

Ниже — готовый шаблон. Скопируйте, замените угловые скобки на свои данные и вставьте в начало промта. Этот раздел читает заказчик (согласовывает) и модель (настраивается).

# КОНТЕКСТ ЗАКАЗЧИКА
## Цель
<Что должно измениться у читателя/пользователя после прочтения/взаимодействия>

## Аудитория и момент
<Кто читает, в каком состоянии, на каком этапе воронки>

## Продукт/Предложение в одной фразе
<Суть ценности без маркетинговой шелухи>

## Ограничения формата
- Длина: <символов/слов/абзацев>
- Тон: <например: экспертный, дружелюбный, строгий, вдохновляющий>
- Структура: <обязательные блоки, порядок>
- Запреты: <слова, фразы, подходы, которые нельзя использовать>

## Эталонные примеры (2–3 пары)
### Хорошо
<Образец результата, который нравится заказчику>

### Плохо
<Образец результата, который НЕ нравится, с комментарием почему>

## Критерии успеха (для проверяющего)
- <Измеримый признак 1>
- <Измеримый признак 2>
- <Измеримый признак 3>

Слой 2. Директивы модели: инструкции, которые исполняются точно

Роль и поведение

Назначьте роль: «Ты — старший редактор fintech-медиа с 10-летним стажем»
Задайте стиль мышления: «Думай пошагово, проверяй факты, избегай обобщений»
Определите границы: «Не выдумывай цифры, пиши [ТРЕБУЕТСЯ ДАННАЯ]»

Алгоритм генерации

Разбейте задачу на шаги: «Сначала составь структуру, затем напиши заголовки, потом — тело»
Укажите порядок: «Не начинай писать, пока не выведешь план»
Добавьте самопроверку: «В конце оцените результат по критериям из блока 3»

Формат выхода

JSON / Markdown / чистый текст / HTML — жёстко фиксируйте
Схема полей: названия, типы, обязательность
Пример валидного ответа — обязателен для структурированных задач

Параметры сэмплирования

Temperature: 0.2–0.4 для фактов, 0.7–0.9 для креатива
Top-p: 0.9 по умолчанию, сужайте для строгого формата
Max tokens: с запасом 20–30% выше ожидаемого

Образец: блок директив модели

# ДИРЕКТИВЫ МОДЕЛИ
## Роль
Ты — <конкретная роль с опытом и специализацией>.

## Процесс выполнения
1. <Шаг 1: что делаем сначала>
2. <Шаг 2: что делаем дальше>
3. <Шаг N: финальная проверка по критериям>

## Жёсткие правила
- <Правило 1: что НЕЛЬЗЯ делать>
- <Правило 2: что ОБЯЗАТЕЛЬНО делать>
- <Правило 3: как обрабатывать неопределённость>

## Формат ответа
<Описание фортера: JSON с полями X, Y, Z / Markdown с заголовками H2/H3 / ...>

## Пример валидного ответа
<Минимальный корректный образец выхода>

Почему это работает

Разделение ответственности Заказчик не лезет в технические параметры, модель не гадает о бизнес-целях, проверяющий получает чёткий чек-лист.

Явная передача контекста Каждый блок пишется на языке своего адресата. Никаких «модель поймёт» — модель понимает только то, что записано в её блоке.

Встроенная приёмка Критерии успеха прописаны до генерации. Проверяющий не придумывает требования постфактум — они согласованы в начале.

Слой 3. Критерии приёмки: чек-лист, который исключает споры

Третий блок — это не просто список пожеланий. Это контракт между заказчиком и проверяющим, который модель может использовать для самопроверки. Хорошие критерии — бинарные (да/нет) или шкальные с понятными якорями.

Бинарные критерии

Есть ли призыв к действию в конце?
Упомянут ли новый тариф «Про»?
Длина не превышает 1800 знаков?
Нет запрещённых слов («лучший», «уникальный», «инновационный»)?

Шкальные критерии с якорями

Тон: 1 — слишком формальный, 3 — идеально экспертно-дружелюбный, 5 — слишком разговорный
Полнота раскрытия темы: 1 — поверхностно, 3 — все ключевые аспекты, 5 — избыточно детально
Соответствие бренд-голоса: 1 — чужой, 3 — узнаваемо, 5 — карикатурно

Критерии процесса (для модели)

Выведена ли структура до написания?
Проверены ли факты против контекста?
Сделан ли финальный проход по бинарным критериям?
Выдан ли ответ в задекларированном формате?

Собираем всё вместе: единый промт-документ

Ниже — полная структура, которую можно скопировать в один файл. Разделы разделены маркерами `—`, чтобы модель (и человек) чётко видели границы. Порядок важен: контекст → директивы → критерии.

# ПРОМТ-ДОКУМЕНТ v1.0
# Задача: <Название задачи>
# Дата: <ДД.ММ.ГГГГ>
# Автор промта: <Имя>
# Версия: <Номер>

=== КОНТЕКСТ ЗАКАЗЧИКА ===
## Цель
<...>

## Аудитория и момент
<...>

## Продукт/Предложение
<...>

## Ограничения формата
- Длина: <...>
- Тон: <...>
- Структура: <...>
- Запреты: <...>

## Эталонные примеры
### Хорошо
<...>
### Плохо
<...>

## Критерии успеха
- <Критерий 1>
- <Критерий 2>
- <Критерий 3>

---
=== ДИРЕКТИВЫ МОДЕЛИ ===
## Роль
Ты — <роль>.

## Процесс выполнения
1. <Шаг 1>
2. <Шаг 2>
3. <Самопроверка по критериям успеха>

## Жёсткие правила
- <Правило 1>
- <Правило 2>
- <Правило 3>

## Формат ответа
<Формат + схема полей>

## Пример валидного ответа
<Образец>

---
=== КРИТЕРИИ ПРИЁМКИ (ДЛЯ ПРОВЕРЯЮЩЕГО И САМОПРОВЕРКИ МОДЕЛИ) ===
### Бинарные (да/нет)
- [ ] <Критерий 1>
- [ ] <Критерий 2>

### Шкальные (1–5 с якорями)
- <Критерий 3>: 1 — <якорь>, 3 — <якорь>, 5 — <якорь>

### Процессные
- [ ] Структура выведена перед генерацией
- [ ] Факты сверены с контекстом
- [ ] Формат соответствует спецификации

Типичные ошибки и как их избежать

Смешивание слоёв

Параметры temperature и top_p пишутся в блоке модели, а не в контексте заказчика. Критерий «тон голоса» — в критериях приёмки, а не в директивах. Нарушение границ создаёт конфликт инструкций.

Отсутствие примеров

«Напиши в нашем тоне» без пары образцов — гарантия переделки. Примеры закрывают неопределённость лучше любых прилагательных. Минимум одна пара «хорошо/плохо» на задачу.

Критерии без якорей

«Качественный текст» — не критерий. «Текст содержит 3 конкретизирующих детали из контекста» — критерий. Проверяющий должен ответить «да/нет» за 10 секунд без интерпретации.

Игнорирование версии модели

Промт, написанный под GPT-4o, может давать мусор на Claude 3.5 Sonnet или локальной Llama. Версию модели и её особенности фиксируйте в мета-данных промта и тестируйте при смене провайдера.

Адаптация под разные сценарии

Короткие задачи (твиты, заголовки, пуши)

Контекст заказчика — 3–4 строки
Директивы модели — только роль, формат, 1 пример
Критерии — 2–3 бинарных пункта
Temperature: 0.7–0.9

Длинные форматы (статьи, лонгриды, отчёты)

Полный контекст + 3–5 примеров
Пошаговый процесс: план → черновик → правка → финал
Критерии: бинарные + шкальные + процессные
Temperature: 0.3–0.5, разбивка на чанки

Структурированные данные (JSON, CSV, код)

JSON Schema в директивах модели
Пример валидного объекта — обязателен
Критерии: валидность схемы + заполненность обязательных полей
Temperature: 0.1–0.2, top-p: 0.5–0.7

Как внедрить в рабочий процесс команды

Библиотека промт-документов

Храните в Notion/Git/Confluence. Каждая задача — отдельный файл с версией. Изменения только через PR/ревью. История версий = понятная эволюция качества.

Ритуал согласования

Заказчик заполняет контекст → промт-инженер добавляет директивы → проверяющий утверждает критерии. 15 минут на старте экономят часы на правках.

Автоматизированная приёмка

Бинарные критерии проверяйте скриптом (regex, длина, наличие полей). Шкальные — человеком. Модель может вернуть самопроверку в JSON вместе с результатом.

Реротриспективы по провалам

Если результат не прошёл приёмку — какой слой сработал плохо? Недостаток контекста? Нечёткая директива? Размытый критерий? Исправляйте промт-документ, а не ругайте модель.

Главное, что стоит запомнить

Один промт — три адресата

Пишите так, чтобы поняли заказчик (зачем), модель (как) и проверяющий (по каким правилам).

Структура побеждает талант

Чёткий трехслойный документ даёт стабильный результат лучше, чем гениальный, но хаотичный запрос.

Критерии до генерации

Приёмка договаривается в начале. Постфактум — это уже не приёмка, а спор.

Промт — это не запрос к машине. Это соглашение между людьми, которое машина помогает исполнить.