Структура промта для DeepSeek: как получать точный результат от первой попытки

Структура промта для DeepSeek: как получать точный результат от первой попытки

Разбор чёткой формулы — роль, контекст, задача, формат, ограничения — с примерами для кода, текстов, анализа и рассуждений. Без проб и ошибок.

Роль + Контекст Задача + Формат Ограничения + Примеры Итерация

Почему 90% промтов дают мусор

DeepSeek — модель рассуждения. Она не «угадывает» намерение, а восстанавливает логику из того, что вы написали. Если в промте нет структуры, модель заполняет пробелы самой — и часто не так, как нужно вам.

Типичный слабый промт: «Напиши функцию для парсинга JSON». Нет роли, нет контекста входных данных, нет требований к обработке ошибок, нет формата ответа. Модель выдаст рабочий, но хрупкий код.

Правило: каждая мелочь, которую вы не указали — модель решит за вас. Цель промта — убрать свободу интерпретации там, где она вредна, и оставить её там, где нужен креатив.

Формула сильного промта

1Роль: кто вы — эксперт, ревьюер, архитектор?
2Контекст: входные данные, ограничения среды, цель.
3Задача: чёткий глагол — написать, рефакторить, объяснить, сравнить.
4Формат: код, таблица, JSON, маркдаун, пошаговый план.
5Ограничения: что не делать, лимиты, стиль, безопасность.

Пять блоков — пять уровней контроля

Роль

Задаёт линзу восприятия. «Ты — старший бэкенд-инженер с 10-летним опытом на Go и распределённых системах» работает лучше «Ты — программист». Роль включает релевантные паттерны в весах модели.

Контекст

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

Задача

Один глагол-императив. Не «помоги с…», а «Напиши», «Рефакторь», «Найди баг», «Сравни», «Объясни». Если действий несколько — разбивай на подзадачи или используй цепочку промтов.

Формат

Жёсткая спецификация выхода: «Только код, без комментариев», «JSON по схеме {…}», «Таблица с колонками A, B, C», «Маркдаун с заголовками H2/H3». Формат экономит время на постобработку.

Ограничения

Что запрещено: «Не используй regex», «Не более 50 строк», «Никаких внешних библиотек», «Не выдумывай факты». Отрицательные инструкции часто важнее положительных — они срезают ложные ветви генерации.

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

Chain of Thought

Пошаговое рассуждение

Добавьте: «Рассуждай шаг за шагом перед ответом» или «Выводи промежуточные выводы в теге <thinking>». DeepSeek-r1 делает это нативно, но явная инструкция усиливает эффект на сложных задачах.

«Перед решением разложи задачу на подзадачи. Выводи каждый шаг в блоке: <step N>…</step> Итоговый ответ — после <final>.»

Self-Consistency

Голосование нескольких путей

Для критических задач: «Сгенерируй 3 независимых решения, сравни их, верни лучшее с обоснованием». Модель сама производит ансамбль и выбирает консистентный результат.

«Создай 3 варианта архитектуры. Оцени каждый по: сложности, производительности, поддержке. Верни сравнительную таблицу и рекомендацию.»

Few-Shot / Примеры

Обучение в контексте

2-5 пар «вход — идеальный выход» перед основной задачей. Работает для стиля, формата, логики извлечения. Примеры должны быть разнообразными, но единообразными в структуре.

Пример 1: Вход: {…} Выход: {…} — Пример 2: Вход: {…} Выход: {…} — Теперь обработай: Вход: {…}

Meta-Prompting

Промт, пишущий промты

«Ты — инженер промтов. Напиши промт для задачи X по формуле Роль+Контекст+Задача+Формат+Ограничения. Верни готовый промт». Получаете шаблон для повторного использования.

«Ты — эксперт по промт-инженерии. Составь промт для: [описание задачи]. Используй структуру: 1. Роль 2. Контекст 3. Задача 4. Формат 5. Ограничения Верни только промт.»

Готовые шаблоны для частых сценариев

Код / Рефакторинг
Роль: Ты —Senior Rust-разработчик, эксперт по zero-cost abstractions и unsafe.
Контекст: Есть функция parse_config (приложена ниже). Она падает на невалидном UTF-8. Нужно сделать устойчивой к любым байтам, вернуть Result<Config, ParseError>.
Задача: Рефакторь функцию. Добавь валидацию, логирование через tracing, unit-тесты.
Формат: Только код файла lib.rs. Без объяснений. Импорты сверху.
Ограничения: Не используй anyhow/eyre. Только std + thiserror. MSRV 1.70. Не меняй публичный API.
Анализ / Сравнение
Роль: Ты — техлид, выбирающий БД для write-heavy сервиса (50k ops/sec).
Контекст: PostgreSQL 15 vs CockroachDB vs ScyllaDB. Данные — события аналитики, append-only, TTL 90 дней. Команда знает PostgreSQL, нет опыта с остальными.
Задача: Сравни по: latency p99, операционная сложность, стоимость владения, миграция схемы, нагрузочное тестирование.
Формат: Таблица Markdown + краткий вердикт (3 предложения).
Ограничения: Не маркетинговый флаф. Цитируй публичные бенчмарки с указанием источника. Укажи риски для нашего стека.
Тексты / Контент
Роль: Ты — технический редактор DevRel-блога. Стиль: лаконично, по делу, без воды, с уважением к времени читателя.
Контекст: Статья о миграции с REST на gRPC. Аудитория — бэкенд-инженеры middle/senior. Цель: показать плюсы/минусы, дать чек-лист миграции.
Задача: Напиши структуру статьи (H2/H3), лид-абзац (2-3 фразы), 5 ключевых тезисов для каждого раздела.
Формат: Markdown. Заголовки — H2. Тезисы — маркированный список.
Ограничения: Не более 1500 слов итогово. Никаких «в современном мире». Примеры только из реального опыта (указывай псевдонимы компаний).
Отладка / Поиск бага
Роль: Ты — инженер по надежности (SRE), специализирующийся на distributed tracing.
Контекст: Сервис на Go (приложен main.go + Dockerfile). Симптом: p99 latency скакает с 50ms до 2s каждые ~17 минут. Нет ошибок в логах. CPU/MEM ровные. Трассировка Jaeger показывает gap в спане DB query.
Задача: Предложи 5 гипотез причины в порядке вероятности. Для каждой — как проверить за 5 минут.
Формат: Нумерованный список: Гипотеза → Проверка → Ожидаемый признак.
Ограничения: Не предлагай «добавить логи» — их уже много. Фокус на системных причинах: GC, connection pool, cron, network, kernel.

