Fable 回来了。下面是真正拿它写代码的方法。

Fable 回来了。

在六月那场出口管制的乱局之后，Anthropic 已经恢复了 Claude Fable 5 的访问。截至 2026 年 7 月 1 日，Fable 再次在全球范围内通过 Claude.ai、Claude Platform、Claude Code 和 Claude Cowork 提供，Anthropic 也在尽快重新开放 AWS、Google Cloud 和 Microsoft Foundry 上的访问。

但这次回归带着一条非常重要的告诫。

Fable 现在受更严格的安全分类器保护。当这些分类器判定某个请求太接近高风险的网络安全、生物学或推理提取领域时，请求会被拦下，转而路由到 Claude Opus 4.8。Anthropic 还说，在他们调低误报的过程中，新分类器更可能把无害的编码和调试任务也标记出来。

这就是为什么有些开发者看到的感觉像是这样的行为：

“我选了 Fable，让它写代码，它却切到了 Opus 4.8。”

可以理解的反应是：“那 Fable 是不是不能写代码了？”

我认为那是个错误的结论。

更好的结论是：

Fable 用来编码仍然可以极其有用，但你得别再把它当成一个通用的自动补全模型来用。把它当成一名资深工程师、架构师、迁移规划者、调试主管和最终评审来用。

这个转变很关键。

Anthropic 自己的 Fable 提示指南说，Fable 在复杂、含糊、长时间运行的工作上最强：那种可能要一个人花上数小时、数天、数周的工作。它特别点名了更强的长程自主性、代码评审、受限网络安全类别之外的调试、代码仓历史搜索、含糊处理，以及子 agent 委派。

所以问题不是：“Fable 能写代码吗？”

真正的问题是：“Fable 该在我的编码工作流里坐在哪个位置，我才能拿到最大价值又不老是撞上回退？”

下面是实操手册。

1. 用 Fable 做判断，而不是敲键盘

浪费 Fable 最快的办法，就是让它去做每一处小改动。

别用它来做：

• 细小的语法修复
• 简单的 CRUD 改动
• 变量改名
• 格式化
• 样板代码生成
• 例行的文件搜索
• 基础的测试更新
• 机械的实现步骤

这些任务通常交给更便宜或更快的模型更合适。

把 Fable 用在犯错代价高昂的地方：

• 架构决策
• 大型重构
• 迁移规划
• 复杂调试
• 设计评审
• 含糊的产品到代码的转译
• 多文件依赖分析
• 最终生产评审
• 测试策略
• 代码库考古
• 长时间运行的 agent 任务
• 在另一个模型实现了改动之后做 pull request 评审

一个好的心智模型：

Sonnet 或 Opus 可以做实现者。
Fable 往往应该做架构师和评审者。

这也和一些早期从业者指南推荐的一致：用更便宜的模型做分诊、重复执行和简单的工具调用，然后请 Fable 来做更深的判断、迁移规划、架构评审和最终决策。

2. 把编码工作拆成三个阶段

从文档和社区模式里我找到的最可靠的 Fable 工作流是这样的：

第一阶段：探索
第二阶段：规划
第三阶段：执行与验证

Fable 不需要独揽每个阶段。

一个实用的搭法：

用一个更便宜的模型或 Opus 4.8 去探索代码仓、收集文件、总结架构、找出测试命令，并准备一份干净的简报。

用 Fable 去推理难的部分：该改什么、可能会坏什么、按什么顺序做、以及怎么验证。

用 Opus 或 Sonnet 去实现重复性的编辑。

再用 Fable 做最终评审。

这套“Fable 三明治”往往比让 Fable 从第一条提示就盲目地把整件活全做完更可靠。

示例工作流：

Opus：梳理代码仓，找出受影响的文件，总结当前行为。
Fable：设计最安全的迁移计划，找出隐藏风险。
Opus 或 Sonnet：实现该计划。
Fable：评审 diff、测试、边缘情况和上线风险。
人：拍板最终交付决定。

这不是绕过防护措施，只是好的模型路由而已。

