DeepSeek Prompts: The Complete Guide to Writing Them Right

Same request, two prompts, two different worlds.

"Write a product description for my app." What comes back is a generic paragraph about "the future of work" that could describe any of ten thousand apps — because it had to guess everything: which app, which reader, how long, what to avoid.

Now the same ask, rebuilt: "Rewrite the product description below. The product is a project-management app for freelance designers; the audience is solo professionals who want a simple alternative to enterprise software. Keep it under 120 words, professional but approachable tone, no buzzwords. Output as one markdown paragraph plus a one-line tagline. Before finalizing, check that every claim is supported by the source text." Same model, same thirty seconds — but now the answer arrives usable.

That gap is what this guide closes. I've run this exact before-and-after for colleagues more than once, and the second prompt landing is still the cheapest demo I know. Writing DeepSeek prompts well isn't about magic phrases or trick questions. It's about handing over a complete order instead of a vague craving. And in 2026, with V4's thinking mode doing the heavy reasoning by default, the rules changed in ways most tutorials online still haven't caught up with. This guide covers the framework, the official prompt library, the thinking-mode rules nobody told you about, structured output, multi-turn drift, and a set of copy-paste templates you can steal today.

Why DeepSeek Prompts Are Different Now

Two things changed, and both matter for how you write.

First, the models. V4 arrived on April 24, 2026 as a pair: deepseek-v4-pro (1.6T parameters, built for complex reasoning and long code) and deepseek-v4-flash (284B parameters, built for speed), both with a 1M-token context window. The old API aliases deepseek-chat and deepseek-reasoner were retired after July 24, 2026 — which quietly broke half the tutorials on the internet, the ones still showing three-year-old model names in their examples. If a guide you're reading mentions those aliases as live options, it's a fossil. (For the full model story, see What is DeepSeek?.)

Second, and bigger: thinking mode. DeepSeek now reasons through a chain of thought before answering, and through the API it's on by default. That shifts the job of a prompt. The old prompt-engineering playbook — coax the model into reasoning step by step, stack few-shot examples, whisper "think carefully" — assumed you had to teach the model how to think. You don't anymore. The navigation system already plans the route; what it needs from you is the exact street address, not driving directions.

A widely shared observation from Chinese developers put it well: DeepSeek's deep-thinking feature has, to a large extent, replaced the job of prompt engineering — but combining it with solid prompting makes the output something you can use as-is. That's the honest summary. The thinking does the reasoning; your prompt does the specifying.

So the center of gravity moved. Less "here's how to think," more "here's exactly what done looks like."

The Five-Part Framework

Every reliable prompt — for DeepSeek or anything else — answers five questions. Miss one and the model fills the gap with a guess, and the guess is where bad outputs come from.

