Fable 5 让 Claude Code 更像真同事

我拆了这篇测评，整理出一套把 Fable 5 用进 coding 和 agent 工作流的可复制模板。

我用 Claude Code 这类工具已经有一阵子了。说实话，前面几代模型都挺能聊，甚至挺会认错，但总有种别扭感。你把任务交给它，它先说“好”，再说“明白”，然后开始绕圈子。代码写得像是知道答案，真到要跑、要合并、要进主干的时候，又开始露怯。最烦的是那种“看起来很努力”的假动作，像是在配合你，而不是在解决问题。

所以我看到这篇中文测评时，第一反应不是“又一篇 SOTA 通稿”，而是想看看它到底是不是把那种别扭感往前推了一步。原文来自知乎专栏《实测「神话」级模型 Fable 5：强者世界里的最强者 | AI 上新》，作者是极客公园。它讲得很直白：Anthropic 放出来的 Fable 5 不是完全裸奔的 Mythos 级模型，而是套了一层安全分类器，危险问题会回退到更保守的 Opus 4.8。这个设定本身就很有意思，因为它把“能力”和“可公开使用”硬拆开了。

我先把结论放前面：这篇文章真正值得我抄的，不是“Fable 5 很强”这种废话，而是它看模型的方式。它不是只盯着 benchmark 分数，而是盯着模型到底把什么能力放在第一位、它能不能在真实工程里被接受、以及它会不会把外部 harness 逼薄。这个视角对我们做 agent、做 coding workflow、做内部评测，都比单纯看榜单有用得多。

先看厂商把什么放第一位，别被榜单顺序骗了

“看模型发布有哪些能力更新了，其实有个很取巧的办法：看厂商把哪个指标放在第一位。”

这句我很认同。厂商不是随便排顺序的，谁都知道首页最上面的那个数字最能打人。原文里，Fable 5 开头放的是 SWE-bench Pro 和 FrontierCode，前者是 coding，后者是 agent。这个顺序本身就已经说明问题了：Anthropic 想让你记住的，不是它会不会写几段花活，而是它能不能把复杂任务真的做完。

What this actually means is：别把 benchmark 当成一个平面分数表，要把它当成产品策略说明书。SWE-bench Pro 这种题，更多是在测模型是否“听话”、是否能按题意补丁式修代码；而 FrontierCode 测的是更接近真实工程的东西，代码能不能被接受、能不能进主干、能不能通过项目自己的规范和审查。后者明显更接近我们日常碰到的脏活累活。

我自己也踩过这个坑。以前我会拿一堆“解题题”去测模型，问它写个函数、补个 bug、改个脚本，觉得挺准。后来真把它丢到一个有历史包袱的仓库里，问题就来了。它不是不会写，而是不理解上下文，不知道哪里能动、哪里不能动，不知道改完之后谁会炸。那一刻我才明白，单点能力和工程能力根本不是一回事。

怎么用这个思路？我建议你以后评估模型时，先问三个问题：

• 这个模型最想让我记住的能力是什么？
• 这个能力是“答题”还是“交付”？
• 它的分数是在实验室里好看，还是能进真实仓库？

如果你在做产品选型，这个顺序比“谁高了 2 分”重要得多。尤其是你要做 coding assistant、内部自动化、代码迁移、测试修复，这种场景里，能不能进主干比能不能把题做对更值钱。

FrontierCode 这种题，才像真工程，不像考试

文章里最打动我的，其实是 FrontierCode 这个基准。它不是让模型做一套“标准答案题”，而是从真实开源项目里抽任务，要求结果能被接受、能被合并。原文提到，任务来自 Celery、Mattermost 这些项目，而且专业开发者会花四十多个小时打磨一道题。这个信息很关键，因为它说明题目本身就带着工程世界的摩擦。

What this actually means is：模型不只要“会写”，还要“写得像能活下去”。真实项目里，正确答案往往不是唯一答案，甚至不是最优雅答案，而是那个能过 review、能符合 repo 习惯、能不把别的模块带崩的答案。这个差别太大了。你在 LeetCode 上的满分，到了真实仓库里可能连 PR 都开不出来。

