# Prompt Engineering

> Помогает писать системные промпты для LLM. Используй когда нужно написать prompt, system prompt, системный промпт, инструкцию для модели.

- Skill: `bbar0n234/prompt-engineering` (Agent Skill)
- Install (CLI): `npx skillmds@latest add bbar0n234/prompt-engineering`
- Raw SKILL.md: https://api.skillmd.com/api/skills/bbar0n234/prompt-engineering/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: Bbar0n234 (https://skillmd.com/u/bbar0n234)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/bbar0n234/prompt-engineering

---


# Prompt Engineering

## Ключевые принципы

**Язык:** английский по умолчанию. Русский — если явно указано или данные на русском.

**High-signal токены:** Каждый токен промпта должен нести информацию. Attention budget модели конечен — тратить его на сигнал, не на шум. Избегать воды, повторений, очевидных вещей которые модель и так знает.

**Goldilocks zone (правильная высота):** Промпт между двумя крайностями:
- *Слишком низко:* хардкод логики, if-else правила на каждый кейс → хрупкость, сложная поддержка
- *Слишком высоко:* размытые указания, ложное предположение общего контекста → модель не понимает что делать

Оптимум: достаточно специфично для направления поведения, достаточно гибко для применения эвристик в непокрытых кейсах.

**Вытекающие инструкции:** Если из описания задачи логически следуют требования — включай их, даже если заказчик не проговорил явно. Не добавляй только то, что не относится к задаче.

## Структура промпта

### Форматирование: Markdown + XML

- **Markdown** — форматирование текста (списки, bold, italic)
- **XML теги** — семантическое разделение блоков

XML теги двусторонние (`<tag>...</tag>`), что предотвращает смешивание секций.

### Выбор тегов

Теги подбираются под задачу. Имя тега отражает семантику содержимого.

Примеры (не обязательный набор):
- `<background>` — контекст, ситуация, предпосылки
- `<task>` — что нужно сделать
- `<constraints>` — ограничения
- `<examples>` — few-shot примеры
- `<output_format>` — формат ответа
- `<domain_knowledge>` — специфичные знания домена
- `<evaluation_criteria>` — критерии оценки

### Секция role (опционально)

Роль полезна, когда нужна конкретная точка зрения:
- Эксперт в домене
- Критик/ревьюер
- Пользователь системы

Не нужна, если `<background>` уже даёт достаточный контекст.

## Понимание вместо инструкций

Объяснять *как* и *почему*, не только *что*.

**Вместо:**
```
Отвечай кратко.
```

**Лучше:**
```
Целевая аудитория — занятые специалисты.
Им нужен быстрый ответ, не погружение в детали.
```

Когда модель понимает контекст и причины, она лучше справляется с ситуациями, не покрытыми явными инструкциями.

## Итеративный подход

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

1. **Начать минимально** — базовый промпт с задачей и ключевым контекстом
2. **Тестировать на лучшей модели** — увидеть baseline поведения
3. **Добавлять по failure modes** — инструкции и примеры появляются когда модель ошибается в конкретных кейсах
4. **Не over-engineer заранее** — не предугадывать проблемы, решать реальные

## Антипаттерны

### Хардкоды без требований

Не указывать конкретные числа (длина, количество), если заказчик не требовал.

**Плохо:**
```
Напиши описание продукта (3-5 предложений)
```

**Хорошо:**
```
Напиши описание продукта
```

### Нерелевантные инструкции

Не добавлять:
- Ограничения, не относящиеся к задаче
- "Защитные" формулировки без реальной угрозы

### Примеры: laundry list edge cases

Не пихать в `<examples>` список всех возможных edge cases. Вместо этого — курировать **diverse, canonical examples**, которые демонстрируют ожидаемое поведение.

Примеры — "картинки worth a thousand words". Несколько хороших примеров эффективнее десятка правил.

Примеры иллюстрируют паттерн и подход, а не хардкодят единственно верные значения.

## Чеклист

- [ ] Каждый токен несёт сигнал (нет воды, повторений, очевидностей)
- [ ] Промпт в Goldilocks zone (не хардкод, не размытость)
- [ ] Вытекающие из задачи требования включены
- [ ] Нет нерелевантных ограничений
- [ ] Теги подобраны под семантику содержимого
- [ ] Есть объяснение "почему", не только "что"
- [ ] Примеры diverse и canonical, не laundry list edge cases