Claude Architect · 课时

确定性执行与提示词

钩子具有 100% 的确定性；提示词的成功概率约为 90%。

第 2 / 4 课13 个步骤

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

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

Two Ways to Enforce a Rule

When you need an agent to always follow a rule, you have two fundamentally different tools.

Prompts ask the model to behave a certain way. The model usually complies — but it's still a probabilistic system making a judgment call.
Hooks are deterministic code that runs around tool calls. They don't ask — they enforce.

This lesson teaches the single most important number in workflow enforcement: a well-written prompt gives you roughly ~90% compliance; a hook gives you 100%.

Prompts Are Probabilistic

A system prompt is guidance. Even an excellent one — explicit criteria, few-shot examples — steers the model toward the right behavior but never guarantees it.

Across thousands of requests, that residual ~10% surfaces: an edge case, an unusual phrasing, a long context where the rule sits in the lost-in-the-middle zone. The model generalizes from your instructions, which is exactly why it can also generalize wrong.

For most behaviors that's fine. For rules where a single violation is unacceptable, ~90% is a liability.

system = (
    "You are a refund agent. "
    "NEVER issue a refund above $500 without manager approval."
)
# This is guidance. The model will *usually* obey —
# but 'usually' is not 'always'. There is no code path
# that physically blocks a $501 refund.

Hooks Are Deterministic

A hook is ordinary code wired into the agent lifecycle. It runs every time, evaluates a condition the same way every time, and its decision does not depend on model reasoning.

PostToolUse hooks intercept a tool's result before the model ever sees it.
Outgoing-call hooks block policy-violating actions before they execute.

Because the logic is hard-coded, the guarantee is absolute: 100% deterministic enforcement. A blocked action is blocked — no matter what the model decides.

def block_large_refund(tool_name, tool_input):
    if tool_name == "process_refund" and tool_input["amount"] > 500:
        return {"allow": False,
                "reason": "Refunds over $500 require manager approval"}
    return {"allow": True}
# Runs on EVERY process_refund call. $501 is blocked, every time.

The Decision Rule

Here is the rule to memorize for the exam and for real architecture:

Use hooks when failure has financial, legal, or safety consequences.

If a single violation costs money, breaks the law, or endangers someone, ~90% is not acceptable — you need 100%. That is a hook's job. Prompts are for guidance, tone, preference, and the countless soft behaviors where an occasional miss is recoverable.

Don't enforce a critical business rule with prompts alone. That is one of the most common wrong answers on scenario questions.

Programmatic Preconditions

The same deterministic principle applies to preconditions — rules about what must happen before an action is allowed.

Example from the Customer Support scenario: never run process_refund until get_customer has returned a verified customer ID. You could write that as a prompt instruction... or you could enforce it in code so it physically cannot be skipped.

A programmatic precondition gives a deterministic guarantee that prompt guidance cannot. The identity check happens 100% of the time, not 90%.

def require_verified_identity(tool_name, tool_input, state):
    if tool_name == "process_refund" and not state.get("verified_customer_id"):
        return {"allow": False,
                "reason": "Block refund until get_customer returns a verified ID"}
    return {"allow": True}

Why Not Just Prompt Harder?

A tempting trap: "I'll write a really strong prompt — all caps, repeated three times, with examples." This improves compliance, but it does not change the category. You are still on the probabilistic side of the line.

Few-shot examples and explicit criteria are powerful — they raise quality, reduce hallucination, and lock in output format. But they raise the ceiling of ~90%; they never reach the deterministic 100% that financial, legal, and safety rules demand.

If the requirement is a guarantee, no amount of prompt engineering substitutes for code.

Hooks Don't Replace Model Decisions

Important balance: hooks are not a license to hard-code everything. The agentic loop is model-driven — the model decides which tools to call and when, based on stop reasons.

You reserve hard code for guarantees, not for routine decision-making. Think of it as a thin, deterministic safety boundary around an intelligent, flexible core.

