fable5-best-practice

fable5-best-practice

将 Claude Fable 5 视为长周期决策与编排模型，而不是更快的聊天模型。只有当判断、任务分解、验证或持续使用工具的重要性足以抵消其较高的成本和延迟时，才使用它。

当前的 Fable 信息变化很快。在提供定价、可用性、数据保留、回退或特定平台 API 建议之前，请重新核查 Anthropic 官方文档。截至 2026-07-09，官方文档将 Fable 5 描述为具有高度自主性的模型，始终启用自适应思考，通常以 high 作为起始工作强度，价格高于 Opus/Sonnet，并要求保留数据 30 天，因此无法用于零数据保留安排。

核心原则

使用能够可靠满足验收标准的最便宜模型。

• 使用 Sonnet 进行探索、机械执行、长时间工具循环和确定性验证。
• 使用 Opus 处理注重品味的创作、架构/API 审查、细致实现和资深判断。
• 使用 Fable 5 处理复杂推理、长周期自主工作、事前复盘、综合相互矛盾的证据和最终裁决。
• 如果执行环境提供 Codex，就将它用作独立的资深工程同伴；它采用不同的模型系列，并具备强大的本地工具支持。

只有在更便宜的模型未能满足某项具体验收标准，或任务的重要性高到使用较弱模型反而不划算时，才升级模型。将 Fable 的 token 用于判断，而不是大量搜集上下文。

何时使用 Fable

当工作至少具备以下一项特征时，优先使用 Fable 5：

• 涉及多个步骤、文件、系统、相关方或多天的工作。
• 方向不明确，需要界定问题、设计架构、品味判断、权衡取舍或事前复盘。
• 用户需要的是策略、设计、研究计划、迁移计划、评估套件或 Agent 循环，而不是简短答案。
• 验证很重要，而且 Agent 能够检查证据、运行工具、测试假设并自我纠正，然后再宣告成功。
• 持久化记忆或可长期保留的工作笔记能够显著改善结果。

简单问答、格式调整、机械编辑、一次性摘要、常规仓库搜索，或更便宜的模型能够一次完成的工作，都不要使用 Fable 5。

善用模型

优先提出目标，而不是逐步进行微观管理：

• 说明期望结果、成功标准、约束、受众和审批关卡。
• 说明输出的用途，以及它将支持哪项决策或工作流。
• 提供工具、文件、测试和证据来源，让 Fable 能够衡量进展。
• 让它提出执行路径，但对于破坏性、高成本、对外可见或会改变范围的操作，必须设置检查点。

指令保持精简。保留保护安全、预算、数据、风格、范围或业务判断的规则。删去那些只会迫使模型重新解释、过度规划、过度组织结构或暴露隐藏推理的框架。

信息足以采取行动时，就立即行动。不要重新推导已经确定的事实，不要重开用户已经做出的决定，不要调查不会采用的选项，也不要在现在就能完成工作时以承诺将来处理作结。

限制高工作强度的运行范围。除非证据表明确有必要，否则不要添加功能、大范围重构、防御性备份、功能标志、兼容性垫片、抽象层或超出任务要求的验证。在用户输入和外部 API 等系统边界进行验证；在适当情况下，信任内部框架提供的保障。

如果用户是在提问、分享问题或边想边说，而不是委托你修改内容，就给出评估并停止。

审查旧提示词

将现有提示词、技能或工作流迁移到 Fable 5 之前：

• 删除仅用于弥补较弱模型能力的分步脚手架。
• 保留用于保障安全、预算、数据、风格、范围或业务约束的规则。
• 删除“展示你的推理过程”“转录你的思考过程”及类似指令。
• 检查超时、流式传输、进度指示器和异步任务处理；复杂任务可能运行数分钟，而自主运行可能持续数小时甚至数天。
• 在推广迁移之前，先用真实工作负载重新评估成本和令牌用量。

探索未知因素

提示词是地图。代码库、设计空间、用户、约束和部署范围则是疆域。Fable 的输出通常受限于运行过程揭示未知因素的能力，而非模型的原始能力。

将不确定性分为四类：

• 已知的已知：在提示词中明确说明。
• 已知的未知：提出问题、开展研究或制作原型。
• 未知的已知：通过头脑风暴和一次性原型，展现“看到就知道”的审美判断。
• 未知的未知：要求检查盲点。

对于影响重大的工作或含糊不清的任务，请阅读 references/phase-playbook.md，并仅选择适合该任务的技巧：