Цикл итерации: от черновика к продакшену

1

Черновик

Напишите промт по формуле. Не идеализируйте — цель: получить базовый ответ.

2

Оценка

Что не так: формат, глубина, стиль, галлюцинации, упущенный контекст.

3

Уточнение

Добавьте недостающее в следующий промт: «Исправь: добавь обработку X, убери Y, измени формат на Z».

4

Фиксация

Сохраните итоговый промт как шаблон. В следующий раз начните с него, а не с чистого листа.

✓
Делайте: одно изменение за итерацию. Меняйте роль, потом формат, потом ограничения — по одному.
✓
Делайте: просите модель критиковать свой же ответ: «Что в твоём ответе слабое? Исправь».
✗
Не делайте: пишите новый промт с нуля каждый раз. Накапливайте библиотеку шаблонов.
✗
Не делайте: ждите идеального результата с первой попытки. Итерация — нормальный процесс, а не провал.

Ловушки, в которые попадают даже опытные

1

Перегруз контекстом

Скидывание 5000 строк кода «для контекста» забивает окно внимания. Лучше: краткое описание архитектуры + релевантный фрагмент 50-100 строк. Используйте RAG или многошаговую подачу для больших кодовых баз.

2

Смешение задач

«Напиши код и напиши к нему документацию и сделай тесты и объясни архитектуру» — модель потеряет фокус. Разбивайте: отдельный промт на код, на тесты, на доки. Каждый — со своей ролью.

3

Игнорирование формата

Без явного формата модель выберет «средний по больнице» — часто маркдаун с лишними пояснениями. Укажите: «Только JSON», «Только код», «Без вводных фраз». Экономит часы парсинга.

4

Доверие без верификации

DeepSeek уверенно галлюцинирует несуществующие API, устаревшие методы, неверные сигнатуры. Правило: любой код — через компилятор/линтер, любые факты — через первоисточник. Модель — ускоритель, не оракул.

5

Скрытые предположения

«Сделай быстро» — что значит быстро? O(1)? <10ms? Без аллокаций? Модель подставит своё понимание. Заменяйте прилагательные на метрики: «latency p99 < 50ms», «0 аллокаций на hot path».

6

Отсутствие негативных примеров

Показать, чего НЕ надо делать, часто эффективнее положительных примеров. Добавьте блок «Anti-patterns: не делай так…» с 2-3 конкретными ошибками, которые модель любит повторять.

Главный навык — не знание промтов, а умение думать структурно

Промт-инженерия — не магия слов. Это дисциплина: чётко сформулировать задачу, выделить существенные ограничения, предвидеть неопределённость и дать модели точный вектор. Те же навыки делают вас лучше инженером, архитектором, коммуникатором.

Структура Роль → Контекст → Задача → Формат → Ограничения работает не только для DeepSeek. Она универсальна: для любой LLM, для ТЗ подрядчику, для тикета в Jira, для код-ревью, для делегирования задаче.

5
Блоков
∞
Комбинаций
1
Навык

Сохраните структуру — используйте её каждый раз

Скопируйте чек-лист ниже. Вставьте в заметки, IDE snippet, системный промт. Следующий раз начните не с пустого экрана, а с каркаса, который работает.

# TEMPLATE: DeepSeek Prompt Structure [ROLE] Ты — [конкретная роль с экспертизой и фокусом]. [CONTEXT] Вход: [что на входе, формат данных, окружение]. Цель: [зачем это нужно, какой результат ожидается]. Ограничения среды: [версии, стек, лимиты, команда]. [TASK] [Один глагол-императив: Напиши / Рефакторь / Найди / Сравни / Объясни]. Подзадачи (если сложно): 1. … 2. … [FORMAT] Выход: [только код / JSON по схеме / Таблица / Маркдаун / План]. Структура: [детали формата: заголовки, поля, порядок]. [CONSTRAINTS] Не делай: [конкретные запреты: библиотеки, паттерны, предположения]. Стиль: [лаконично / подробно / академично / practically]. Безопасность: [не выдумывать / не раскрывать секреты / валидировать вход]. [EXAMPLES — опционально] Пример 1: Вход → Выход Пример 2: Вход → Выход [THINKING — для сложных задач] Рассуждай пошагово в <thinking>…</thinking>. Итог — после <final>.