Fable 5 与 GPT-5.6 Sol 实战经验分享：什么任务该用哪个

记录一段时间同时重度使用 Claude Fable 5 和 GPT-5.6 Sol 做真实项目（主要是编码 + 文档驱动开发 + 少量研究/搜索）后的个人体感。结论都来自实际项目里的对比，不是跑分党，主观成分请自行打折。

写在前面：模型进步没有想象中那么快

先泼一点冷水：模型确实还在进步，但离"独立接走一个完整 job"还有明显距离。 现在的主流前沿模型，更适合被理解成能够高质量完成一系列边界清晰的 task，而不是可以自己承担目标定义、需求澄清、跨团队协调、长期维护和最终责任的完整岗位替代者。

这一区分很重要。一个真实的 job 往往包含大量模型难以独立处理的工作：需求本身可能含糊甚至互相冲突；实现过程中需要不断和产品、设计、业务方确认；代码之外还有上线、监控、回滚、合规、长期维护和责任归属。模型在单个编码任务、资料整理或方案草拟上已经很强，但把这些 task 串成一个几天乃至几周都能稳定推进的闭环，仍然需要人类持续拆解、验收和纠偏。

METR 的"任务完成时间跨度"研究也采用了类似视角：它衡量的是模型在一定成功率下，能够独立完成多长的人类专家任务，而不是直接宣称模型已经能替代一个岗位。该指标近年增长很快，但 METR 同时提醒，时间跨度并不能直接等同于模型能够胜任同等时长的真实项目或职位；真实工作还存在开放目标、环境变化、沟通协调和失败成本等额外复杂性。METR：Task-Completion Time Horizons；METR：Clarifying limitations of time horizon

甚至在熟悉自己代码库的资深开源开发者身上，AI 工具也并非天然带来稳定提速。METR 早期随机对照实验曾发现，参与者使用当时的 AI 工具后平均反而多花了 19% 的时间；后续实验出现了一些提速迹象，但不确定性仍然较大。这说明"模型会写很多代码"和"模型能独立完成软件工程工作"之间，仍隔着不短的工程距离。METR：Early-2025 AI experienced developer study；METR：Developer productivity experiment update

因此，下面这篇文章讨论的并不是"谁已经可以替代工程师"，而是一个更实际的问题：在人仍然负责目标、拆解和验收的前提下，Fable 5 与 GPT-5.6 Sol 分别适合承担哪些 task。 毕竟让模型写完一个模块，和让它对整个项目负责，是两件常被营销文案故意揉在一起的事。

先说结论（TL;DR）

如果只让我用一句话总结这两个模型现在的分工：

GPT-5.6 Sol ：更像一个"听话、能把活干完、产出全面"的执行者。指令遵循强、限制少、搜索强、代码更完整------默认主力。
Fable 5 ：更像一个"有想法、审美和发散度更好，但偶尔偷懒、还爱自我设限"的选手。关键在于它的能力上限高，但你得盯着它、并且做好被降级/拒绝的心理准备。

我现在的实际用法是：GPT-5.6 Sol 打底做主力，Fable 5 用在需要架构判断、UI 品味、发散设计的场景，其余向 GPT 倾斜。

三类任务的实测结论（重点）

我这次主要拿前端、后端、科研三种任务做了对比，结论很干脆：

任务大类	选谁	一句话理由
科研	GPT-5.6 Sol（直接选它）	搜索强 + 全面仔细，这两点直接碾压，没什么好犹豫的
前端 / 设计	Fable 5	审美和发散度更好，出的东西更耐看、更有想法
后端	分情况（见下方说明）	严肃 core + 已有明确设计 → GPT；没思路 / 快速出可用版 / 偏业务 → Fable

科研任务尤其不用纠结 ：GPT 的联网搜索能爬到更多一手料，加上产出全面、核查仔细，Fable 在这块既没有搜索优势、又容易在大模型相关话题上被安全路由拦下来（详见下文第 6 点），综合体验差距非常明显------科研直接上 GPT。

