最佳实践提示工程

为 Claude Fable 5 编写提示

Claude Fable 5 和 Claude Mythos 5 的行为差异与提示模式，涵盖 effort、指令遵循、长时间运行、记忆以及脚手架变更。

本指南介绍 Claude Fable 5 和 Claude Mythos 5 特有的提示和脚手架模式。有关模型的能力、API 变更、定价和可用性，请参阅Claude Fable 5 和 Claude Mythos 5 介绍。有关适用于所有当前 Claude 模型的技术，请参阅提示最佳实践。

Claude Fable 5 能够处理对先前模型而言过于复杂、耗时过长或过于模糊的问题，尤其擅长需要人工花费数小时、数天甚至数周才能完成的端到端工作。取得最佳成果的团队会将 Claude Fable 5 应用于他们最棘手的未解决问题；仅在较简单的工作负载上测试它往往会低估其能力范围。它在较为直接的任务上同样表现可靠。

Claude Fable 5 与 Claude Opus 4.8 存在若干行为差异，可能需要更新提示或脚手架。这种级别的能力提升也是重新评估哪些指令、工具和防护措施仍然必要的良好契机。以下模式涵盖了最常需要调整的行为。

有关 Claude Fable 5 和 Claude Mythos 5 特有的 API 参数变更（仅支持自适应思考、仅输出摘要化的思考内容、无扩展思考预算、refusal 停止原因及回退处理），请参阅Claude Fable 5 和 Claude Mythos 5 介绍。

Claude Fable 5 运行的安全分类器针对攻击性网络安全技术（如构建漏洞利用程序、恶意软件或攻击工具）、生物学和生命科学内容（如实验室方法或分子机制）以及提取模型摘要化思考内容的行为。良性的网络安全工作和有益的生命科学任务也可能触发这些防护措施。要自动重新路由被拒绝的请求，请配置服务器端或客户端回退至 Claude Opus 4.8。

能力提升

与 Claude Opus 4.8 相比，Claude Fable 5 在以下方面有所改进：

长时程自主性。 Claude Fable 5 能够在较长时间内持续产出有效成果，完成持续多天的目标导向运行，并在冗长复杂的任务中保持出色的指令记忆能力。
复杂且规范明确问题的首次正确率。 早期测试者报告称，以往需要数天迭代的系统现在可以一次性实现。
视觉能力。 Claude Fable 5 能够以显著更高的准确率解读密集的技术图像、Web 应用程序和详细的屏幕截图，且通常使用更少的输出令牌；它还经过训练，可使用 bash 和裁剪工具来处理翻转、模糊或含噪声的图像。
企业工作流。 Claude Fable 5 能够遵循指令、保持在范围内，并在财务分析、电子表格、幻灯片和文档方面产出专业级成果。
代码审查和调试。 缺陷发现召回率（在安全分类器所覆盖的网络安全领域之外）明显高于 Claude Opus 4.8，包括跨代码库和仓库历史的搜索。
应对模糊性。 当收到复杂的多线程请求并被要求确定后续步骤时，Claude Fable 5 表现出色。
委派与协作。 Claude Fable 5 在调度和维持并行子智能体方面显著更加可靠，并能稳定地管理与长时间运行的子智能体及对等智能体之间的持续通信。

除了这些具体改进之外，Claude Fable 5 在几乎所有任务上的能力都普遍优于先前的模型。Claude Fable 5 不适用于攻击性网络安全或生物学和生命科学工作；这些领域的请求可能返回 stop_reason: "refusal"。

默认更长的回合

在较高的 effort 设置下，针对困难任务的单个请求可能运行数分钟，尤其是当任务需要收集上下文、构建和自我验证时；而自主运行可能持续数小时。这是团队在适应 Claude Fable 5 时遇到的最大转变之一。在迁移之前，请调整客户端超时、流式传输和面向用户的进度指示器，并考虑重构测试框架以异步检查运行状态（例如通过定时任务），而不是阻塞等待。为防止 Claude Fable 5 在任务模糊时过度规划：

When you have enough information to act, act. Do not re-derive facts already established
in the conversation, re-litigate a decision the user has already made, or narrate
options you will not pursue in user-facing messages. If you are weighing a choice, give
a recommendation, not an exhaustive survey. This does not apply to thinking blocks.

