How to use examples to demonstrate a format to AI
Examples in a prompt demonstrate the input-output pattern you expect from AI. They are especially useful when the desired structure is difficult to describe through adjectives such as “organized” or “standardized”.
In this tutorial, you will build a small demonstration for turning fictional requests into tracking records. The focus is task format rather than permanent model training.
1. Define the rule before examples
Write down which output fields are required and what each means. Without defined categories, similar examples may demonstrate contradictory patterns.
This exercise uses subject, requested action and stated deadline. The system should not invent a deadline when a message does not include one.
2. Choose cases teaching different things
A complete case shows the usual path; an incomplete one defines handling of gaps. A third can clarify ambiguity common in your work.
Google’s prompt strategies describe using examples to guide answers. The actual selection should reflect your goal and permitted material.
| Case | What it demonstrates |
|---|---|
| Complete request | Filling the fields |
| Missing deadline | Marker for information not found |
| Two actions | Rule for separating items |
| Ambiguous sentence | Request for human review |
3. Keep the demonstration consistent
Use identical field names, categories and markers across examples. Alternating between “no deadline”, an empty value and an invented date demonstrates three incompatible behaviors.
Check the examples themselves before supplying them. A demonstration error may recur in the output even when the general instruction looks correct.
Keep each example small enough to inspect. If an example contains unnecessary background, it may imply a relationship between that background and the output that you did not intend to teach.
4. Test with an unseen input
Reserve a case absent from the demonstration. It helps check whether the system applies the rule rather than simply repeating a shown solution.
Turn fictional messages into records with subject, action and deadline fields.
Do not infer dates or owners.
When a deadline is absent, write “not stated”.
EXAMPLE 1
Input: “I need to review the manual by Friday.”
Output: subject=manual; action=review; deadline=Friday.
EXAMPLE 2
Input: “I want to confirm receipt of the proposal.”
Output: subject=proposal; action=confirm receipt; deadline=not stated.
NEW CASE
“Check the presentation and send a list of corrections.”
Explain separately any uncertainty preventing you from filling the fields.Read the new record and look for information absent from the message. An attractive format still needs fidelity to the content.
5. Add exceptions intentionally
If testing reveals a repeated failure, add an example clarifying that boundary. Do not enlarge the collection merely to make the request longer.
Keep a small set of cases outside the demonstration for repeated evaluation. If every test becomes an example, you lose an independent way to observe behavior.
Include a test in which word order changes while the action stays the same. This shows whether the tool recognizes the requested pattern without depending on the precise wording used in the demonstration.
Record content problems separately from presentation problems. A field can appear in the correct place while still representing an action that nobody requested.
Common mistakes
Contradictory examples, unnecessary personal data and exclusively perfect inputs weaken testing. Another mistake is calling any response change permanent learning.
The demonstration guides the current interaction; capabilities and memory mechanisms depend on the tool and should not be assumed in this method.
How to assess the result
The system should preserve fields, represent gaps as agreed and handle a different case without adding facts. Record the observed failure and the change made so the evaluation can be repeated.
Save examples in your prompt library and use comparison criteria to assess request versions.
Frequently asked questions
Do examples permanently train the model?
Do not assume so. They guide the task within the supplied context and are not, by themselves, permanent training.
How many examples should I use?
Use enough to demonstrate the pattern and relevant exceptions, testing whether each case adds information.
Can I show only easy successful cases?
Include missing or ambiguous information too, so the system knows how those limits should be represented.