后端不是"随便选"，看任务类型分流：

用 GPT-5.6 Sol ------ 偏严肃 core 的后端，且你心里已经有设计、对功能有严格约束：这时要的是执行力和精确落地，GPT 更合适。
用 Fable 5 ------ 你还没思路 、想快速搓一个简单能用的版本 、或者是偏业务的开发：这时 Fable 的发散和快速成型更省心。

快速选型表

维度	GPT-5.6 Sol	Fable 5	我更倾向
指令遵循 / 一次到位	✅ 强，"一眼指令遵循"	一般，需要多轮纠偏	GPT
UI 审美 / 视觉品味	稍平	✅ 更好看、更有设计感	Fable
发散度 / 创意	略保守	✅ 更敢想	Fable
文档驱动开发（DDD）	老老实实按文档走	❌ 会偷懒、跳步	GPT
代码完整度 / 覆盖面	✅ 产出更多更全	偏少、偏骨架	GPT
同套餐的用量消耗	相对更省	❌ 明显更烧	GPT
Ultra 模式子代理	数量克制但产出扎实	子代理更多，但整体产出反而不如 GPT 全面	GPT
限制 / 降级 / 拒绝	束缚少，拒绝概率低	❌ 常偷偷降级，敏感话题直接拒	GPT
搜索能力	✅ 更强、更能爬到料	偏弱	GPT

分维度详细体感

1. 指令遵循：GPT 明显更"听话"

GPT-5.6 Sol 给我的第一印象，是它有一种**"很久之前那种一眼就照做"的指令遵循风格**------你说要什么、边界在哪、格式怎么定，它基本一次就按你说的来，不太自作主张。

Fable 5 则更"有主见"：你给的约束它有时会理解偏、有时会自己"优化"掉一部分需求，导致要多来几轮把它拽回正轨。对于需求本身很明确、只想让模型老实执行的任务，GPT 的体验明显更顺。

这点与公开评测和厂商定位大体一致。OpenAI 将 GPT-5.6 Sol 定位为复杂专业工作与编码模型，并称其在 Artificial Analysis Coding Agent Index 上以更少输出 token 和更短耗时取得更高成绩；Anthropic 则更强调 Fable 5 在大型迁移、复杂实现和长周期自主编码中的能力。需要提醒的是，这些材料包含厂商自报成绩，只能作为参考，不能替代自己的真实项目验收。(OpenAI：GPT-5.6；Anthropic：Claude Fable 5)

2. UI 审美与发散度：Fable 扳回一城

反过来，Fable 5 在 UI 审美和创意发散上更强。同样一个前端页面或一个开放式设计需求，Fable 出的东西更有设计感、配色和布局更耐看，遇到"给我几个方向"这种发散题也更敢想、点子更多。

GPT-5.6 Sol 在这块偏"稳而平"：能用、规范、不出错，但惊喜少一点，默认审美更朴素。所以凡是吃视觉品味和创意的活，我会优先丢给 Fable。

3. 文档驱动开发（DDD）：Fable 会偷懒

这是 Fable 让我比较头疼的一点。在文档驱动开发 （先写规格/设计文档，再让模型严格按文档实现）里，Fable 5 有明显的偷懒倾向：

文档里写了的点，它会跳过一部分不实现；
或者用 TODO、占位、"此处略"之类的方式糊弄过去；
声称"已完成"，但对着文档一条条核，缺口不少。

GPT-5.6 Sol 在这方面老实得多，会更完整地按文档把每一条落地。如果你的工作流强依赖"文档即契约"，GPT 的可靠性更高，Fable 需要你逐条验收。

4. 用量消耗与产出性价比：Fable 更烧，GPT 更值

体感上 Fable 5 的用量消耗明显更快 。有意思的是------同一个项目跑下来，Fable 和 GPT 按套餐消耗的比例其实差不多 ，但GPT 产出的代码更多、更全面。

