Example-Based Prompting: Zero-Shot, One-Shot, and Few-Shot Explained
Compare zero-shot, one-shot, and few-shot prompting techniques with templates, examples, and guidance on when to use each approach.
Compare zero-shot, one-shot, and few-shot prompting techniques with templates, examples, and guidance on when to use each approach.
Most people talk to AI models the way they'd talk to a search engine: type a question, hit enter, hope for the best. That works fine until you need something specific, like a product description that matches your brand voice, or a code review formatted exactly the way your team expects. That's the moment you discover the real lever most people never touch: showing the model examples instead of just describing what you want.
This is the core idea behind example-based prompting, and it covers three related techniques: zero-shot, one-shot, and few-shot prompting. Each one trades off effort against precision, and knowing when to reach for which one can be the difference between a mediocre first draft and an output you can use immediately.
Every prompt you write asks a model to complete a pattern. When you give instructions only ("write a professional email declining a meeting"), the model has to guess what "professional" means to you specifically. It pulls from the statistical average of everything it has seen labeled "professional email" during training, which might not match your idea of professional at all.
Example-based prompting changes the game by giving the model a concrete pattern to follow. Instead of describing the destination, you show the model a map. You provide one or more input-output pairs, and the model infers the underlying rule connecting them, then applies that rule to your new input.
This matters because language is genuinely ambiguous. Words like "concise," "friendly," "technical," or "punchy" mean different things to different people and in different contexts. A single well-chosen example can convey nuances of tone, structure, and formatting that would take paragraphs of instructions to describe, and even then might not land correctly.
Example-based prompting is sometimes called "in-context learning" in research papers. The model isn't being retrained; it's using the examples in your prompt as temporary context to adjust its behavior for that single conversation.
Zero-shot prompting is the default mode most people use without realizing it has a name. You give the model a task description and maybe some constraints, but no examples of what the finished output should look like.
{{Task instruction describing what the model should produce}}
Requirements:
- {{Constraint 1}}
- {{Constraint 2}}
- {{Constraint 3}}
Write a product description for a wireless charging pad.
Requirements:
- Keep it under 60 words
- Highlight the fast-charging feature
- Use a confident but not salesy tone
Zero-shot works well when:
Zero-shot struggles when:
If you find yourself writing three or four sentences trying to describe what "the right tone" sounds like, stop. That's usually a signal you need an example instead of more instructions.
One-shot prompting adds exactly one example to your prompt. This single demonstration anchors the model's understanding of format, tone, length, and structure before it tackles your actual request.
Here is an example of the kind of {{output type}} I want:
Input: {{example input}}
Output: {{example output}}
Now do the same for this input:
Input: {{actual input}}
Here is an example of the kind of customer support reply I want:
Input: My order arrived damaged and I need a replacement.
Output: I'm really sorry to hear your order arrived damaged, that's frustrating and not the experience we want for you. I've already started a replacement order, and you'll receive a tracking number within 24 hours. No need to send the damaged item back, just dispose of it safely.
Now do the same for this input:
Input: My subscription renewed but I meant to cancel it last week.
One example is often enough to establish:
One-shot is a strong middle ground when you have a clear mental model of what "good" looks like but don't want to build out a full example library. It's also useful when token budget is a concern, since every example you add consumes context space and, in API use cases, costs money.
One-shot prompting reduces ambiguity but doesn't eliminate it. A single example can still be misread as a special case rather than a general pattern, especially if the example has an unusual feature the model latches onto by mistake.
Few-shot prompting extends the same idea with two or more examples, typically between two and five. More examples give the model a clearer signal about what varies (the actual content) versus what stays constant (the format, tone, and structure).
Follow the pattern shown in these examples:
Example 1
Input: {{input 1}}
Output: {{output 1}}
Example 2
Input: {{input 2}}
Output: {{output 2}}
Example 3
Input: {{input 3}}
Output: {{output 3}}
Now apply the same pattern to:
Input: {{actual input}}
Follow the pattern shown in these examples:
Example 1
Input: laptop, lightweight, good battery life
Output: Slim, portable, and built to last all day. This laptop goes wherever you do.
Example 2
Input: coffee maker, fast brewing, compact size
Output: Big flavor, small footprint. Brew a full pot before your coffee craving even peaks.
Example 3
Input: desk lamp, adjustable brightness, energy efficient
Output: Light that adapts to you, not the other way around. Bright when you need it, gentle on your energy bill.
Now apply the same pattern to:
Input: backpack, water-resistant, multiple compartments
Few-shot prompting shines in situations where:
The tradeoff is cost. Each example takes up context window space and, when working through an API, adds to your token usage on every single call. There's also a risk of overfitting: if all your examples share an incidental feature (say, they're all about electronics, or they're all under 15 words), the model may assume that feature is part of the required pattern rather than a coincidence.
Vary your examples deliberately. If you're building a few-shot prompt for product descriptions, include products from different categories and different lengths so the model learns the underlying pattern rather than memorizing surface details.
| Technique | Examples Provided | Best For | Tradeoff |
|---|---|---|---|
| Zero-shot | 0 | Common tasks, quick exploration, low stakes | Less predictable, harder to control tone/format |
| One-shot | 1 | Establishing tone and structure quickly | Model may over-generalize from a single case |
| Few-shot | 2 to 5+ | Structured, repeatable, or high-precision tasks | Higher token cost, risk of overfitting to shared traits |

