Exemples de format et de cas particuliers
Imposez la structure de sortie et clarifiez les limites délicates.
Exemples de format et de cas particuliers est une leçon Claude Architect gratuite sur CoddyKit. Ceci est la leçon 2 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Claude Architect, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Claude Architect comprend 4 leçons au total.
Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.
Why Format Examples Exist
Instructions tell Claude what to do. Examples show it exactly what the output should look like.
Few-shot prompting means dropping 2-4 targeted examples into your prompt. The model generalizes from them - it doesn't just copy them back. In this lesson we use examples for two jobs: pinning the output shape and clarifying tricky edge cases.
These two jobs are where few-shot earns its keep: consistency, output format, and reducing hallucination on the weird inputs.
The Problem: Drifting Shape
Imagine you ask Claude to extract a date. Sometimes you get 2026-06-10, sometimes June 10, 2026, sometimes 10/06/2026. Every variation breaks the code that consumes the output.
A prose instruction like "return the date" is ambiguous. Vague guidance produces vague consistency. The fix is to show the exact shape you want instead of describing it.
Pinning Shape with Examples
Put a couple of input/output pairs in the system prompt. The model locks onto the format of the outputs and reproduces it for new inputs.
Notice each example pins the same structure: ISO date, uppercase status, no extra commentary.
system = (
"Extract the event into JSON. Match this shape exactly.\n\n"
"Input: Launch is on June 10th, all systems go.\n"
'Output: {"date": "2026-06-10", "status": "GO"}\n\n'
"Input: Demo slipped to the 3rd of July, still pending.\n"
'Output: {"date": "2026-07-03", "status": "PENDING"}'
)
resp = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=256,
system=system,
messages=[{"role": "user", "content": "Input: Kickoff is set for May 1st and confirmed."}],
)Examples Beat Adjectives
Explicit criteria beat vague pleas. "Be more consistent" or "format it nicely" gives the model nothing to anchor on.
Compare two ways to ask for the same thing:
- Vague: "Return the status in a clean format."
- Concrete: show two outputs that are both
{"status": "GO"}/{"status": "PENDING"}.
The concrete version removes the guesswork. The model sees the target and hits it.
Format-Critical? Combine with Structured Output
Examples make the shape likely. A JSON Schema via tool_use makes it guaranteed - it eliminates syntax errors and enforces required fields.
Setting tool_choice to "any" forces the model to call some tool, which guarantees you get structured output instead of free text. Use few-shot examples to clarify the content, and the schema to lock the structure.
tools = [{
"name": "record_event",
"description": "Save the parsed event.",
"input_schema": {
"type": "object",
"properties": {
"date": {"type": "string", "description": "ISO 8601, e.g. 2026-06-10"},
"status": {"type": "string", "enum": ["GO", "PENDING", "OTHER"]},
"status_detail": {"type": "string"}
},
"required": ["date", "status"]
}
}]
resp = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=256,
tools=tools,
tool_choice={"type": "any"}, # must call a tool -> structured output
messages=msgs,
)The Required-Field Trap
A schema is only safe if you mark fields correctly. The rule: mark a field required ONLY if it is always present.
If you require a field that may be absent from the source, the model will fabricate a value to satisfy the schema. That is a silent data-quality bug.
In the example above, date and status are always derivable, so they are required. status_detail may be missing, so it stays optional.
Designing for Edge Cases
Now the second job: tricky boundaries. The default output covers the happy path. Edge-case examples teach the model what to do when the input is weird, incomplete, or doesn't fit.
Pick 2-4 examples that target the specific ambiguities you actually hit - not random samples. Each example should resolve one boundary the model would otherwise guess at.
Show the Empty / Absent Case
The most common edge case: the answer simply isn't in the input. Distinguish a valid empty result (no data present) from an access failure (couldn't read the source).
Show an example where the field is absent and the model returns a sentinel like "OTHER" plus a detail - never an invented value.
system = (
"Extract status. If the text states no status, use OTHER and explain.\n\n"
"Input: Meeting moved to Friday.\n"
'Output: {"status": "OTHER", "status_detail": "no status stated"}\n\n'
"Input: Release approved by the board.\n"
'Output: {"status": "GO", "status_detail": "approved"}'
)Enums with an 'Other' Escape Hatch
Edge cases break rigid enums. An input that fits none of your categories forces the model to either fabricate a fit or crash the schema.
The extensible pattern: an enum plus an "other" value and a free-text detail field. This lets the model classify cleanly when it can, and gracefully overflow when the input is unexpected - without you re-deploying the schema.
"properties": {
"category": {
"type": "string",
"enum": ["GO", "PENDING", "BLOCKED", "OTHER"]
},
"category_detail": {
"type": "string",
"description": "Required when category is OTHER; free text"
}
}Examples Generalize - Don't Over-Enumerate
A common mistake is treating few-shot like a lookup table - stuffing in 30 examples hoping to cover every input. The model generalizes from a few well-chosen pairs; it doesn't need an exhaustive list.
More examples also cost context, and long prompts suffer from lost-in-the-middle: the model attends most to the start and end, least to the middle. A bloated example block buries the very patterns you care about.
Keep it to 2-4 sharp, boundary-targeting examples.
When the Output Is Still Wrong
Even with good examples, you may get a malformed result. Retry-with-feedback fixes format, structural, and arithmetic errors: resend the original input, the wrong output, and the exact validation error.
But know the limit: retry does not help when the information is simply absent from the source. No amount of re-prompting invents data that isn't there - that's an edge case your examples and schema should handle up front with an "OTHER"/empty path.
try:
event = validate(tool_input) # Pydantic-style schema check
except ValidationError as err:
retry = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=256,
tools=tools,
tool_choice={"type": "any"},
messages=msgs + [
{"role": "assistant", "content": [tool_use_block]},
{"role": "user", "content": f"Validation failed: {err}. Fix and resubmit."},
],
)Quick Check: Optional Field
You are extracting invoices into JSON. Most invoices have a purchase_order number, but about 30% omit it. You add two few-shot examples to pin the output shape.
How should you handle the purchase_order field in your JSON Schema?
Recap: Pin the Shape, Tame the Edges
Key takeaways:
- Show, don't describe: 2-4 input/output pairs pin format far better than adjectives like "clean" or "consistent".
- Examples + schema: few-shot makes the shape likely; JSON Schema via tool_use (with
tool_choice: "any") makes it guaranteed. - Required only if always present: requiring a possibly-absent field forces fabrication.
- Use enum + "other" + detail for extensibility, and show an absent/empty example so the model never invents data.
- The model generalizes: a few sharp, boundary-targeting examples beat a bloated list that buries the pattern in the middle.
- Retry-with-feedback fixes malformed output, but not information that simply isn't in the source.
Apprends Python avec un tuteur IA — gratuit
Écris et exécute du vrai code dans ton navigateur, obtiens de l'aide instantanée d'un tuteur IA disponible 24h/24, et reprends là où tu t'es arrêté sur le web ou dans l'app.
- Cours
- 26
- Leçons
- 104
Questions Fréquemment Posées
La leçon « Exemples de format et de cas particuliers » est-elle gratuite ?
Oui — le texte complet de « Exemples de format et de cas particuliers » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Claude Architect, passe à CoddyKit PRO. Le cours Claude Architect comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Exemples de format et de cas particuliers » ?
Imposez la structure de sortie et clarifiez les limites délicates. Tu pratiques Claude Architect avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer Claude Architect ?
Aucune expérience préalable n'est requise. Claude Architect sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 2 sur 4.
Combien de temps prend la leçon « Exemples de format et de cas particuliers » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon Claude Architect ?
Oui. Chaque leçon Claude Architect inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Pourquoi 2 à 4 exemples fonctionnent
- Exemples de format et de cas particuliers
- Généralisation ou répétition
- Few-shot pour réduire les hallucinations