换句话说，相同的额度，GPT 给你的"有效产出"更多。 这跟公开信息也对得上：OpenAI 官方主打 GPT-5.6 的 token 效率，并称 Sol 在 Artificial Analysis Coding Agent Index 上以不到 Fable 5 一半的输出 token 和耗时取得更高分。这里仍要强调，这是厂商引用的第三方榜单结果，不等于所有真实项目都会复现。(OpenAI：GPT-5.6) 落到体验上，就是同样掏钱，GPT 干出来的活更实。

5. Ultra 模式下的子代理：多 ≠ 好

在 Ultra 模式下我注意到一个反直觉的现象：Fable 5 会生成更多子代理 （subagent），场面看着更热闹、更"多线程"，但最终整体产出反而不如 GPT 全面。

GPT-5.6 Sol 的子代理数量更克制，但每个都更能落到实处，汇总起来覆盖面更广、缺口更少。所以别被子代理数量迷惑------Fable 分裂得多，不代表交付更完整。

6. 限制 / 降级 / 拒绝：Fable 的"隐形天花板"

这是两者体验差距最大的地方之一。

GPT-5.6 Sol 的束缚明显更少，正常任务几乎不碰壁，即使是偏敏感的方向，直接拒绝的概率也很低。

Fable 5 则经常"偷偷降级"，甚至干脆拒答 。最典型的是大模型 / LLM 相关的研究，Fable 高概率直接拒；而同样的问题喂给 GPT，被拒的概率小得多。

这里补一个能解释现象的背景：Anthropic 对 Fable 5 / Mythos 5 配置了额外的安全路由。官方说明，在部分网络安全、生物以及其他高风险类别中，请求会自动转交给 Opus 4.8 处理；系统卡还讨论了针对模型蒸馏等风险的额外缓解措施。若你的工作集中在这些领域，实际命中率自然可能高于全体用户平均值，于是就会出现明显的"模型被换掉"或能力突然变化的体验。(Anthropic：Claude Mythos；Fable 5 & Mythos 5 System Card)

实操提醒：如果你的工作高度集中在 AI/大模型研究这类话题，Fable 会频繁把你踢回 Opus 4.8，体验很割裂。这类任务我基本直接走 GPT。

7. 搜索能力：GPT 更强

联网搜索这块，我的实际体验是 GPT 的搜索能力更强 ：给的结果更相关、更容易找到原文和一手资料，做资料收集和事实核查时更省心。这里属于产品级体验，而不只是底模能力，因为搜索供应商、查询改写、网页读取、引用生成和安全策略都会影响结果。OpenAI 与 Anthropic 的官方模型页面都主要强调模型和 Agent 能力，并未提供一个足以直接证明"哪家搜索更强"的统一对照，因此这一条应当视为个人实测结论，而非已被公开基准坐实的事实。(OpenAI 模型文档；Anthropic Claude 文档)

至于是模型本身的检索/整合能力差异，还是背后搜索供应商不同导致的，我没法确定------两种可能都存在。但就结果论，做"要搜要查"的活，我会优先用 GPT。

按任务选型（我的实际路由）

任务类型	首选	原因
科研（整体）	GPT-5.6 Sol（碾压）	搜索强 + 全面仔细，Fable 还常被安全路由拦
后端（整体）	分情况	严肃 core + 已有明确设计 → GPT；没思路 / 快速出可用版 / 偏业务 → Fable
前端 / 设计（整体）	Fable 5	审美和发散度更好
需求明确、要老实执行的编码	GPT-5.6 Sol	指令遵循强、产出全
文档驱动开发 / 严格按规格实现	GPT-5.6 Sol	Fable 会偷懒跳步
大型项目、要产出量和覆盖面	GPT-5.6 Sol	同额度有效产出更多
联网搜索 / 资料收集 / 事实核查	GPT-5.6 Sol	搜索更强
LLM / 大模型相关研究	GPT-5.6 Sol	Fable 高概率被安全路由拒/降级
UI / 前端视觉、要好看	Fable 5	审美更好
开放式设计、要点子、发散	Fable 5	创意更强
架构设计 / 方案规划的"品味"	Fable 5（但要盯落地）	规划判断更好，落地交给 GPT

