Prompt Engineering: как разговаривать с LLM

prompt-engineeringllmaiproductivity

Промпт-инжиниринг звучит как маркетинговый термин, но за ним стоит вполне конкретный навык: умение формулировать запросы к LLM так, чтобы получать предсказуемые, качественные результаты. После нескольких месяцев ежедневной работы с разными моделями — от локальной Llama до Claude — я собрал набор техник, которые реально работают.

Zero-shot vs Few-shot

Zero-shot — это когда вы просто даёте задачу без примеров:

Преобразуй этот текст в JSON: Сервер nginx, порт 8080, SSL включён

Модель попробует угадать формат. Иногда угадает, иногда нет. Это лотерея.

Few-shot — вы даёте 1-3 примера, и модель понимает паттерн:

Преобразуй описание сервера в JSON.

Пример 1:
Вход: Сервер apache, порт 80, SSL выключен
Выход: {"server": "apache", "port": 80, "ssl": false}

Пример 2:
Вход: Сервер postgres, порт 5432, SSL включён
Выход: {"server": "postgres", "port": 5432, "ssl": true}

Теперь преобразуй:
Вход: Сервер nginx, порт 8080, SSL включён

Разница в качестве — колоссальная. Few-shot особенно важен для локальных моделей, которые без примеров чаще ошибаются с форматом.

Chain-of-Thought: пусть модель думает

Chain-of-Thought (CoT) — техника, при которой вы просите модель рассуждать пошагово, прежде чем дать ответ. Это не просто «для красоты» — исследования показывают, что пошаговое рассуждение реально улучшает точность ответов на сложных задачах.

Схема паттернов промптинга — zero-shot, few-shot, chain-of-thought и их комбинации

Без CoT:

Какой размер VRAM нужен для запуска Llama 3 70B в Q4_K_M?

Модель может дать приблизительный ответ или ошибиться.

С CoT:

Какой размер VRAM нужен для запуска Llama 3 70B в Q4_K_M?
Рассуждай пошагово:
1. Сколько параметров в модели
2. Сколько бит на параметр при Q4 квантизации
3. Какой overhead на KV-cache и runtime
4. Итоговый расчёт

Модель выдаст развёрнутое рассуждение: 70B параметров * ~4.5 бит (Q4_K_M не ровно 4) / 8 = ~39 ГБ, плюс 2-4 ГБ overhead. Итого ~42-43 ГБ. И этот ответ будет точнее.

Простой трюк — добавить в конец промпта фразу: Let's think step by step или Давай разберём по шагам. Работает удивительно хорошо.

System Prompt: задаём контекст

System prompt — это инструкция, которая определяет поведение модели на протяжении всего диалога. Плохой system prompt — пустой. Хороший — конкретный.

Плохо:

Ты — полезный ассистент.

Хорошо:

Ты — senior DevOps-инженер с 10-летним опытом. Специализация: Linux, Docker, Kubernetes, CI/CD.

Правила:
- Отвечай кратко и по делу
- Всегда приводи примеры команд или конфигов
- Если вопрос неоднозначный — уточни, прежде чем отвечать
- Указывай потенциальные проблемы безопасности
- Формат: сначала краткий ответ (1-2 предложения), потом детали
- Если не знаешь — скажи прямо, не выдумывай

Чем конкретнее роль и правила, тем предсказуемее поведение модели. Я держу набор system prompt’ов для разных задач в отдельных файлах и подключаю нужный через Modelfile в Ollama.

Structured Output: JSON Mode

Когда результат нужен в машиночитаемом формате, важно явно это указать:

Проанализируй этот nginx-конфиг и верни результат в формате JSON.

Структура ответа:
{
  "server_name": "строка",
  "listen_port": число,
  "ssl_enabled": boolean,
  "locations": [{"path": "строка", "proxy_pass": "строка"}],
  "issues": ["список проблем, если есть"]
}

Верни ТОЛЬКО JSON, без пояснений и markdown-обёртки.

Конфиг:
server {
    listen 80;
    server_name example.com;
    location / {
        proxy_pass http://localhost:3000;
    }
}

Ключевые моменты:

  • Дайте точную схему ожидаемого JSON
  • Укажите типы данных
  • Попросите вернуть «ТОЛЬКО JSON» — иначе модель обернёт его в пояснения
  • Для OpenAI-совместимых API используйте response_format: {"type": "json_object"}

Role Prompting

Назначение роли — не просто косметика. Разные роли активируют разные «области знаний» модели:

Выступи в роли security-аудитора. Проанализируй этот Dockerfile
и найди все потенциальные уязвимости. Для каждой укажи:
- Уровень критичности (high/medium/low)
- Описание проблемы
- Как исправить

Без роли модель даст общий обзор. С ролью security-аудитора — сфокусируется на уязвимостях, которые иначе могла бы пропустить.

Промпты для кодогенерации

Вот паттерн, который даёт стабильно хорошие результаты:

Плохо:

Напиши скрипт для бэкапа

Хорошо:

