Claude Architect · 课时

反模式：情绪与置信度评分

绝不要根据情绪或自评的 1–10 分进行升级。

第 2 / 4 课13 个步骤

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

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

The Tempting Shortcut

When you build a Claude agent that handles real users, one question dominates: when do we hand off to a human?

A seductive idea appears early: "Let the model tell us how it feels." Ask Claude to rate its own confidence 1-10, or run a sentiment classifier on the customer's tone, and escalate when the number crosses a line.

It feels data-driven. It is actually one of the most common anti-patterns on the certification exam. This lesson shows you why, and what to do instead.

What a Good Escalation Trigger Looks Like

Escalation should fire on observable, verifiable facts about the conversation, not on a vibe.

The exam recognizes exactly four good escalation triggers:

Explicit human request — the user asks for a person. Escalate immediately.
Policy gaps — the situation falls outside what the agent is allowed to resolve.
No progress after attempts — repeated tool calls or turns yield nothing.
Threshold violations — a concrete, defined limit is crossed (e.g. refund amount).

Each of these is grounded in something you can point to in the transcript or the data.

The Bad Triggers

Now the flip side. The exam lists triggers you must never use as the basis for escalation:

Sentiment analysis — escalating because the message "sounds angry."
Model self-rated confidence — a 1-10 score Claude assigns to itself.
Untrained classifiers — ad-hoc mood/intent detectors with no validated ground truth.

These share one fatal flaw: they are not grounded in verifiable state. They are guesses about an internal feeling, dressed up as a metric.

Why Self-Rated Confidence Fails

A self-rated 1-10 confidence score has no calibration. The model is not measuring anything external — it is producing a plausible-looking number on demand.

The same answer might get an 8 in one phrasing and a 4 in another. The score does not correlate reliably with correctness, so an escalation threshold built on it is arbitrary noise.

Contrast this with a real reliability practice from the fact sheet: field-level confidence calibrated on a labeled validation set before automating. Calibration against ground truth is rigorous; a model grading its own homework is not.

# ANTI-PATTERN: do not do this
system = (
    "Answer the question, then rate your confidence "
    "from 1 to 10. If your confidence is below 7, "
    "end your reply with ESCALATE."
)
# The 1-10 number is uncalibrated self-report.
# Threshold 7 is arbitrary -> noisy, unreliable handoffs.

Why Sentiment Escalation Fails

Sentiment-based escalation routes on the customer's mood instead of their request. That is the wrong variable.

A calm user may have a hard, out-of-policy problem that genuinely needs a human. A frustrated user may have a trivial, fully solvable request. Mood and resolvability are not the same axis.

Worse, naive sentiment detection is itself an untrained classifier — brittle to sarcasm, politeness, and phrasing. You would be stacking one unreliable signal on top of another and calling it a policy.

The Right Pattern for Emotion

Emotion is not irrelevant — it is just not an escalation trigger. The exam prescribes a specific three-step pattern for an upset user:

Acknowledge the emotion.
Propose a concrete solution.
Escalate only if the request is reiterated — i.e. the user explicitly insists or asks for a human.

So you respond empathetically and try to solve the problem first. The handoff happens on the explicit reiterated request, which is a verifiable event, not on the sentiment score that detected the frustration.

# Good: empathy in the reply, escalation on the REQUEST
system = (
    "If the customer is upset: first acknowledge how they "
    "feel, then propose a concrete next step using your tools. "
    "Call escalate_to_human ONLY if the customer explicitly "
    "asks for a person or repeats the request after your fix."
)

Anchor Escalation in Tools and Thresholds

The reliable way to escalate is to wire it to concrete state and explicit thresholds, enforced where it matters.

In the Customer Support scenario, you expose an escalate_to_human tool alongside get_customer, lookup_order, and process_refund. The model decides to call it based on the four good triggers — not on a mood reading.

For anything with financial, legal, or safety consequences, you do not trust the prompt alone. You enforce it deterministically.

# Escalate on a real threshold, deterministically enforced.
# A PostToolUse / outgoing-call hook blocks the action
# regardless of how the model 'feels' about it.
def on_process_refund(amount, customer):
    if amount > 500:
        # Hook = 100% deterministic enforcement
        return {"block": True, "route": "escalate_to_human"}
    return {"block": False}

Hooks vs Prompts for the Hard Limits

Why a hook and not a sentence in the system prompt?