"Sonnet 或 Opus 可以做实现者。Fable 往往应该做架构师和评审者。胜出的团队，是那些学会在模型之间交接工作的团队，而不是硬逼一个模型走完每一条提示。"

3. 大改动先从规划模式开始

对大型编码任务，Fable 往往应该从只读模式起步。

Claude Code 的文档建议在大改动前用 /plan，并指出 /model 和 /effort 让你调整在任务里投入多少推理。在交付之前，Claude Code 提供 /diff、/code-review、/review 和 /security-review 这些工作流。

一条强力的 Fable 提示长这样：

/model claude-fable-5
/effort high
/plan

Goal:
Design the safest implementation plan for [feature/refactor/migration].

Constraints:
- Do not edit files yet.
- First map the affected files and dependencies.
- Identify assumptions and unknowns.
- Propose the smallest safe change.
- Separate implementation steps from verification steps.
- Tell me which parts should be delegated to a cheaper model.

这做了三件事。

第一，它给了 Fable 那种适合它的高层次推理任务。

第二，它减少了意外的过度编辑。

第三，它产出一份干净的计划，即便 Fable 之后回退，另一个模型也能拿去执行。

4. 默认用 high 力度，而不是永远拉满

Fable 有一个力度旋钮，用好它很关键。

Anthropic 建议对大多数 Fable 任务把 high 作为默认，仅对最考验能力的工作负载用 xhigh，对更例行的工作用 medium 或 low。文档还警告，高力度的 Fable 在例行任务上可能收集比必要更多的上下文、斟酌得比必要更多。

我的实操规则：

交互式编码帮助用 medium。
大多数正经工程任务用 high。
架构、迁移、深度调试和最终评审用 xhigh。
细小改动别用 xhigh。

搭配更高力度的一条好指令：

Do the simplest thing that solves the stated problem. Do not add features, abstractions, compatibility layers, or surrounding cleanup unless they are necessary for this task.

这条指令接近 Anthropic 自己关于在更高力度下防止 Fable 过度重构的指引。

5. 让你的代码仓对 Fable 可读

Fable 很强，但它不会读心术。

如果你的项目上下文一团乱，Fable 就会浪费 token 去发现那些人类团队本可以一次写下来的东西。

Claude Code 建议用 /init 生成一份起步的 CLAUDE.md，再用构建命令、测试命令、代码风格、工作流规则以及不显眼的项目坑点去打磨它。它还警告说，臃肿的 CLAUDE.md 文件会导致 Claude 忽略那些重要的指令。

一份好的 CLAUDE.md 应该包含：

• 如何安装依赖
• 如何跑单个测试
• 如何跑完整测试套件
• 如何做类型检查
• 如何做 lint
• 该用哪个包管理器
• 不显眼的架构规则
• 重要目录
• 分支和 PR 约定
• 代码仓里已知的陷阱

一份糟糕的 CLAUDE.md 包含：

• 冗长的教程
• 显而易见的语言约定
• 逐个文件的说明
• 过时的信息
• 彼此冲突的规则
• 诸如“写干净的代码”这类泛泛的指令

一段实用的 CLAUDE.md 片段：

# Project commands
- Install: pnpm install
- Dev server: pnpm dev
- Typecheck: pnpm typecheck
- Unit test one file: pnpm test path/to/file.test.ts
- Full test suite: pnpm test
- Lint: pnpm lint

# Workflow
- Prefer small, reviewable diffs.
- For bug fixes, add or update a regression test first when practical.
- Run typecheck after a series of code changes.
- Do not run the full test suite unless the targeted tests pass first.

# Architecture
- API routes live in src/server/routes.
- Shared domain logic lives in src/domain.
- UI components should not call database code directly.

这让 Fable 更可靠，因为它能把推理预算花在难题上，而不是重新发现你的工作流。

6. 把可复用的工作流放进 skills

别把每一套工作流都塞进 CLAUDE.md。

Claude Code 通过 SKILL.md 文件支持 skills。文档建议把 skills 用于领域知识和可复用的工作流，让它们按需加载，而不是把每次对话都撑臃肿。

例如，你可以创建：

.claude/skills/fable-migration-review/SKILL.md

---
name: fable-migration-review
description: Review a proposed code migration for hidden risks and verification gaps
---