考虑所有 effort 级别

Effort 是在 Claude Fable 5 上控制智能、延迟和成本之间权衡的主要手段。对于大多数任务，使用 high 作为默认值；对于对能力最敏感的工作负载使用 xhigh；对于常规工作使用 medium 或 low。Claude Fable 5 上较低的 effort 设置仍然表现良好，且通常超过先前模型上 xhigh 的表现。如果任务能够完成但耗时超出必要，或者您希望获得更快速、更具交互性的工作方式，请降低 effort。

在较高 effort 下处理常规工作时，Claude Fable 5 可能会收集超出任务所需的上下文并进行过度推敲。与此同时，较高的 effort 通常会产生出色的验证行为、复杂的推理以及最严谨的输出。为防止在较高 effort 下出现未经请求的整理或重构：

Don't add features, refactor, or introduce abstractions beyond what the task requires. A
bug fix doesn't need surrounding cleanup and a one-shot operation usually doesn't need a
helper. Don't design for hypothetical future requirements: do the simplest thing that
works well. Avoid premature abstraction and half-finished implementations. Don't add
error handling, fallbacks, or validation for scenarios that cannot happen. Trust
internal code and framework guarantees. Only validate at system boundaries (user input,
external APIs). Don't use feature flags or backwards-compatibility shims when you can
just change the code.

强大的指令遵循能力

指令遵循能力的提升足以让您通过简短的指令来引导大多数行为，而无需逐一列举每种行为。例如，在未经引导的情况下，Claude Fable 5 可能会超出任务所需进行详细阐述，尤其是在较高的 effort 设置下：罗列它不会采用的选项、冗长地解释根本原因、生成结构繁复的 PR 描述，或编写逐行解说下一行代码作用的注释。一条简短的简洁性指令与逐一列出每种模式同样有效：

Lead with the outcome. Your first sentence after finishing should answer "what happened"
or "what did you find": the thing the user would ask for if they said "just give me the
TLDR." Supporting detail and reasoning come after. Being readable and being concise are
different things, and readability matters more.

