大模型网摘A Four-Part Prompt Skeleton for Code Generation: Requirements, I/O, Constraints, Negative Examples
When asking DeepSeek to write code, the most common cause of failure isn't the model—it's an unclear request. One-liners like "write me a web scraper" leave the model guessing. Here's a four-part skeleton I use all the time: requirements, input/output, constraints, and negative examples. It skips the fancy role-play openers, which fits how DeepSeek actually works: reasoning and coding ability is the foundation, and the more structured and explicit your constraints, the more reliable the output. Piling on phrases like "you are a senior architect" does little for the R-series deep-thinking models—what they respond to is a clear spec, not a persona.
Breaking Down the Skeleton: What Goes in Each Part
Part 1: Requirements. State in one or two sentences what the feature should do and what problem it solves—no detours. "Write a function that flattens nested JSON into dot-separated keys" beats "help me process JSON" by a mile.
Part 2: Input/Output. This is the part most prompts skip. Provide a concrete input sample and the expected output sample; the model understands "follow this example" far better than prose descriptions. Also spell out types and edge cases (empty values, very long inputs, invalid formats) here.
Part 3: Constraints. Language version, framework, dependency limits, performance requirements, code style—use a checklist wherever possible. Deep-thinking models take every hard constraint seriously; this is where the real gap opens up.
Part 4: Negative examples. Explicitly say what NOT to do and what counts as wrong. For example: "don't parse HTML with regex," "don't import any third-party library besides pandas." Negative examples block the model's most common shortcuts.
Template 1: General Code Generation
text
[Requirements]
Write a Python function flatten_json(obj) that flattens a dictionary nested
to arbitrary depth into a single level, joining nested keys with dots.
[Input/Output]
Input example: {"a": {"b": 1, "c": {"d": [1, 2]}}}
Output example: {"a.b": 1, "a.c.d": [1, 2]}
Do not expand lists into indexed keys; keep each list as a single value.
[Constraints]
1. Standard library only; no third-party dependencies
2. Python 3.10+ syntax
3. Include 3 pytest test cases covering empty dict, list nesting, and deep nesting
4. Write comments in Chinese for the key logic
[Negative examples]
- No unbounded recursion: raise ValueError beyond 50 levels of depth
- Do not mutate the original input object
- Do not return keys with list indices (e.g., a.c.d.0)
Note constraint #1 in Part 3, "no third-party dependencies." Without it, the model will happily import pandas, and your deployment environment breaks. That's exactly where the constraints section earns its keep.
Template 2: Bug Fixing / Code Refactoring
Modifying existing code goes wrong more often than generating from scratch, because the model loves to "refactor on the side." The four-part skeleton works here too:
text [Requirements] The following FastAPI endpoint occasionally returns 500 under high concurrency. Identify the root cause and provide the complete fixed code. [Input/Output] Input: existing code (see the code block below) Output: 1. Root-cause analysis (max 5 lines); 2. the complete fixed file; 3. an itemized list of changes. [Constraints] 1. Fix only the concurrency issue; do not change the endpoint signature or response structure 2. Keep dependency versions as-is per requirements.txt; no upgrades 3. For any shared state, clearly justify the choice between locking and a stateless approach [Negative examples] - Do not rewrite unrelated functions - Do not introduce new middleware or a caching layer - No hedging language like "possibly" or "you might consider"—give conclusions and code directly Existing code:
python (paste your code here)
The last negative example deserves a callout: "no hedging language" is especially effective with the R-series deep-thinking models. With thinking mode on, the model reasons internally before answering, and this constraint channels that reasoning into actionable judgments instead of a pile of disclaimers.
When to Turn On Deep Thinking
Once the skeleton is filled in, you still need to decide whether to enable the R-series thinking mode. Rule of thumb: for single-file, straightforward tasks (CRUD, format conversion, simple scripts), the V-series standard chat mode is enough and responds faster. For algorithm design, tricky debugging, or multi-module architecture trade-offs, turn on deep thinking. The test is simple—if you'd need to sketch it out yourself to reason it through, enable thinking; if you can see the answer at a glance, don't.
Save this skeleton as a snippet template. Spending two minutes filling it in before each generation saves you from reworking the code three rounds later.