Think of it like ordering at a restaurant. The kitchen is skilled (that's the model), but the kitchen can't read your mind:

Part	The question it answers	Restaurant version	Missing it gets you
Task	What exact job?	The dish	Something adjacent to what you wanted
Context	Who's it for, what's the situation?	Allergies, occasion, who's at the table	Right answer to the wrong situation
Constraints	Boundaries on scope, length, tone, exclusions?	Budget, spice level, no cilantro	Over-long, off-tone, includes what you banned
Output format	What shape should it take?	Plated, boxed to go, family style	Wall of text when you needed a table
Verification	How do we check it's right?	The receipt	Confident errors nobody catches

Here's the whole thing as a fill-in template:

Task:
[The exact result you want.]

Context:
[Audience, situation, goal, background, source material.]

Inputs:
[The text, data, code, or requirements to work from.]

Constraints:
- [Length, tone, scope, exclusions, technical rules]
- Use only the information provided; if something required is missing, say so — don't invent it.

Output format:
[Markdown, table, JSON, code, checklist, email…]

Verification:
Before finalizing:
1. Check every requirement above is addressed.
2. Flag any assumptions you had to make.
3. Confirm the output follows the requested format.

For a quick question you only need Task and Output format. For anything you'll ship — code, a client email, a published paragraph — keep all five. The pattern shows up under different names around the prompt-engineering world, but the skeleton is always the same.

Four Frameworks, One Table

You'll run into several named frameworks. They're less different than they look:

Framework	Parts	Where it's from
T-C-C-O-V	Task, Context, Constraints, Output, Verification	chat-deep.ai's editorial framework (2026)
CO-STAR	Context, Objective, Style, Tone, Audience, Response	Popular general-purpose framework, widely used for V4
RICE	Role, Input, Capability, Expectation	Distilled by Chinese developers from DeepSeek's own official prompts
Role-Problem-Goal-Requirements	立角色 + 述问题 + 定目标 + 补要求	Tencent Cloud developers' "universal template"

Zoom out and they all map onto the same four moves: set a role or context, state the task, bound it with constraints, define the output. CO-STAR splits style and tone into separate knobs; T-C-C-O-V adds the verification step (worth keeping — it's the part people skip and then get burned by). Pick one, use it until it's muscle memory. Switching frameworks buys you nothing; using any of them completely buys you a lot.

The Official DeepSeek Prompt Library

Here's the part most guides bury: DeepSeek publishes its own prompt library, thirteen scenarios with complete, tested prompts. It's the closest thing to an official answer to "what does a good prompt look like for this model":

Scenario	What it's for
Code rewriting	Fix, comment, or optimize provided code
Code explanation	Explain what a snippet does
Code generation	Build working code for a described function
Structured output	Extract information into JSON
Content classification	Sort text into predefined categories
Role play (custom persona)	Interact in a defined character
Role play (scenario continuation)	Simulate a scene's dialogue
Prose writing	Creative prose on a theme
Poetry	Poems in a named style
Copy outline	Article outlines from a topic
Slogan generation	Product slogans with rhyme and punch
Prompt generator	Have DeepSeek write your prompt for you
Translation (CN↔EN)	Faithful, natural, polished translation

The official prompts share a shape — and it's the same shape as the framework above. Take the slogan prompt, shortened: "You are a slogan expert… combine the product's core value and features… must rhyme and be easy to remember. Output only the slogan, no explanation. Generate a slogan for '[Greek yogurt]'." Role, task, constraints, output rule, input. The classification prompt goes further and uses markdown section headers — #### 定位, #### 能力, #### 知识储备, #### 使用说明 — to fence off the persona, the abilities, the category list, and the I/O contract. Structure isn't decoration; it's how the model keeps your category list from leaking into its answer.

One scenario deserves a spotlight: the prompt generator. You describe what you want in rough terms, and DeepSeek drafts the structured prompt for you. It's a legitimate meta-move — use the model to bootstrap the prompt you're not sure how to write, then tighten it yourself.

Three Upgrades You Can Make

The official library is a floor, not a ceiling. Three upgrades turn any official-style prompt into a stronger one:

Add an audience. "Summarize this paper" becomes "summarize for a product manager who needs the findings but not the methodology." The summary's depth, vocabulary, and what it skips all lock into place.
Pin the output format. The official prose prompt says 750 characters; yours should say the same kind of thing — a table with named columns, JSON with a schema, "one paragraph plus a tagline." Ambiguity in format is where "close enough" answers breed.
Add the verification line. One sentence — "before answering, check that every requirement above is met; flag anything you assumed" — routinely catches the invented statistic or the missed constraint. It's the cheapest quality control you'll ever install.

Apply all three to the official code-rewriting prompt and it stops being "explain the problems, then optimize" and becomes "explain the problems and their fixes, then optimize; the optimized code must preserve the original API; note any edge cases you couldn't handle; output the final code in one block with comments only on changed lines." Same skeleton. Sharper teeth.

Thinking Mode Changed the Rules

This is the section that dates most of the internet's prompt advice. Three rules, straight from the official thinking-mode documentation:

Rule one: sampling dials are disconnected. In thinking mode, temperature, top_p, presence_penalty, and frequency_penalty have no effect — set them and the API accepts them silently, ignoring every one. Every tutorial that says "lower the temperature to 0.6 for more focused output" is describing a dashboard wired to nothing. If you're on the API and actually need those controls, turn thinking off first; otherwise spend the effort on the prompt, where it still pays.

Rule two: incantations are obsolete. "Think step by step." "Think harder." "Take a deep breath." In the pre-thinking era these phrases measurably helped. Now the reasoning happens whether or not you ask nicely — asking for the reasoning transcript just makes responses longer. If you want rigor, don't request effort, specify the deliverable: "list the assumptions you made," "verify each constraint before answering," "give the answer, then a two-line rationale." Those are outputs you can check, not moods you're hoping for.

Rule three: effort is a setting, not a sentence. Through the API, thinking is on by default at high effort, adjustable with reasoning_effort across low, high, and max:

You request	Model actually runs
low	low
medium	high
high	high
xhigh	high
max	max

On the website, the same control wears a simpler costume: the Instant and DeepThink buttons. One caveat worth knowing: the API docs say thinking is enabled by default, while community testing finds v4-flash leaning toward quick answers in casual chat. Both are true in their places — the API parameter is authoritative for API calls, and the web interface picks a sensible default per model. Don't let either surprise you.

The practical translation of all three rules: in the thinking era you don't manage how the model thinks. You manage what it has to work with — precise task, real constraints, a checkable definition of done. The model handles the route planning; you supply the exact address.

Structured Output: Tags, Tables, and JSON

When a prompt gets long — role, background, task, rules, format — prose paragraphs start bleeding into each other. Structure fixes it, and DeepSeek meets you halfway: it reads markdown and XML-style tags natively.

For everyday chat prompts, markdown fences and headers do the job: put the task up top, the source material under a --- line, the rules as a bullet list. When a prompt carries many moving parts, XML-style tags draw harder walls:

<context>
Q3 e-commerce data: 50,000 rows; columns date, SKU, revenue, customer_region.
</context>

<task>
Write Python that aggregates revenue by customer_region,
keeping only regions above $10,000 total.
</task>

<rules>
- Base pandas only, no other libraries.
- Output the script only — no explanation.
</rules>

Nothing exotic — the tags just say "background lives here, command lives there, hard limits live over there." It's the same reason a print shop asks you to fill in a spec form instead of writing instructions on the back of the manuscript: fields keep things from drifting between departments.

For JSON, the API gives you a real contract, not just a promise. Three conditions, all from the official JSON guide:

Set response_format to {'type': 'json_object'}.
Put the word "json" in the prompt, with an example of the exact structure you want.
Set max_tokens generously — a JSON string cut off mid-way parses as nothing.

One honest footnote from the docs themselves: the feature occasionally returns empty content, and DeepSeek says tweaking the prompt helps. Which is exactly why the third habit matters — validate the JSON in your own code even with the mode on. A contract is only as good as the inspection at the door.

And for the hardest format cases there's a sledgehammer: prefix completion. You hand the model the opening of its own answer — an assistant message ending in ```python\n — with prefix: true, and it has no choice but to continue inside your code block. Pair it with stop=["```"] and the explanation the model wanted to add simply never happens. (It's a beta feature on the API's /beta endpoint — a power tool, but when you need format compliance at 100%, nothing else is as absolute.)

Multi-turn Prompts That Don't Drift

Here's the mechanism behind every "it forgot what I asked two messages ago" complaint — a complaint I made for a solid week before finally reading the docs: the API is stateless. The server remembers nothing between requests; your client resends the entire history with every call. The official multi-round guide shows the pattern (the request anatomy is in the API quickstart) — append each answer, append the new question, send it all again.

The web chat remembers for you, but the failure it can't prevent is subtler: on turn twelve, the constraint you set on turn one is twelve messages back, buried. Every long conversation is a colleague with a short memory and excellent skills — the qualifications never degrade, only the briefing does. So the fix is a better briefing discipline:

Restate the load-bearing constraints — audience, format, banned moves — in any message where they matter. One line is enough: "Same rules as before: table only, no speculation."
Summarize and reset on long threads. When a conversation crosses a milestone, ask for a summary of decisions so far, then start a fresh conversation seeded with that summary plus the original constraints. You trade a little context for a lot of coherence.
On the API, mind the reasoning trail. In thinking mode without tools, previous turns' chain-of-thought can be dropped from the history — the API ignores it anyway. But the moment your requests carry tools, every turn's reasoning_content must be passed back in full, or the API returns a 400. Multi-turn agent code that "helpfully" trims it will break in exactly this way.

Drift isn't the model getting worse. It's your original instructions decaying out of the picture — and structure is how you keep them in it.

Copy-Paste Prompt Templates

Twelve starters, each following the five-part skeleton. Paste, replace the brackets, ship. (They're tuned for DeepSeek but work anywhere the framework does.)

Code generation

Task: Write a Python function that [exact behavior].
Context: Runs on Python 3.11; callers pass a list of [type]; errors should surface, not be swallowed.
Constraints: Standard library only. Include type hints. Handle empty input gracefully.
Output format: One code block, then a 2-line usage example.
Verification: Before finalizing, trace the function once with a 3-item list and confirm the result.

Code explanation

Task: Explain what this code does, line by line for the tricky parts.
Context: I'm [your situation: new to this codebase / reviewing a PR].
Constraints: Don't rewrite it, explain it. Flag any bugs you notice separately.
Output format: A short summary paragraph, then a numbered walkthrough, then "Suspected bugs:" (or "none").

Code debugging

Task: Find why this code [observed wrong behavior].
Context: Expected [correct behavior]. Environment: [language version, OS].
Inputs: [code] + [error message or wrong output].
Constraints: Diagnose first, fix second. The fix must not change the public API.
Output format: 1) Root cause, 2) Minimal fix as a code block, 3) One test case that would have caught it.