The way to keep output short is to be selective about what you include (drop details
that don't change what the reader would do next), not to compress the writing into
fragments, abbreviations, arrow chains like A → B → fails, or jargon.

这同样适用于长时间运行工作流中的检查点行为。要让 Claude Fable 5 仅在真正需要您介入时停下，无需列举每种情况：

Pause for the user only when the work genuinely requires them: a destructive or
irreversible action, a real scope change, or input that only they can provide. If you
hit one of these, ask and end the turn, rather than ending on a promise.

在长时间运行期间核实进度声明

在长时间自主运行中，指示 Claude Fable 5 根据实际工具结果审核进度。在 Anthropic 的测试中，即使是专门设计用于诱发虚假状态报告的任务，这种做法也几乎完全消除了此类问题：

Before reporting progress, audit each claim against a tool result from this session.
Only report work you can point to evidence for; if something is not yet verified, say so
explicitly. Report outcomes faithfully: if tests fail, say so with the output; if a step
was skipped, say that; when something is done and verified, state it plainly without
hedging.

明确边界

Claude Fable 5 偶尔会执行未经请求的操作（在未被要求时起草电子邮件、创建防御性的 git 分支备份）。请明确定义 Claude Fable 5 应该做什么和不应该做什么的约束：

When the user is describing a problem, asking a question, or thinking out loud rather
than requesting a change, the deliverable is your assessment. Report your findings and
stop. Don't apply a fix until they ask for one. Before running a command that changes
system state (restarts, deletes, config edits), check that the evidence actually
supports that specific action. A signal that pattern-matches to a known failure may have
a different cause.

并行子智能体

Claude Fable 5 比先前的模型更倾向于调度并行子智能体。请频繁使用子智能体，提供关于何时适合委派的明确指导，并优先采用编排器与子智能体之间的异步通信，而非阻塞等待每个子智能体返回。在多个子任务之间保持上下文的长期子智能体可以通过缓存读取节省时间和成本，并避免因最慢的子智能体而形成瓶颈。

Delegate independent subtasks to subagents and keep working while they run. Intervene
if a subagent goes off track or is missing relevant context.

构建记忆系统

当 Claude Fable 5 能够记录先前运行中的经验教训并加以参考时，其表现尤为出色。请提供一个记录笔记的位置，简单到一个 Markdown 文件即可：

Store one lesson per file with a one-line summary at the top. Record corrections and
confirmed approaches alike, including why they mattered. Don't save what the repo or
chat history already records; update an existing note rather than creating a duplicate;
delete notes that turn out to be wrong.

要从现有历史记录引导记忆系统，可让 Claude Fable 5 回顾过去的会话：

Reflect on the previous sessions we've had together. Use subagents to identify core
themes and lessons, and store them in [X]. Make sure you know to reference [X] for
future use.

罕见的提前停止情况

在长时间会话的深处，Claude Fable 5 偶尔会以纯文本的意图声明（"我现在将运行 X"）结束一个回合，而不发出相应的工具调用；或者在已有足够信息继续的情况下暂停请求许可。此时回复"继续"或"直接端到端完成"即可。要定义何时暂停是合适的，请将此与强大的指令遵循能力中的检查点指令配合使用。对于自主流水线，请添加系统提醒：

You are operating autonomously. The user is not watching in real time and cannot answer
questions mid-task, so asking "Want me to…?" or "Shall I…?" will block the work. For
reversible actions that follow from the original request, proceed without asking.
Offering follow-ups after the task is done is fine; asking permission after already
discussing with the user before doing the work is not. Before ending your turn, check
your last paragraph. If it is a plan, an analysis, a question, a list of next steps, or
a promise about work you have not done ("I'll…", "let me know when…"), do that work now
with tool calls. End your turn only when the task is complete or you are blocked on
input only the user can provide.

罕见的上下文预算顾虑情况

在非常长的会话中，Claude Fable 5 偶尔会建议开启新会话、提议总结并交接，或自行削减工作内容。这种情况最常在测试框架向模型显示剩余令牌倒计时时触发。请尽可能避免显示明确的上下文预算计数。如果测试框架必须显示这些信息，添加一条安抚性说明会有所帮助：

You have ample context remaining. Do not stop, summarize, or suggest a new session on
account of context limits. Continue the work.

说明原因，而非仅提出请求

当 Claude Fable 5 理解请求背后的意图时，往往表现更好：上下文使其能够将任务与相关信息关联起来，而不是自行推断意图。请提供关于您为何提出请求的背景信息，对于需要调用多个工作流的长时间运行智能体尤其如此：

I'm working on [the larger task] for [who it's for]. They need [what the output
enables]. With that in mind: [request].

与用户沟通时的可读性

在扩展的或智能体式的对话中（大量工具调用、庞大的工作上下文），Claude Fable 5 可能会生成难以理解的文本：密集的箭头链式简写、深入的实现细节、引用用户从未看到的思考内容，或过于技术化的措辞。添加一条沟通风格补充说明可以缓解这一问题：

Terse shorthand is fine between tool calls (that's you thinking out loud, and brevity
there is good). Your final summary is different: it's for a reader who didn't see any of
that.

If you've been working for a while without the user watching (overnight, across many
tool calls, since they last spoke), your final message is their first look at any of it.
Write it as a re-grounding, not a continuation of your working thread: the outcome
first, then the one or two things you need from them, each explained as if new. The
vocabulary you built up while working is yours, not theirs; leave it behind unless you
re-introduce it.

When you write the summary at the end, drop the working shorthand. Write complete
sentences. Spell out terms. Don't use arrow chains, hyphen-stacked compounds, or labels
you made up earlier. When you mention files, commits, flags, or other identifiers, give
each one its own plain-language clause. Open with the outcome: one sentence on what
happened or what you found. Then the supporting detail. If you have to choose between
short and clear, choose clear.

创建发送给用户的工具

在运行长时间的异步智能体时，为智能体提供一种方式，使其能够在不结束回合的情况下向用户呈现必须原样查看的消息：交付物（生成的代码片段或起草的消息）、带有具体数字的进度更新，或对用户在循环中途提出的问题的直接回复。该工具的输入即为要显示的消息；当 Claude 调用它时，直接在您的 UI 中渲染该输入，并返回一个简单的确认作为工具结果。工具输入永远不会被摘要化，因此内容会完整送达。