The fact sheet is blunt about this: hooks are 100% deterministic; prompts are ~90% probabilistic. When a wrong escalation (or a missed one) has financial, legal, or safety consequences, ~90% is not good enough.

A self-rated confidence threshold lives entirely inside the probabilistic layer — it can drift, be re-rated, or be talked around. A threshold violation enforced by a hook (e.g. refund > $500 always routes to a human) is a guarantee. Reserve hard code for guarantees; keep model-driven judgement for everything softer.

No-Progress: A Verifiable Trigger Done Right

"No progress after attempts" sounds fuzzy but is actually concrete: it is grounded in observable loop state, not feelings.

You count real attempts — tool calls that returned no usable result, turns with no forward movement. That is a fact about the transcript, the same way stop_reason is a fact about the response.

Critically, note the difference from the anti-patterns: an iteration cap here is a safety net for a genuinely stuck loop, never a confidence dial. You are escalating because nothing worked, which you can prove, not because the model rated itself unsure.

# Escalate on demonstrable lack of progress, not on mood.
attempts = 0
while True:
    resp = client.messages.create(model=MODEL, max_tokens=1024,
                                   system=SYS, tools=TOOLS,
                                   messages=history)
    if resp.stop_reason == "tool_use":
        results = run_tools(resp)
        if all(r["empty"] for r in results):
            attempts += 1
        history += [as_turn(resp), tool_results(results)]
        if attempts >= 3:        # verifiable, not a vibe
            escalate_to_human(reason="no_progress")
            break
    else:
        break  # terminate on stop_reason, never on parsed text

Empty Result Is Not Low Confidence

A frequent trap: treating an empty or ambiguous result as "the model is unsure, so escalate."

The fact sheet draws a sharp line. Distinguish:

an access FAILURE (the lookup errored — maybe retry the transient fault locally), from
a valid EMPTY result (the query ran fine; there are simply no matches).

And for ambiguity — multiple customer matches — the correct move is to ask for more identifiers, never guess, and never escalate on a fabricated confidence drop. The right signal is the structured outcome of the tool, not a sentiment or self-score wrapped around it.

Putting It Together

An architect-grade escalation policy reads like this:

Escalate on explicit human request, policy gaps, no progress after attempts, and threshold violations — all verifiable.
For upset users: acknowledge, propose a solution, escalate only on reiteration.
Enforce consequential thresholds with hooks, not prompt text.
Never route on sentiment, a self-rated 1-10 confidence, or an untrained classifier.

The throughline: escalate on facts you can point to, and reserve deterministic code for the guarantees that matter.

GOOD_TRIGGERS = [
    "explicit_human_request",   # escalate immediately
    "policy_gap",
    "no_progress_after_attempts",
    "threshold_violation",      # hook-enforced when consequential
]
BAD_TRIGGERS = [
    "sentiment_score",          # mood is not resolvability
    "self_rated_confidence",    # uncalibrated 1-10 self-report
    "untrained_classifier",     # no validated ground truth
]

Quick Check

A scenario-style question on escalation design.

在交互式课程中回答

Recap & Takeaways

Key takeaways:

Escalate only on verifiable triggers: explicit human request, policy gaps, no progress after attempts, threshold violations.
Never escalate on sentiment, a model self-rated 1-10 confidence score, or untrained classifiers — they are not grounded in real state.
For emotion: acknowledge → propose a solution → escalate only if the request is reiterated.
Distinguish an access failure from a valid empty result; for ambiguous matches, ask for more identifiers, don't guess.
Enforce consequential thresholds with hooks (deterministic), not prompts (~90%). Reserve hard code for guarantees.

Design escalation around facts you can point to — and you will pass both the exam and production.

免费开始

用 AI 导师学习 Python — 免费

在浏览器中编写并运行真实代码，获得全天候 AI 导师的即时帮助，并在网页或应用中继续学习。

课程: 26
课程: 104

免费开始学习查看完整课程

常见问题解答

「反模式：情绪与置信度评分」课时是免费的吗？

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

「反模式：情绪与置信度评分」这节课中我会学到什么？

绝不要根据情绪或自评的 1–10 分进行升级。你通过在浏览器中直接运行的动手代码来练习 Claude Architect，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Claude Architect 需要有经验吗？

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

「反模式：情绪与置信度评分」课时需要多长时间？

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

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

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

此课程中的所有课时

← 返回 Claude Architect