原文还提到一个 Stripe 的案例：在一个 5000 万行 Ruby 代码库里，Fable 5 用一天完成了原本要一个团队干两个多月的迁移。这个说法我不会替它背书成绝对事实，但它至少表达了一个方向：模型正在从“帮你写代码”变成“帮你搬家”。这两个动作的难度不是一个量级。

我自己做过代码迁移，最痛的从来不是语法转换，而是边角料：老接口、历史注释、隐式约定、测试夹具、奇怪的命名、没人敢删的兼容分支。你让模型只写新代码，它往往还行；你让它在旧代码上动刀，它就开始犯糊涂。FrontierCode 这种基准的价值就在这儿，它逼模型面对真实工程的脏和乱。

如果你想把这个思路用到自己的团队里，我建议你把评测题改成这三类：

• 单文件修复：看它能不能补一个明确 bug。
• 跨文件改动：看它能不能理解依赖关系。
• 真实仓库 PR：看它能不能接受 review 约束。

这三层一层比一层接近真实价值。只测第一层，容易高估模型；只看榜单，不看 PR，基本等于自我安慰。

拍照直接解题，比转 LaTeX 更像真实使用

我很喜欢原文在数学题上的测法。作者故意没走那种“先把 PDF 转 LaTeX，再喂给模型”的老路，而是直接拍照截图丢进去，让模型自己读图解题。这个选择很对，因为现实里没人会为了问一道题先花半小时做格式清洗。那不是 AI 辅助，那是给 AI 打工。

原文里说，Fable 5 能直接看懂高考数学卷里的几何图、辅助线，然后一题一题解下去，最后拿到 150 满分。这里我不打算把这个结果神化，但我要承认，这种“直接看图并推理”的体验，确实比单纯文本问答更接近我们未来会用到的方式。

What this actually means is：多模态能力真正有价值的地方，不是“它能看图”，而是“它能少一步”。少一步就意味着少一个人工转换层，少一个出错点，少一个让人放弃的门槛。很多模型看起来都能处理图片，但一旦你真的把原始截图、白板照、票据、UI 截图扔进去，马上就露馅。不是它不聪明，是它没把输入世界当成真实世界。

我以前做内部知识库问答时，最烦的就是用户总要上传乱七八糟的截图。传统做法是 OCR、清洗、再总结，链条长得离谱。最后你得到一个看起来很“工程化”的流程，但用户体验烂透了。Fable 5 这类模型给我的启发是，别急着把输入格式标准化到过头，先看看模型能不能直接吃原始材料。

如果你要落地，可以这么做：

• 保留原图输入，不要默认转文字。
• 让模型先解释它看到了什么，再开始推理。
• 把“读图正确率”和“最终答案正确率”分开记。

这样你才能知道问题出在感知层，还是出在推理层。很多团队把这俩混在一起，最后根本不知道模型到底差在哪。

Agent 真正的分水岭，不是会不会调用工具，而是会不会自己收尾

原文里对 Fable 5 的 Agent 体感描述得很到位：以前的模型像聪明实习生，要你拆好任务，一步一步喂；它更像一个能自己拆任务、自己调子代理、自己验证结果、自己处理异常的人。这个比喻虽然有点夸张，但方向是对的。Agent 的核心不是“能不能调用工具”，而是“能不能把一件事从头做到尾”。

What this actually means is：真正有价值的不是某一次工具调用，而是长链路执行能力。模型要能记住目标、分解任务、在中间卡住时自救、发现失败后改策略、最后把结果收回来。这里面任何一个环节掉链子，用户就得重新接管。只要你得接管，那它就还没从“演示”进入“工作”。

文章引用了 Ethan Mollick 和 Simon Willison 的体验，这两个人都不是来凑热闹的。Mollick 让模型自主构建等时线地图，涉及多个子代理、上千条交通数据、连续十个小时；Willison 则说挑战在于找到它做不成的任务。这个方向和我自己的体感一致：模型越强，你越少需要盯着它每一步，但你越需要给它一个清楚的边界。

我自己也遇到过类似情况。以前模型一旦中间出错，我就得人工插手修正。到了更强的模型，问题变成了另一种：它未必一开始就错，但它会自己绕开一些你本来希望它处理的细节，最后交给你一个“差不多”的结果。这个时候，最重要的不是再加提示词，而是加验收标准。

