Prompt Engineering Guide
Zero-shot = just ask. Few-shot = show 2-5 worked examples in the prompt so the model imitates the pattern instead of guessing your intent.
In plain terms
Telling a new hire 'label these support tickets by urgency' (zero-shot) gets inconsistent results - their idea of 'urgent' differs from yours. Show them three already-labeled tickets first (few-shot) and they calibrate instantly. Models are exactly that new hire.
Why it matters
Half of 'bad model output' is really under-specified intent. Examples communicate format, tone, edge-case handling and labeling standards far more precisely than any description - showing beats telling.
How it works
Structure: instruction -> examples as input/output pairs -> the real input. Example quality dominates: cover the tricky cases (an ambiguous ticket, an empty field), keep formatting perfectly consistent across examples, and order them randomly (models over-imitate the last example). 2-5 well-chosen examples usually saturate the benefit.
When you use it
Zero-shot first - modern models are strong. Add few-shot when: output format wanders, labels are inconsistent, the task has house rules ('we count billing complaints as high priority'), or tone must match a brand.
Common mistakes
- Examples that are all easy - the model learns nothing about the edge cases where it actually fails.
- Examples with inconsistent formatting, teaching the model that format is optional.
- Cramming 30 examples in - past a handful you're paying tokens for nothing (that's when fine-tuning enters the conversation).
Best practices
- Pull examples from real production failures - each one is a lesson the model needs.
- Balance categories in classification examples (don't show 4 'urgent' and 1 'low').
- Keep a test set separate from your prompt examples, or you're grading the model on questions it saw.
Try it yourself
Task: classify tweets as complaint / question / praise. Run 10 tweets zero-shot, note the errors, then add 3 examples targeting exactly those errors. Measure the improvement.
Deep dive
Prompt engineering is the craft of giving a model clear intent, context, constraints, examples, and output rules so it can produce useful results reliably.
What it is
Prompt engineering is not magic wording. It is specification design for probabilistic software.
Why it matters
Most poor model output comes from missing context, vague criteria, or conflicting instructions.
How it works
Write the task clearly, show examples when format matters, define failure behavior, and test the prompt against real cases.
Common mistakes
- Using vague quality words like better or engaging.
- Burying constraints in long paragraphs.
- Changing many prompt variables at once.
Best practices
- Version important prompts.
- Keep a small eval set.
- Use structured output when code consumes the result.
Practical workflow
role + task + context + constraints + examples + output formatResources
- Prompt Engineering Guide - Few-shot Concise, example-driven reference.
FAQ
Is prompt engineering still useful with better models?
Yes. Better models still need clear goals, context, constraints, and evaluation.
Should prompts be tested?
Yes. Treat production prompts like code and test them against fixed cases.