DeepSeek 破甲提示词: structure template and 5 checks

A 破甲提示词 is worth writing only when it is a reviewable instruction, not a spell. Complete structure, clear variables, and explicit boundaries are the basis for asking why it failed.

Four-part structure: role, task, constraint, output

A reviewable prompt has at least four sections. Missing one makes failure impossible to attribute.

Order matters. Role and task come first, constraint and output last; putting constraints at the end lets long preceding text dilute them.

Structure is not length. Keep only necessary information in each section and avoid repetition; repeated constraints compete and reduce stability.

Role: the judgment standard

The role is not a costume; it changes the judgment standard. The same task looks different to a reviewer and an executor.

Common mistakes:

• Role conflicts with task: the role is "unrestricted" while the task requires rules;
• Stacked roles: several identities at once, with no priority;
• Abstract roles: "you are an expert" without saying what the expert attends to.

How to write it: one layer, stating what to attend to and what to judge by, with no personality detail unrelated to the task. A specific role makes later execution more stable.

Task: comparability

The task should be clear enough that another person knows what to do. A vague task makes results incomparable and failure unattributable.

Common mistakes:

• A one-line task without input, scope, or completion criteria;
• Constraints mixed into the task, blurring primary and secondary goals;
• Several tasks at once with no priority.

How to write it: use verb-object structure, state input, processing scope, and completion conditions; number multiple tasks and mark priority. Avoid "as much as possible" or "appropriately," which cannot be verified.

Constraint: clear boundaries

Constraints are the most often omitted section and the one that most affects compliance. They state what the model must not do and how to handle conflicts.

Common mistakes:

• "Do not violate rules" with no conflict handling;
• Constraints conflicting with the task, forcing a binary choice;
• Constraints placed at the end and diluted by long context.

How to write it: combine negative statements with priority statements: first what not to do, then the order to follow in conflicts. Constraints must be judgeable; avoid subjective words like "appropriate" or "safe."

Output: verifiability

The output section determines whether a result can be checked. Without a format, every run produces a different structure and comparison is impossible.

Common mistakes:

• "Explain in detail" with no fields;
• A format that does not match the task, such as a table for a narrative task;
• No length limit, causing truncation.

How to write it: specify structure, fields, and a length cap; use fixed fields for machine checks and fixed sections for human reading. Once fixed, later comparisons have a baseline.

Variable substitution: structure or scenario?

When a prompt fails, substitute variables before rewriting the whole thing. Replace scenario-bound parts with placeholders and change only the variables.

1. Mark every part tied to a specific scenario: object, scope, format, examples.
2. Replace them with placeholders while keeping the structure unchanged.
3. Run once with two different variable sets and compare.
4. Differences only in variable-related parts mean the structure is fine; differences everywhere mean the structure depends on a variable.

The value is isolation. Without it, you never know whether failure comes from structural conflict or scenario mismatch.

Five checks: is this prompt worth keeping?

A prompt is worth keeping when it passes five checks, not when it succeeded once.

1. Verifiable: results have clear correctness or checkable fields, not subjective feel.
2. Not copied: the structure comes from the task, not from a template copied elsewhere.
3. Bounded: it states what not to do and how to handle conflicts, judgeably.
4. Reproducible: same version, entry, and context produce stable results.
5. Reversible: changes have before-and-after records, so you can roll back.

The most ignored check is reversibility. Without version records, a bad change means starting over; keeping structure and results per revision lowers diagnosis cost.

When to stop rewriting

Three situations mean further prompt edits have low value.

1. All three layers point to the request itself being disallowed. Structure changes will not change the conclusion.
2. It requires unauthorized environments or someone else's account. Outside prompt discussion.
3. The result cannot serve a legitimate purpose. Even if possible, do not continue.

Stopping is a judgment, not a failure. Moving from "one more revision" to "a compliant goal" is usually more productive.

Next steps

Structure first, variables second, boundaries last. For word-level signals, read DeepSeek 破甲词: 3 types and failure checks. For the three-layer test, read Why old DeepSeek jailbreak prompts fail. For compliant assessment, read What DeepSeek Harness 破甲 means.

Sources: DeepSeek Harness docs, DeepSeek Terms of Service