DeepSeek как разработчик: системный промт, который включает навык программирования

Инженерия контекста

DeepSeek как разработчик: системный промт, который включает навык программирования

Почему модель пишет код джуниора — и как системным промтом задать архитектуру мышления сеньора. Готовые шаблоны под разные задачи.

System PromptRole PromptingChain of ThoughtFew-Shot

Проблема не в модели, а в контракте

По умолчанию DeepSeek (как и любой LLM) оптимизирован под «среднего пользователя». Он вежлив, вербален, избегает риска и пишет код, который «выглядит правильно», но не работает в продакшене. Это поведение по умолчанию — не баг, а фича безопасности.

Когда вы пишете «напиши парсер на Python», модель подставляет самый вероятный шаблон из обучающей выборки. Она не знает ваш стек, ваши конвенции, ваши ограничения по памяти и вашу политику логирования. Она играет в разработчика, а не работает им.

Системный промт — это не инструкция. Это контракт. Он переводит модель из режима «чат-бот» в режим «Инженер ПО».

Анатомия промта, который работает

1. Определение роли (Identity)

Кто он есть

Не «ты программист». А: «Ты — Старший инженер бэкенда с 12-летним стажем. Специализация: высоконагруженные системы на Go/Python, распределённые базы данных, observability. Ты пишешь production-ready код: с обработкой ошибок, метриками, идемпотентностью и документацией». Конкретика снижает энтропию ответов.

Анти-паттерны

Что запрещено

  • Никаких «TODO: implement later» — пиши полный код.
  • Никаких заглушек `pass` / `…` в логике.
  • Не используй `print` для логгирования — только structured logging (zap, slog, loguru).
  • Не игнорируй ошибки — возвращай `error` как значение.
  • Никаких глобальных переменных для состояния.

Пять блоков системного промта

01

Role & Persona

Жёсткое закрепление экспертизы, стека, уровня ответственности. Указание на то, как модель должна мыслить (First Principles, Trade-offs analysis).

You are a Staff Engineer. Stack: Go 1.22, PostgreSQL, Redis, gRPC. Focus: Correctness, Observability, Maintainability.
02

Hard Constraints

Негативные ограничения (Don’ts) работают надежнее позитивных. Запрет анти-паттернов, библиотек, паттернов архитектуры, нежелательных в проекте.

FORBIDDEN: — sync.Mutex for hot paths (use atomic/sync.Map) — ORM (raw SQL / sqlc only) — panic() outside init/main — relative imports
03

Workflow / CoT

Явный алгоритм мышления: Понять контекст → Выявить ограничения → Предложить альтернативы → Написать код → Проверить на гонки/утечки → Сформулировать ответ.

THINKING PROCESS: 1. Analyze requirements & constraints 2. Design interface & data flow 3. Identify failure modes 4. Write implementation 5. Self-review: race conditions, leaks, coupling 6. Output final code
04

Few-Shot Examples

2-3 пары «Задача — Идеальное решение». Это калибрует стиль, формат комментариев, нейминг, структуру файлов. Примеры должны быть из вашего реального кодовой базы (обезличенные).

EXAMPLE 1: User: «Rate limiter» Assistant: // sliding window log impl… // with redis lua script for atomicity // exports prometheus metrics
05

Context Injection Protocol

Правила подачи контекста в пользовательском сообщении: структурированные блоки <context>, <files>, <constraints>. Модель учится парсить этот формат и игнорировать шум.

<context> Service: payment-gateway Load: 5k RPS, p99 < 50ms Stack: Go, PostgreSQL, Kafka </context> <task> Refactor idempotency key storage </task> <files> internal/idempotency/store.go </files>'>

Особенности DeepSeek: Reasoning Mode

С включенным DeepThink (R1)

Модель генерирует скрытый блок рассуждений <think>...</think>. Для программирования это мощно: она может «пропросить» архитектуру перед кодом.

В промте нужно: Явно разрешить/требовать рассуждения для сложных задач. Запретить их для рутинных (генерация DTO, миграций).

Совет: Добавьте правило: «Если задача требует архитектурного решения — используй полный цикл рассуждений. Если задача локальная (функция, хендлер, тест) — отвечай сразу кодом, без <think>.»

Без Reasoning (V3 / Chat)

Быстрее, дешевле, но склонен к галлюцинациям в логике. Требует более жестких Constraints и большего количества Few-Shot примеров.

В промте нужно: Жёсткая структура вывода (Markdown блоки с языком), обязательные чек-листы самопроверки в конце ответа.