Review the proposed migration.

1. Identify affected modules.
2. Find hidden dependencies.
3. Identify backwards compatibility risks.
4. Check whether the plan can be split into smaller PRs.
5. Define targeted tests.
6. Define rollback strategy.
7. Produce a ship/no-ship recommendation.

然后每当 Fable 在做迁移评审时，你都可以调用它。

这是对 Fable 的一个好用途，因为价值不在于敲代码，价值在于抓住另一个模型或工程师可能漏掉的东西。

7. 对必须永远发生的规则，用 hooks

指令是建议性的，hooks 是确定性的。

Claude Code 的文档在这一点上非常清楚：对那些必须每次都发生、零例外的动作，用 hooks。例如，一个 hook 可以在编辑后跑 eslint，或者拦下对敏感文件夹的写入。

这对 Fable 很重要，因为在一个漫长的会话里，你不该指望任何模型记住每一条操作规则。

好的 hook 想法：

• 文件编辑后跑格式化
• 编辑后跑 lint
• 拦下对生成文件的改动
• 除非明确允许，否则拦下对迁移文件的改动
• 把庞大的测试日志过滤到只剩失败项
• 防止对生产配置的意外写入
• 当 diff 里出现密钥时发出警告

文档还指出，hooks 可以通过预处理嘈杂的输出来减少 token 用量。例如，与其让 Claude 读一份 10,000 行的日志，一个 hook 可以只返回匹配到的错误行。

这正是那种让 Fable 更有效的环境搭建：给它正确的信号，而不是所有的噪声。

8. 做安全工作时，要明确、要防御

这是很多回退发生的地方。

Anthropic 说 Fable 的防护措施针对的是进攻性网络安全技术，比如构建漏洞利用、恶意软件或攻击工具。同一份文档也说，无害的网络安全工作可能触发防护措施。

所以别把正当的工作说得像在开发漏洞利用。

糟糕的提示：

Find vulnerabilities in this auth system and show me how to exploit them.

更好的提示：

I am reviewing my own authorized codebase. Please perform a defensive code review focused on correctness, authentication boundaries, authorization checks, input validation, secrets handling, and test coverage.

Do not provide exploit chains, offensive tooling, payloads, or attack instructions. For each issue, provide:
1. The affected file and line
2. Why it is risky
3. A safe remediation
4. A safe regression test

即便这样，它有时可能仍会路由到 Opus 4.8。那有时候是意料之中的。Anthropic 有意采用一种留安全余量的做法，会拦下含糊的网络请求，即使其中许多很可能是无害的。

目标不是骗过分类器，目标是清楚地陈述正当的防御范围，并避免索要危险的输出。

要在 Claude Code 内做更深入的安全评审，在合适的地方用内置的 /security-review 命令。Claude Code 把它记载为交付前一次更深的只读检查。

9. 别索要隐藏的推理过程

另一个可以避免的回退触发点：让 Fable 揭示内部推理。

Anthropic 的 Fable 文档说，该模型对摘要式思考的提取有防护措施，迁移指南也记载了一个 reasoning_extraction 拒绝类别。

所以别问：

Show your full hidden chain of thought step by step.

要问：

Give me the conclusion, key evidence, tradeoffs, risks, and recommended next action.

对编码来说，这通常反正更好。你不需要模型私有推理的一份逐字记录，你需要的是一个你能审视的工程决策。

10. 在另一个模型写完代码之后，用 Fable 做代码评审

最好的模式之一是：

让一个更便宜的模型写 diff。
让 Fable 来评审它。

Anthropic 的 Fable 页面里有客户反馈说，Fable 评审了一份由 Opus 起草的 PR，并一次性做出了显著改进。同一页面里还有反馈说，Fable 在 UI 设计、游戏编码、意图理解，以及抓住复杂的设计漏洞上都很强。

一条实用的提示：

/model claude-fable-5
/effort xhigh

Review the current diff as a senior engineer.

Focus on:
- Correctness bugs
- Hidden coupling
- Backwards compatibility
- Missing tests
- Edge cases
- Simpler implementation paths
- Risky assumptions
- Files that should not have changed