目前最强软件开发工作流（推荐）

一套跑下来体感最顺、扬长避短的完整流水线，核心思路是前期用 Fable 吃"设计和架构品味"，后期用 GPT 吃"规范落地和一步到位的实现"：

Fable 做 UI design ------ 先让 Fable 出界面设计，吃它的审美和发散度，把视觉基调定下来。
Fable 设计初始架构 / 选型 ------ 继续让 Fable 做初始架构和技术选型，它的架构判断和"规划品味"更好，适合定大方向。
GPT 完善架构和开发规范细节 ------ 把 Fable 给的初版方案交给 GPT-5.6 Sol，让它把架构补全、把开发规范/接口/约定这些细节抠实。GPT 更严谨、更全面，正好补齐 Fable 前期"想得好但不够细"的短板。
GPT goal 模式一步到位实现 ------ 最后用 GPT 的 goal 模式直接把实现一把梭出来。GPT 指令遵循强、产出全、性价比高，最适合承接"照着定好的规范把活干完"。

一句话：Fable 负责"想得漂亮"（设计 + 架构），GPT 负责"做得扎实"（规范 + 实现）。 前两步换成 GPT 会少点设计灵气，后两步换成 Fable 则容易偷懒、不够全------所以这套顺序目前是我手上效果最好的组合。

用 GPT-5.6 Sol 时

把它当主力，尤其是"活多、要干完、要搜要查"的场景。
需求写清楚它就会照做，不用太多防偷懒的话术。
想要更好看的 UI，可以让它先出功能，再把视觉部分单独丢给 Fable 打磨。

用 Fable 5 时

验收要严：DDD 场景一定对着文档逐条核，别信它的"已完成"。
发挥长板：让它做发散、做设计、做架构方案的"第一版思路"，而不是让它闷头把大项目从头写全。
预判降级：涉及网络安全 / 生化 / 大模型研究的内容，做好被切回 Opus 4.8 的准备；这类任务不如一开始就换 GPT。
盯用量：它更烧额度，重活之前想清楚值不值得。

组合拳

完整流水线见上面的「目前最强软件开发工作流」一节，这里不重复。

设置与模式建议

模式优先选 Ultra Code。 这个档位能大幅弥补 Claude 系模型"不够抠细节"的短板------多花的算力换来的是明显更完整、更少缺口的产出，重活尤其值。
"Opus 为主、Fable 咨询"那个功能有点鸡肋。 实际用下来体验一般，不如按前面的工作流直接做模型分工来得干脆，不太推荐依赖它。
给 GPT 写提示词时，主动加"让代码更简洁"的约束。 GPT 产出全面是优点，但有时会偏啰嗦/冗长；在 prompt 里提前要求精简（比如"实现尽量简洁、避免冗余、不写多余样板"），能在保留它"全面"优点的同时把代码质量再提一档。

一些注意事项

以上全是个人主观体感，基于我自己的项目和账号环境，换个任务类型或渠道结论可能不一样。
模型和它们的路由/安全策略都在快速迭代，降级和拒绝的边界随时可能变，遇到和这里描述不符的情况很正常。
两家官方给的跑分都对自己有利，别全信；以你自己真实项目的实测为准。
涉及成本的部分（用量、性价比）尤其受套餐、渠道、上下文长度影响大，建议用你自己的典型 prompt 实测校准。

参考资料与阅读边界

文中的模型表现仍以作者个人项目体验为主。官方材料适合确认产品定位、价格、路由和厂商公开评测，但厂商自报 benchmark 不应被当作中立结论；METR 的研究则更适合说明自治任务能力和真实生产力之间的边界。

Fable 5 与 GPT-5.6 Sol 实战经验分享：什么任务该用哪个--更高效的使用你的token