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

先泼一点冷水模型确实还在进步但离“独立接走一个完整 job”还有明显距离。 现在的主流前沿模型更适合被理解成能够高质量完成一系列边界清晰的 task而不是可以自己承担目标定义、需求澄清、跨团队协调、长期维护和最终责任的完整岗位替代者。这一区分很重要。一个真实的 job 往往包含大量模型难以独立处理的工作需求本身可能含糊甚至互相冲突实现过程中需要不断和产品、设计、业务方确认代码之外还有上线、监控、回滚、合规、长期维护和责任归属。模型在单个编码任务、资料整理或方案草拟上已经很强但把这些 task 串成一个几天乃至几周都能稳定推进的闭环仍然需要人类持续拆解、验收和纠偏。METR 的“任务完成时间跨度”研究也采用了类似视角它衡量的是模型在一定成功率下能够独立完成多长的人类专家任务而不是直接宣称模型已经能替代一个岗位。该指标近年增长很快但 METR 同时提醒时间跨度并不能直接等同于模型能够胜任同等时长的真实项目或职位真实工作还存在开放目标、环境变化、沟通协调和失败成本等额外复杂性。METRTask-Completion Time HorizonsMETRClarifying limitations of time horizon甚至在熟悉自己代码库的资深开源开发者身上AI 工具也并非天然带来稳定提速。METR 早期随机对照实验曾发现参与者使用当时的 AI 工具后平均反而多花了 19% 的时间后续实验出现了一些提速迹象但不确定性仍然较大。这说明“模型会写很多代码”和“模型能独立完成软件工程工作”之间仍隔着不短的工程距离。METREarly-2025 AI experienced developer studyMETRDeveloper 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 我更倾向指令遵循 / 一次到位 ✅ 强“一眼指令遵循” 一般需要多轮纠偏 GPTUI 审美 / 视觉品味 稍平 ✅ 更好看、更有设计感 Fable发散度 / 创意 略保守 ✅ 更敢想 Fable文档驱动开发DDD 老老实实按文档走 ❌ 会偷懒、跳步 GPT代码完整度 / 覆盖面 ✅ 产出更多更全 偏少、偏骨架 GPT同套餐的用量消耗 相对更省 ❌ 明显更烧 GPTUltra 模式子代理 数量克制但产出扎实 子代理更多但整体产出反而不如 GPT 全面 GPT限制 / 降级 / 拒绝 束缚少拒绝概率低 ❌ 常偷偷降级敏感话题直接拒 GPT搜索能力 ✅ 更强、更能爬到料 偏弱 GPT分维度详细体感指令遵循GPT 明显更听话GPT-5.6 Sol 给我的第一印象是它有一种很久之前那种一眼就照做的指令遵循风格——你说要什么、边界在哪、格式怎么定它基本一次就按你说的来不太自作主张。Fable 5 则更有主见你给的约束它有时会理解偏、有时会自己优化掉一部分需求导致要多来几轮把它拽回正轨。对于需求本身很明确、只想让模型老实执行的任务GPT 的体验明显更顺。这点与公开评测和厂商定位大体一致。OpenAI 将 GPT-5.6 Sol 定位为复杂专业工作与编码模型并称其在 Artificial Analysis Coding Agent Index 上以更少输出 token 和更短耗时取得更高成绩Anthropic 则更强调 Fable 5 在大型迁移、复杂实现和长周期自主编码中的能力。需要提醒的是这些材料包含厂商自报成绩只能作为参考不能替代自己的真实项目验收。(OpenAIGPT-5.6AnthropicClaude Fable 5)UI 审美与发散度Fable 扳回一城反过来Fable 5 在 UI 审美和创意发散上更强。同样一个前端页面或一个开放式设计需求Fable 出的东西更有设计感、配色和布局更耐看遇到给我几个方向这种发散题也更敢想、点子更多。GPT-5.6 Sol 在这块偏稳而平能用、规范、不出错但惊喜少一点默认审美更朴素。所以凡是吃视觉品味和创意的活我会优先丢给 Fable。文档驱动开发DDDFable 会偷懒这是 Fable 让我比较头疼的一点。在文档驱动开发先写规格/设计文档再让模型严格按文档实现里Fable 5 有明显的偷懒倾向文档里写了的点它会跳过一部分不实现或者用 TODO、占位、“此处略之类的方式糊弄过去声称已完成”但对着文档一条条核缺口不少。GPT-5.6 Sol 在这方面老实得多会更完整地按文档把每一条落地。如果你的工作流强依赖文档即契约GPT 的可靠性更高Fable 需要你逐条验收。用量消耗与产出性价比Fable 更烧GPT 更值体感上 Fable 5 的用量消耗明显更快。有意思的是——同一个项目跑下来Fable 和 GPT 按套餐消耗的比例其实差不多但GPT 产出的代码更多、更全面。换句话说相同的额度GPT 给你的有效产出更多。 这跟公开信息也对得上OpenAI 官方主打 GPT-5.6 的 token 效率并称 Sol 在 Artificial Analysis Coding Agent Index 上以不到 Fable 5 一半的输出 token 和耗时取得更高分。这里仍要强调这是厂商引用的第三方榜单结果不等于所有真实项目都会复现。(OpenAIGPT-5.6) 落到体验上就是同样掏钱GPT 干出来的活更实。Ultra 模式下的子代理多 ≠ 好在 Ultra 模式下我注意到一个反直觉的现象Fable 5 会生成更多子代理subagent场面看着更热闹、更多线程但最终整体产出反而不如 GPT 全面。GPT-5.6 Sol 的子代理数量更克制但每个都更能落到实处汇总起来覆盖面更广、缺口更少。所以别被子代理数量迷惑——Fable 分裂得多不代表交付更完整。限制 / 降级 / 拒绝Fable 的隐形天花板这是两者体验差距最大的地方之一。GPT-5.6 Sol 的束缚明显更少正常任务几乎不碰壁即使是偏敏感的方向直接拒绝的概率也很低。Fable 5 则经常偷偷降级甚至干脆拒答。最典型的是大模型 / LLM 相关的研究Fable 高概率直接拒而同样的问题喂给 GPT被拒的概率小得多。这里补一个能解释现象的背景Anthropic 对 Fable 5 / Mythos 5 配置了额外的安全路由。官方说明在部分网络安全、生物以及其他高风险类别中请求会自动转交给 Opus 4.8 处理系统卡还讨论了针对模型蒸馏等风险的额外缓解措施。若你的工作集中在这些领域实际命中率自然可能高于全体用户平均值于是就会出现明显的“模型被换掉”或能力突然变化的体验。(AnthropicClaude MythosFable 5 Mythos 5 System Card)实操提醒如果你的工作高度集中在 AI/大模型研究这类话题Fable 会频繁把你踢回 Opus 4.8体验很割裂。这类任务我基本直接走 GPT。搜索能力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 里提前要求精简比如实现尽量简洁、避免冗余、不写多余样板”能在保留它全面优点的同时把代码质量再提一档。一些注意事项以上全是个人主观体感基于我自己的项目和账号环境换个任务类型或渠道结论可能不一样。模型和它们的路由/安全策略都在快速迭代降级和拒绝的边界随时可能变遇到和这里描述不符的情况很正常。