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

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

Архитектура промта Chain-of-Thought Few-shot шаблоны Контроль формата

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

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

В материале — схема слоёв, готовые шаблоны для типовых сценариев (код, анализ, творчество, рассуждение) и чек-лист самопроверки перед отправкой запроса.

обязательных слоя в рабочем промте

Пропуск слоя = риск ошибки

Четыре слоя промта, которые читает DeepSeek 2.1.0

Слой 1

Роль и стиль

Кто отвечает: эксперт, ревьюер, собеседник, преподаватель. Задаёт тон, глубину, терминологию и границы дозволенного.

Пример: «Ты — старший инженер по бэкенду, пишешь лаконично, без вводных слов, указываешь на риски производительности».

Слой 2

Контекст и входные данные

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

Пример: «Вход: JSON с 1200 записями логов. Поля: timestamp, level, message, service. Задача — найти аномалии за последний час».

Слой 3

Задача с критериями успеха

Что сделать, как оценить качество, что избегать. DeepSeek 2.1.0 лучше следует негативным ограничениям («не используй…») в сочетании с позитивными целями.

Пример: «Найди 3 причину падения конверсии. Критерий: каждая причина — метрика + гипотеза + способ проверки. Не пиши общие фразы вроде «плохой UX»».

Слой 4

Формат и структура ответа

JSON, Markdown, таблица, список, код без пояснений. Указание формата в начале ответа модели экономит токены и исключает «воду».

Пример: «Ответ строго в JSON: {"cause": string, "metric": string, "hypothesis": string, "test": string}[] — массив из 3 объектов. Без комментариев, без markdown».

Chain-of-Thought: заставляем модель рассуждать вслух

DeepSeek 2.1.0 обучена на рассуждениях. Если в промте явно требуется пошаговый вывод мыслей («Рассуждай шаг за шагом» или «Выведи цепочку рассуждений перед финальным ответом»), точность на задачах логики, кода и математики возрастает на 15–30 % по внутренним бенчмаркам.

Важно: не просто просить «подумать», а задать структуру рассуждения. Модель повторяет паттерн, который вы задали.

Шаблон CoT-блока

## Reasoning (обязательно)
1. Problem decomposition — разбей задачу на подзадачи
2. Assumptions — перечисли явные предположения
3. Step-by-step derivation — выведи каждый шаг
4. Verification — проверь результат на противоречия
5. Confidence — оцови уверенность 0–100%

## Final Answer
[твой формат ответа из Слоя 4]

Схема: как CoT меняет путь токенов

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

Паттерн 1

Генерация и рефакторинг кода

DeepSeek 2.1.0 хорошо пишет код, если задать: язык, фреймворк, стиль, ограничения производительности, формат вывода (только код / код + тесты / diff).

# Роль
Ты — senior TypeScript-разработчик. Пишешь production-ready код: строгая типизация, никаких any, обработка ошибок, JSDoc для публичных API.

# Контекст
Есть функция fetchUserData(id: string): Promise<User>. Нужна обёртка с кэшем (TTL 5 мин), ретраями (3 раза, экспоненциальный бэкофф) и таймаутом 8 с.

# Задача
Напиши wrapper-функцию withResilience. Критерий: код проходит tsc —strict, нет утечек памяти, логирует ошибки в консоль.

# Формат
Только код в одном блоке «`ts … «`. Без пояснений.

Анализ данных и метрик

Модель видит сырые числа — отдаёт инсайты. Ключ: перечислить колонки, задать вопросы, требовать гипотезы с метриками проверки.

«Данные: CSV, 50к строк, колонки: date, channel, spend, revenue, clicks. Задача: найди 3 канала с аномальным ROAS за последнюю неделю. Ответ: JSON [{channel, roas, deviation_pct, hypothesis, test_plan}]. CoT обязателен.»

Творческие тексты и копирайтинг

Стиль задаётся через роли + референсы («в тоне Дойля», «как release notes Linear»). Ограничения длины и запрещённые клише убирают «воду».

