Claude Fable 5 将于明天在全球推出

究竟发生了什么

Claude Fable 5 将于明天在全球推出，成为 Anthropic 当前模型阵容的一部分：

全球可用在实际运营中很重要。如果你正在跨区域基于 Claude API 构建产品，分阶段开放往往会迫使你采用别扭的回退逻辑：一个地区使用一种模型，其他地区使用另一种模型，而它们的上下文限制和提示词响应方式又各不相同。全球可用意味着平台团队可以开始为长上下文工作负载设计统一的模型调用路径，而不再将其视为特定区域的例外情况。

技术上的变化在于 1M 的上下文窗口。上下文不是人类意义上的记忆，也不是数据库。它是模型在一次请求中能够关注的材料。更大的上下文并不能消除对索引、检索、缓存、摘要或精心设计提示词的需求。但当压缩本身是缺陷的来源时，它确实能让工程师推迟进行有损压缩。

在实践中，长上下文最有价值的地方并不是可以粘贴一百万个 token，而是可以不必过早决定模型“获准”看到哪些内容。

为什么 Claude Fable 5 对 Claude API 工程师很重要

如今，常见的生产环境模式如下：

1. 用户提出一个关于大型代码库或文档集的问题。
2. 系统将查询转换为嵌入向量。
3. 系统检索排名前 k 的片段。
4. 系统要求 Claude 根据这些片段回答。
5. 答案出错，因为关键约束位于片段 17，而不是片段 5。

这种架构仍然有其适用场景。相比在每次请求中塞入庞大的上下文，检索更便宜、更快，而且往往更简洁。但对于完整性比最小化上下文更重要的任务，Fable 5 的 1M 上下文提供了另一条路径。

例如，设想一个内部迁移助手。用户问道：

“如果我们移除对旧版发票状态的支持，哪些服务会出问题 PENDING_REVIEW?”

范围较窄的 RAG 流水线可能会检索到枚举定义和少量直接引用。长上下文工作流则可以包含：

• 枚举定义。
• 所有调用点。
• 数据库迁移历史。
• API 契约文件。
• 生成的客户端代码。
• 测试夹具。
• 近期故障记录。
• 拟议的补丁。

这种差异很重要，因为工程问题很少只涉及局部。缺陷往往出在生成的客户端、旧测试夹具和一条两年无人修改的重试路径之间的相互作用中。

下面是用于代码仓库分析任务的简单 Claude API 请求结构。具体的 SDK 接口可能因版本而异，但重要的是这一模式：将长期有效的指令放在系统提示词中，发送结构化的文件集合，并要求给出基于证据的答案。

{
  "model": "claude-fable-5",
  "max_tokens": 4096,
  "system": "You are reviewing a production codebase migration. Use only the provided repository snapshot. Cite file paths for every claim. If evidence is missing, say what is missing.",
  "messages": [
    {
      "role": "user",
      "content": [
        {
          "type": "text",
          "text": "We plan to remove support for invoice status PENDING_REVIEW. Identify breaking changes, risky assumptions, and tests to update."
        },
        {
          "type": "text",
          "text": "<repo_snapshot>\n...large structured repository content...\n</repo_snapshot>"
        }
      ]
    }
  ]
}

一个实用细节：不要发送一团形似 tar 归档的数据，就指望模型自行推断其结构。要让输入内容便于浏览和定位。

对于代码，我更喜欢这样的格式：

<file path="services/billing/src/invoice_status.py">
...
</file>

<file path="services/billing/tests/test_invoice_lifecycle.py">
...
</file>

<file path="docs/billing-state-machine.md">
...
</file>

这少量的结构化处理很值得。如果你做好标注，Claude 就能引用精确路径、分析边界，并区分生成文件和手写代码。

1M 上下文带来的 Claude Code 工作流变化

当 Claude Code 能够通过工具探索代码仓库时，它已经表现良好。对于问题涉及多个文件，或希望模型保持更大的工作集、无需反复重新获取上下文的会话，Fable 5 会改变其处理方式。

例如，在进行大型迁移时，我可能会这样启动 Claude Code：

claude

然后在以下位置设置明确的工作指令 CLAUDE.md:

# Project Instructions

- Prefer small, reviewable patches.
- Do not modify generated files directly.
- Run `pnpm test --filter billing` before finalizing billing changes.
- For API changes, update OpenAPI specs and generated clients.
- When uncertain, inspect call sites before editing shared types.

对于长上下文任务，我还喜欢添加一个任务专用的临时记录文件，而不是仅依赖聊天历史：

# Migration Notes: Remove PENDING_REVIEW

