Промты для DeepSeek: как писать запросы, которые включают глубокое рассуждение

Промты для DeepSeek: как писать запросы, которые включают глубокое рассуждение

DeepSeek — модель с явным рассуждением. Качество ответа зависит от того, насколько чётко промт задаёт контекст, цель и формат мышления. Материал разбирает структуру работающих промтов, даёт готовые шаблоны и показывает, где теряется качество.

Рассуждение vs ответ Четыре блока промта Шаблоны под задачи Ошибки и фиксы
Почему DeepSeek иначе

Модель думает перед ответом

В отличие от чат-моделей, генерирующих токен за токеном, DeepSeek-R1 производит скрытую цепочку рассуждений (Chain-of-Thought). Промт должен не просто спросить — он должен задать алгоритм мышления.

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

Ключевой принцип

Промт = инструкция для мыслителя

Хороший промт для DeepSeek описывает не желаемый текст ответа, а процесс получения этого ответа.

Задайте роль, контекст, критерии качества и формат итогового сообщения — модель выполнит остальное в скрытом блоке рассуждения.

Четыре обязательных блока рабочего промта

Роль и перспектива

Кто отвечает: эксперт по безопасности, senior-разработчик, редактор научно-популярных текстов. Роль задаёт лексику, глубину и критерии самопроверки.

Контекст и ограничения

Входные данные, аудитория, длина ответа, запрещённые подходы, формат вывода (JSON, таблица, маркированный список). Чем точнее рамки, тем меньше галлюцинаций.

Алгоритм рассуждения

Явная инструкция: «разложи на подзадачи», «проверь каждое утверждение на противоречия», «приведи контрпримеры», «оцени уверенность в %». Это запускает глубокий CoT.

Формат итогового сообщения

Что именно выводить пользователю: только заключение, краткое резюме + ключевые аргументы, полное рассуждение с пометами неопределённости. Разделяет «мышление» и «ответ».

Шаблоны промтов под типовые задачи

1

Анализ кода / рефакторинг

Роль: Senior-инженер, специализирующийся на архитектуре и производительности. Контекст: Код ниже — часть продакшн-системы. Требуется сохранить API, улучшить читаемость и убрать узкие места. Алгоритм: 1. Выяви 3 главных риска (безопасность, сложность, производительность). 2. Предложи рефакторинг по приоритету ROI. 3. Для каждого изменения: обоснование + оценка риска регресса. 4. Финальный код с комментариями «почему так». Формат: Markdown. Секции: Риски → План → Код → Чек-лист ревью. Вход: [вставить код]
2

Генерация технической спецификации

Роль: Техлид, пишущий RFC для распределённой команды. Контекст: Задача — [описание в 2-3 предложениях]. Стек: [стек]. Ограничения: [latency, бюджет, команда]. Алгоритм: 1. Сформулируй проблему и цель успеха (SMART). 2. Перечисли альтернативы с плюсами/минусами. 3. Выбери оптимальную, аргументируй через trade-offs. 4. Опиши API, схему данных, миграцию, риски, план отката. Формат: RFC-структура: Summary, Motivation, Design, Alternatives, Risks, Rollout. Вход: [описание задачи]
3

Обучение / объяснение сложной темы

Роль: Преподаватель, объясняющий [тема] студентам [уровень]. Контекст: Аудитория знает [база], не знает [пробелы]. Цель — рабочее понимание, а не заучивание. Алгоритм: 1. Аналогия из жизни (1 абзац). 2. Минимальная рабочая модель (3-5 компонентов). 3. Пошаговый разбор примера «от простого к сложному». 4. Типичные ошибки и почему они возникают. 5. Упражнение для самопроверки. Формат: Структурированный урок с заголовками H2/H3, код-блоками, callout-блоками «⚠ Ошибка», «💡 Инсайт». Вход: [тема + уровень аудитории]
4

Принятие решения / выбор варианта

Роль: Стратег, оценивающий опции по критериям. Контекст: Нужно выбрать между [вариант А] и [вариант Б]. Критерии: [список с весами]. Алгоритм: 1. Нормализуй критерии к единой шкале. 2. Оцени каждый вариант по каждому критерию с уверенностью. 3. Построй взвешенную матрицу. 4. Проведи sensitivity analysis: при каком изменении весов выбор сменится? 5. Сформулируй рекомендацию + условие пересмотра. Формат: Таблица оценок → Анализ чувствительности → Рекомендация. Вход: [варианты + критерии + веса]

Приём «Рассуждение в двух проходах»

Паттерн для сложных задач

Сначала — план, потом — выполнение

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

Промт 1 (планирование): «Ты — эксперт по [область]. Задача: [описание]. Не решай задачу. Напиши подробный план рассуждения: этапы, проверки, ветвления, критерии остановки. Выведи как нумерованный список.» Промт 2 (исполнение): «Выполни план выше. На каждом этапе: кратко опиши рассуждение, затем дай промежуточный результат. В конце — итоговый ответ в формате [формат].»

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