«Роль: UX-писатель SaaS. Тон: дружелюбный, конкретный, без маркетинговой воды. Задача: 3 варианта заголовка для фичи «автосохранение черновиков». Длина ≤ 45 символов. Запрещено: «революционный», «лучший», «инновационный». Формат: нумерованный список.»

Самокритика и улучшение ответа

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

Проход 1: [основной промт]
Проход 2: «Провери свой ответ по пунктам: 1) выполнены все требования формата? 2) нет ли фактических ошибок? 3) убраны ли запрещённые фразы? 4) код компилируется? Выведи список найденных проблем, затем исправленный ответ.»

Какую стратегию выбрать: навигатор по задачам

Если задача…

…требует точного факта или расчёта

→ Добавь блок CoT с этапом «Verification» и требуй в ответе поле confidence (0–100). Модель редко преувеличивает уверенность, когда просит её оценить сама.

Если задача…

…творческая или открытая

→ Задай 3–5 вариантов с разным углом (консервативный, сбалансированный, смелый). Потребуй самокритику каждого варианта. Выбирай лучший в отдельном промте.

Если задача…

…длинная и многошаговая

→ Разбей на цепочку под-промтов. Передавай результат предыдущего шага как контекст следующего. Используй формат JSON для передачи между шагами — модель не теряет структуру.

Если задача…

…требует соблюдения стиля бренда

→ Приложи 3–5 примеров «как надо» и 2–3 «как нельзя» в блоке Few-shot. DeepSeek 2.1.0 улавливает паттерн стиля лучше по позитивным + негативным примерам, чем по вербальному описанию.

Few-shot: покажи, а не только расскажи

DeepSeek 2.1.0 — модель с сильной способностью к in-context learning. Два-три качественных примера в промте дают больший прирост качества, чем страница инструкций. Но примеры должны быть разнообразными (разные кейсы, разная сложность) и репрезентативными (близкими к реальным данным).

Структура few-shot блока:

Вход → рассуждение (CoT) → выход в целевом формате
Покрытие граничных случаев (пустые данные, ошибки, нестандартные форматы)
Единый стиль оформления примеров — модель копирует и его

## Пример 1 (стандартный)
Input: {«text»: «Сервер упал с 500 ошибкой при деплое v2.3.1»}
Reasoning: 1) Ошибка 500 = серверная. 2) Связана с деплоем = регрессия. 3) Версия указана.
Output: {«category»: «regression», «severity»: «critical», «version»: «2.3.1», «action»: «rollback»}

## Пример 2 (граничный: нет версии)
Input: {«text»: «API возвращает 500 на /checkout»}
Reasoning: 1) 500 = серверная. 2) Эндпоинт checkout = критичный. 3) Версии нет → unknown.
Output: {«category»: «incident», «severity»: «critical», «version»: «unknown», «action»: «investigate»}

## Пример 3 (не инцидент)
Input: {«text»: «Пользователь жалуется на медленную загрузку отчёта»}
Reasoning: 1) Не 5xx. 2) Производительность, не падение. 3) Категория = performance.
Output: {«category»: «performance», «severity»: «medium», «version»: «N/A», «action»: «profile»}

Эффект few-shot на качестве классификации (условная схема)

Универсальный шаблон-промт (копируй и адаптируй)

Шаблон для сложных задач с CoT и контролем формата

# ═══════════════════════════════════════════
# UNIVERSAL PROMPT TEMPLATE — DeepSeek 2.1.0
# ═══════════════════════════════════════════

## ROLE
Ты — [РОЛЬ: senior engineer / analyst / copywriter / reviewer].
Стиль: [конкретные прилагательные: лаконичный, скептичный, педагогичный].
Границы: [что НЕ делать: никаких any, никакой маркетинговой воды, не придумывай факты].

## CONTEXT
Входные данные:
[JSON / код / текст / метрики / ссылки на предыдущие сообщения]
Ограничения окружения:
[стек, лимиты токенов, таймауты, политики безопасности]

