Prompt Engineering from Scratch · Lesson 2
Examples (Few-Shot) and Answer Tone
How a few examples in the prompt make the model grasp format and style better than long explanations.
Practical exercise
What to do after this lesson
Build a prompt that turns your notes into meetings / tasks. Give it 3 examples. Run it on a new note — did it get better?
Task grader
Build a prompt that turns your notes into meetings / tasks. Give it 3 examples. Run it on a new note — did it get better?
Ready-to-use prompt
Template for this lesson
Copy and adapt to your context. Text in angle brackets should be replaced.
I want to teach you a task through examples. Below are 3 "input → output" pairs I want you to follow. After them I'll give a new input; answer in the same format. Example 1: input: <...> output: <...> Example 2: input: <...> output: <...> Example 3: input: <...> output: <...> New input: <...>
Prompt sandbox
Common mistakes
What people get wrong
- They supply inconsistent examples (different format) — the model gets confused.
- They supply too many examples (10+) — the context gets cluttered.
- They pick examples of one type, so the model breaks on a different type.
Pro tips
What works but no one documents
- If you want JSON output, you must show JSON in the example, not describe it in words.
- For tone, add a counter-example of "how not to do it" tagged "BAD".
- Put an "edge case" example last so the model sees the boundaries.
When to use
When format is critical (JSON, classification, a specific style).
When not to use
When the task is creative and format doesn't matter — examples can box the model in.
Official sources
Quiz — 2 questions
1.How many examples are usually enough for few-shot?
2.When does few-shot work best?
Answered: 0 of 2
Discussion
No comments yet. Be the first!