How to properly compose proms for DeepSeek: a complete guide

DeepSeek is a powerful AI model, but many people get mediocre results from it not because the model is bad, but because it is written incorrectly. In this article, you will learn how to formulate queries in order to get accurate, structured and predictable answers.

## First Important: DeepSeek is Not One Model

Before you write a prom, you need to understand which version of DeepSeek you are working with. This directly affects the strategy.

DeepSeek-V3/V4 (Chat) is a universal model for text, analysis, and structured responses. Works like GPT-4o: understands system proms, roles, examples, formats. This model is most often used in services and API integrations.

DeepSeek-R1 (Reasoning) is a thinker model. Before the answer builds an internal chain of reasoning. It's focused on mathematics, logic, complex analysis. It requires a completely different approach to prom.

If you’re using DeepSeek through an API in your service, it’s probably a V3/V4 model. This is what most of the advice below is about.

## Principles of compiling proms for DeepSeek V3/V4

### 1. Let's play a role through system prom

DeepSeek V3 responds well to a clear definition of the role in the system industry. This sets the tone, style, and scope of the whole response.

Bad:

Evaluate this text.

All right (system prompt):

You're a speech quality expert. Analyze transcribed texts
Talks and calls. Your estimates are accurate, structured, without water.
You list specific pieces of text as proof of each score.

### 2. Structure the prom blocks

DeepSeek works well with clearly separated sections. Use XML tags or Markdown headers to distinguish between context, task, and data.

** Structure pattern:**

<context >>
You evaluate the quality of a sales manager's work based on
Transcription of a call with a client.
</context >>

<task >>
Evaluate transcription according to the following criteria:
1. Welcome and Contact (0-10)
2. Identification of customer needs (0-10)
3. Work with objections (0-10)
4. Closing the transaction / next step (0-10)

For each criterion: set a score, quote a specific fragment
From transcription as justification, give a short recommendation.
</task >>

<transcription >>
[Transcription text here]
</transcription >>

### 3. Specify the output format explicitly

If you want a specific format, describe it. DeepSeek can deliver JSON, spreadsheets, lists, Markdown — but only if you ask.

Example to evaluate the call:

Make the result strictly in the following JSON format:
{
"criteria": [
{
"name": "Name of criterion",
"score": 0,
"quote": "quote from the text,"
“comment”: “brief comment”
}
]
"total score": 0,
"overall summary": "final conclusion"
}
No text outside JSON.

### 4. Transmit context before data

Static context (rules of evaluation, criteria, scale) always put at the beginning of the prom – before the transcription text. This is consistent with DeepSeek’s caching architecture and improves response accuracy.

** Correct order of blocks:**

1. Role/system prom
2. Evaluation criteria and scale
3. Examples (if necessary)
4. The text itself for analysis
5. Instructions on output format

### 5. Use negative restrictions

Explicitly forbid what is not required in response. This greatly improves predictability.

Don’t add introductory phrases like “Of course!” or “Great question!”
Don’t write conclusions about the manager’s personality – only about specific actions in the call.
Do not judge what is not reflected in the transcription.
If the fragment for the quote is not found, write "not fixed in the text".

### 6. Break down complex tasks into stages

If you need several different types of analysis – do not put everything into one smt. Ask the model to do one thing first and then another.

Instead of:

Evaluate the call, highlight key phrases, give script recommendations and
Identify the type of client.

Better:

Step 1. Evaluate the call by criteria (list). Take it to JSON.
Step 2. Based on the assessment from step 1 formulate 3 specific recommendations
for the manager.

## Special rules for DeepSeek-R1

If you work with R1, the rules change dramatically

• Do not use the system promt - place all instructions in the user message
• **Don't ask for "step-by-step reasoning" - R1 does it automatically, repeated request breaks the conclusion
• • Don't give examples (few-shot) * R1 starts copying the example pattern instead of reasoning on its own
• • Set the temperature 0.5-0.6** - high temperature destroys the logic of reasoning
• Request only the final answer - log the internal reasoning on the server, do not show the user

## Practical template: Evaluation of transcribed call

Here is a ready-made prom for a transcription-based call quality assessment system:

[SYSTEM PROMPT]
You're an automatic call quality assessment system. Analyze.
transcribed text of the manager's conversation with the client and exhibit
assessments strictly according to the given criteria. You only rely on what you have.
in the text. You don't think or assume.

[USER PROMPT]
Evaluate the transcription of the call by the following criteria. Scale: 0-10.

Criteria:
Greetings: did the manager introduce himself, did he name the company?
Identifying the need: Did you ask open-ended questions, listened to the client?
Presentation: Did the value of the product explain the customer’s task?
Dealing with objections: how to respond to doubts and rejections
Closing: is the next step fixed (agreement, date, action)

Response format: JSON:
{
"scores":
"greeting": {"score": 0, "evidence": "quotation or 'not fixed'},
"needs identification": {"score": 0, "evidence": "..."},
"presentation": {"score": 0, "evidence": "..."},
"objection handling": {"score": 0, "evidence": "..."},
"closing": {"score": 0, "evidence": "..."}
}
Total: 0,
"summary": "2-3 sentences of general conclusion"
}

Transcription:
-
[TRANSCRIPTION TEXT]
-

## Common mistakes

## Outcome

The quality of DeepSeek’s response depends on how accurately you describe the task, context, and expected format. A good propt is not a “smart question”, but a clear technical task: role, data, criteria, output format, limitations.

For the tasks of transcription analysis, it is especially important:

• Transmit the scale and criteria explicitly
• Require citations as proof of each evaluation
• Prohibit going beyond the text
• Fix the output format (JSON is preferred for further processing)

Test the promt on several real transcriptions, compare the results with a manual estimate - and iteratively refine the wording. Prompt engineering is always an experiment.