Вариация: Few-Shot CoT

Дай примеры мышления

Вставь 1-2 примера пар «задача → пошаговое рассуждение → ответ» перед реальной задачей. Модель подхватит стиль и глубину.

Пример few-shot блока: ### Пример 1 Задача: Оценить риск утечки в коде. Рассуждение: 1. Найти все входы внешних данных… 2. Проверить санитизацию… 3. Оценка: HIGH — нет валидации на строке 42. Ответ: HIGH, причина: … ### Пример 2 … ### Твоя задача [вставить задачу]

Где промты ломаются: типичные провалы и как их чинить

✗Слишком общий запрос

«Напиши код для авторизации» — модель выберет случайный стек, пропустит безопасность, не спросит контекст.

✓Фикс: рамки + стек + угрозы

«Node.js 20, Express, JWT в httpOnly cookie. Угрозы: CSRF, XSS, replay. Нужна регистрация, логин, refresh, logout. Выведи файлы routes, middleware, config».

✗Нет критериев качества

«Сделай код быстрее» — модель может сломать читаемость, убрать проверки, ввести баги. Нет метрики успеха.

✓Фикс: измеримые ограничения

«Сократи p99 latency до <100мс на нагрузке 1k rps. Не меняй публичный API. Покрытие тестами ≥90%. Покажи профиль до/после».

✗Игнорирование неопределённости

Модель выдаёт уверенный ответ там, где данных мало. Галлюцинирует факты, выдумывает API.

✓Фикс: требовать калибровку

«Для каждого факта укажи уверенность 0-100%. Если <70% — пометь «требует проверки» и предложи, как проверить».

✗Один гигантский промт

Пытаются засунуть контекст, инструкции, примеры, данные в одно сообщение. Контекст переполняется, внимание размывается.

✓Фикс: цепочка промтов

Разбей на этапы: 1) сбор требований → 2) план → 3) реализация по модулям → 4) ревью. Каждый шаг — отдельное сообщение с накопленным контекстом.

Продвинутые приёмы для DeepSeek-R1

Self-Consistency投票

Запусти 3-5 независимых рассуждений с температурой 0.6-0.8, затем попроси агрегировать: «Вот 5 вариантов решения. Найди общие шаги, выяви расхождения, выбери лучшее объединённое решение».

Работает для: архитектурных решений, математических доказательств, планирования.

Constitutional AI промт

Задай «конституцию» — список принципов, которые модель должна соблюдать при рассуждении (например: «не выдумывай библиотеки», «признавай незнание», «проверяй边界 случаи»). Вставь в системный промт или начало диалога.

Работает для: снижения галлюцинаций, соблюдения стиля компании, безопасности.

Tree-of-Thoughts (упрощённый)

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

Работает для: открытых задач, где нет однозначного алгоритма.

Structured Output Enforcement

Требуй строгую схему (JSON Schema / Pydantic-описание) и добавляй: «Если не уверен в поле — поставь null и добавь комментарий в _meta.uncertainty». Парсинг не упадёт, неопределённость сохраняется.

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

Шпаргалка: минимальный рабочий промт за 30 секунд

1
Роль
Кто думает
2
Контекст
Данные и рамки
3
Алгоритм
Как рассуждать
4
Формат
Что выдать
[Роль] [Контекст + входные данные] [Алгоритм рассуждения: шаги, проверки, критерии] [Формат ответа] — Задача: [конкретная задача]

Как проверить промт перед отправкой

1

Тест «Новичок в команде»

Прочитай промт так, будто видишь его впервые. Понятно ли, что нужно сделать, без знания контекста в твоей голове? Если нет — добавь недостающее.

2

Тест «Граничные случаи»

Есть ли в промте инструкция на случай: пустых данных, противоречивых требований, отсутствия информации, ошибок исполнения? Добавь блок «Если что-то не так…».

3

Тест «Один запуск»

Может ли модель выполнить задачу за один проход, не задавая уточняющих вопросов? Если нужен диалог — оформи промт как инструкцию для ассистента, который задаёт вопросы сам.

4

Тест «Обратная совместимость»

Если промт сработает через месяц на новой версии модели — выдаст ли он то же качество? Убери привязки к текущим особенностям (именные параметры, временные хacks).

Главное — не промт, а мышление

Лучшие промты для DeepSeek не «хитрят» — они структурируют твою собственную мысль перед тем, как передать её модели. Когда ты чётко формулируешь роль, контекст, алгоритм проверки и формат ответа, ты сам решаешь задачу наполовину. DeepSeek лишь доносит её до конца с меньшей вероятностью ошибки.

Начни с минимального шаблона из четырёх блоков. Добавляй сложность только там, где простой вариант даёт плохой результат. Качество промта растёт итерациями, а не одной идеальной формулой.