大模型网摘deepseek.wang
中文

Prompt Optimization · 2026-11-02

Prompting Reasoning Models: Context and Constraints First, Then the Open Question

When using DeepSeek's R-series deep thinking mode for complex reasoning, many people still open with the familiar "You are a senior expert" role-play setup—and the results are often mediocre. The reason is simple: reasoning models excel at following a chain of thought within the conditions you provide. The clearer your constraints, the more focused the model's reasoning path and the more reliable its conclusions. If you just toss out an open-ended question, the model burns thinking tokens trying to guess what you want, producing scattered output and extra rework.

What these models actually respond to is structured input: background, hard constraints, output format, and only then the open question itself. Let's break this down.

Why "constraints first, question last" works better with reasoning models

DeepSeek's R-series unfolds an internal reasoning process during its thinking phase. That process is essentially solving a problem under the conditions you gave it. If you bury a key constraint in the last sentence, the model may already be deep into its reasoning before it sees the limitation, forcing a backtrack. Putting background and constraints up front means every reasoning branch is based on the complete set of conditions—thinking effort goes into solving the problem, not interpreting it.

The other practical benefit is controllability. With constraints up front, when the output misses expectations you can pinpoint exactly which constraint was violated and retry with a one-line fix instead of rewriting the whole prompt.

Which tasks are worth triggering deep thinking

DeepSeek's thinking mode can be toggled (with a corresponding parameter in the API—see official docs for specifics), and not every task deserves it. Good use cases:

Not worth it: translation, rewriting, simple Q&A, format conversion. Use the V-series general chat mode or turn thinking off—faster responses and lower cost. A rule of thumb: if you could work out the answer yourself in 30 seconds, you don't need deep thinking.

Template 1: Complex reasoning / decision analysis

text
[Background]
I'm an independent developer, mostly writing Python backends. My server is a 4-core 8GB cloud VM with a tight budget.

[Constraints]
1. The solution must run on a single machine; no additional paid services.
2. Prioritize operational simplicity; modest performance loss is acceptable.
3. Every recommendation must explain the trade-offs—no bare conclusions.

[Question]
I need a scheduled task system with retry-on-failure and task dependencies. Analyze from three angles—tech stack choice, deployment approach, and failure handling—then give one clear recommendation with reasoning.

Note the structure: the background states real conditions (hardware, budget, skill set), the constraints rule out unacceptable options and demand trade-off explanations, and only the final question is open-ended. Framed this way, the model's reasoning converges around your constraints instead of rambling.

Template 2: Code problem diagnosis

text
[Background]
This is a FastAPI endpoint that reads a paginated order list from the database. In production it intermittently times out; the logs show no errors, just slower responses.

[Code]
(paste the complete relevant code)

[Constraints]
1. Don't suggest infrastructure fixes like "upgrade the server"—analyze only code and query level.
2. Rank each possible cause by likelihood of suspicion, and explain how to verify it.
3. If the information is insufficient to locate the issue, first list what else you need—don't guess.

[Question]
Analyze the most likely causes of the slow responses and give me a debugging checklist.

The key here is the third constraint: "ask for more info when uncertain." Reasoning models tend to force a conclusion even without enough evidence; explicitly requiring them to acknowledge uncertainty noticeably reduces hallucinated diagnoses.

Common pitfalls

First, stacking too many constraints. Constraints are filters, not wish lists—beyond ten the model starts dropping them; 3–5 hard constraints work better. Second, writing background like a novel. Background only needs facts that affect the reasoning—two or three sentences. Third, turning an open question into a closed one. If you already know the answer you want, just state the requirement—no need to trigger deep thinking for a lap around it.

Division of labor with the V-series

For everyday Q&A, writing polish, and translation, use the V-series general chat—a single clear sentence is enough. For tasks that need the model to think before answering, switch to the R-series with the structure above. DeepSeek has open weights for local deployment and low API pricing, so experimentation is cheap: run the same question in both modes and compare. You'll quickly build your own instinct for which questions deserve deep thinking. For exact toggle details, refer to the official pages.

Before your next prompt, run background, constraints, and question through your head in three passes—30 seconds of prep usually saves three rounds of rework.