Structured JSON extraction

Task: Extract the key facts from the text below into JSON.
Constraints: Use exactly this schema: {"topic": string, "date": "YYYY-MM-DD or null", "figures": [{"label": string, "value": string}], "summary": string}. Missing values are null — never guessed.
Output format: The JSON object only, no commentary.
Inputs: ---
[text]
---
Verification: Check every date and figure appears verbatim in the source; flag anything ambiguous as null.

Long-document summary

Task: Summarize this document for [audience, e.g., "an executive who will decide whether to fund this"].
Context: They care about [what: costs, risks, timeline]; they do not need methodology.
Constraints: Max 200 words. Every claim must come from the document — mark anything you're unsure of with (unclear).
Output format: 3 bullets: What it proposes / What it costs / Biggest risk.

Translation (CN↔EN)

Task: Translate the text below from [source] to [target].
Constraints: Translate meaning, not words — smooth, natural [target]. Keep technical terms in [source language] where they're standard. Preserve formatting and paragraph breaks.
Output format: The translation only. If a phrase is ambiguous, translate your best reading and add [alt: other reading] after it.

Copy outline

Task: Create an article outline on [topic].
Context: Audience [who]; goal [inform/persuade/teach]; tone [e.g., practical and direct].
Constraints: 4-6 main sections; each section gets 2-4 bullet points of what it covers; include one section addressing the reader's biggest objection.
Output format: Markdown headings with bullets, plus 3 title options at the end.

