Claude Architect · 课时

排除错误答案

反模式通常就是干扰项，请学会识别它们。

排除错误答案 是 CoddyKit 上的免费 Claude Architect 课时。这是第 3 节课，共 4 节。你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。这是 Claude Architect 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Claude Architect 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

The Distractor Is Usually an Anti-Pattern

On the Claude Certified Architect exam, every question gives you 4 options and exactly 1 is correct. The other 3 are distractors — and they are not random. They are engineered to look reasonable to someone who half-knows the material.

Here is the single most useful insight for this lesson: distractors are very often well-known anti-patterns dressed up as solutions. If you can recognize the anti-pattern catalog on sight, you can eliminate 2-3 options before you even finish reading them.

Elimination is leverage. With no penalty for guessing, killing two wrong answers turns a 25% guess into a 50% one — and usually leaves the correct answer obvious.

Build a Mental Anti-Pattern Catalog

Before you can eliminate, you need a list of red flags memorized cold. These are the recurring wrong answers across all 8 exam scenarios:

Parsing text for completion signals ("stop when the reply contains 'done'")
Arbitrary iteration caps as the primary stop mechanism
Minimal/ambiguous tool descriptions or too many tools per agent
Generic error statuses ("Operation failed")
Enforcing critical business rules with prompts alone
Single-pass multi-file review and same-session self-review
Batch API for blocking/time-sensitive checks
Sentiment/confidence-based escalation
Requiring possibly-absent schema fields
Silent error suppression and aggregate-only accuracy metrics

When an option matches one of these, it is almost certainly the wrong answer. Treat the list as a tripwire.

Red Flag: Parsing Text to Stop the Loop

The agentic loop terminates on stop_reason — never by scanning the model's text for words like "done" or "finished". Any option that loops while a string is in the output is an anti-pattern distractor.

The correct mechanism: send the full history each turn, inspect stop_reason, run tools on tool_use, and stop on end_turn.

# ANTI-PATTERN (a distractor you should eliminate):
while "done" not in response.content[0].text.lower():
    response = client.messages.create(...)

# CORRECT: terminate on the structured stop_reason
while response.stop_reason == "tool_use":
    tool_results = run_tools(response.content)
    messages.append({"role": "user", "content": tool_results})
    response = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        messages=messages,
        tools=tools,
    )
# loop exits when stop_reason == "end_turn"

Red Flag: Iteration Caps as the Primary Stop

A close cousin of the previous trap. An iteration cap ("stop after 10 turns") is a legitimate safety net — but it is never the primary stop mechanism. Decisions are model-driven; you reserve hard-coded limits for guarantees, not for control flow.

So when two options both mention a loop cap, read carefully: the wrong one makes the cap the main exit condition. The right one stops on end_turn and keeps the cap purely as a runaway guard.

MAX_TURNS = 25  # safety net ONLY — not how we normally stop
turns = 0
while response.stop_reason == "tool_use":
    if turns >= MAX_TURNS:
        raise RuntimeError("runaway loop guard tripped")  # rare escape hatch
    turns += 1
    messages.append({"role": "user", "content": run_tools(response.content)})
    response = client.messages.create(model="claude-sonnet-4-5",
        max_tokens=1024, messages=messages, tools=tools)
# normal, expected exit: stop_reason == "end_turn"

Red Flag: Prompts for Critical Business Rules

When a question involves money, legal, or safety consequences (refund limits, policy violations), an option that says "instruct the model in the system prompt to never refund over $500" is a distractor. Prompts are ~90% probabilistic. Hooks are 100% deterministic.

The correct answer enforces the rule with a PostToolUse / outgoing-call hook or a programmatic precondition — code the model cannot talk its way around.

# Distractor: "Add 'never refund more than $500' to the system prompt."
# Correct: deterministic enforcement outside the model.
def on_pre_tool_use(tool_name, tool_input):
    if tool_name == "process_refund" and tool_input["amount"] > 500:
        return {"block": True,
                "reason": "Refunds over $500 require human approval."}
    # precondition: identity must be verified first
    if tool_name == "process_refund" and not customer_verified():
        return {"block": True, "reason": "Verify customer identity first."}
    return {"block": False}

Red Flag: Bad Tool Design

Two tool-design distractors show up constantly in Scenario 4 and 8 questions:

"Improve selection by renaming the tools" — wrong. Tool descriptions, not names, are the primary selection mechanism.
"Give the agent all 18 tools so it never lacks one" — wrong. 4-5 tools per agent is optimal; 18+ degrades selection reliability.

The correct answers: write rich descriptions (purpose, return values, input formats with examples, edge cases, boundaries) and scope tools tightly to the role with least privilege.

# Correct: a description that actually drives selection.
lookup_order = {
    "name": "lookup_order",
    "description": (
        "Retrieve a customer's order by order_id. "
        "Returns status, line items, and total. "
        "order_id format: 'ORD-' + 8 digits, e.g. 'ORD-10293847'. "
        "Use AFTER get_customer verifies identity. "
        "Returns an empty result (not an error) if no order matches."
    ),
    "input_schema": {"type": "object",
        "properties": {"order_id": {"type": "string"}},
        "required": ["order_id"]},
}

Red Flag: Generic Errors & Silent Suppression

In multi-agent and extraction scenarios, watch for two error anti-patterns:

Returning "Operation failed" — a generic status that blocks intelligent recovery.
Silently swallowing a failure, or aborting the whole workflow because one subagent failed.