Do not rewrite the whole PR. Return only:
1. Must-fix issues
2. Should-fix issues
3. Tests to add or run
4. Ship/no-ship recommendation

这是个完美的 Fable 任务，因为模型不只是在生成代码，它是在判断这份活是否安全。

11. 用子 agent，但别让它们全都是 Fable

Fable 擅长委派。Anthropic 说它在调度和维持并行子 agent 上更可靠，它的提示指南也建议对独立的子任务频繁使用子 agent。

但这不意味着每个子 agent 都该用 Fable。

Claude Code 的成本文档建议给队友用更便宜的模型、把团队保持小、把 spawn 提示保持聚焦，并在队友干完时把它们关掉。

一个更好的模式：

Fable = 编排者
Sonnet 或 Opus = 实现 agent
Haiku 或更便宜的模型 = 简单的扫描 / 提取 agent
Fable = 最终综合与决策

示例子 agent 搭法：

• 研究 agent：梳理文件和依赖
• 测试 agent：找到并运行相关测试
• 实现 agent：做机械性的编辑
• 评审 agent：检查 diff 质量
• Fable 编排者：决定计划和最终建议

Claude Code 让你用 /agents 创建自定义子 agent，选择它们的工具，选择它们的模型，并在合适时把它们限制为只读工具。

这就是你如何在不把 Fable token 烧在每个重复步骤上的前提下，拿到更多 Fable 质量的输出。

12. 用 worktrees 做并行实验

如果你想测试多种方案，就把它们隔离开。

Claude Code 通过 claude --worktree 支持 git worktrees，创建独立的工作目录和分支，让一个会话里的编辑不会碰到另一个会话里的文件。

这和 Fable 配合得很好：

让 Fable 提出两三种可行的实现策略。
用更便宜的实现 agent 在各自独立的 worktree 里跑每种策略。
把各个 diff 带回给 Fable 做对比。
问 Fable 哪一个上线最安全。

提示：

Compare these three worktree diffs.

Evaluate:
- Smallest safe change
- Test coverage
- Maintainability
- Regression risk
- Compatibility with current architecture
- Rollback simplicity

Pick one. Explain why. Do not merge anything.

再一次，Fable 做的正是它最擅长的：综合、判断和风险分析。

13. 让 Fable 对着工具结果验证，而不是凭感觉

Fable 很强，但你仍然该让它证明自己的工作。

Anthropic 建议指示 Fable 把进度声明落地到实际的工具结果上，并说这在他们的测试中几乎消除了编造的状态报告。

用这样的提示：

Before reporting success, audit each claim against actual tool output from this session.

Only say something is complete if:
- The code was changed
- The relevant tests were run
- You can cite the command output
- Any skipped verification is explicitly marked as skipped

对实现任务：

After making changes:
1. Show the files changed.
2. Run targeted tests first.
3. Run typecheck.
4. If tests fail, stop and report the failure honestly.
5. Do not claim success unless verification passed.

这对那些漫长会话尤其有用，否则模型可能给出一份过于自信的总结。

14. 让上下文保持小而有意

Fable 有一个很大的上下文窗口，但大上下文不是免费的。

Claude Code 的成本文档说 token 成本随上下文大小而增长，并建议在不相关的任务之间清理、用带自定义压缩指令的 /compact、选对模型、禁用不用的 MCP 服务、安装代码智能插件，并用 hooks 或 skills 来减少不必要的文件读取。

实操规则：

• 切换任务时用 /clear。
• 用 /context 看看是什么在占空间。
• 用 /compact Focus on test output, decisions, changed files, and unresolved risks.
• 别留着不相关的调试历史。
• 在一份过滤后的错误摘要就够用时，别粘贴巨大的日志。
• 比起含糊的描述，更该用 @file 引用。
• 在合适的地方用 gh、aws、gcloud 或 sentry-cli 这类 CLI 工具，因为 Claude Code 说 CLI 工具往往比 API 或 MCP 替代方案更省上下文。

当上下文丰富而不是臃肿时，Fable 发挥得最好。

15. 系统性地诊断回退