• 之前：检查盲点、头脑风暴／制作原型、访谈、源码参考，以及优先列出可变决策的实施计划。
• 期间：在新的实施会话中，保留一份临时的 implementation-notes.md 偏差日志。
• 之后：在合并前，制作推介／说明材料，或进行测验。

如果用户需要对某种形式作出反馈，而不是阅读文字说明，头脑风暴、原型、计划、推介和测验优先采用 HTML 材料。

简要访谈

对于影响重大的工作，如果可用，请在规划前使用运行环境提供的用户提问工具。询问意图、优先事项、约束和判断事项，而非你可以自行检查的事实。

高影响力的问题：

• 理想的目标状态是什么，而不只是下一项任务？
• 谁会使用输出？它应该支持什么决策或工作流？
• 哪些约束是真实存在的：截止日期、预算、技术栈、政策、数据、质量标准？
• 哪些情况应该让 Fable 暂停：破坏性变更、采购、部署、对外消息、法律／安全／隐私议题，或重大范围变更？
• 即使完成了大量工作，什么情况仍会让这次运行失败？
• 此运行环境能否生成子 Agent？如果可以，请明确设计模型路由。

如果提问工具支持选项，请将推荐的默认选项放在首位，并标记为 (Recommended)。如果没有可用的提问工具，请用简洁易懂的语言提问；风险较低时，可基于合理假设继续进行。

设定投入程度和预算

有意识地选择投入程度：

• low：常规分类、提取、可靠且范围明确的工作，以及成本低廉的机械式检查。
• medium：交互式探索、快速设计反馈、简单调试，或延迟比深入搜索更重要的情况。
• high：严肃的编码、架构、规划、研究综合、产品战略和多步骤工具调用的默认等级。
• xhigh 或可用的最高投入程度：高风险决策、大型迁移、复杂根因分析、评估设计、深入的事前复盘和最终裁决。

由 Fable 主导的编码工作流默认设为 high，而非最高等级。仅在决策风险较高或 high 未满足验收标准时升级。如果 high 已解决任务，但探索了未采用的替代方案、添加了未经要求的改进，或输出的细节超出用户可处理的范围，则降至 medium。

在可用时设置明确预算：时间、令牌、成本、工具调用次数、可修改文件的上限、尝试次数上限，以及停止条件。对于范围狭窄的任务，添加控制范围的指令。

投入程度与模型选择相互独立。Sonnet-low 映射流程和 Opus-high 设计审查，是同一坐标系上的不同点。

定义边界

对于长期运行或敏感工作，使用简短的允许／禁止边界：

Boundary:
- Allowed: [files, tools, systems, actions]
- Forbidden: [external messages, deploys, branch changes, destructive commands,
  purchases, secrets, unrelated directories]

Pause only for destructive or irreversible actions, real scope changes, or information
only the user can provide. Otherwise continue and report when done.

如果 Agent 发现边界之外有用的操作，应先提出建议并等待。

设计循环

对于雄心勃勃的工作，应构建一个循环：

1. 明确目标、约束和审批关卡。
2. 制定计划，列出里程碑、风险、依赖项和验证方式。
3. 执行下一个最具杠杆效应的部分。
4. 使用工具、测试、审查或源系统中的证据进行验证。
5. 记录简洁的经验，并更新计划。
6. 持续推进，直到达到完成标准、预算上限或停止条件。

每个循环都需要明确且可确定的停止条件、最大尝试次数，以及包含剩余失败项或停止原因的报告格式。优先采用数值化或可通过外部检查的完成标准，而不是“做得更好”之类的表述。

不要让执行上下文独自评判重要工作。当正确性、安全性、成本或外部影响至关重要时，应加入独立验证者：子 Agent、更便宜的模型、测试套件、代码检查工具、基准测试、查询、截图检查、利益相关方检查清单或人工审批关卡。

只有在本地运行环境确实提供 /goal、/loop、/schedule、/sprint、自定义命令或动态工作流时，才使用它们。将其视为阶段控制原语，而非验收标准、预算和停止条件的替代品。

以证据为依据跟踪进展

长期自主运行必须将状态与证据关联起来。需要确保状态准确时，添加以下指令：

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 verified, label it
unverified. If tests failed or a step was skipped, say so plainly.

不要把“我计划运行 X”算作进展。如果 Agent 表示将运行某个工具，且允许执行该操作，就应在结束本轮前运行该工具。

