Prompt Engineering

Prompt Engineering

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

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

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

Goldilocks zone (правильная высота): Промпт между двумя крайностями:

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

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

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

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

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

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

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

Выбор тегов

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

Примеры (не обязательный набор):

• `` — контекст, ситуация, предпосылки
• `` — что нужно сделать
• `` — ограничения
• `` — few-shot примеры
• `` — формат ответа
• `` — специфичные знания домена
• `` — критерии оценки

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

Роль полезна, когда нужна конкретная точка зрения:

• Эксперт в домене
• Критик/ревьюер
• Пользователь системы

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

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

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

Вместо:

Отвечай кратко.

Лучше:

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

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

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

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

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

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

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

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

Плохо:

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

Хорошо:

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

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

Не добавлять:

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

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

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

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

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

Чеклист

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

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Bbar0n234
• Source: Bbar0n234/learnflow-ai
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.