Напиши bash-скрипт для инкрементального бэкапа PostgreSQL-базы.

Требования:
- Использовать pg_dump с форматом custom (-Fc)
- Сжатие gzip уровня 6
- Ротация: хранить последние 7 ежедневных и 4 еженедельных бэкапа
- Логирование в /var/log/backup.log с таймстемпами
- При ошибке — отправить уведомление через curl в Telegram
- Переменные окружения для чувствительных данных (пароль, токен бота)

Окружение: Ubuntu 22.04, PostgreSQL 15, bash 5.x

Формула: Язык + Задача + Требования + Ограничения + Окружение.

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

Когда модель помогает дебажить, контекст решает всё:

Помоги разобраться с ошибкой.

Что делаю: запускаю Ansible playbook для деплоя на Ubuntu 22.04
Команда: ansible-playbook -i inventory.yml playbooks/deploy.yml
Ошибка:
fatal: [production]: FAILED! => {"msg": "Using a SSH password instead
of a key is not possible because Host Key checking is enabled"}

Что уже пробовал:
- Проверил ssh-ключ — подключение по SSH вручную работает
- В ansible.cfg есть host_key_checking = False

Нужно: понять корневую причину и исправить

Схема пошагового рассуждения Chain-of-Thought — от вопроса через промежуточные шаги к ответу

Формула: Контекст + Действие + Ошибка + Что пробовал + Что нужно.

Промпты для документации

Напиши docstring для этой Python-функции в формате Google Style.
Включи описание, аргументы с типами, возвращаемое значение,
возможные исключения и пример использования.

def retry_request(url, max_retries=3, backoff_factor=0.5, timeout=30):
    ...

Борьба с галлюцинациями

LLM уверенно врут. Вот как минимизировать это:

  1. Просите источники. «Укажи, откуда эта информация» — модель хотя бы задумается.

  2. Пошаговое рассуждение. CoT заставляет модель проверять свою логику.

  3. Ограничивайте область. «Отвечай ТОЛЬКО на основе предоставленного контекста» — запрещает додумывать.

  4. Калибровочные вопросы. Задайте вопрос, ответ на который вы знаете. Если модель ошибётся — к остальным ответам тоже стоит отнестись скептически.

  5. Формулируйте чётко. Чем более расплывчатый вопрос, тем больше простора для галлюцинаций.

# Плохо — широкий вопрос, провоцирующий галлюцинации
Расскажи про настройку Kubernetes

# Хорошо — конкретный, проверяемый вопрос
Как настроить HPA (Horizontal Pod Autoscaler) в Kubernetes 1.28
для деплоймента, чтобы скейлить по CPU utilization > 70%?
Покажи YAML-манифест.

Temperature и Top-p

Два параметра, которые влияют на «креативность» модели:

Temperature (0.0 — 2.0):

  • 0.0-0.3 — детерминированные ответы, минимум вариативности. Для кода, конфигов, фактических вопросов.
  • 0.5-0.7 — баланс. Для рефакторинга, ревью, объяснений.
  • 0.8-1.2 — творческий режим. Для генерации текстов, брейншторма.

Top-p (0.0 — 1.0):

  • 0.1 — очень консервативно, модель выбирает из самых вероятных токенов.
  • 0.9 — широкий выбор, более разнообразные ответы.

Практическое правило: настраивайте что-то одно. Либо temperature, либо top-p. Крутить оба сразу — непредсказуемо.

Версионирование промптов

Когда промпты становятся частью пайплайна, их нужно версионировать как код:

prompts/
├── code-review/
│   ├── v1.txt
│   ├── v2.txt      # добавлен security-чеклист
│   └── v3.txt      # оптимизирован для Llama 3
├── docs-generation/
│   └── v1.txt
└── debug-helper/
    ├── v1.txt
    └── v2.txt      # добавлен формат "что пробовал"

Каждый промпт — в Git, с описанием изменений в коммите. Когда работаете в команде, это спасает от «а какой промпт давал хорошие результаты в прошлый раз?».

Шаблоны промптов

Для повторяющихся задач имеет смысл создать шаблоны:

REVIEW_TEMPLATE = """
Проведи code review следующего {language}-кода.

Контекст: {context}

Проверь:
1. Баги и потенциальные ошибки
2. Производительность
3. Безопасность
4. Читаемость и стиль
5. Соответствие best practices для {language}

Для каждого замечания укажи строку, уровень серьёзности
и предложи исправление.

Код:
```{language}
{code}

"""


## Главный вывод

Промпт-инжиниринг — это не магия и не «правильные слова». Это структурированный подход к коммуникации с моделью. Конкретность, контекст, примеры, формат — вот четыре столпа хорошего промпта. Модели становятся умнее с каждым поколением, и многие хитрости со временем станут ненужными. Но навык чётко формулировать задачу полезен не только для LLM — он полезен вообще для любой коммуникации. С коллегами, с документацией, с самим собой.

© 2026 Terminal Notes. Built with SvelteKit.