如果你要把 Agent 用起来，我建议你只盯四件事：

• 它能不能自己拆任务。
• 它能不能自己检查中间结果。
• 它能不能在失败时换路。
• 它能不能在结束时给出可交付物。

这四件事，比“会不会多轮对话”重要得多。多轮对话只是聊天，收尾能力才是工作。

审美没那么强，说明它把筹码全压在 coding 和 agent 上了

原文对审美生成部分是失望的，我觉得这个判断挺诚实。作者测了金门大桥和鹈鹕 SVG，Fable 5 和 GPT-5.5 都没给出特别惊艳的结果。这个结果不算意外，但它有个很重要的信号：这代模型的优化重心，明显不是设计和创意，而是 coding 和 agent。

What this actually means is：厂商在做取舍。模型能力不是均匀增长的，它会朝最容易商业化的方向倾斜。coding 能直接卖开发者，agent 能直接卖生产力，审美和创意虽然也能卖，但离“立刻证明 ROI”总差一口气。Anthropic 这次的选择很冷静，也很现实。

这对我们做产品的人其实是个提醒。别幻想一个模型能同时把所有事都做成天花板。你要先认清它的强项，再把它塞进对的工作流。比如你做设计辅助，就别指望它替代审美判断；你做工程自动化，就别浪费时间拿它去拼视觉效果。能力分布不均，才是常态。

我自己最怕的就是团队拿一个强模型去做不该它做的事，然后得出“AI 不行”的结论。不是 AI 不行，是你把它放错了地方。像 Fable 5 这种模型，明显更适合放在代码迁移、测试修复、脚本生成、研究助理、长链路任务协调这些地方。

如果你要做内部选型，直接按场景分桶就行：

• 高价值工程任务：优先 coding 和 agent。
• 创意产出任务：单独评估审美，不要混着看。
• 多模态输入任务：先测原图理解，再测结果质量。

这样你会少很多幻觉式预期，也少很多无意义争论。

安全分类器不是纯护栏，它也是产品边界

原文里我最在意的另一段，是关于 Anthropic 的安全分类器。官方说法很正面：因为 Mythos 级别能力太强，在网络安全、生物这些高危领域可能被滥用，所以加了一道分类器，遇到危险问题就回退给更保守的 Opus 4.8。听起来像责任感，但作者也点出来了，公开版本里一些星号标注的高危 benchmark 分数会被压下去。

What this actually means is：护栏不只是安全机制，它也是能力分层和市场控制。最强的能力被锁在内部，公开版只给你一部分。对用户来说，这当然会让体验变差，甚至会误伤正常问题；但对厂商来说，这既能控制风险，也能控制竞争对手能看到多少。

我不想把这件事讲得太阴谋论，但也没必要装天真。任何一个大模型厂商，都会同时考虑安全、成本、品牌、竞争壁垒。护栏不是纯道德，也不是纯商业，而是两者的混合物。你把它看成单一动机，都会看偏。

我自己碰到过类似的“安全回退”问题。模型明明知道怎么答，但一碰到某些关键词就开始装傻，或者切换到很保守的模板化回答。对普通用户来说，这当然是烦的；但对平台来说，这是可控的。问题在于，护栏一旦过重，就会把正常工作流也一起挡掉。

所以如果你在做企业内部部署，我建议你别只问“有没有安全机制”，还要问：

• 误判率有多高？
• 回退后能力损失多少？
• 能不能区分高风险和正常专业问题？

这三个问题比一句“我们有安全层”有用得多。否则你最后拿到的只是一个更礼貌的模型，不是一个更好用的模型。

模型越强，harness 越该变薄，不然你是在给弱点续命

文章最后提到一个我特别喜欢的点：harness 工程。原文引用了 Claude Code 工程师 Boris Cherny 的说法，未来的 Claude Code 可能只需要 100 行代码。这个说法听上去反直觉，但逻辑很清楚：模型越弱，你越要靠外部框架补洞；模型越强，框架就应该越薄，因为很多原来靠工程硬拧的事，模型自己就能想明白。

What this actually means is：harness 不是越厚越好，厚到一定程度，你其实是在替模型的短板做永久性装修。短期看很稳，长期看很蠢。因为一旦模型能力上来，旧 harness 反而会拖慢它，限制它，甚至把它的能力压回去。

