Core Prompting Techniques

Zero-shot vs. few-shot prompting#

Zero-shot prompting means asking the model to perform a task with no examples at all — just an instruction. Modern LLMs are often good enough at this for straightforward tasks.

Classify the sentiment of this review as positive, negative, or neutral:

"The battery life is disappointing, but the camera quality is excellent."

Few-shot prompting means giving the model a small number of worked examples before the actual task, so it can infer the exact pattern, format, or edge-case handling you want — useful when the task has a specific format or judgment call that's easier to demonstrate than to describe in words.

Classify the sentiment of each review as positive, negative, or neutral.

Review: "Fast shipping and works exactly as described."
Sentiment: positive

Review: "Arrived broken and support never responded."
Sentiment: negative

Review: "The battery life is disappointing, but the camera quality is excellent."
Sentiment:

Given the mixed review in the last example, a zero-shot prompt might inconsistently pick positive, negative, or an unrequested "mixed" — a plausible-sounding answer that doesn't actually fit your three allowed categories. The few-shot version, by showing two prior examples that each commit to a single label, makes the model far more likely to reliably return exactly one of your three defined categories, even for the ambiguous case.

Chain-of-thought prompting#

Language models are often noticeably more accurate on multi-step problems — arithmetic, logic, multi-part reasoning — when explicitly asked to reason through the steps before giving a final answer, rather than jumping straight to it. This is called chain-of-thought (CoT) prompting.

Without CoT:

A store had 120 apples. They sold 35% of them in the morning and 28 more in
the afternoon. How many apples are left?
Answer:

A model asked to jump straight to an answer sometimes skips or miscombines one of the two steps involved.

With CoT:

A store had 120 apples. They sold 35% of them in the morning and 28 more in
the afternoon. How many apples are left?

Think through this step by step, then give the final answer.

This nudges the model to produce (and be guided by) intermediate reasoning explicitly:

Step 1: 35% of 120 = 42 apples sold in the morning.
Step 2: Remaining after morning: 120 - 42 = 78.
Step 3: Afternoon sales: 28 more sold, so 78 - 28 = 50.
Final answer: 50 apples.

Explicitly generating each intermediate step means each step only has to be locally correct, and errors are easier to catch (by you, or by the model itself in a follow-up check) than when the model has to silently do all the arithmetic and combine it in one leap. This effect is most pronounced on tasks that genuinely require multiple dependent steps — it does very little for tasks that are already a single lookup or a single simple transformation.

System prompts vs. user prompts#

Most chat-based LLM APIs distinguish between two (or more) roles in a conversation:

• System prompt — sets the model's persona, rules, and constraints for the entire conversation: "You are a customer support agent for a software company. Only answer questions about our product. Never make up pricing information — if you don't know, say so and offer to connect the user with a human." It's set once, typically by the application developer, not the end user.
• User prompt — the specific request or message for this turn of the conversation: "How do I reset my password?"

Splitting responsibility this way keeps behavioral rules and per-turn requests cleanly separated: the system prompt holds the stuff that should be true for every single message in the conversation (persona, scope, safety constraints, output format defaults), while the user prompt holds only what's specific to this particular question. This also means an application can swap out user questions freely across a whole conversation without having to repeat the standing rules every single time.

{
  "messages": [
    { "role": "system", "content": "You are a concise, factual customer support agent. Only answer questions about billing and account settings." },
    { "role": "user", "content": "How do I update my card on file?" }
  ]
}

Common mistakes#

• Using few-shot examples that are all the same "shape," so the model overfits to superficial patterns in your examples (for example, every positive example being long and every negative one short) instead of the actual distinction you meant to teach.
• Asking for chain-of-thought reasoning on a task simple enough that it adds latency and cost without improving accuracy — it helps most on genuinely multi-step problems, not single-fact lookups.
• Putting per-conversation, one-off instructions in the system prompt (or, conversely, putting standing behavioral rules in the user prompt) — this makes the rules inconsistent across turns and harder to maintain as the application grows.