DeepSeek API 破甲: calls, parameters and log checks

API-level 破甲 is not the same environment as the web UI. The API removes interface prompts but adds explicit system prompts, parameters, and authentication; a web-working phrase may need restructuring.

Three differences from the web UI

Understand the differences before testing.

Instruction entry differs. In the web UI the system prompt is controlled by the product; the API exposes both layers, which is freer and easier to get wrong.

Parameters differ. Temperature, max output, and stop sequences affect results; the web UI usually uses defaults, while the API requires explicit values (source).

Interception differs. API 4xx errors are mostly authentication or parameters; a model refusal is a 200 response with content-level judgment.

Before calling

Three preparations; missing one produces misleading results.

1. Model: confirm name and version; behavior differs across versions.
2. Key: valid, permitted, and matched to the endpoint.
3. Endpoint: confirm base URL and protocol to avoid mixing 404 with authentication.
4. Parameters: fix a baseline set before comparing.
5. Logging: enable request logs and record parameters and responses.

A baseline matters. Change one parameter at a time; changing three means neither success nor failure is attributable. Get a minimal request working before complex structures.

Where prompts and parameters go

Position decides priority; priority decides the result.

1. System prompt: role, boundaries, output format; effective every turn.
2. User message: the specific task and input; changes per turn.
3. History: carries context but may be compacted; do not rely on it for key constraints.
4. Parameters: length, randomness, and stop conditions; tune separately from prompts.
5. Tool definitions: declare function calling separately, not inside natural language.

Put key constraints in the system prompt. In user messages they get diluted; in history they may be compacted away. Put the task in the user message; repeating it in the system prompt wastes tokens and blurs boundaries.

Three verification layers

Verify request, response, and logs.

1. Request: parameters, model, and system prompt match intent; confirm with logs.
2. Response: status code, structure, refusal; handle 4xx and 200 separately.
3. Logs: time, model, parameters, and response summary for reproduction.

The request layer is the most error-prone. You may send B while thinking A; log inspection reveals it.

The response layer must separate refusal from failure. A refusal is a model judgment; a failure is a request problem.

The log layer is the basis for reproduction. Without request records, success and failure cannot be explained.

Four common failures

Four failure classes dominate the API layer.

1. 401/403: invalid or unauthorized key; check key and endpoint pairing.
2. 400: missing or invalid parameters, or malformed messages; read the error body.
3. 404: wrong endpoint or model name; check base URL and model list.
4. 200 with refusal: model judgment; change the goal, not parameters.

Classify by status code first. Do not assign 4xx to model behavior or 200 to authentication.

The error body is more specific than the code. It usually names the field and reason.

Compliance boundaries

API-level testing has boundaries too.

1. Authorized environment: your own keys and authorized instances.
2. Test data: fictional or desensitized data, no real sensitive information.
3. Purpose: results for remediation, not production bypass.
4. Terms: API usage is subject to the same terms (source).

Parameters are tunable; boundaries are not. Changing temperature is normal; bypassing safety policy for production is out of scope.

Reports record conditions, not recipes. Trigger conditions, impact, and remediation are worth more than parameter combinations.

Next steps

Align the environment, fix a baseline, read logs. For term boundaries, read 破甲, 破限 and jailbreak. For prompt structure, read DeepSeek 破甲提示词: structure and 5 checks. For integration entries, read DeepSeek Harness SDK.

Sources: DeepSeek API docs, DeepSeek Harness docs, DeepSeek Terms of Service