大模型网摘Writing Self-Check Instructions for DeepSeek: Make the Model Review Before It Answers
People often blame unstable model outputs on the model, but the prompt is frequently at fault: it contains "requirements" but no "acceptance criteria." DeepSeek's R-series offers switchable deep-thinking mode for complex reasoning, while the V-series handles general conversation. Both respond well to structured constraints rather than roleplay theatrics. This article covers a cheap way to raise quality: write the inspection rules into the prompt so the model acts as its own QA, then spot-check the results yourself.
1. The Essence: Move Acceptance Criteria Upfront
A typical prompt is "task + requirements" — the model produces output in one shot, and you only notice errors afterward. A self-check instruction adds a gate: task + requirements + check list. The trick isn't fancy wording; it's translating vague expectations into items that can be judged one by one. "Don't be too wordy" is vague; "keep the body under 300 words; if over, cut secondary arguments" is judgeable.
When writing the list:
1. Each check item maps to one hard constraint (word count, format, required fields, banned words). 2. Each item should have an objective yes/no answer — avoid subjective words like "better" or "more professional." 3. Specify what to do when a check fails: fix silently and output, or flag it for your decision.
2. V-Series: A Pre-Output Checklist Template
The V-series fits daily conversation and mid-complexity tasks. Just append a self-check section to the prompt. Copy-ready template:
[Task] Write an event notice for our smart-home app, aimed at existing buyers, announcing 20% off on March membership renewals. [Hard Constraints] 1. Body under 120 characters, plus a title on its own line (under 15 characters). 2. Must include: event period, discount rate, renewal entry name "My - Membership Center". 3. No more than 2 exclamation marks; no superlative claims like "best deal ever". 4. Tone: customer-service notice, not marketing SMS. [Pre-Output Self-Check] Before answering, verify each of the 4 constraints above: - Over the character limit? If so, cut secondary sentences. - All three required pieces of info present? If not, add them. - Exclamation count and banned wording compliant? If not, rephrase. Output only the final version once all checks pass — do not show the checking process.
Note the last line "do not show the checking process" — for the V-series, which has no separate thinking toggle, internalizing the check before generation keeps output clean. If the task requires an audit trail, change it to "list the check results under a 'Self-Check' section."
3. R-Series: Make Deep Thinking Cover Verification
R-series deep thinking already reasons step by step; the best use of self-check instructions is to make verification an explicit step in that reasoning, not an afterthought. Ideal for math, code, and multi-condition reasoning where errors are costly. Template:
[Problem] A warehouse holds 58 boxes total of types A and B. Type A holds 12 items per box, type B holds 18 items per box; total items = 876. How many boxes of each type? [Requirements] 1. In your thinking, follow three steps: set up equations → solve → verify. Do not skip verification. 2. Verification method: substitute the solution back into both original conditions, confirming box count and item count separately. 3. If verification fails, revisit the equation setup, correct it, and verify again. 4. Final answer must contain only: number of A boxes, number of B boxes, one verification equation.
For the R-series, roleplay-style prompts ("you are a veteran math professor") add little; clearly written constraints and verification steps are the real lever. Also note: a one-equation problem like the above doesn't need deep thinking at all — the V-series handles it fine. Save the R-series for multi-variable, multi-branch reasoning; it saves both money and time (API is usage-based; see the official page for exact pricing).
4. Code: Have the Model Run a Mental Test Pass
DeepSeek's coding strength pairs well with self-checks. The key is changing "write it and done" into "write it + walkthrough + build test cases":
[Task] Write a Python function parse_duration(s: str) -> int that converts strings like "1h30m", "45s", "2d" into seconds, supporting h/m/s/d combinations; return -1 for invalid input. [Self-Check Requirements] After finishing the code, do the following in order: 1. Walk through edge cases: empty string, "0m", "1h30m20s", out-of-order like "30s1h", illegal characters like "1x". 2. For each case, first derive the expected output by hand, then check line by line whether your implementation produces it. 3. On mismatch, fix the code and repeat the walkthrough. 4. Final output: the corrected full code + a "case → expected → actual" comparison table.
The same templates work if you run open-weight versions locally — self-check instructions rely on no cloud-specific features; they operate purely at the prompt level.
5. Self-Check Isn't a Free Pass: Your Verification Duties
Letting the model self-check doesn't mean you can stop reviewing. Models may reinterpret a check item just to "pass," or fix one issue while introducing another. Low-cost verification methods:
1. Spot-check hard constraints: word count, format, required fields — anything confirmable by eye or script in 10 seconds — check every time. 2. Make verification recomputable: for code, actually run the comparison table locally; for math, plug the verification equation back in. 3. Build a feedback loop: when a type of error keeps appearing, add it as a new check item — the list gets sharper with use. 4. Layer the usage: drafts get minimal or no self-check; deliverables get the full list. Don't gate everything.
The value of self-check instructions is turning problems you would have caught into problems the model catches first. Write clear constraints, leave room for verification, and spot-check as a backstop — do all three and your output quality steps up a level.