There's no universal rule, but a few practical heuristics tend to hold up across most use cases.
Start with zero-shot and escalate only if needed. Write your instructions as clearly as you can first. If the output is close enough, you've saved yourself the effort of building examples. If it consistently misses the mark on tone or format, that's your cue to add an example.
Use one-shot when the task is subjective. Anything involving voice, tone, or "feel" benefits enormously from a single well-crafted example, because those qualities are hard to specify in words but easy to demonstrate.
Use few-shot when the task is structural or repeated. If you're extracting data into a consistent format, classifying text into categories, or running the same prompt template across hundreds of inputs, invest the time in three to five diverse examples. The upfront cost pays off in consistency.
Watch for diminishing returns. Research and practical experience both suggest that gains from additional examples taper off after four or five. Beyond that point, you're usually better off refining the quality of your existing examples rather than adding more.
The quality of your examples matters more than the quantity. Two carefully chosen, diverse examples will usually outperform five examples that are all slight variations of the same idea.
Even with the right technique, a few habits can undermine example-based prompting.
Inconsistent formatting between examples. If your first example uses bullet points and your second uses a paragraph, the model doesn't know which format is the actual requirement. Keep the structure identical across every example; only the content should change.
Examples that don't match the real task's difficulty. If your real inputs are messy, ambiguous, or long, but your examples are all clean and short, the model won't have learned how to handle the harder cases it will actually face.
Forgetting to label inputs and outputs clearly. Ambiguity about where an example ends and the actual task begins is a common source of confused, blended responses. Use clear labels like "Input" and "Output," or wrap examples in delimiters, so the model can reliably separate demonstration from instruction.
Overloading with too many examples. Beyond the point of diminishing returns, extra examples mostly add noise, cost more tokens, and can dilute the pattern rather than reinforce it.
Using examples that contain the exact same content type as your real request. If you're worried about the model copying phrases rather than learning structure, make sure your final input differs meaningfully from your examples in subject matter while keeping the same shape.
Think of these three techniques not as separate tools you pick once, but as a spectrum you move along as a task evolves. A first draft of a new content pipeline might start zero-shot while you're still figuring out what "good" looks like. Once you land on a style you like, you convert that into a one-shot example to lock in the tone. As the pipeline scales and you start encountering edge cases, you expand to few-shot with three or four representative examples covering the range of inputs you expect.
This progression mirrors how a human would train a new team member: describe the task first, show one good example if the description alone doesn't land, then provide a handful of varied examples once the person needs to handle a wider range of real situations consistently. Example-based prompting simply applies the same intuition to working with an AI model, and it's one of the highest-leverage skills you can build if you want reliable, on-brand output instead of generic first drafts.
Zero-shot relies entirely on instructions with no examples, while few-shot provides two or more input-output pairs so the model can infer the pattern directly from demonstrations rather than a description alone.
No. Gains typically level off after three to five examples, and adding too many can introduce noise or cause the model to latch onto incidental similarities between examples instead of the actual pattern you want.
Yes, and it's often the most effective approach. Pairing clear written instructions with one or two well-chosen examples gives the model both an explicit rule and a concrete demonstration to follow.
Use one-shot when your main goal is establishing tone, voice, or general structure, and token budget or prompt length is a concern. Reserve few-shot for tasks requiring strict consistency across varied inputs, like data extraction or classification.
This usually happens when examples are too similar to the real input in subject matter, or when the pattern isn't distinct enough from the specific wording. Vary the topics and phrasing across your examples so the model learns the structure rather than memorizing the content.