Claude Fable 5 使用指南：从入门到榨干

⏰ 时效声明：本课内容整理自原文发布时（2026-07-03）的公开信息，模型价格、促销与平台活动变化快，请以官方最新页面为准。

你第一次打开 Fable 5，最容易犯的错，是把它当成一个更强版 Opus。这样用很快会难受：小任务上它贵得没必要；硬任务上你又不知道它到底有没有做完。

以下来自 @noahduck283（诺鸭船长）的原话定位：Fable 5 更适合把一件麻烦事从头跟到尾——它会先看目标、读上下文、拆步骤、动手验证，发现不对还会往回查。Anthropic 给它的定位是 demanding reasoning（高要求推理）与 long-horizon agentic work（长程智能体工作）。

这篇不写模型排行榜，写的是：什么时候该上 Fable、什么时候别浪费钱，怎么跑真实任务、怎么记录成本与返工量，最后把它放进"少数硬任务升级到 Fable、多数日常任务继续用便宜模型"的工作流里。

以下来自 @noahduck283 的划分。普通模型像一个回答问题的人：你问它答。Fable 5 更像一个能接工单的高级助手。它值钱的任务有两类：

第一类：脑子要拧很多圈的任务。比如一个 bug 表面是前端样式，实际是依赖、布局、浏览器兼容、数据状态混在一起。普通模型容易先猜一个答案，Fable 5 更应该做的是复现、看日志、改一小步、跑测试，再判断自己是不是猜错了。

第二类：过程很长的任务。跨几十个文件的重构、长上下文 PR review、从截图定位工程问题、把失败测试一路修到通过——这些不是回答一次就结束，而是要持续行动。

判断方法很简单：如果这个任务十分钟人工就能解决，先别急着上 Fable；如果它需要读很多上下文、守住多个约束、跑测试、自己发现错误，最后给你一个可验收结果，Fable 才开始有价值。

以下来自 @noahduck283，Fable 5 大概有四类入口：

第一类：Claude 官方产品（Claude.ai、Desktop、Mobile、Code、Cowork）。Claude Help Center 写明，2026-07-01 至 07-07 有促销访问期，订阅用户最多可把 50% 的每周订阅额度用在 Fable 5 上；促销结束后不再包含在周限额里，继续用要走 usage credits（额外用量点数）。适合快速试水，不适合严肃横评。

第二类：Claude API。官方 model ID 是 claude-fable-5，默认 1M token 上下文窗口，最高 128k 单次输出。好处是可控，麻烦是账单、限额、fallback、日志、重试都要自己处理——agent 场景下没有预算上限和权限边界，Fable 会很认真地把任务做大。

第三类：Claude Code / Cursor 这类 coding agent。Fable 在这里最容易展示价值：读仓库、改文件、跑命令、看测试输出。Simon Willison 的真实案例：给 Fable 一张 textarea 横向滚动条 bug 的截图加一句提示，Fable 启动本地服务、打开浏览器、写临时 HTML、抓截图、搭本地 CORS server 把测量数据写回文件，再继续验证。

第四类：ZenMux 这类多模型聚合平台。支持多家模型协议，提供 PAYG、订阅、调用日志、成本观测，还有 PK 模式（并排对比多个模型输出）。试用入口：https://zenmux.ai/anthropic/claude-fable-5 。作者建议把它当"测评和调度台"，而不是唯一选择。

以下来自 @noahduck283，Fable 最值得上的任务有三个特征：

硬——验收标准明确，模型不能靠漂亮话过关：测试要通过、类型错误要消失、迁移后公共 API 不能变、PR review 要给出文件级证据。

长——上下文多、步骤多、约束多：几十个文件的重构、跨模块依赖升级、长 issue thread 归因、多轮调试。

脏——任务现场不干净：文档过期、测试偶发失败、依赖版本乱、截图只露一半、报错堆栈很长。Fable 的优势得在这种现场里看。

可以从五类任务开始测：多文件重构、带陷阱的 bug 修复、长上下文 PR review、多模态工程任务、自我验证任务。不适合的也很清楚：普通问答、短代码片段、低价值批量文案、一次性摘要、没有验收标准的 brainstorming——它能做，但性价比差。

以下来自 @noahduck283。很多人测新模型还在用旧 prompt："你是资深工程师，请帮我解决这个问题。"Fable 5 应该吃更像工单的输入，一个好任务包至少包含六件事：目标、上下文、硬约束、可操作权限、验收标准、汇报格式。