我自己见过太多“为了兜底而兜底”的工程。每一步都加校验，每一步都加重试，每一步都加规则，最后整个系统像一辆装了五层防撞梁的车，安全是安全了，但根本开不快。模型升级以后，最该做的不是继续加壳，而是敢不敢把壳拆掉一层。

这也是我觉得这篇测评最值钱的地方。它不是只告诉你“Fable 5 很强”，而是在暗示一个工程判断：如果模型已经能更少 token 做更复杂的事，那你围着它写的那些补丁、脚手架、提示词胶带，就该重新审视了。很多时候，真正该优化的不是 prompt，而是你那套为了补弱模型而搭出来的旧流程。

如果你想把这个判断落地，我建议你做一次 harness 清点：

• 哪些逻辑是为了兜模型错误？
• 哪些逻辑是业务必须？
• 哪些逻辑其实已经可以删掉？

你会惊讶地发现，很多“不可或缺”的步骤，其实只是历史遗留。模型一强，这些东西就开始显得笨重。

你可以直接拿去用的评测模板

下面这套模板，是我按这篇测评的思路整理出来的。你可以拿它去测自己的模型、自己的 agent、或者你准备接入的第三方 API。重点不是得出一个漂亮分数，而是看它到底适不适合真实工作流。

# 模型实测模板：coding + agent + 多模态输入 + harness 评估

## 1. 先定义你最在意的能力
- coding: 单文件修复 / 跨文件改动 / PR 可合并性
- agent: 任务拆解 / 工具调用 / 中间自检 / 失败恢复 / 最终交付
- multimodal: 截图理解 / 图表理解 / 手写或扫描件理解
- safety: 误拦截率 / 回退后的能力损失 / 正常专业问题是否被误伤

## 2. 给模型三个层级的任务
### Level A: 题目级
- 单文件 bug fix
- 简单函数补全
- 单张截图问答

### Level B: 仓库级
- 多文件重构
- 代码风格对齐
- 测试补齐
- 依赖关系修改

### Level C: 交付级
- 真实 PR
- 真实 review 约束
- 真实上线前检查
- 真实长链路 agent 任务

## 3. 每个任务都记录这些指标
- 是否一次完成
- 是否需要人工介入
- 中间步骤是否自洽
- 最终结果是否能被接受
- 修正成本有多高
- 是否因为安全机制被错误回退

## 4. 评测提示词模板
你是一个资深工程助手。

目标：{写清楚最终目标}

约束：
- 只修改必要部分
- 保持现有架构和命名风格
- 先解释你的计划，再执行
- 每一步完成后自检
- 如果失败，说明原因并换方案

输入：
{原始截图 / 仓库片段 / 任务描述}

输出格式：
1. 任务理解
2. 执行计划
3. 实际修改
4. 自检结果
5. 风险和未解决项

## 5. harness 清点清单
- 这个重试逻辑还必要吗？
- 这个规则是业务规则还是模型补丁？
- 这个分类器会不会误伤正常问题？
- 这个工作流能不能在模型更强时缩短一半？

## 6. 最终判断
- 适合做：{写场景}
- 不适合做：{写场景}
- 需要人工兜底的环节：{写场景}
- 可以删掉的工程层：{写场景}

这套模板我建议你真的去跑一次。别只在小样本上试，尽量放进你们真实的 repo、真实的文档、真实的截图、真实的脏数据里。模型在演示环境里看着都挺像回事，只有碰到真实输入，优缺点才会露出来。

最后我想补一句：这篇原文最有价值的地方，不是替 Fable 5 站台，而是把“强模型”到底意味着什么讲清楚了。它意味着更少的外部补丁、更长的自主执行、更接近真实工程的交付，以及更高的使用门槛。你要是只看热闹，会觉得又是一次发布会；你要是拿它来改自己的工作流，就会发现很多旧假设都该翻新了。

我这里的整理是基于原文观点做的二次拆解和模板化，不是 Anthropic 官方材料本身。原始来源是知乎专栏这篇文章：https://zhuanlan.zhihu.com/p/2048470791449268396。如果你要追溯具体 benchmark、作者体验和配图，还是应该回到原文看完整上下文。