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

Гайд по промпт-инженерии

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

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

Две модели — две логики работы

DeepSeek не «один чат». Внутри живут две принципиально разные архитектуры: DeepSeek-V3 (быстрый чат, System 1) и DeepSeek-R1 (рассуждение, System 2). Промпт, идеальный для V3, сломает R1. И наоборот.

V3 отвечает сразу. R1 генерирует скрытый блок <think>, куда уходит на «размышление» от нескольких секунд до минут. Ваша задача — дать модели правильный контекст до запуска этого движка.

Ключевое различие

  • V3: Инструкция → Ответ. Любит чёткие роли, формат, few-shot.
  • R1: Проблема → Рассуждение → Ответ. Любит контекст, цель, ограничения. Не любит, когда за него думают.

Анатомия рабочего промпта для R1

Роль и персона

Не «ты эксперт», а контекст: «Ты — старший архитектор безопасности, пишешь отчёт для CTO банка. Тон: сухой, структурированный, нулевая вода». R1 использует это для калибровки глубины рассуждения.

Role: Senior Security Architect Audience: CTO, Banking Tone: Executive summary, evidence-based
Контекст и ограничения

Что известно, что нельзя, какие ресурсы есть. R1 строит дерево рассуждений; лишние ветки едят токены и время. Пишите: «Вход: JSON 500 объектов. Лимит: 2000 токенов на ответ. Запрет: сторонние библиотеки».

Context: Legacy codebase, no tests Constraints: Zero deps, O(n log n) Output: Single file, typed TS
Критерий успеха (Success Criteria)

Самый игнорируемый блок. R1 оптимизирует под неявную цель. Сделайте её явной: «Критерий: код проходит линтер, покрыт тестами на 80%+, нет any». Модель будет проверять себя в блоке think.

Success: Compiles, passes lint, Coverage > 80%, no `any` type, Docs for public API
Формат выхода

JSON, Markdown, Mermaid, diff-патч — задавайте жёстко. R1 склонен к вербальности. Добавьте: «Вывод ТОЛЬКО валидный JSON по схеме X. Никакого текста до и после». Это экономит кучу токенов на пост-обработке.

Format: JSON Schema (draft-07) No markdown, no commentary, Strict validation required

Ловушка «Think Step by Step»

Для GPT-4 или Claude фраза «Let’s think step by step» — магия. Для R1 — вредный совет. Модель уже рассуждает внутри <think>. Явная просьба заставляет её дублировать логику в видимом ответе, раздувая вывод, теряя фокус и часто ухудшая качество финального решения.

Не нужно: «Think step by step»Нужно: чёткая цель + критерии

Правило «Цель, а не процесс»

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

Когда попросить шаги явно

Только если нужен видимый аудит: «Выведи план рефакторинга по шагам перед кодом, я должен его согласовать». Тогда шаги — это доставляемый артефакт, а не инструкция модели.

R1 vs V3: вердикт по сценариям

DeepSeek-R1 (Reasoning)

Slow thinking
  • Сложная архитектура и дизайн систем
  • Рефакторинг легаси без тестов
  • Математика, доказательства, алгоритмы
  • Многошаговые логические цепочки
  • Анализ противоречивых требований
  • Генерация тестов к сложному коду
Ожидайте 10–120 сек генерации

DeepSeek-V3 (Chat)

Fast thinking
  • Рутинный код: DTO, миграции, бойлерплейт
  • Творчество: копирайтинг, нейминг, идеи
  • Суммаризация, перевод, форматирование
  • Брейншторм, вопросы-ответы, обучение
  • Few-shot задачи с готовыми примерами
  • Интерактивный диалог, правки «на лету»
Ответ за 1–3 секунды

Паттерны промптов: готовые шаблоны

Архитектор: декомпозиция задачи

Идеально для старта проекта или сложной фичи. R1 строит дерево зависимостей, риски и план.