## Known entry points
- services/billing/src/invoice_status.py
- services/api/openapi/billing.yaml
- workers/invoice_reconciliation/*

## Questions to resolve
- Does any external webhook still emit PENDING_REVIEW?
- Are old records migrated or tolerated at read time?
- Which tests encode this status as a fixture?

然后在 Claude Code 中：

claude "Analyze the billing status migration notes and inspect the repository for all remaining dependencies on PENDING_REVIEW. Do not edit yet. Return a risk map with file paths."

使用上下文较小的模型时，助手可能需要反复搜索、总结并遗忘细节。而使用 Fable 5 时，会话可以同时保留更多调查内容。当任务需要比较仓库中相距较远的部分时，改进最为明显：API 架构定义、前端渲染、工作进程行为、数据库值和测试。

一个常见陷阱是：长上下文可能让用户在编写指令时变得更随意。这会适得其反。更多上下文为模型提供了更多证据，但也带来了更多干扰。我仍然会严格限定任务范围：

claude "Implement only the server-side compatibility layer for legacy invoice statuses. Do not change frontend code. Preserve existing API response shape. Add tests for reading old records."

长上下文不能取代有明确范围的工作。它能让这类工作建立在更充分的信息之上。

Fable 5 的 API 设计模式

最大的设计问题是：何时使用 Fable 5，何时使用 Sonnet 4.6 或 Haiku 4.5。

我不会将每个请求都路由到具有 1M 上下文的模型。权衡很简单：更大的上下文让模型有更多空间基于完整证据进行推理，但根据请求大小和定价，也可能增加延迟和成本。即使模型支持大型输入，如果应用程序盲目地序列化无关材料，你仍然要承担额外的工程开销。

一种不错的路由模式是：

def choose_claude_model(task):
    if task.kind in {"classification", "routing", "field_extraction"}:
        return "claude-haiku-4-5"

    if task.context_tokens > 180_000:
        return "claude-fable-5"

    if task.requires_deep_reasoning and task.blast_radius == "high":
        return "claude-opus-4-8"

    return "claude-sonnet-4-6"

这个阈值不是普遍适用的建议。它只是说明我通常如何考虑模型路由：当输入规模是任务本身所必需的时，才使用 Fable，而不是为了省去裁剪输入的麻烦。

对于生产环境中的 API 集成，我还会分别记录上下文大小和结果质量：

import time
from anthropic import Anthropic

client = Anthropic()

def analyze_change(repo_bundle: str, question: str):
    started = time.time()

    response = client.messages.create(
        model="claude-fable-5",
        max_tokens=5000,
        system=(
            "You are a senior code reviewer. Use the provided files only. "
            "Return risks, evidence, and recommended tests. Cite paths."
        ),
        messages=[
            {
                "role": "user",
                "content": f"""
Question:
{question}

Repository bundle:
{repo_bundle}
"""
            }
        ],
    )

    elapsed_ms = int((time.time() - started) * 1000)

    return {
        "model": "claude-fable-5",
        "elapsed_ms": elapsed_ms,
        "answer": response.content[0].text,
    }

对于实际系统，还应加入：

• 以 token 数记录请求大小，而不只是记录字节数。
• 按任务类别设置超时和重试行为。
• 为非关键工作流提供备用模型调用路径。
• 提示词版本管理。
• 带有已知预期发现结果的评估夹具。
• 在打包长上下文内容之前进行脱敏。

脱敏这一点很容易被低估。更大的上下文窗口更容易导致意外纳入密钥、客户数据或无关的内部记录。如果你的代码仓库文件集合包含 .env、生产环境配置、私钥或原始用户导出数据，那就是应用程序的缺陷，而不是模型的功能。

长上下文在哪些场景优于检索

检索增强生成仍然很有用。我一直在使用它。但长上下文改变了两者之间的权衡。

关键区别在于失败模式。检索因遗漏而失败。长上下文更常因信息被稀释而失败：生成答案时可能已经拥有全部证据，但仍然需要明确有力的指令，才能优先关注正确的部分。

对于工程任务，遗漏往往更糟。如果我问“这次迁移会破坏生产环境吗？”，相比回答稍慢一些，我更在意是否漏掉了依赖项。

不过，对于严肃的系统，我仍然更倾向于混合设计：

1. 使用检索识别可能相关的部分。
2. 加入依赖扩展：导入项、调用方、配置和测试。
3. 将扩展后的内容集合提供给 Fable 5。
4. 要求 Claude 识别缺失的内容。
5. 进行第二轮分析，仅聚焦风险最高的文件。

这样既能获得检索的效率，又能在关键之处获得长上下文推理的完整性。

它在 Claude 产品阵容和路线图中的定位

当前的产品阵容正逐渐不再像“小、中、大”的划分，而更像一组专门化的执行方式。

在许多生产工程工作流中，Sonnet 4.6 仍然是我会优先选择的默认模型。它足以胜任大多数编码、审查和使用工具的智能体循环，也通常适合同时重视延迟、成本和质量的系统。

我会将 Opus 4.8 留给最困难的推理环节：架构权衡分析、原因不明的缺陷、复杂重构，以及错误答案代价高昂的规划任务。

Haiku 4.5 适用于大规模处理。如果任务在结构上很简单，就不要为不需要的深度付费。

Fable 5 为产品阵容带来了一个不同的维度：不仅是更强的推理能力，还有更广的工作记忆。这很重要，因为许多 AI 应用失败并不是模型无法推理所致，而是因为模型看到的是不完整、失真的问题表述。

无需夸大，其对路线图的影响已经相当明确：Claude 正在迈向能够让模型直接处理更大型现实工作材料的工作流。代码仓库、长文档、客户历史记录、追踪记录、规范和设计档案正在成为一等输入，而不再是必须在推理前大幅压缩的内容。

这一限制同样重要。1M 的上下文窗口并不意味着每个 token 都同样重要，也不能保证完美记住每一个细节。工程师仍应合理设计提示词和输入，确保重要材料易于查找、带有清晰标注，并与任务相关。

实用输入打包方法

对于 Fable 5，输入打包已成为提示词工程的一部分。

不理想的输入：

Here is a giant dump of files:
[file contents pasted in arbitrary order]
What breaks?

更好的输入：

Task:
Determine whether removing PENDING_REVIEW breaks billing behavior.

Repository map:
- services/billing: core invoice lifecycle
- services/api: public REST schema
- workers/reconciliation: async status updates
- web/admin: admin UI

Constraints:
- Do not recommend frontend changes unless API behavior changes.
- Treat database values older than 2024-01-01 as still possible.
- Cite file paths.

Files:
<file path="services/billing/src/status.py">...</file>
<file path="services/api/openapi/billing.yaml">...</file>
<file path="workers/reconciliation/status_mapper.ts">...</file>

对于 API 应用，我通常通过自动化方式构建输入包：

rg -l "PENDING_REVIEW|InvoiceStatus|invoice status" \
  services workers web docs \
  | sort \
  > /tmp/fable-files.txt

然后可以用一个小脚本封装这些文件：

from pathlib import Path

paths = Path("/tmp/fable-files.txt").read_text().splitlines()

for path in paths:
    p = Path(path)
    if p.suffix in {".png", ".jpg", ".lock"}:
        continue

    text = p.read_text(errors="replace")
    print(f'<file path="{path}">')
    print(text)
    print("</file>")

在生产环境中，我会改用完善的打包工具，排除机密信息、生成产物、依赖目录、大型二进制文件以及无关快照。

使用过多上下文时，实际会发生什么

团队首次获得更大的上下文窗口时，往往会用得过头。他们会把所有内容都放进去：整个代码仓库、完整的 Slack 导出记录、日志、文档、工单、指标和会议记录。

模型能处理的内容比以前多得多，但你的应用仍然需要合理取舍。纳入过多内容会带来几个问题：

• 延迟增加。
• 成本增加。
• 敏感数据暴露的风险增加。
• 提示词变得更难调试。
• 模型可能将注意力花在无关的上下文上。
• 由于每个请求包含过多变量，评估结果中的噪声会增加。

解决办法不是重新退回到极小的分块，而是为任务打包完整的依据。对于代码迁移，这可能意味着纳入整个子系统，而不是公司的整个单体仓库。对于故障事件，这可能意味着纳入完整的时间线，而不是一周内的每一行日志。

我的经验法则是：提供足够的上下文，让 Claude 能够质疑你的前提。如果模型无法发现你所选的文件不足以完成任务，那么输入包的范围就太窄了。如果模型必须从一堆无关材料中推断任务是什么，那么输入包的范围就太宽了。

实践要点

Claude Fable 5 在全球推出，对因上下文碎片化而导致 Claude 工作流受阻的团队最有意义。如果你的应用使用简洁的提示词和检索就已经运行良好，不要仅仅因为出现了更大的窗口就重写它。

当推理所涉及的单元本身就很大时，可以使用 Fable 5：例如一个子系统、一份长篇合同、一条完整的故障事件时间线，或跨多份文档的设计历史。

继续将 Sonnet 4.6 作为一般生产任务的默认选择，将 Haiku 4.5 用于快速的结构化任务，将 Opus 4.8 用于最困难的推理场景。

对于 Claude Code，添加清晰的 CLAUDE.md 指令，将任务笔记保存在代码仓库中，并在进行大规模更改时要求先检查再编辑。Fable 5 能容纳更多调查内容，但明确的边界仍然有助于它发挥作用。

对于 API 使用，应投入精力做好输入打包：文件标签、代码仓库结构图、明确的约束、机密信息过滤、token 日志记录以及评估用的固定测试数据。1M 的上下文窗口很强大，但只有严谨的工程实践才能充分发挥其价值。

真正的变化不是“往提示词里粘贴更多东西”，而是 Claude 现在能在你迫使它总结、检索或猜测之前，基于实际系统的更多内容进行推理。这让工程师更有机会向模型提出自己真正想问的问题。