目标要具体（"把旧 user settings 读取逻辑迁移到新 config service，保留现有 API 行为"，而不是"优化这个项目"）；硬约束提前写（不改公共 API、不引入新依赖、每次修改后跑测试）；权限要分级（允许读/改/跑测试/启动本地服务，但别一上来就给外部网络和生产密钥）；验收标准最重要（测试命令通过、用户可见问题消失）；汇报格式固定（改了哪些文件、为什么改、验证了什么、哪些没验证）。

原文给出的任务包模板（可直接套用）：

复制你要处理一个真实工程任务，不要只给建议。

目标：


上下文：


硬约束：
1. 不要改公共 API，除非先说明原因。
2. 不要引入新依赖，除非先解释收益和风险。
3. 每次修改后运行相关测试。
4. 如果证据不足，先说明你还需要检查什么。

允许操作：


验收标准：
1. 通过。
2. 消失。
3. 输出变更摘要、验证记录、未覆盖风险。

最后输出：
- Root cause
- Files changed
- Verification
- Remaining risks

输入越像真实工单，Fable 越有机会把长程执行能力跑出来。

以下来自 @noahduck283。横评 Fable 最偷懒的办法是把同一段提示词丢给几个模型、截图比谁更像高级工程师——这不够。要放到完整任务里测：计划是否靠谱、是否读对上下文、是否主动验证、失败后有没有恢复、最后需不需要人工返工。

一组合格的 PK 至少记录这些字段：模型名称、任务类型、是否 fallback、首字出现速度、总耗时、输入输出消耗、实际费用、是否运行测试、人工返工量。

可以先跑三组对照：Fable 5 vs Opus 4.8（看贵出来的部分值不值）、Fable 5 vs GPT/Gemini（跨模型能力差异）、Fable 5 vs 便宜模型组合（路由策略：先用 Sonnet 定位，只有复杂迁移和验证才交 Fable）。

有说服力的结论长这样："我跑了 10 个任务。Fable 明显赢了 3 个，主要是长程重构和自我验证；4 个任务 Opus 就够；2 个任务 Fable 做得很认真但太贵；1 个因为 fallback 没有干净结论。"——这比"Fable 全面碾压"更可信。

以下来自 @noahduck283。官方 API 价格是每百万输入 token 10 美元、输出 50 美元。更麻烦的是长程任务的 token 消耗：读文件、看日志、写计划、改代码、跑测试、读失败日志、再改一轮——你以为买的是一次回答，实际跑的是一段工程流程，账单按流程算。

成本警示案例：Simon Willison 的 CSS bug——一个最后可能两行 CSS 解决的问题，Fable 为了复现验证搭了真实浏览器和本地数据回传链路，按 API 全价约 12 美元级别。贵不贵看买到什么：省下两小时调试就是便宜；把五分钟问题做成半小时调查就不划算。

成本控制按任务做：给预算闸门（先跑 10 分钟或 token 上限，超了暂停汇报）；分层路由（日常走便宜模型，硬任务再上 Fable）；记录人工返工量（花 5 美元还要你修 2 小时≠便宜）；拆任务（定位/方案/修改/验证四段，每段有停止点）；清上下文（别拿 token 当垃圾桶）。

以下来自 @noahduck283，Fable 的边界不只来自能力：

先看回退（fallback）。Fable 5 带 classifier（安全分类器，模型回答前的一道自动门禁）。官方文档说明：请求被拒绝时 Messages API 可能返回 stop_reason: "refusal"；部分命中安全边界的请求也可能 fallback 到其他 Claude 模型。安全、漏洞、供应链、网络、自动化、逆向这类任务容易靠近边界——测评时要把"是否 fallback"单独记下来，不要把 Opus 接手后的结果算进 Fable 成绩。

再看数据保留。Claude Help Center 明确：Mythos-class 模型的输入输出会保留 30 天用于安全工作（官方说明不用于训练新模型）。企业团队先用开源项目、脱敏样本、合成故障做评估，别一上来就塞核心私有仓库和生产密钥。

然后是 sandbox。Fable 主动性很强，可能跑命令、启动服务、写临时文件、打开浏览器。运行 coding agent 时用测试仓库、sandbox、低权限目录、测试账号、无生产密钥环境。

稳妥流程：先用公开或低敏任务测能力，再记录成本和延迟确认路由策略，最后逐步进入团队内部场景。