The correct answer returns structured errors: isError, errorCategory (transient/validation/business/permission), isRetryable, the attempted query, and partial results. It also distinguishes an access failure (maybe retry) from a valid empty result (no matches — don't retry).

# Distractor: return {"status": "Operation failed"}
# Correct: structured, routable error
error = {
    "isError": True,
    "errorCategory": "transient",   # vs validation/business/permission
    "isRetryable": True,
    "message": "Upstream timeout from inventory service",
    "attempted_query": "SELECT * FROM stock WHERE sku='A91'",
    "partial_results": [{"sku": "A91", "warehouse": "EU"}],
}

Red Flag: Same-Session & Single-Pass Review

For code-review and CI/CD scenarios (Scenario 2 and 5), eliminate any option that reviews in the same session that generated the code — the author keeps its own reasoning and won't challenge itself. An independent, fresh-instance review is always stronger.

Also eliminate single-pass multi-file review: it dilutes attention. The correct multi-pass approach does a per-file local pass, then a separate cross-file integration pass.

# Distractor: same chat asks itself "now review what you wrote."
# Correct (CI/CD): isolated, non-interactive review session.
#   claude -p "Review this diff for correctness bugs only." \
#     --output-format json \
#     --append-system-prompt "Flag an issue ONLY when code contradicts intent."
#
# Multi-pass: pass 1 per-file, pass 2 cross-file integration —
# never one single pass across all files at once.

Red Flag: Batch API for Blocking Checks

The Message Batches API is 50% cheaper with up to a 24-hour window — but it has no latency SLA and does not support multi-turn tool calling. So any option that uses Batch for a pre-merge gate, a synchronous user-facing check, or an agentic tool loop is a distractor.

Batch is correct only for non-blocking jobs: overnight audits, bulk reports. If the scenario word is "blocking", "pre-merge", "real-time", or "the user is waiting" — eliminate Batch immediately.

# Correct use of Batch: overnight, non-blocking audit.
batch = client.messages.batches.create(requests=[
    {"custom_id": "doc-001",   # custom_id correlates each result
     "params": {"model": "claude-sonnet-4-5", "max_tokens": 1024,
                "messages": [{"role": "user", "content": audit_prompt(d)}]}}
    for d in nightly_documents
])
# WRONG: using this for a pre-merge CI gate (no latency SLA, no tool loop).

Red Flag: Bad Escalation & Bad Schemas

Two more high-frequency distractors:

Escalation triggered by sentiment analysis or a model self-rated confidence score (1-10). These are bad triggers. Good triggers: explicit human request, policy gaps, no progress after attempts, threshold violations.
Marking a possibly-absent field as required in a JSON schema. The model will fabricate it. Require a field ONLY if it is always present; use enums with an "other" value plus a free-text detail for extensibility.

If an option escalates on "angry tone" or requires "middle_name" — eliminate it.

# Distractor schema: requires a field that's often missing.
# Correct: only truly-always-present fields are required.
schema = {
    "type": "object",
    "properties": {
        "invoice_id": {"type": "string"},
        "category": {"type": "string",
                     "enum": ["goods", "services", "other"]},
        "category_detail": {"type": "string"},  # free-text, NOT required
        "po_number": {"type": "string"},        # may be absent -> NOT required
    },
    "required": ["invoice_id", "category"],
}

The Elimination Drill

Put it together into a repeatable process for every question:

1. Read the scenario for the real constraint — money/legal (needs a hook), blocking vs overnight (Batch or not), single vs multi-file (passes), present vs absent field (required or not).
2. Scan all 4 options for anti-pattern tripwires and strike every match. Usually 2-3 fall away.
3. Among survivors, pick the one with a deterministic guarantee where it matters — structured over generic, model-driven stop over text parsing, independent over self-review.
4. Always answer. No penalty for guessing — never leave a blank, even when you're down to a coin flip.

Anti-pattern recognition isn't a shortcut around understanding; it's how an experienced architect reads a question fast and clean.

Quick Check

Apply the elimination drill to a real exam-style scenario.

Recap: Read the Constraint, Strike the Anti-Pattern

Key takeaways for eliminating wrong answers:

Distractors are usually anti-patterns in disguise. Memorize the catalog and treat each one as a tripwire.
Eliminate on sight: text-parsing to stop, iteration caps as the primary stop, prompts for critical rules, generic/suppressed errors, too many tools, name-based tool selection, single-pass and same-session review, Batch for blocking checks, sentiment/confidence escalation, requiring absent fields.
The right answer favors deterministic guarantees where stakes are high: hooks and preconditions, structured errors, model-driven termination on end_turn, independent review, rich tool descriptions.
Always answer — no guessing penalty. Strike two distractors and a coin flip becomes a strong bet.

Recognize the trap, and the correct option practically selects itself.

常见问题解答

「排除错误答案」课时是免费的吗？

是的 — 「排除错误答案」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Claude Architect 课程的其余内容，请升级到 CoddyKit PRO。 Claude Architect 课程共包含 4 节课。

「排除错误答案」这节课中我会学到什么？

反模式通常就是干扰项，请学会识别它们。你通过在浏览器中直接运行的动手代码来练习 Claude Architect，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Claude Architect 需要有经验吗？

无需任何先前经验。CoddyKit 上的 Claude Architect 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。这是第 3 节课，共 4 节。

「排除错误答案」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 Claude Architect 课中编写并运行代码吗？

能。每节 Claude Architect 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

← 返回 Claude Architect