DeepSeek Prompt Engineering Guide

Updated: 2026-08-12. Model availability and surfaces follow DeepSeek and your account UI.

Overview

DeepSeek prompt work and DeepSeek prompt engineering are not about stacking magic phrases like “be professional” or “think step by step.” They are about writing an acceptably precise task brief: goal, evidence, constraints, output contract, and quality checks. With clear context, DeepSeek tends to draft usable work; with vague context, it can be confidently empty or invent details. This guide gives a six-part structure, four scenario templates, and a sample-set method to iterate prompt versions.

What this guide solves

• Turn casual chat into an executable six-part brief
• Copy writing, analysis, code, and reasoning templates
• Diagnose vagueness, format drift, hallucination, and bloat
• Evaluate prompt versions on a fixed sample set—not one “feels good” run

Six-part prompt structure

Keep this logic even when you compress into a short prompt:

1. Task — verb + deliverable (rewrite, extract, diagnose, compare…)
2. Context — audience, situation, where you are stuck
3. Source material — text, data, stack traces, policy snippets the model must use
4. Constraints — length, tone, bans, no invention, mark unknowns outside sources
5. Format — fields, table, JSON, checklist, or fixed section order
6. Acceptance — what “done” means and which facts must survive

Role: [optional, one line]
Task: [verb + deliverable]
Audience / situation: [who uses this, which decision]
Sources: use only the material below; write "unknown" if missing; do not guess.
Constraints: [length / tone / bans / confidentiality]
Format: [fields or structure]
Acceptance: [must-keep facts, pass criteria]
Self-check against constraints before final output.
Sources:
"""
[paste]
"""

Minimal daily version: goal → evidence → constraints → output shape → ask when unknown. Run a short prompt first, then patch only failure modes—more reliable than one giant “universal” prompt.

Four high-frequency templates

1. Writing and rewrite

Serve the reader’s action while preserving facts—not “more eloquent.”

Rewrite the material for [audience] so they can [action].
Keep every date, number, product name, and link; do not add features or promises absent from the source.
Output:
1) body (≤[N] words, tone: [formal/casual])
2) list of semantic changes vs source (or "none")
3) missing information (≤3 items)
Sources:
"""
[paste]
"""

2. Analysis and comparison

Define weighted dimensions first; fill the table; mark “unknown” where evidence is missing—do not force a winner.

Compare options [A/B/C] using only the provided sources.
Dimensions (weights): [cost 30%] [risk 30%] [time-to-ship 20%] [maintainability 20%]
Output table: dimension | A | B | C | evidence paragraph # | confidence
Also: 1-paragraph conclusion, critical unknowns, next verification step.
Do not invent numbers missing from the sources.
Sources:
"""
[numbered paragraphs]
"""

3. Code and debugging

Provide environment, minimal code, full stack, expected vs actual; demand verification commands before a minimal patch.

Environment: [language/framework/version]; no new dependencies.
Task: [implement function / diagnose error]
Expected vs actual: […]
Full stack / minimal related code:
"""
[paste]
"""
Output order:
1) single most likely root cause + evidence line
2) verification commands I can run
3) minimal patch notes
4) regression checks
If evidence is thin: ask ≤3 clarifying questions; do not dump speculative code.

For a fuller coding workflow: DeepSeek coding guide.

4. Reasoning and multi-constraint decisions

Number known facts and hard constraints; require conclusion, checkable evidence, constraint audit, and an independent verification path. For deep reasoning modes, see R1 reasoning guide.

Known facts (numbered):
1. …
2. …
Hard constraints (must not violate): …
Decision goal: […]
Output:
- conclusion (one sentence)
- reasoning steps mapped to fact numbers
- constraint audit (each: met / violated / unknown)
- independent verification method (without trusting the model)
- if facts conflict: list conflicts; do not force a merge
Do not introduce unnumbered “common knowledge” as fact.

Iteration diagnosis table

Do not only say “make it more detailed.” Change one variable at a time and keep the same test input.

Symptom	Likely cause	Fix
Vague output	Missing audience, sources, or crisp goal	Add scenario + paste evidence + name the deliverable
Format drift	Structure described only in prose	Give fixed field names or a one-line example
Hallucination	Forced to answer somehow	Allow “unknown”; limit to provided sources
Overlong	No scope or priority	Cap length; lead with the conclusion
Missed hard rules	Constraints buried mid-prompt	Isolate hard constraints and mirror them in acceptance
Fixing one part breaks another	Too many edits at once	Patch instruction: keep section X, rewrite only Y
Unrunnable code	Missing versions and edges	Pin environment; ask for a test table before implementation

Patch instruction example:

Keep sections 1 and 3 unchanged.
Rewrite section 2 using only the attached policy; cite paragraph numbers for every claim.
Mark conflicts; do not arbitrate. Self-check against the acceptance list.

Evaluate with a sample set

“Feels better” is not reproducible. Maintain a small set:

1. Collect 12–20 representative inputs (writing / extract / reasoning / code)
2. Define expectations: required facts, bans, format validity, allowed unknowns
3. After each prompt change, re-run the full set on the same surface and parameters
4. Score accuracy, completeness, format pass, unsupported claims, human edit minutes
5. Log prompt version, date, surface (web / API), and model name as shown in the UI

A short prompt that passes tests beats a sophisticated-sounding untested prompt. For API versioning habits, see DeepSeek API guide.

Daily checklist

• Task names a verb and deliverable
• Sources pasted; unknowns allowed outside them
• Hard constraints isolated (length, no invention, secrecy)
• Output format is directly reviewable
• Failures diagnosed; one change at a time
• Critical flows have a fixed sample set and version log
• Sensitive data stripped before upload

Access and entry points

• China-friendly chat: DeepSeek V4
• Mirror studio: AI Chat Studio
• Official chat: chat.deepseek.com
• API docs: api-docs.deepseek.com

The same prompt can behave differently across surfaces—pin surface, model, and prompt version for important evaluations.

FAQ

Do I need “think step by step”?

Usually no. Clear constraints and verifiable outputs beat vague “think harder.” When you need deep decomposition, pick a reasoning-capable mode and verify evidence—don’t rely on a verbal spell.

Are longer prompts always better?

No. Keep only what the task needs; remove conflicts and duplication. Short run → patch failures beats a novel-length persona.

How do I reduce hallucination?

Bound the source set, allow “unknown,” require locatable citations, and manually verify dates, numbers, and links for high-stakes decisions.

Can I reuse viral “universal” prompts?

As a starting point only. Re-test on your sample set; model or surface changes can invalidate old prompts.

Is role-play useful?

Optional—one line is enough. Evidence, constraints, and acceptance drive quality more than long personas.

Should web and API prompts differ?

Same principles; APIs emphasize stable formats (JSON/schema), parameters, and version logs—see the API guide.

Official resources

• DeepSeek website
• Official chat
• API documentation

Next reading

• DeepSeek coding guide
• DeepSeek R1 reasoning
• DeepSeek V4 complete guide
• DeepSeek API getting started

Summary

Prompt engineering is requirements engineering: write task, sources, constraints, format, acceptance, then iterate on a fixed sample set. Treat DeepSeek as an acceptably constrained executor—not a chat partner that improves with more adjectives—and you will spend less time editing bad drafts.