Slogan generation

Task: Generate 10 slogans for [product], each tied to its core value: [the value].
Constraints: Max 8 words each. At least 3 must rhyme. No corporate buzzwords ("innovate", "solutions", "empower").
Output format: A numbered list. Nothing else.

Email polish

Task: Rewrite this email to [recipient] to be [e.g., 30% shorter and firmer without being rude].
Context: Relationship [e.g., a client who has missed two deadlines]; my goal [e.g., set a final date without escalating].
Constraints: Keep my voice — professional, not corporate. Don't add apologies I didn't write.
Output format: The rewritten email, then a one-line note on what you changed and why.

Learning plan (Feynman-style)

Task: Teach me [topic] starting from zero.
Context: I have [background]; I learn best from examples before theory.
Constraints: Start with a concrete example, then explain the principle it illustrates. One concept per reply.
Output format: Example first, then "The principle:", then "Check yourself:" with one question. Wait for my answer before continuing.

Decision comparison

Task: Compare [option A] and [option B] for my situation and recommend one.
Context: My criteria, in order: [criterion 1], [criterion 2], [criterion 3]. Deal-breakers: [any].
Constraints: Score both options against each criterion (1-5) with a one-line justification. Where information is missing, say "unknown" — don't estimate.
Output format: A score table, then the recommendation in 2 sentences, then the single biggest risk of that recommendation.

Brainstorm cleanup

Task: Turn my chaotic notes below into a structured brief.
Inputs: ---
[paste raw notes]
---
Constraints: Keep every idea — group, don't delete. Mark duplicates as one item with "(x2)".
Output format: Grouped under 3-5 headings you invent; each idea one line; a "Loose ends" section for anything that fits nowhere.

Notice what all twelve share: nothing exotic. Task, context, constraints, format, a check at the end. The craft is in the specifics — the schema, the banned words, the "mark unknowns" instruction. That's where your prompts stop being lottery tickets.

Flash or Pro: Matching Prompt to Model

