Stage 2 — Core Prompt Patterns

At this stage you move from “writing text” to reproducible prompt engineering patterns.

Stage topics

• Zero-shot / One-shot / Few-shot
• Role prompting
• Output format prompting
• Step-by-step / Chain of Thought (controlled)
• Constraints prompting

Zero-shot, One-shot, Few-shot

• Zero-shot: instruction only.
• One-shot: one reference example.
• Few-shot: multiple target examples.

Few-shot often boosts quality significantly because the model sees the target response pattern.

Role prompting

Role defines behavior framing: “you are a senior reviewer”, “you are a data analyst”.
This is not magic, it shifts output distribution toward desired style and depth.

Format prompting

Always define output format explicitly:

• JSON,
• table,
• list,
• fixed fields.

If format is not specified, model chooses it implicitly, which usually hurts integration reliability.

Step-by-step and Chain of Thought

“Think step by step” can improve difficult tasks.
But in production, controlled final format and verification matter more than verbose reasoning text.

Constraints prompting

Good constraints are:

• testable,
• specific,
• non-conflicting.

Examples: length, structure, forbidden actions, allowed sources.

Choosing the right pattern

Pattern choice depends on how much target behavior is already obvious. Zero-shot is best when you want to test the raw instruction and discover the model's default interpretation. One-shot is useful when one example can remove ambiguity. Few-shot becomes important when the task has a recognizable style, repeated structure, or domain-specific judgment that the model should imitate.

Beginner explanation

Zero-shot means you do not show the model an example answer. You only give an instruction: “Write a product description in 3 sentences.” This is fine when the task is simple and the criteria are obvious. For example, short translation or a simple definition often works with zero-shot. But if the team has a special style, fixed structure, or evaluation rules, one instruction is often not enough.

One-shot means you provide one example. The example acts as a sample: the model sees answer length, allowed wording, fields, and level of detail. Few-shot means several examples. It is useful when one example does not cover the range of inputs. For example, support-ticket classification may include billing, bug, feature request, and security. One example shows one case; several examples show the pattern.

Important: examples are not decoration. They are training samples inside the prompt. If an example is weak, the model copies weak style. If an example is too long, answers become longer. If an example misses an edge case, the model may fail on a similar edge case. Treat examples like test fixtures.

Few-shot example:

Classify the request as billing, bug, or feature_request.

Example 1:
Request: "My plan did not update after payment"
Answer: billing

Example 2:
Request: "The save button does not work"
Answer: bug

Example 3:
Request: "Please add PDF export"
Answer: feature_request

Request: "My card was charged twice"
Answer:

In production, few-shot is especially useful when the model must repeat team judgment: tone of voice, ticket labeling, classification, quality evaluation, or data formatting. But few-shot increases prompt size, so examples should be short and representative.

The main risk is using examples that are not actually excellent. The model treats examples as evidence of the desired pattern, including their weaknesses. If an example is too verbose, the output becomes verbose. If an example hides edge cases, the model may repeat that blind spot. In production, examples should be treated as test fixtures: reviewed, versioned, and replaced when the product behavior changes.

What you must be able to explain

• Why few-shot often improves production quality sharply.
• Why output format should almost always be explicit.
• Why unbounded free text scales poorly.

Mini scenarios from real projects

• Zero-shot gives generic output without business context: adding 1-2 relevant examples significantly improves precision.
• Few-shot makes output worse: examples conflict with desired style or include weak patterns.
• A role is declared but has no effect: role definition lacks explicit responsibility and quality criteria.

Fast decision rules

• If the task is template-like and format-sensitive, start with few-shot.
• If the task is new and you want baseline behavior, start zero-shot and iterate.
• Every few-shot example must be a gold standard, not a rough draft.

Self-check questions

1. Why does few-shot often produce a large quality jump over zero-shot?
2. How do you detect that few-shot examples are harming output quality?
3. Which matters more for deterministic machine-readable output: role or format?