如果 Agent 可以提前停止并只提供计划，而不采取行动，则添加：

Before ending your turn, check whether your last message is a plan, promise, question,
or list of next steps. If the original request allows the work and no user-only input
is required, do the work now with tools.

谨慎使用记忆

对于跨会话工作，应维护简短的持久记忆，例如 state.md；只有在经验教训需要跨任务保留时，才使用 learnings/。将记忆维护为实时快照，而非变更日志。

建议采用以下格式：

# Current State

One-sentence summary of the goal and current status.

## Decisions
- Durable decisions that should affect future work.

## Constraints
- Real constraints and approval gates.

## Learnings
- Things discovered through failed attempts, tests, user feedback, or measurement.

## Next
- The next highest-leverage action.

用更新后的内容替换过时内容，不要追加日记。不要重复仓库或聊天中已有的事实。创建更多文件前，先更新重复的记录；如果后续证据证明某些记录有误，就删除它们。

路由模型并控制上下文

对于任何工作流、子 Agent 树、模型分配策略，或可生成子 Agent 的 Agent 提示词，都应阅读 references/claude-model-routing.md。该参考文档包含详细的路由矩阵、成本规则、缓存／会话成本、令牌管理检查清单、Codex 就绪关卡和交接提示词。

在主提示词中保留以下操作模式：

• 让 Fable 梳理问题、拆解工作、精简上下文，并做出最终判断。
• 当验收标准明确时，将原始信息发现、文件阅读、日志分类、浏览器／计算机操作的底层配置、脚本化运维和机械式实现委派给 Sonnet。
• 将架构、细微的代码质量问题、对审美要求较高的 UI／文案／API 工作以及设计审查交给 Opus。
• 只有当前运行环境提供 Codex 且设置确认其已就绪时，才将 Codex 用作独立的同行审查者。
• 向工作 Agent 提供精简的设计任务包：目标、约束、负责路径、不变量、验收标准、验证命令和审批关卡。
• 要求工作 Agent 提交简洁的输出：结论、证据、变更文件、验证结果、阻碍因素，以及需要升级处理的决策。

绝不要把大批量工作委派给 Fable 的分身。分身会继承昂贵的上下文，因此预期中的低成本工作者实际上会按编排器的价格运行。应改为启动具有全新上下文的 Sonnet／Opus 工作 Agent。

对于长期运行的工作 Agent，添加：

Never end your turn while work remains. Wait by blocking (sleep/poll loops inside a
tool call with a generous timeout), not by stopping to await notifications.

处理拒绝

将 Fable 的拒绝和回退视为产品行为，而不是崩溃。

• 将 stop_reason: "refusal" 视为需要路由处理的成功响应。
• 在可用时配置服务端、客户端或手动回退。
• 适当将请求改写为无害的防御、教育或合规工作。
• 不要尝试绕过安全措施。
• 不要指示 Fable 复现、转录或暴露隐藏推理。

沟通结果

长时间运行后，Fable 可能会过度解释。在最终回复中，先说明结果： 发生了什么、发现了什么或改变了什么。只补充会影响读者信任程度或后续行动的细节。

面向没有观看工具调用过程的用户进行写作。避免使用晦涩的简写、未解释的标签、箭头链、对隐藏推理的提及，以及臆造的分类体系，除非这些内容有助于用户做出决定。

只有在工作确实需要用户参与时才暂停：例如破坏性或不可逆的操作、实质性的范围变更、对外承诺，或只有用户才能提供的信息。

如果运行框架向模型显示剩余上下文预算，不要将该数字纳入任务描述。如果必须展示，请明确说明不要仅仅因为上下文限制而停止、总结或移交任务。

提示词模式

对于重要任务，请使用 references/prompt-patterns.md。它将 Fable 提示词划分为上下文、请求、输出格式、约束、当前状态、成功标准、委派／模型组合、审批关卡，以及以“你的任务”收尾的部分，要求模型先询问用户、检查盲点、制定计划、进行事前验尸、执行并验证。

向用户提供建议时，请明确说明适用模式：

• 任务适合长期自主执行时，说明“这项任务适合交给 Fable”。
• 任务主要是执行工作时，说明“仅将 Fable 用于决策环节”。
• 任务简单或重复时，说明“使用成本更低的模型”。
• 正确性、安全性或外部影响很重要时，说明“添加验证器”。
• 运行可能失控扩展时，说明“设定预算和停止条件”。