DeepSeek System Prompt: Write and Test Your Instructions

DeepSeek models accept a system message at the start of the conversation, and the model generally follows those instructions within its trained behavior. The practical challenges are writing instructions specific enough to get consistent output, and testing the result on the inputs your work actually produces.

DeepSeek's own internal instructions for its products are not user-accessible; what you control is the system message you write. Tools like fenbs let you store tested system prompts as skills so the approved version is available across sessions without re-entry.

How to set a system prompt in DeepSeek

Through the DeepSeek API, pass the system message as the first item in the messages array with "role": "system". This follows the standard chat completions format used by most current model APIs. The system message applies to the whole conversation.

{
  "model": "deepseek-chat",
  "messages": [
    {
      "role": "system",
      "content": "You are a technical writing assistant. Help the user write clear, accurate documentation for software engineers. Use US English. When a term needs defining, define it in the text the first time it appears."
    },
    {
      "role": "user",
      "content": "Write an introduction for our REST API documentation."
    }
  ]
}

In DeepSeek's web chat interface, you can often add a system prompt or standing instruction through a settings or persona option at the start of a conversation. The exact location of that option may change as the product updates; check the current interface before relying on it.

DeepSeek has also released reasoning models (DeepSeek-R1 and variants) with a thinking mode. For those models, the system prompt applies primarily to the final answer. The thinking process follows its own internal reasoning, which may not stay within the persona or constraints you set. Test that behavior explicitly if you are using a reasoning model.

What the model follows and what to test

DeepSeek follows role, tone and format instructions reliably in most cases. The areas that need explicit testing are constraints and refusals. A general scope description is often not enough; write the refusal case explicitly.

• Format: test your format instructions with inputs that would naturally produce a different format. If you ask for bullet points, test with a request that seems to call for a table.
• Refusals: if the model should decline certain requests, say so directly ("If asked about X, tell the user you cannot help with that") rather than relying on a general scope description.
• Language: if you specify a language, test with a user message in a different language and check that the model responds in the language you set.
• Length: length instructions like "under 150 words" need testing with questions that naturally produce longer answers.

See prompts for DeepSeek for user-turn prompt examples that complement your system instructions, and prompt engineering for a full guide to writing and testing AI instructions.

Common mistakes in DeepSeek system prompts

• Vague role descriptions: "be a helpful assistant" gives the model no specific guidance. Describe the role, the audience, and the constraints explicitly.
• Missing the refusal case: leaving out what the AI should do when a request is out of scope produces unpredictable behavior. Add a specific fallback instruction.
• Contradictory instructions: asking the model to be brief and comprehensive in the same prompt forces it to choose. Pick the priority and state it clearly.
• Treating reasoning model output as following the system prompt fully: DeepSeek's reasoning models think before answering. The system prompt shapes the final answer, but the thinking steps may go beyond the defined role.
• Not testing after a model update: DeepSeek releases updated models. Test your system prompt again when you switch model versions.

For the broader context around prompt injection, where a user message attempts to override your system instructions, see indirect prompt injection. That risk is relevant whenever your AI takes user input.

Storing and reusing tested prompts

A tested, working system prompt is worth keeping in a shared location. A prompt that lives only in the latest API call or a personal notes file creates problems when a colleague needs the same setup, when you switch tools, or when you need to compare two versions after a model update.

See context engineering vs prompt engineering for when improving the system prompt alone is not enough and broader session context management produces better results.

How to do this with fenbs

1. Create a free account and add a project for the work you are setting up DeepSeek for.
2. Draft a system prompt: role, always-do rules, never-do rules, fallback for out-of-scope requests.
3. Test the draft using the API with your real inputs. Include edge cases and out-of-scope requests in the test set.
4. Revise the prompt for each failure. Add concrete examples for cases where general instructions do not produce the right behavior.
5. Add the tested prompt as a skill in fenbs with a note on which DeepSeek model version it was tested on.
6. Record any recurring failures as Lessons so future prompts for similar roles start from what you already know.

When you move to a new DeepSeek model version, treat it as a new test run. Fetch the stored skill from fenbs, test it against your test set on the new model, and update the skill with the results. The record of what changed and why stays in History.

If a tested system prompt stops producing the expected output after a model update, the most likely cause is a change in how the new model weights the system role relative to user messages. Check the DeepSeek changelog at platform.deepseek.com↗ (opens in a new tab) for notes on behavior changes before revising the prompt itself.