The same wisdom appears with iteration caps: a cap is a safety net, never the primary stop mechanism. Terminate on stop_reason, and use deterministic code only where a hard guarantee is genuinely required.

PostToolUse: Guarding Inputs to the Model

A PostToolUse hook intercepts a tool result before the model sees it. This is more than blocking — it's a deterministic checkpoint on data flowing back into the conversation.

Use it to enforce things like: redact secrets from output, validate that a required field is present, or refuse to surface a result that violates policy. Because it runs deterministically on every result, the model never even gets a chance to mishandle data you've decided it must not see raw.

def post_tool_use(tool_name, result):
    if tool_name == "lookup_order":
        # Deterministically strip PII before the model sees it
        result.pop("raw_credit_card", None)
    return result

Outgoing-Call Hooks: Guarding Actions

The mirror image of PostToolUse is the outgoing-call hook: it sits between the model's decision to act and the action actually firing.

This is where you block policy-violating actions — the refund over $500, the email to an unapproved domain, the deletion of a protected resource. The model may request the action; the hook decides whether it executes.

This separation is the architecture: the model proposes, deterministic code disposes — but only for the small set of rules that truly require a guarantee.

def on_outgoing_call(action):
    if action.type == "refund" and action.amount > 500:
        raise PolicyViolation("Refund exceeds $500 ceiling")
    if action.type == "refund" and not action.customer_verified:
        raise PolicyViolation("Customer identity not verified")

Reading the Signal in a Scenario

Exam scenarios telegraph the answer with their wording. Train yourself to spot it:

Words like "must never," "financial," "compliance," "safety," "regulatory," or a hard dollar threshold → the answer involves a hook / deterministic enforcement.
Words like "prefer," "tone," "style," "usually," "when appropriate" → a prompt is fine.

If an option proposes enforcing a hard, costly rule with "a stronger system prompt," it is almost certainly a distractor.

Combine Both Layers

The strongest designs use both. The prompt makes the model want to do the right thing 90% of the time — fewer blocked attempts, smoother conversations, better UX. The hook catches the remaining 10% with a hard guarantee.

Prompt for good default behavior; hook for the non-negotiable boundary. You get a system that is both intelligent and provably safe — guidance for the common case, deterministic enforcement for the catastrophic one.

# Layer 1 (prompt, ~90%): set the right default behavior
system = "Confirm customer identity before any refund, and keep refunds under $500."

# Layer 2 (hook, 100%): the guarantee the prompt can't make
hooks = [require_verified_identity, block_large_refund]

Quick Check: Refund Policy Enforcement

Apply the decision rule to a real scenario.

在交互式课程中回答

Recap: 100% vs ~90%

Key takeaways:

Prompts are ~90% probabilistic guidance; hooks are 100% deterministic enforcement.
Use hooks when failure has financial, legal, or safety consequences; use prompts for tone, preference, and soft behavior.
PostToolUse hooks guard results before the model sees them; outgoing-call hooks block policy-violating actions before they fire.
Programmatic preconditions (block a refund until identity is verified) give guarantees prompts cannot.
Reserve hard code for guarantees — keep the loop model-driven, and combine a good prompt (default behavior) with a hook (hard boundary).
Distrust any answer that enforces a critical, costly rule with "a stronger prompt" alone.

免费开始

用 AI 导师学习 Python — 免费

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

课程: 26
课程: 104

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

常见问题解答

「确定性执行与提示词」课时是免费的吗？

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

「确定性执行与提示词」这节课中我会学到什么？

钩子具有 100% 的确定性；提示词的成功概率约为 90%。你通过在浏览器中直接运行的动手代码来练习 Claude Architect，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Claude Architect 需要有经验吗？

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

「确定性执行与提示词」课时需要多长时间？

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

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

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

此课程中的所有课时

← 返回 Claude Architect