Принцип

Промпт — это программа для LLM. Чёткая структура и явные инструкции дают предсказуемый результат.

Компоненты промпта

Оптимальный порядок

$РОЛЬ$           — кто отвечает  
$КОНТЕКСТ$       — с чем работаем  
$ЗАДАЧА$         — что сделать  
$ОГРАНИЧЕНИЯ$    — чего избегать  
$ФОРМАТ$         — как оформить ответ  
$ПРИМЕРЫ$        — образец (если нужен)

Пример 1: Минимальный промпт

КОНТЕКСТ:  
Список чисел: $1, 5, 3, 9, 2$  
  
ЗАДАЧА:  
Отсортируй по убыванию  
  
ФОРМАТ:  
Python код

Пример 2: Стандартный промпт

РОЛЬ:  
Senior Python developer  
  
КОНТЕКСТ:  
- FastAPI приложение  
- SQLAlchemy async  
- PostgreSQL 15  
- Pydantic v2  
  
ЗАДАЧА:  
Напиши endpoint GET /users с пагинацией  
  
ОГРАНИЧЕНИЯ:  
- Не использовать sync код  
- Не использовать raw SQL  
- Максимум 50 записей на страницу  
  
ФОРМАТ:  
\`\`\`python  
\# код с type hints

  
\#\#\# Пример 3: Промпт с примерами (few-shot)

ЗАДАЧА: Конвертируй описание в SQL запрос

ПРИМЕРЫ: "все пользователи" → SELECT * FROM users "активные за неделю" → SELECT * FROM users WHERE last_login > NOW() - INTERVAL '7 days' "топ 5 по заказам" → SELECT * FROM users ORDER BY orders_count DESC LIMIT 5

ВХОД: "неактивные более месяца с email на gmail"

ВЫХОД:

  
\#\# Роль  
  
\#\#\# Когда использовать  
  
- Нужна специфическая экспертиза  
- Важен определённый стиль ответа  
- Требуются ограничения поведения  
  
\#\#\# Примеры ролей

Пример 1: Технический эксперт "Ты senior Python developer с 10-летним опытом в финтехе. Специализация: высоконагруженные системы, безопасность."

Пример 2: Код-ревьюер "Ты строгий код-ревьюер. Фокус: безопасность, производительность. Стиль: прямой, без похвалы, только проблемы."

Пример 3: Учитель "Ты преподаватель Python для начинающих. Объясняй просто, с примерами. Избегай жаргона."

  
\#\#\# Антипаттерн: конфликтующие роли

Плохо: "Ты эксперт и новичок одновременно" "Ты строгий, но дружелюбный критик"

Хорошо: "Ты эксперт, объясняющий концепцию новичку" "Ты критик, указывающий на проблемы конструктивно"

  
\#\# Контекст  
  
\#\#\# Что включать  
  
- Технологии и версии  
- Ограничения окружения  
- Релевантный код  
- Бизнес-контекст (если влияет на решение)  
  
\#\#\# Что НЕ включать  
  
- Нерелевантный код  
- Историю проекта  
- Очевидные факты ("Python — язык программирования")  
  
\#\#\# Примеры

Пример 1: Технический контекст "КОНТЕКСТ:

• Python 3.11, FastAPI 0.100+

• База: PostgreSQL 15 + asyncpg

• Кэш: Redis 7

• Деплой: Kubernetes

• Нагрузка: 1000 RPS"

Пример 2: Контекст данных "КОНТЕКСТ:

• Датасет: 1M строк, 50 колонок

• Формат: Parquet

• Память: ограничение 8GB

• Целевая переменная: churn (binary)"

Пример 3: Контекст кода "КОНТЕКСТ: Существующий интерфейс:

class Repository(Protocol):  
    async def get(self, id: int) -\> Entity | None: ...  
    async def save(self, entity: Entity) -\> Entity: ...

Нужно добавить метод, соответствующий стилю."

  
\#\# Задача  
  
\#\#\# Правило: одна задача — один промпт

Плохо: "Напиши код, объясни его, добавь тесты и задокументируй"

Хорошо: Промпт 1: "Напиши функцию валидации email" Промпт 2: "Объясни логику функции $код$" Промпт 3: "Напиши pytest тесты для $код$"

  
\#\#\# Формулировка задачи  
  
Глагол + объект + (опционально) уточнение

Пример 1: Чёткая задача "Напиши функцию" — что делаем "валидации email" — объект "по RFC 5322" — уточнение

Пример 2: Размытая → чёткая Плохо: "Сделай что-нибудь с данными" Хорошо: "Удали дубликаты из DataFrame по колонке 'id'"

Пример 3: Составная → декомпозированная Плохо: "Создай API для пользователей" Хорошо: "Создай endpoint POST /users для регистрации"

  
\#\# Ограничения  
  
\#\#\# Типы ограничений  
  
1. \*\*Что НЕ делать\*\*  
2. \*\*Лимиты\*\* (длина, количество)  
3. \*\*Исключения\*\* (технологии, подходы)  
  
\#\#\# Примеры

Пример 1: Функциональные "НЕ ДЕЛАТЬ:

• Не обрабатывать файлы > 100MB

• Не использовать многопоточность

• Не модифицировать входные данные"

Пример 2: Технологические "НЕ ИСПОЛЬЗОВАТЬ:

• Внешние библиотеки (только stdlib)

• async/await

• Классы (только функции)"

Пример 3: Стилистические "НЕ ВКЛЮЧАТЬ В ОТВЕТ:

• Объяснения

• Альтернативные варианты

• Комментарии в коде"

  
\#\# Формат  
  
\#\#\# Явное указание формата

Пример 1: JSON "ФОРМАТ:

\{  
  'result': str,  
  'confidence': float,  
  'errors': list$str$  
\}  
\`\`\`"  
  
Пример 2: Markdown  
"ФОРМАТ:  
\#\# Проблема  
$описание$  
  
\#\# Решение  
\`\`\`python  
$код$

Тесты

$тесты$  
\`\`\`"  
  
Пример 3: Список  
"ФОРМАТ:  
1. $проблема$: $решение$  
2. ...  
Максимум 5 пунктов."

Метрика качества промпта

Специфичность промпта:

$S = \\frac\{N\_\{constraints\}\}\{N\_\{interpretations\}\}$

где:

• $N\_\{constraints\}$ — число явных требований

• $N\_\{interpretations\}$ — число возможных интерпретаций

Пример расчёта:  
  
Промпт: "Напиши функцию обработки данных"  
- Требования: 1 (функция)  
- Интерпретации: 100+ (какие данные? какая обработка?)  
- S ≈ 0.01 — плохо  
  
Промпт: "Напиши функцию: вход — CSV строка,  
         выход — dict, разделитель — запятая,  
         первая строка — заголовки"  
- Требования: 4  
- Интерпретации: ~5 (обработка ошибок, кодировка)  
- S ≈ 0.8 — хорошо