当 Fable 切到 Opus 4.8 时，别只是把同一条提示再试一遍。

问问你大概撞上了哪个类别。

• 这个任务是不是关于漏洞、漏洞利用、认证、恶意软件、payload，或攻击路径？
• 它是不是在要复现步骤而不是修复方案？
• 它是不是在要隐藏的推理？
• 你的 CLAUDE.md 或某个 hook 是不是注入了可疑的措辞？
• 某个子 agent 提示是不是措辞太宽泛了？
• 这个任务是不是其实更适合 /security-review 或 Opus 4.8？

Claude API 迁移指南说，Fable 的拒绝会以一个成功的 HTTP 200 响应返回 stop_reason: "refusal"，其 stop_details.category 取值有 cyber、bio 或 reasoning_extraction 之类。它还描述了 API 的回退处理，把被拒的请求在另一个模型上重跑。

具体到 Claude Code，CLI 文档提到 claude --safe-mode，用来检查某项自定义配置是不是触发 Fable 5 自动回退的原因。

这是个实用的调试技巧：如果 Fable 在安全模式下表现不同，那你本地的配置可能是问题的一部分。

16. 用这张任务地图

这里是最简单实用的路由地图。

很棒的 Fable 任务：

• 架构评审
• 迁移规划
• 复杂 bug 诊断
• 多文件重构
• 最终 PR 评审
• 含糊的产品需求
• 测试策略
• 代码仓级别的依赖分析
• 从截图做 UI 评审
• 长时间运行的 agent 编排
• 对比多种实现方案
• “这个系统为什么脆弱？”这类分析

不错但要留意成本：

• 写测试
• 生成实现计划
• 从代码产出文档
• 性能剖析计划
• API 设计
• 数据模型评审
• CI 失败分析
• 发布规划
• 大型代码库上手

通常不值得用 Fable：

• 细小修复
• 样板代码
• 简单的文件编辑
• 格式化
• 单函数重写
• 依赖升级
• 基础的文档清理
• 例行的 shell 命令
• 简单的查找替换工作

很可能回退或需要小心的防御性措辞：

• 安全漏洞评审
• 认证与授权评审
• 接近漏洞利用的调试
• 类恶意软件行为分析
• 涉及 payload 或绕过的请求
• 索要隐藏推理的请求
• 生物或化学工作流

别用 Fable 来做：

• 进攻性漏洞利用开发
• 恶意软件
• 凭据窃取
• 绕过指令
• 攻击工具
• 越狱尝试
• 任何目标是规避防护措施的事

17. 一套实用的 Fable 编码提示库

把这些当作起点用。

架构提示

Use Fable as a senior staff engineer.

Goal:
Evaluate the architecture for [change].

Please:
1. Map the relevant modules.
2. Identify hidden coupling.
3. Identify the smallest safe implementation path.
4. List risks and tradeoffs.
5. Define verification steps.
6. Recommend whether this should be one PR or multiple PRs.

Do not edit files yet.

实现交接提示

Turn this plan into an implementation brief for a cheaper coding model.

Include:
- Files to edit
- Exact behavioral changes
- Tests to add
- Commands to run
- Things not to change
- Acceptance criteria

最终评审提示

Review the current diff as a senior engineer.

Return:
1. Must-fix issues
2. Should-fix issues
3. Missing tests
4. Regression risks
5. Ship/no-ship recommendation

Ground every claim in the actual diff or test output.

防御性安全提示

I am reviewing my own authorized codebase.

Perform a defensive review focused on:
- Authentication boundaries
- Authorization checks
- Input validation
- Secrets handling
- Unsafe data exposure
- Test coverage

Do not provide exploit chains, payloads, offensive tooling, or attack instructions.

For each finding, provide:
- File and line
- Risk
- Safe remediation
- Safe regression test

回退诊断提示

Analyze why this request may have triggered fallback.

Do not try to bypass safeguards. Instead:
1. Identify ambiguous or risky wording.
2. Rewrite the task with a clearly defensive, authorized scope.
3. Remove requests for exploit reproduction or hidden reasoning.
4. Suggest whether this belongs in Fable, Opus, /security-review, or a human review.