# Prompt Engineering Walkthrough — Learn by Doing ## Step 1: Structure a Basic Prompt **Task:** You want the AI to summarize a meeting transcript. Write a prompt that includes: role, context (what kind of meeting), task (summarize), format (bullet points? sections?), and one constraint (e.g., max 200 words). **Question:** What would happen if you only said "Summarize this"? What does each component add? **Checkpoint:** The user's prompt has at least role, context, task, format, and one constraint. They can explain why each piece improves output (e.g., format ensures machine-readable structure). --- ## Step 2: Zero-Shot vs Few-Shot **Task:** You need the AI to classify support tickets as "bug", "feature request", or "question". Write (a) a zero-shot prompt and (b) a few-shot prompt with 2–3 examples. Run both (or predict): which would you expect to perform better? Why? **Question:** For which tasks would zero-shot be enough? When do you *need* few-shot? **Checkpoint:** The user has both prompts. They understand few-shot establishes the pattern for structured or style-sensitive tasks. They can name cases where zero-shot suffices (simple translation, broad summarization). --- ## Step 3: Chain-of-Thought for Reasoning **Task:** Ask the AI: "If a train leaves Station A at 60 mph and Station B at 40 mph toward each other, 200 miles apart, when do they meet?" Use a prompt that asks the model to "think step by step" before giving the answer. Compare to a prompt that doesn't. **Question:** Why does "show your reasoning" help? What kinds of tasks benefit most from chain-of-thought? **Checkpoint:** The user has used CoT. They observe: CoT reduces errors on logic and math; it makes output verifiable. They can name other CoT-suitable tasks (multi-step planning, debugging). --- ## Step 4: Structured Output **Embed:** https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering **Task:** Ask the AI to extract names, emails, and phone numbers from a short paragraph of text. Request the output as JSON with keys `names`, `emails`, `phones`. Run it. If the format drifts, add more explicit structure (e.g., "Return valid JSON only, no markdown"). **Question:** Why is JSON useful for downstream use? What if the model returns markdown-wrapped JSON? **Checkpoint:** The user has gotten JSON output. They understand structured output enables parsing and integration. They can handle common drift (e.g., "valid JSON only"). --- ## Step 5: Iterate on a Failing Prompt **Task:** Your prompt for "write a product description" produces generic, marketing-fluffy text. Iterate: add (a) a constraint ("no buzzwords"), (b) an example of the tone you want, (c) a length limit. Which change helped most? **Question:** When would you add an example vs a constraint? What's the risk of too many constraints at once? **Checkpoint:** The user has iterated and seen improvement. They understand: examples establish style; constraints narrow scope. They recognize constraint overload can confuse the model. --- ## Step 6: Choose Temperature **Task:** For each scenario, choose temperature (0, 0.3, 0.7, 1.0) and justify: (a) Extracting entity names from text. (b) Brainstorming 10 product names. (c) Writing unit tests from a spec. (d) Creative short story. **Question:** Why does low temperature reduce hallucination risk? When is high temperature useful despite that risk? **Checkpoint:** The user matches: extraction (0–0.3), brainstorming (0.7–1.0), tests (0–0.3), story (0.7–1.0). They connect low temp to factual consistency and high temp to creativity. --- ## Step 7: System vs User Prompts **Task:** Many APIs support a system prompt and user messages. Design a system prompt for a "helpful coding assistant" that: (a) sets the role, (b) specifies output format (code blocks, explain briefly), (c) adds one guardrail (e.g., "don't assume APIs we don't have"). Why put this in the system prompt vs the user message? **Question:** What should *not* go in the system prompt? When would you put task-specific instructions in the user message instead? **Checkpoint:** The user has a system prompt with role, format, and guardrail. They understand system = persistent context; user = per-request. They can distinguish what belongs where.