# Role Senior Staff Engineer, Distributed Systems # Task Design architecture for: [Описание фичи/проблемы] # Context - Scale: [RPS, Data volume, Latency SLA] - Stack: [Текущий стек, ограничения] - Team: [Кол-во команд, экспертиза] # Output 1. Context Diagram (Mermaid C4) 2. Component list + responsibilities 3. Data flow + consistency model 4. Risks & Mitigations (table) 5. Phased rollout plan # Success Criteria - Addresses all constraints - Explicit trade-offs documented - Mermaid renders valid
Детектив: root-cause анализ

Когда ломается прод и логов много. R1 действует как старший SRE: гипотезы → проверки → вывод.

# Role Principal SRE, Incident Commander # Input - Symptoms: [Что сломалось, метрики, логи] - Recent changes: [Деплои, конфиги, инфра] - Architecture ref: [Ссылка на диаграмму] # Process 1. List 3-5 hypotheses ordered by probability 2. For each: evidence FOR / AGAINST 3. Identify minimal verification steps 4. Root cause + contributing factors 5. Immediate fix + Preventive actions # Format Structured Markdown, ready for Postmortem
Code Review

R1 находит баги, которые пропускают люди: race conditions, утечки памяти, нарушения контрактов.

Review this PR for: 1. Correctness & edge cases 2. Concurrency safety 3. Resource leaks 4. API contract compliance 5. Performance anti-patterns Output: JSON {file, line, severity, msg, fix}
Миграция стека

Перевод кодовой базы между языками/фреймворками с сохранением семантики и идиом целевого стека.

Source: [Код/файл/папка] Target: [Язык/Фреймворк/Версия] Constraints: - Idiomatic [Target] patterns - Preserve behavior 1:1 - Typing: strict - Tests: generate for critical paths Output: Diff patches per file

Схема итеративного уточнения

Условная схема: промптинг как цикл обратной связи, а не однократный выстрел
Цикл промпт-инженерии: Контекст → Черновик → Верификация → Уточнение → Готовый артефактКОНТЕКСТРоль, Цель, ОграниченияПРОМПТ v1Сырая инструкция+ Примеры (few-shot)R1 THINKСкрытое рассуждениеОТВЕТ v1Код / Текст / JSON+ Логика (опционально)Вернуть в контекстВЕРИФИКАЦИЯЛинтер / Тесты / Схема / ЧеловекГОТОВЫЙ АРТЕФАКТ

Типичные ошибки промптинга

  • Перегруз контекстом: Кидаете 5 файлов «на всякий случай». R1 пытается обосновать использование каждого. Давайте минимум необходимое.
  • Противоречивые инструкции: «Будь лаконичен» + «Опиши все детали». Выбирайте одно; добавляйте «Детали в приложении, если нужно».
  • Игнорирование схемы: Просите JSON без JSON Schema. Получите «псевдо-JSON» с комментариями и trailing commas.
  • Смешивание V3/R1 в чате: Спросили у R1 «продолжи код», он начал думать заново. Для правок используйте V3 или дайте R1 полный контекст сразу.
  • Запрос «лучшего» без критериев: «Сделай лучший код». Лучший — быстрый? читаемый? безопасный? Пишите метрики.

Продвинутые приёмы

  • Chain-of-Verification: «Сгенерируй решение, потом найди в нём 3 потенциальных бага, потом исправь их». Запускает второй проход think.
  • Constitutional Prompting: Приложите файл CONSTITUTION.md с правилами проекта. Ссылайтесь: «Следуй CONSTITUTION.md».
  • Self-Consistency (упрощённо): «Дай 3 варианта архитектуры с плюсами/минусами, затем рекомендуй один». R1 сравнит внутри себя.
  • Tool-use симуляция: «Представь, что у тебя есть `grep`, `sql`, `curl`. Напиши последовательность вызовов для решения задачи, затем синтезируй ответ».
  • Meta-prompting: «Напиши промпт для V3, который выполнит рутину, описанную ниже. Выведи только промпт». Делегируйте рутину быстрой модели.

Промптинг — это не магия,
это системное проектирование

Вы не «просите» нейросеть. Вы передаёте спецификацию: входы, инварианты, критерии приёмки, формат артефакта. R1 — это компилятор намерений в код/текст/решение. Качество сборки определяется качеством ТЗ.

Контекст > ИнструкцияКритерии > НадеждаИтерация > Идеальный первый раз