Prompting & In-Context Learning
Write prompts as testable contracts with instructions, examples, data, and output rules.
Quick start
Reach one useful result first
- Explain
- 15 min
- Visualize
- 10 min
- Practice
- 25 min
- Deep dive
- 25 min
Explanation
Start with the direct answer, follow one example, then check your understanding.
Choose your explanation depth
The mechanism stays the same; emphasis and evidence change.
A prompt supplies instructions, context, examples, and the desired answer shape.
Carried example
A classification prompt improves when it defines labels and includes one boundary example instead of only asking “classify this”.
Focus on the observable input, change, and output of prompting.
Learning goals and prerequisites
After this lesson
- Separate prompt roles and trust levels
- Use examples to clarify boundaries
- Evaluate and version a prompt contract
Helpful before starting
- LLM generation and decoding
- Basic application requirements
5 chapters · about 1 hr 3 min estimated study
0/5 chapters marked complete
Direct answer
A prompt arranges instructions, context, examples, untrusted input, and the expected response shape for one model request. It can steer behavior without changing model weights, but it cannot replace software validation, authorization, or business rules.
Follow the mechanism
- State the task and the allowed labels, tools, or sources.
- Place user and document content inside an explicit data boundary so it is not confused with privileged instruction.
- Add examples only when they clarify a difficult boundary or demonstrate the required format.
- Require a response shape, validate it in code, and define what happens when the result is ambiguous, unsupported, or invalid.
Running example
Consider the message “I was charged twice for order 1842.” The vague prompt “Classify this support message and explain” can produce polished prose that downstream software cannot parse. A stronger contract defines the labels billing | technical | other, places the message inside a data field, and requires exactly label and reason. The model can now return {"label":"billing","reason":"The user disputes a charge."}; the application still checks the field names, the allowed label, and the non-empty reason before using it.
What this does not mean
A clear prompt is not a security boundary. Text inside the user message may say “ignore previous instructions”, but identity, access control, payment approval, and irreversible actions must remain outside model persuasion. A schema can prove that output is structurally valid; it does not prove that the classification is semantically correct, so representative evaluation cases are still required.
Ideas to understand
- Task → trust boundaries → examples → output schema → validation is the prompt contract.
- In-context examples affect the current request without updating model weights.
- Untrusted text remains data even when it resembles an instruction.
- Structural validation and semantic evaluation answer different quality questions.
Decision and failure guide
Use Prompting & In-Context Learning with evidence
A complete explanation includes the conditions that make the technique useful and the nearby ways it can fail.
Before you call it ready
- Separate instructions from data
- Define unsupported behavior
- Validate outputs
- Keep fixed regression cases
Common failure → better decision
- Adding examples without a purpose
- Choose examples that clarify a boundary.
- Using prompt text as authorization
- Enforce identity and policy in code.
- Judging by one polished output
- Evaluate a representative fixed set.
Was this lesson helpful?
Submit to the team when server feedback is available; otherwise this browser keeps a local copy and tells you so.
Concept connections
See prerequisites, applications, and nearby decisions.
Learn before
Often compared with
Continue next
Get one next lesson each week
A focused path reminder, not a marketing newsletter. Unsubscribe in one click.