การอ่านพรอมต์สถานการณ์
ระบุขอบเขต เงื่อนไขจำกัด และต้นทุนของความล้มเหลว
การอ่านพรอมต์สถานการณ์ เป็นบทเรียน Claude Architect ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Claude Architect และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Claude Architect มีบทเรียนทั้งหมด 4 บทเรียน
บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ
Why Reading Comes First
The Claude Certified Architect exam is scenario-based: every question is a short situation followed by four options, exactly one correct. You see 4 of 8 scenarios, scored 100-1000, and you pass at 720.
Most wrong answers aren't knowledge gaps - they're reading gaps. The prompt always tells you which domain it lives in, what constraint must hold, and what it costs when the system fails. Miss any of those three and a plausible distractor will catch you.
This lesson trains one skill: dissect a scenario into domain, constraint, and failure cost before you ever look at the options.
The Three Signals
Train your eye to extract three signals from any scenario:
- Domain - which of the five exam areas is being tested. This tells you which mental model applies.
- Constraint - the hard requirement the answer MUST satisfy (e.g. "must be deterministic", "runs in CI", "context resets between subagents").
- Failure cost - what breaks if the constraint is violated (financial, legal, safety, or just a slow report). High cost changes the right answer.
Read the prompt three times if needed - once per signal. The options are designed so the wrong ones satisfy two signals but violate one.
Signal 1 - Naming the Domain
The exam weights five domains. Knowing the split tells you what shows up most and which model to reach for:
- D1 Agent Architecture & Orchestration - 27% (the largest)
- D3 Claude Code Config & Workflows - 20%
- D4 Prompt Engineering & Structured Output - 20%
- D2 Tool Design & MCP - 18%
- D5 Context Management & Reliability - 15%
Keywords map fast: "coordinator/subagent" - D1; ".mcp.json / tool description" - D2; "CLAUDE.md / plan mode / -p" - D3; "JSON Schema / few-shot" - D4; "summarization / lost-in-the-middle" - D5.
# Keyword -> domain map you keep in your head:
DOMAIN_HINTS = {
"coordinator|subagent|delegate": "D1 Agent Architecture (27%)",
".mcp.json|tool description|isError": "D2 Tool Design & MCP (18%)",
"CLAUDE.md|plan mode|-p|slash command": "D3 Claude Code (20%)",
"JSON Schema|few-shot|tool_choice": "D4 Prompt Eng & Output (20%)",
"summarization|lost-in-the-middle|provenance": "D5 Context & Reliability (15%)",
}Spotting the Domain in Practice
Read this stem and name the domain before reading on:
"A coordinator delegates three independent lookups to subagents. One subagent returns empty; the others succeed. How should the system respond?"
Signals: "coordinator", "subagents", "delegates" - this is D1 Agent Architecture & Orchestration, specifically the Multi-Agent Research scenario. Now your mental model loads: subagents don't inherit history, distinguish an access FAILURE from a valid EMPTY result, and return partial results with coverage annotations rather than aborting the whole workflow.
Naming the domain pre-loads the correct anti-patterns to reject.
from anthropic import Anthropic
client = Anthropic()
# Coordinator delegates; each subagent gets context EXPLICITLY -
# subagents do NOT inherit the coordinator's conversation history.
subagent_prompt = (
"You are a research subagent. Context: " + shared_facts + "\n"
"Task: look up Q3 revenue for ACME. Return partial results "
"and a coverage note if data is missing."
)Signal 2 - The Constraint
The constraint is the requirement the answer cannot violate. It is often a single load-bearing phrase. Watch for these triggers:
- "must never" / "guarantee" / "always block" - demands DETERMINISTIC enforcement (a hook), not a prompt.
- "in CI" / "in a pipeline" - demands non-interactive
-pwith--output-format json. - "blocking" / "pre-merge" / "time-sensitive" - rules OUT the Batch API (no latency SLA).
- "shared via VCS" vs "personal" - project
./CLAUDE.mdvs user~/.claude/CLAUDE.md.
The constraint is what separates two options that otherwise look identical.
Constraints That Force Determinism
The single most common constraint trap: a rule with financial, legal, or safety consequences. The fact sheet is blunt - hooks are 100% deterministic; prompts are ~90% probabilistic. When failure is costly, prompt guidance is the wrong answer.
If the stem says "refunds over $500 must require approval", the correct option is an outgoing-call hook that blocks the action - not "add a clear instruction to the system prompt". Same logic for identity verification: a programmatic precondition (block process_refund until get_customer returns a verified ID) beats any wording.
# Deterministic enforcement - a hook, not a prompt.
def pre_refund_hook(tool_call, state):
if tool_call.name == "process_refund":
if not state.get("verified_customer_id"):
return block("Identity not verified")
if tool_call.input["amount"] > 500:
return block("Refund > $500 requires human approval")
return allow()Signal 3 - The Failure Cost
Failure cost is the lever that changes which trade-off wins. The exam rewards matching the mechanism's strength to the cost of being wrong.
- High cost (money/law/safety): choose deterministic guarantees - hooks, preconditions, structured validation. Never settle for "probably right".
- Low cost (an overnight audit, a draft report): cheaper, slower, model-driven paths are fine - Batch API at 50% off, adaptive decomposition.
A correct mechanism applied where the cost doesn't justify it can still be the wrong answer if a simpler option fits - but under-protecting a costly failure is always wrong.
Cost Maps to Mechanism
Tie the cost to the right tool. The Batch API is 50% cheaper with up to a 24h window but no latency SLA and no multi-turn tool calling - perfect for an overnight compliance audit, disqualified for a pre-merge check.
If a scenario says "validate each pull request before merge", the failure cost is a blocked developer and a broken main branch - that's time-sensitive, so Batch is out and an interactive -p review session is in.
# Time-sensitive / blocking -> NON-interactive CI run, NOT Batch.
claude -p "Review the diff for correctness bugs only" \
--output-format json \
> review.json
# Batch API (50% cheaper, <=24h, no SLA) is for overnight audits,
# never for a pre-merge gate.Mapping All Three Together
Now combine the signals on a full stem:
"A support agent processes refunds. Policy: refunds above $500 need human sign-off. The team added a sentence to the system prompt but a few large refunds still slipped through. What should they do?"
- Domain: D1 - Customer Support Agent.
- Constraint: the $500 rule must hold every time ("must").
- Failure cost: financial - unapproved money leaving.
Three signals point the same way: replace the probabilistic prompt with a deterministic outgoing-call hook. The reading did the work; the answer is now obvious.
signals = {
"domain": "D1 - Customer Support Agent",
"constraint": "refunds > $500 MUST get human sign-off", # 'must'
"failure_cost": "financial", # high
}
# high cost + 'must' -> deterministic enforcement
verdict = "Outgoing-call hook (block), NOT a system-prompt sentence"Distractors Attack One Signal
Distractors are engineered to satisfy two signals and quietly break the third. Learn the shapes:
- Right domain, right intent, wrong mechanism strength - "add explicit wording to the prompt" where a hook is required.
- Right mechanism, wrong constraint - "use the Batch API" for a blocking check.
- Plausible but a known anti-pattern - parsing text for "done", iteration caps as the primary stop, requiring a possibly-absent schema field, single-pass multi-file review, same-session self-review.
When two options feel close, find the signal they disagree on - that's the whole question.
A Repeatable Reading Routine
Run this routine on every scenario, in order:
- 1. Domain - one keyword scan; name D1-D5.
- 2. Constraint - underline the load-bearing phrase ("must", "in CI", "blocking", "shared").
- 3. Failure cost - financial/legal/safety = high; report/draft = low.
- 4. Predict the answer BEFORE reading options.
- 5. Eliminate any option that violates the constraint or matches a top anti-pattern.
And remember: there's no penalty for guessing. After eliminating, commit to your best remaining option and move on - answer every question.
# Mental checklist as pseudocode you run per question:
for scenario in exam:
domain = name_domain(scenario) # D1..D5
constraint = find_must_phrase(scenario) # the hard requirement
cost = failure_cost(scenario) # high | low
guess = predict_answer(domain, constraint, cost)
answer = eliminate_antipatterns(options, constraint) or guess
# never leave it blank - no penalty for guessingQuick Check
Apply the three-signal routine to the scenario in the question.
Recap - Read Before You Answer
Reading a scenario well is the highest-leverage exam skill. Lock in the routine:
- Domain - keyword-scan to D1-D5; the right mental model loads with it.
- Constraint - find the load-bearing phrase; "must/guarantee" forces determinism, "in CI" forces
-p, "blocking" rules out Batch, "shared" picks project CLAUDE.md. - Failure cost - high (money/law/safety) demands hooks and preconditions; low tolerates cheaper model-driven paths.
Predict before reading options, eliminate anything that breaks the constraint or matches a top anti-pattern, and - since there's no guessing penalty - always commit to an answer. Read three signals first, and the correct option stops being a guess.
คำถามที่พบบ่อย
บทเรียน “การอ่านพรอมต์สถานการณ์” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “การอ่านพรอมต์สถานการณ์” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Claude Architect ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Claude Architect มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “การอ่านพรอมต์สถานการณ์”
ระบุขอบเขต เงื่อนไขจำกัด และต้นทุนของความล้มเหลว คุณปฏิบัติ Claude Architect ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Claude Architect หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Claude Architect บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน
บทเรียน “การอ่านพรอมต์สถานการณ์” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Claude Architect นี้ได้ไหม
ได้ บทเรียน Claude Architect ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- วิธีให้คะแนนคำถามตามสถานการณ์
- การอ่านพรอมต์สถานการณ์
- การตัดคำตอบที่ผิดออก
- การทำข้อสอบจำลองฉบับเต็ม