Важно: DeepSeek V3 часто «забывает» инструкции из системного промта в середине длинного диалога. Используйте <reminder> в пользовательских сообщениях: «Напоминаю: нет ORM, структурное логирование, ошибки как значения.»

Готовые шаблоны под задачи

Универсальный Сеньор (Backend)

Go / Python / SQL
# SYSTEM PROMPT
You are a Staff Backend Engineer (Go/Python).
Expertise: High-load, Distributed Systems, Clean Architecture, Observability.

IDENTITY:
- Write production-grade code only. No prototypes, no stubs.
- Every function: input validation, error handling, structured logs, metrics.
- Concurrency-safe by default. Context propagation mandatory.
- Database: raw SQL (sqlc) or explicit queries. No ORM.

FORBIDDEN:
- panic(), global state, bare 'error' returns without context.
- print/fmt.Println. Use slog/zap with JSON output.
- Magic numbers. Constants in config.
- Commenting obvious code. Comment *why*, not *what*.

WORKFLOW:
1. Analyze requirements & constraints from <context>.
2. Define interface (Go) / signature (Py) first.
3. Identify failure modes (retries, timeouts, partial failures).
4. Implement with defensive coding.
5. Self-review: Race detector clean? Leaks? Coupling?

OUTPUT FORMAT:
Single markdown block per file. Path as comment on line 1.
No conversational filler. No "Here is the code:".

Debugging Partner (Postmortem)

Logs / Traces / Dumps
# SYSTEM PROMPT
You are a Principal SRE / Debugger. Expertise: Linux internals, Go runtime, Network stack, Distributed tracing.

METHOD:
1. Form hypotheses from symptoms (logs, metrics, traces).
2. Rank by probability & blast radius.
3. Request *specific* missing data (pprof, tcpdump, specific log lines).
4. Verify hypothesis against code paths.
5. Propose fix + prevention (alert, test, runbook update).

RULES:
- Never guess randomly. Always trace code -> symptom.
- Distinguish: Root Cause vs Contributing Factor vs Symptom.
- Ask for *one* specific artifact at a time.
- Explain reasoning: "I suspect X because Y in trace shows Z".

INPUT FORMAT EXPECTED:
<incident>...</incident> <logs>...</logs> <code>...</code>

Architecture Reviewer (Design Docs)

RFC / ADR / Diagrams
# SYSTEM PROMPT
You are a Distinguished Architect. Review design docs (RFC/ADR) for correctness, scalability, operability.

REVIEW DIMENSIONS:
1. Requirements Coverage: Functional & Non-functional (SLOs).
2. Data Flow & Consistency: Boundaries, transactions, eventual consistency.
3. Failure Modes: Partial degradation, cascading failures, recovery.
4. Operational Readiness: Deploy, migrate, rollback, capacity, observability.
5. Coupling & Evolution: API versioning, schema migration, deprecation.

OUTPUT:
Structured Markdown: Summary, Critical Risks (P0), Major Concerns (P1), Questions, Approved/Needs Revision.
Tone: Constructive, precise, reference patterns (e.g., "Outbox pattern required here per [ref]").

Что ломает иллюзию компетентности

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

Скидывание 50 файлов «для контекста» заставляет модель искать иголку в стоге сена. Подавайте только изменяемые файлы + интерфейсы зависимостей. Используйте RAG / ретривер, а не контекстное окно как помойку.

Смешение ролей в диалоге

Просите «сначала проанализируй как архитектор, потом напиши как разработчик» в одном сообщении — получите кашу. Разбивайте на ходы: 1. Анализ (вывод — план). 2. Реализация (ввод — план, вывод — код).

Игнорирование верификации

Модель не запускает код. Всегда добавляйте в промт шаг «Self-Review Checklist» (Race conditions? Nil pointers? Context cancellation? Leaked goroutines? SQL injection?). И запускайте линтеры/тесты сами.

Чрезмерная вежливость

Фразы «пожалуйста», «будь добр», «если не сложно» едят токены и размывают инструкции. Промт — это конфиг. Пишите императивно, структурировано, без шума. «Do X. Constraints: Y. Format: Z.»

Главное, что стоит запомнить

Промт — это исходный код поведения модели

Вы не «просите» нейросеть. Вы конфигурируете её веса во время инференса через контекст. Каждый блок системного промта — это гиперпараметр. Role Definition задаёт вектор внимания. Constraints обрезают пространство решений. Few-Shot калибрует стиль. Workflow задаёт алгоритм генерации токенов.

Промтинг — это программирование на естественном языке. С той же строгостью, что и код.

НейросетиПромтыРазное
21 октября, 2026

Статьи по теме

Copyright 2026 CanadaTalk.ru