## TASK
Цель: [одно чёткое предложение: что именно должен произвести модель].
Критерии успеха (чек-лист):
☐ [критерий 1: измеримый, проверяемый]
☐ [критерий 2]
☐ [критерий 3]
Анти-критерии (что автоматически делает ответ невалидным):
☐ [например: использование запрещённых библиотек]
☐ [например: превышение лимита строк]

## REASONING (Chain-of-Thought — ОБЯЗАТЕЛЬНО)
Выведи рассуждение в структуре:
1. Problem decomposition — разбей задачу на атомарные подзадачи.
2. Assumptions — перечисли всё, что предполагаешь неявно.
3. Step-by-step derivation — пройди каждый шаг, покажи промежуточные выводы.
4. Verification — проверь итог на противоречия, крайние случаи, соответствие критериям.
5. Confidence — оцови уверенность в итоговом ответе от 0 до 100.

## OUTPUT FORMAT
Строго в формате:
[JSON Schema / Markdown таблица / чистый код / нумерованный список]
Пример валидного ответа:
[один мини-пример в целевом формате]

## FEW-SHOT (опционально, 2–3 примера)
### Example 1
Input: …
Reasoning: …
Output: …

### Example 2
Input: …
Reasoning: …
Output: …

## FINAL INSTRUCTION
Начни ответ с блока REASONING. После него — блок FINAL ANSWER в заданном формате.
Никакого текста вне этих двух блоков.

Чек-лист перед отправкой: 10 секунд — минуты отладки

Роль задана явно — не «ты помощник», а конкретная специализация с описанием стиля и границ.

Контекст самодостаточен — модель не должна гадать, что за поля в JSON, каков стек, какие термины используются.

Критерии успеха измеримы — «качественно» не критерий. «Покрытие тестами ≥ 80 %» — критерий.

Формат ответа жёстко зафиксирован — JSON Schema, пример валидного объекта, запрет на markdown/комментарии.

CoT включён для сложных задач — если задача требует > 2 шагов логики, добавлен блок REASONING со структурой.

Few-shot покрывает граничные случаи — не только «идеальный ввод», но и пустые данные, ошибки, нестандартные форматы.

Что не работает: мифы о промптинге DeepSeek

Миф

«Чем длиннее промт, тем умнее ответ». Люди пишут простыни текста, надеясь, что модель «поймёт суть».

Реальность

DeepSeek 2.1.0 лучше следует структурированным коротким промтам. Шум в инструкциях размывает внимание. 500 токенов чёткой структуры > 3000 токенов простыни.

Миф

«Модель сама поймёт формат из контекста». Не указывают JSON Schema, надеясь на «умность».

Реальность

Без явного формата модель выбирает «свой» вариант — часто markdown вместо JSON, лишние пояснения, разные ключи. Экономия 50 токенов на схеме стоит часов парсинга.

Миф

«CoT нужен только для математики». Пропускают рассуждения для кода, анализа, планирования.

Реальность

CoT улучшает любую задачу, где есть логическая цепочка: рефакторинг, root-cause анализ, генерация тестов, архитектурные решения. Включай по умолчанию.

Миф

«Один промт на всё». Пытаются схитрить: один универсальный промт для всех сценариев.

Реальность

Специализированные промты (для кода, для аналитики, для текстов) дают выше качество. Храни библиотеку версионированных промтов — как код.

Промт — это интерфейс к модели. Проектируй его как API.

DeepSeek 2.1.0 не читает мысли. Она исполняет инструкции. Чёткая архитектура из четырёх слоёв, обязательный CoT для сложных задач, few-shot для стиля и формата, жёсткий контроль выходного контракта — это не «трюки», это инженерная дисциплина. Собирай промты как собираешь функции: с типизированными входами, проверяемыми выходами и тестами на граничных случаях.

Роль → Контекст → Задача → Формат CoT по умолчанию Few-shot для стиля Версионируй промты

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