The two live models want slightly different prompts. v4-flash answers fast and shines on direct tasks — for those, ask straight and skip the "reason step by step" scaffolding; it just adds latency. v4-pro pays its way on multi-step reasoning, long documents, and serious code — for those, bring the full five-part structure and let the thinking mode grind.

Teams running both often add a routing line at the top of internal templates — "use flash: quick lookup, no reasoning needed" / "use pro: multi-step analysis" — turning model choice into part of the prompt convention instead of a per-request guess. Community reports put the savings from routing simple traffic to flash at 60–80% (an estimate, not a benchmark — your ratio depends on your mix). The direction, at least, is not in dispute: fast model for fast asks, deep model for deep ones, and the prompt should match the lane you picked.

Common Mistakes

The failure modes, in rough order of how often they're quietly costing you quality:

Following dated tutorials. Model names move; tutorials don't. deepseek-chat and deepseek-reasoner retired in July 2026 — if your reference still shows them, treat everything around it as suspect too. Even prompt guides themselves rot: one well-ranked techniques page from this research now returns a 404.
Twisting temperature dials. Covered above, worth repeating because it's everywhere: in thinking mode those four sampling parameters do nothing. Effort belongs in reasoning_effort, not in temperature folklore.
Incantations instead of instructions. "Think carefully" is a mood. "List your assumptions, then verify each constraint" is a deliverable. One of them shows up in the output; you can guess which.
Stacking few-shot examples. DeepSeek responds well to zero-shot instructions — a clear task description usually beats three stuffed examples, and community testing keeps finding that less context often means better focus. Give examples when the format is genuinely hard to describe; otherwise, describe it.
Dumping everything in one blob. Role, data, rules, and pleasantries in a single paragraph is how constraints get lost. Use the tags or headings — background / task / rules / format — so nothing has to be inferred about what's load-bearing.
Skipping verification. Both halves: the prompt's verification line (the model self-checks) and your own read-through (the model is not the last line of defense — you are). JSON mode still needs a parser check; "confidently wrong" survives every model upgrade.
Confusing prompting with tool access. A prompt can say "check the database," but no phrasing grants the model a database. On the API, tools are defined and executed by your application; the prompt's job is to say when a tool would help.
Letting long chats go unmanaged. Constraints decay over turns. Restate them, summarize-and-reset long threads, and on the API remember the reasoning-passback rule from the multi-turn section.

None of these are model failures. Every one is a briefing failure — which is good news, because briefings are the part you control.

FAQ

What makes a good DeepSeek prompt?A complete order: task, context, constraints, output format, and a verification step. If any of the five is missing, the model guesses — and you see the guess in the output. The five-part framework above is the whole trick, practiced.

Do I still need prompt engineering if the model "thinks"?Less than in 2024, more than the hype says. The thinking mode handles the how to reason part that old techniques (chain-of-thought tricks, example stacking) used to fake. What's left — and what matters more now — is specification: exactly what's wanted, for whom, within what limits, in what shape, checked how. Deep thinking makes a vague prompt produce elaborate vagueness, faster.

Should I write prompts in Chinese or English?Either — DeepSeek is strongly bilingual, and both its training and its official prompt library treat Chinese and English as first-class. Use whichever language you think in, with one exception: be consistent within a prompt. Mixing languages mid-instruction is where fidelity drops (mixing them in content, like a translation task, is of course the point).

Why is DeepSeek ignoring my instructions?Usually one of three: the instruction is buried in a blob (structure it), it was set many turns ago (restate it), or it conflicts with a stronger, later instruction and the model resolved the clash silently (make priorities explicit: "if X and Y conflict, X wins"). Rarely is the model "refusing" — almost always it never clearly received the rule.

Does adjusting temperature still help?Not in thinking mode — temperature, top_p, and both penalty parameters are ignored there, set or unset. On the API you'd disable thinking to regain them, which makes sense for high-volume creative variety; otherwise your effort is better spent on the prompt, which always works.

Where did deepseek-chat and deepseek-reasoner go?Retired as aliases on July 24, 2026. They mapped to v4-flash in their final months; the live names now are deepseek-v4-flash and deepseek-v4-pro. Update old code and older bookmarks — and hold any tutorial still using the old names a little more loosely.

The shortest next step: open the official prompt library, pick the scenario closest to your daily work, and add the three upgrades — audience, format, verification line — before you use it once. Twenty minutes of that beats another hour of prompt-theory reading.

Edward Wang