为什么 2–4 个示例有效
示例足以建立模式，同时又足够少，不会限制泛化。
为什么 2–4 个示例有效 是 CoddyKit 上的免费 Claude Architect 课时。 这是第 1 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 Claude Architect 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Claude Architect 课程共包含 4 节课。
本课时的部分内容尚未翻译，以英文显示。
The Core Idea
Few-shot prompting works because Claude generalizes from examples — it doesn't just memorize and repeat them. The exam fact sheet is precise about the dose: use 2-4 targeted examples per ambiguity.
That range is not arbitrary. It is enough to set a pattern, yet few enough to keep the model general. This lesson explains why that sweet spot holds for production work.
Examples Teach a Rule, Not a Lookup Table
When you show Claude 2-4 examples, you are demonstrating a rule: this input shape maps to that output shape. The model infers the underlying pattern and applies it to new, unseen inputs.
This is why few-shot is the go-to tool for consistency, edge cases, output format, and reducing hallucination — all areas where a vague instruction leaves too much room for drift.
system = (
"Classify each support message as: billing, technical, or other.\n"
"Examples:\n"
"Message: 'My card was charged twice' -> billing\n"
"Message: 'The app crashes on login' -> technical\n"
"Message: 'Do you have a dark mode?' -> other"
)
# 3 examples set the mapping rule; Claude generalizes to new messages.Why Not Zero Examples?
Zero-shot relies entirely on your instruction wording. For genuinely ambiguous tasks, words alone under-specify the boundary. The fact sheet stresses that explicit criteria beat vague guidance — but even sharp criteria sometimes need a concrete demonstration to lock in.
A single well-chosen example resolves ambiguity that a paragraph of prose cannot. That is the floor of the 2-4 range: at least a couple of demonstrations per ambiguous decision.
Why Not One Example?
One example is risky: the model can over-fit to its surface features — a specific phrasing, length, or coincidental detail — and treat that accident as part of the rule.
A second and third example let Claude triangulate what actually varies versus what stays constant. The shared structure becomes the signal; the incidental differences become noise to ignore.
# One example: model may copy the exact tone/length.
# Two+ examples reveal what is INVARIANT (the JSON shape)
# versus INCIDENTAL (the specific values).
examples = [
{"review": "Loved it, fast shipping!", "out": {"sentiment": "positive"}},
{"review": "Broke after a day.", "out": {"sentiment": "negative"}},
]
# The constant is the {"sentiment": ...} schema, not the wording.Why Not 20 Examples?
If a few examples are good, why not flood the prompt? Two reasons.
- Over-specialization: with too many examples, Claude can start mirroring their exact style and stop generalizing — it narrows to the training set instead of the rule.
- Context cost: long example blocks eat the context window and worsen lost-in-the-middle, where the model attends less to content buried in the middle.
2-4 keeps the demonstration sharp and the prompt lean.
Stay General: Cover the Decision, Not Every Case
The goal of few-shot is to set a pattern, not to enumerate the world. If you find yourself adding a 10th example to handle one more case, that is a signal: the task probably needs clearer criteria or a structured output schema, not more examples.
Examples that disagree with each other or pile up only confuse the rule and dilute attention. Keep each demonstration earning its place.
One Set Per Ambiguity
Read the fact sheet phrasing carefully: 2-4 examples per ambiguity. The budget is scoped to each distinct point of confusion, not the whole prompt.
If a task has two separate ambiguous decisions — say, how to classify and how to format the date — give a small targeted set for each. You are not capped at four examples total; you are capped at a focused few per decision you are disambiguating.
# Ambiguity 1: category boundary (3 examples)
# Ambiguity 2: date normalization (2 examples)
# Each ambiguity gets its own small, targeted set.
prompt = f"""
Category examples:
'refund my order' -> billing
'page is blank' -> technical
'how do I export' -> other
Date examples:
'next Tuesday' -> 2026-06-16
'06/10' -> 2026-06-10
Now process: {user_message}
"""Choose Examples That Mark the Boundary
Quality beats quantity. Two examples that sit right on the decision boundary teach more than ten obvious ones. Pick cases that are easy to get wrong: the near-miss, the edge case, the input that looks like one category but belongs to another.
This is exactly why the fact sheet ties few-shot to edge cases — a couple of well-placed contrast pairs define the rule far better than a heap of central, unambiguous samples.
Few-Shot Plus Structured Output
For output shape, pair a couple of examples with a JSON Schema via tool_use. The schema enforces required fields and eliminates syntax errors; the 2-4 examples teach the judgment the schema can't express — which value belongs in which field on a tricky input.
Remember the schema rule: mark a field required only if it is always present. Never require a possibly-absent field, or the model will fabricate one.
tools = [{
"name": "record_ticket",
"description": "Save a classified support ticket.",
"input_schema": {
"type": "object",
"properties": {
"category": {"enum": ["billing", "technical", "other"]},
"priority": {"enum": ["low", "high"]},
},
"required": ["category"], # priority may be absent -> not required
},
}]
# tool_choice="any" guarantees a structured call; examples teach the judgment.Few-Shot vs. Retry-With-Feedback
Don't confuse the two. Few-shot sets the pattern up front so the first response is right. Retry-with-feedback fixes a specific bad response after the fact by resending the original input, the wrong output, and the exact validation error.
Adding more examples won't fix a missing-information failure — retry can't recover info that is simply absent from the source either. Use examples to shape behavior; use retry to repair format/arithmetic slips.
A Practical Recipe
For any ambiguous prompt:
- Write explicit criteria first (vague instructions are the weak baseline).
- Add 2-4 examples per remaining ambiguity, chosen on the decision boundary.
- Reach for a schema when the gap is output shape, not judgment.
- If you keep adding examples, stop — fix the criteria or the schema instead.
Enough to set a pattern; few enough to stay general.
system = """Flag a code comment ONLY when it contradicts the code.
Examples:
Code: x = a + b Comment: 'subtract b' -> FLAG (contradicts)
Code: x = a + b Comment: 'sum a and b' -> OK
Code: retry(3) Comment: 'retry twice' -> FLAG (count wrong)
"""
# Explicit criterion + 3 boundary examples = consistent, general behavior.Checkpoint: Choosing the Example Count
Scenario question — pick the best answer.
Recap
Key takeaways:
- 2-4 examples per ambiguity is the sweet spot — Claude generalizes from them, it doesn't just repeat them.
- Too few (0-1) under-specifies or over-fits to surface detail; too many over-specializes and wastes context, hurting attention to the middle.
- Pick examples on the decision boundary; quality beats quantity.
- Pair examples with explicit criteria and, for output shape, a JSON Schema — and never require a possibly-absent field.
- If you keep adding examples, fix the criteria or schema instead.
常见问题解答
「为什么 2–4 个示例有效」课时是免费的吗？
是的 — 「为什么 2–4 个示例有效」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Claude Architect 课程的其余内容，请升级到 CoddyKit PRO。 Claude Architect 课程共包含 4 节课。
「为什么 2–4 个示例有效」这节课中我会学到什么？
示例足以建立模式，同时又足够少，不会限制泛化。 你通过在浏览器中直接运行的动手代码来练习 Claude Architect，全天候 AI 导师会在你学习这节课的过程中回答你的问题。
学习 Claude Architect 需要有经验吗？
无需任何先前经验。CoddyKit 上的 Claude Architect 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。 这是第 1 节课，共 4 节。
「为什么 2–4 个示例有效」课时需要多长时间？
大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。
我能在这节 Claude Architect 课中编写并运行代码吗？
能。每节 Claude Architect 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。
此课程中的所有课时
- 为什么 2–4 个示例有效
- 格式与边界情况示例
- 泛化与重复
- 使用少样本示例减少幻觉