{
  "name": "send_to_user",
  "description": "Display a message directly to the user. Use this for progress updates, partial results, or content the user must see exactly as written before the task finishes.",
  "input_schema": {
    "type": "object",
    "properties": {
      "message": {
        "type": "string",
        "description": "The content to display to the user."
      }
    },
    "required": ["message"]
  }
}

只要您的用户体验依赖于在任务中途逐字传递内容或直接的用户交互，就应添加此工具。对于仅叙述常规进度的智能体，模型自身的摘要通常已经足够。

为 Claude Fable 5 编写提示

Claude Fable 5 和 Claude Mythos 5 的行为差异与提示模式，涵盖 effort、指令遵循、长时间运行、记忆以及脚手架变更。

能力提升

与 Claude Opus 4.8 相比，Claude Fable 5 在以下方面有所改进：

长时程自主性。 Claude Fable 5 能够在较长时间内持续产出有效成果，完成持续多天的目标导向运行，并在冗长复杂的任务中保持出色的指令记忆能力。
复杂且规范明确问题的首次正确率。 早期测试者报告称，以往需要数天迭代的系统现在可以一次性实现。
视觉能力。 Claude Fable 5 能够以显著更高的准确率解读密集的技术图像、Web 应用程序和详细的屏幕截图，且通常使用更少的输出令牌；它还经过训练，可使用 bash 和裁剪工具来处理翻转、模糊或含噪声的图像。
企业工作流。 Claude Fable 5 能够遵循指令、保持在范围内，并在财务分析、电子表格、幻灯片和文档方面产出专业级成果。
代码审查和调试。 缺陷发现召回率（在安全分类器所覆盖的网络安全领域之外）明显高于 Claude Opus 4.8，包括跨代码库和仓库历史的搜索。
应对模糊性。 当收到复杂的多线程请求并被要求确定后续步骤时，Claude Fable 5 表现出色。
委派与协作。 Claude Fable 5 在调度和维持并行子智能体方面显著更加可靠，并能稳定地管理与长时间运行的子智能体及对等智能体之间的持续通信。

默认更长的回合

When you have enough information to act, act. Do not re-derive facts already established
in the conversation, re-litigate a decision the user has already made, or narrate
options you will not pursue in user-facing messages. If you are weighing a choice, give
a recommendation, not an exhaustive survey. This does not apply to thinking blocks.

考虑所有 effort 级别

Don't add features, refactor, or introduce abstractions beyond what the task requires. A
bug fix doesn't need surrounding cleanup and a one-shot operation usually doesn't need a
helper. Don't design for hypothetical future requirements: do the simplest thing that
works well. Avoid premature abstraction and half-finished implementations. Don't add
error handling, fallbacks, or validation for scenarios that cannot happen. Trust
internal code and framework guarantees. Only validate at system boundaries (user input,
external APIs). Don't use feature flags or backwards-compatibility shims when you can
just change the code.

强大的指令遵循能力

Lead with the outcome. Your first sentence after finishing should answer "what happened"
or "what did you find": the thing the user would ask for if they said "just give me the
TLDR." Supporting detail and reasoning come after. Being readable and being concise are
different things, and readability matters more.

