最近复核 Claude Fable 5 / Mythos 5 发布信息时，我重新整理了一套比较适合技术内容的记录方法。

这篇不讨论“哪个模型最强”，也不做模型宣传，而是记录一个更可复查的流程：面对一次 AI 模型发布，如何把官方资料、评测口径、本地实测和结论边界记录下来。

模型发布类信息很容易被简化成一句话：

某某模型发布，某某榜单第一。

但如果要做技术判断，这样的信息密度是不够的。至少要继续追问：

• 发布的到底是哪个版本？
• 是否公开可用？
• 官方参数和 API ID 是什么？
• 评测来自官方还是第三方？
• 本地实测是否能复现部分能力？
• 哪些结论不能从当前证据里推出？

下面以 Claude Fable 5 为例，记录一次复核流程。

1. 先记录版本和开放范围

模型发布信息里，最先要固定的是版本名称和开放范围。

这次容易混淆的点是：不要简单写成“Claude 5 全面发布”。

更准确的记录方式是：

{
  "release_name": "Claude Fable 5 / Claude Mythos 5",
  "public_model": "Claude Fable 5",
  "public_model_api_id": "claude-fable-5",
  "restricted_preview_model": "Claude Mythos 5",
  "restricted_preview_api_id": "claude-mythos-5",
  "note": "Fable 5 is widely available; Mythos 5 is invitation-only / restricted preview."
}

这样记录的好处是，后面写文章、做视频或做对比时，不容易把公开版本和邀请制版本混成一个结论。

2. 参数信息单独成表，不直接推结论

参数信息适合单独记录，但不要直接从参数推出“实际效果一定更好”。

本轮记录到的关键字段包括：

{
  "context_window_tokens": 1000000,
  "max_output_tokens": 128000,
  "input_price_per_mtok_usd": 10,
  "output_price_per_mtok_usd": 50
}

这些字段说明模型具备处理长上下文和长输出的条件，但并不能直接证明每个任务都可靠。

更稳妥的写法是：

长上下文和长输出给了模型处理复杂任务的空间，但最后结果仍然需要结合任务场景和实测表现来判断。

3. 评测数据要记录来源和口径

评测表最容易被误读。

比如官方评测里可以记录：

{
  "benchmark_source": "vendor_official",
  "items": [
    {
      "benchmark": "SWE-Bench Pro",
      "fable_5": "80.3%",
      "gpt_5_5": "58.6%"
    },
    {
      "benchmark": "FrontierCode Diamond",
      "fable_5": "29.3%",
      "gpt_5_5": "5.7%"
    },
    {
      "benchmark": "Terminal-Bench 2",
      "fable_5": "88.0%",
      "gpt_5_5_codex_cli": "83.4%"
    }
  ],
  "caution": "Do not merge vendor table and independent leaderboards as the same measurement."
}

如果还参考了独立榜单，也应该分开记录：

{
  "benchmark_source": "independent_leaderboard",
  "benchmark": "terminal-bench@2.1",
  "items": [
    {
      "system": "Codex CLI + GPT-5.5",
      "score": "83.4% ± 2.2"
    },
    {
      "system": "Claude Code + Claude Opus 4.8",
      "score": "78.9% ± 2.5"
    },
    {
      "system": "Gemini CLI + Gemini 3.1 Pro",
      "score": "70.7% ± 2.9"
    }
  ],
  "caution": "This leaderboard did not directly list Fable 5 in the checked snapshot."
}

重点不是把数字堆上去，而是保留来源和口径。

4. 本地实测要同时记录成功和失败

只记录成功截图，很容易把模型能力写过头。

本次实测里，我会把异常和有效表现都记录下来：

{
  "local_test_observations": [
    {
      "type": "availability",
      "result": "Model isn't available",
      "interpretation": "Observed once during local test; do not generalize as frequent failure."
    },
    {
      "type": "language_output",
      "result": "A Chinese task returned Japanese content once.",
      "interpretation": "Observed once; later constrained prompt returned Chinese output."
    },
    {
      "type": "benchmark_analysis",
      "result": "The model summarized benchmark differences and warned against overreading them.",
      "interpretation": "Useful for transforming technical tables into audience-facing explanations."
    },
    {
      "type": "workflow_planning",
      "result": "The model split a video topic into structure, facts to verify, risks, and deliverables.",
      "interpretation": "Useful as a planning assistant, but output still needs human review."
    }
  ]
}

这类记录能避免两个极端：

• 只看失败，就说模型不行；
• 只看成功，就说模型万能。

更合理的结论是：本次测试中既观察到上线初期波动，也观察到它在评测表分析和工作流拆解上的实用价值。

5. 结论要写边界

复核模型发布时，最后最好单独写一个 claim_boundary 字段。

例如：

{
  "safe_claims": [
    "Fable 5 is worth watching for long-context and long-horizon tasks.",
    "It appears strong in vendor-reported coding and terminal benchmarks.",
    "In local tests, it was useful for benchmark interpretation and workflow planning."
  ],
  "unsafe_claims": [
    "Claude 5 is fully released to everyone.",
    "Fable 5 is the best model in every scenario.",
    "Mythos 5 is available to ordinary users.",
    "One local failure proves the model is unstable for all users."
  ]
}

这一步看起来啰嗦，但对后续写文章、做视频、发平台内容很有用。

因为很多审核风险、事实错误和误导性表达，都是从“结论边界”没写清楚开始的。

6. 可复用模板

以后复核类似模型发布，可以先建一个 Markdown 文件，包含这些小节：

# 模型发布复核记录

## 基本信息
- 发布时间：
- 模型名称：
- API ID：
- 开放范围：

## 官方参数
- 上下文窗口：
- 最大输出：
- 输入/输出价格：

## 评测信息
- 官方评测：
- 第三方评测：
- 不能横向比较的地方：

## 本地测试
- 测试任务：
- 成功表现：
- 异常表现：
- 截图路径：

## 结论边界
- 可以说：
- 不建议说：
- 需要继续观察：

如果需要结构化记录，可以把每次测试也保存成 JSON：

{
  "test_id": "fable5-benchmark-analysis-001",
  "model": "Claude Fable 5",
  "test_time": "2026-06-12T00:00:00+08:00",
  "input_material": "official benchmark table screenshot",
  "task": "Turn benchmark table into a short Chinese video explanation and mark overread risks.",
  "result_summary": "The model extracted core comparison points and added caveats.",
  "evidence_level": "local_observation",
  "screenshot": "evidence-test-benchmark-analysis.png",
  "claim_boundary": "Useful as drafting support; not a final benchmark authority."
}

最后

模型发布信息不要只保存最终结论。

更稳妥的方式是：

1. 先固定版本和开放范围；
2. 参数信息单独记录；
3. 评测表区分官方和第三方；
4. 本地测试同时记录成功和失败；
5. 最后写清楚哪些结论可以说，哪些结论不能说。

这样得到的不是一篇情绪化模型新闻，而是一份可以复查、可以迭代、也方便后续引用的技术记录。