DeepSeek 破甲词: 3 types, signals and failure checks

A 破甲词 is not a list to collect; it is the least stable layer in the word, prompt, and model stack. The same word can produce opposite results across contexts, versions, and hosts.

Separate the three layers first

Before discussing 破甲词, separate word, prompt, and model. Mixing them sends diagnosis in the wrong direction from the start.

The word is the smallest unit and rarely forms an effective instruction alone. It needs to sit inside a prompt and draw on context, so memorizing a word has limited value.

The prompt is how words are organized. The same word behaves differently at the beginning, at the end, or in the system prompt; this is why copying a template into your own scenario often fails.

A modified model is a different route. It does not rely on words but changes the model's safety alignment; the compliance risk is more direct and outside prompt discussion (source).

Three common structures: form, not wording

The many variants people share collapse into three structures. Understanding the form is more useful than collecting originals and less likely to leave you stuck on one template.

1. Role substitution: ask the model to assume another role so the request is framed differently. It fails when the role conflicts with a clearer safety constraint.
2. Task reframing: wrap the request as analysis, translation, or review. It fails when the stated task and the real intent diverge, and the model returns to the original request.
3. Format constraints: use output formats, step requirements, or field templates to change the generation path. It fails when format constraints conflict with safety judgment.

All three assume that changing the wording changes the judgment. That assumption occasionally held for earlier models and is increasingly unreliable now; more complex structures create more conflict points.

Do not chase fancier structures. Stacking role, task, and format lets instructions override each other; a clear, ordinary request often works better.

Success signals: did the word matter?

Do not judge by a single success. The model may have answered a permitted question anyway; run a comparison.

1. Single-variable comparison: remove the target word and change nothing else; no difference means the word did not matter.
2. Repeat: run the same condition several times; a one-off success is not evidence.
3. Change context: run it in a short and a long session; working in only one means it depends on setup.
4. Change entry: try CLI, web, and desktop; different results point to the host layer, not the word.

All four steps are needed before saying the word works. Only the first confuses luck with a pattern; only the last two misassign host problems to the word.

A real signal is reproducible. Same condition, version, and entry, repeated results consistent; anything else is "it happened once."

Failure signals: five observable signs

Word failure is not silent; five signs are observable. Two or more mean stop adding words and return to layer diagnosis.

1. The refusal reason becomes specific. From a generic "cannot" to naming the rule, the model recognized the intent.
2. The answer gets short but is not refused. Often output limits or compaction, not word failure, but the effect looks worse.
3. The same template diverges across sessions. The effect depends on context rather than the word.
4. It stops working in another entry. Interception happens at the host layer; the word never reached the model.
5. Several revisions change nothing. The direction is wrong; more edits only add noise.

The fourth sign is the most ignored. Repeatedly testing in one entry never reveals host-side interception logs.

Why the word-list approach is fading

Treating 破甲词 as a word list has three structural flaws.

1. Words depend on context. The same word behaves differently with and without setup; a list stores words but not contexts.
2. Words get recognized. Widely shared words enter filtering and training samples; the larger the list, the more homogeneous it becomes.
3. Words do not solve layer problems. Model refusal, host interception, and prompt rules are three layers; words only affect the last one.

The alternative is structured assessment records. Record not "which word works" but "under what conditions, at which layer, which signal appeared." Only that record is reusable.

If you keep a word list: compliant practice

Keeping a list is not the problem; the purpose is.

1. Limit the environment: test only on owned or authorized instances, never real user traffic.
2. Limit the record: record trigger conditions, layer, impact, and remediation, not copyable wording.
3. Limit the use: give results to the fixer for hardening; do not publish the list.
4. Limit retention: clean test data after the assessment rather than keeping the list indefinitely.

The output of a compliant assessment is a problem list, not a bypass manual. That is also the simplest boundary test: is the material helping you fix or helping you bypass?

Boundary: when to stop

Three situations mean further attempts have low value.

1. All three layers point to "the request itself is not permitted." More words produce firmer refusals.
2. It requires unauthorized environments or someone else's account. That is outside prompt discussion.
3. The result cannot serve a legitimate purpose. Even if technically possible, do not continue.

The boundary is a use limit, not a technical limit. Understanding it puts effort where it can produce something.

Next steps

Identify the layer before discussing words. For the full three-layer test, read Why old DeepSeek jailbreak prompts fail. For the mechanics of the three structures, read How DeepSeek Harness jailbreak prompts work. For compliant assessment, read What DeepSeek Harness 破甲 means.

Sources: DeepSeek Harness docs, DeepSeek Terms of Service