The way to keep output short is to be selective about what you include (drop details
that don't change what the reader would do next), not to compress the writing into
fragments, abbreviations, arrow chains like A → B → fails, or jargon.

这同样适用于长时间运行工作流中的检查点行为。要让 Claude Fable 5 仅在真正需要您介入时停下，无需列举每种情况：

Pause for the user only when the work genuinely requires them: a destructive or
irreversible action, a real scope change, or input that only they can provide. If you
hit one of these, ask and end the turn, rather than ending on a promise.

在长时间运行期间核实进度声明

Before reporting progress, audit each claim against a tool result from this session.
Only report work you can point to evidence for; if something is not yet verified, say so
explicitly. Report outcomes faithfully: if tests fail, say so with the output; if a step
was skipped, say that; when something is done and verified, state it plainly without
hedging.

明确边界

When the user is describing a problem, asking a question, or thinking out loud rather
than requesting a change, the deliverable is your assessment. Report your findings and
stop. Don't apply a fix until they ask for one. Before running a command that changes
system state (restarts, deletes, config edits), check that the evidence actually
supports that specific action. A signal that pattern-matches to a known failure may have
a different cause.

并行子智能体

Delegate independent subtasks to subagents and keep working while they run. Intervene
if a subagent goes off track or is missing relevant context.

构建记忆系统

当 Claude Fable 5 能够记录先前运行中的经验教训并加以参考时，其表现尤为出色。请提供一个记录笔记的位置，简单到一个 Markdown 文件即可：

Store one lesson per file with a one-line summary at the top. Record corrections and
confirmed approaches alike, including why they mattered. Don't save what the repo or
chat history already records; update an existing note rather than creating a duplicate;
delete notes that turn out to be wrong.

要从现有历史记录引导记忆系统，可让 Claude Fable 5 回顾过去的会话：

Reflect on the previous sessions we've had together. Use subagents to identify core
themes and lessons, and store them in [X]. Make sure you know to reference [X] for
future use.

罕见的提前停止情况

You are operating autonomously. The user is not watching in real time and cannot answer
questions mid-task, so asking "Want me to…?" or "Shall I…?" will block the work. For
reversible actions that follow from the original request, proceed without asking.
Offering follow-ups after the task is done is fine; asking permission after already
discussing with the user before doing the work is not. Before ending your turn, check
your last paragraph. If it is a plan, an analysis, a question, a list of next steps, or
a promise about work you have not done ("I'll…", "let me know when…"), do that work now
with tool calls. End your turn only when the task is complete or you are blocked on
input only the user can provide.

罕见的上下文预算顾虑情况

You have ample context remaining. Do not stop, summarize, or suggest a new session on
account of context limits. Continue the work.

说明原因，而非仅提出请求

I'm working on [the larger task] for [who it's for]. They need [what the output
enables]. With that in mind: [request].

与用户沟通时的可读性

Terse shorthand is fine between tool calls (that's you thinking out loud, and brevity
there is good). Your final summary is different: it's for a reader who didn't see any of
that.

If you've been working for a while without the user watching (overnight, across many
tool calls, since they last spoke), your final message is their first look at any of it.
Write it as a re-grounding, not a continuation of your working thread: the outcome
first, then the one or two things you need from them, each explained as if new. The
vocabulary you built up while working is yours, not theirs; leave it behind unless you
re-introduce it.

When you write the summary at the end, drop the working shorthand. Write complete
sentences. Spell out terms. Don't use arrow chains, hyphen-stacked compounds, or labels
you made up earlier. When you mention files, commits, flags, or other identifiers, give
each one its own plain-language clause. Open with the outcome: one sentence on what
happened or what you found. Then the supporting detail. If you have to choose between
short and clear, choose clear.

创建发送给用户的工具

{
  "name": "send_to_user",
  "description": "Display a message directly to the user. Use this for progress updates, partial results, or content the user must see exactly as written before the task finishes.",
  "input_schema": {
    "type": "object",
    "properties": {
      "message": {
        "type": "string",
        "description": "The content to display to the user."
      }
    },
    "required": ["message"]
  }
}

为 Claude Fable 5 编写提示

能力提升

默认更长的回合

考虑所有 effort 级别

强大的指令遵循能力

在长时间运行期间核实进度声明

明确边界

并行子智能体

构建记忆系统

罕见的提前停止情况

罕见的上下文预算顾虑情况

说明原因，而非仅提出请求

与用户沟通时的可读性

创建发送给用户的工具

推荐的脚手架变更

为 Claude Fable 5 编写提示

能力提升

默认更长的回合

考虑所有 effort 级别

强大的指令遵循能力

在长时间运行期间核实进度声明

明确边界

并行子智能体

构建记忆系统

罕见的提前停止情况

罕见的上下文预算顾虑情况

说明原因，而非仅提出请求

与用户沟通时的可读性

创建发送给用户的工具

推荐的脚手架变更