Fable 5 vs GPT-5.6 Sol：真正拉开差距的，是谁替你做设计决定

观察窗口：截至 2026 年 7 月 16 日。本文综合厂商资料、公开设计榜单、职业设计师盲测和 Reddit、YouTube 等社区的用户案例。社区作品通常只有一次运行，提示词、模型档位、Agent 工具和人工介入也不完全一致，因此适合观察行为模式，不适合当作严格实验。

如果只看最近一周的用户评价，会得到两个完全相反的答案。

一部分人认为 Claude Fable 5 仍然是 UI 设计最强模型：版式更稳、细节更干净、知道什么时候不该加动画，交付物更像经过设计师收口。另一部分人则认为 GPT-5.6 Sol 已经反超：它敢于做完整的视觉方向，色彩与字体更有主见，从一句模糊需求就能做出可以展示的页面，而且速度和成本明显更友好。

两边都拿得出作品，也都能找到失败案例。争论之所以一直没有结果，不是用户都在凭感觉，而是大家把完全不同的任务都叫作“设计”：有人测空白页面的一次生成，有人测旧产品重构；有人只看截图，有人真的运行 App、检查动效和响应式；有人给一句情绪，有人给完整网格、字体、色板与禁用项。

我的核心判断是：Fable 5 与 GPT-5.6 Sol 的差距，不首先是审美高低，而是设计决策权的处理方式不同。Sol 倾向主动补全空白，像一个有强烈主张、动作很快的创意负责人；Fable 更愿意读取现有结构、参考和约束，再把方向精确落地，像一个审慎但昂贵的资深产品设计工程师。

因此，真正的问题不是“谁设计得更好”，而是：你的项目中还有多少关键设计决定没有做，以及你愿意把多少决定交给模型。

一、先拆开“设计能力”，否则所有比较都会失真

模型生成一个漂亮页面，至少混合了七种不同能力：

能力	真正要解决的问题	常见误判
艺术方向	能否从品牌、受众和情绪中形成明确视觉语言	把大胆配色与大字号直接当作好审美
Brief 理解	能否区分硬约束、偏好、参考与留白	只看结果好不好看，不看是否做对了题
信息架构	内容顺序、层级、导航与操作路径是否合理	用装饰掩盖产品逻辑没有被理解
视觉执行	字体、间距、网格、色彩、图标和素材是否一致	只截取首屏，忽略长页面与边界状态
交互设计	状态、反馈、动效、可用性与无障碍是否成立	把“会动”误认为“好用”
工程落地	响应式、组件复用、性能与现有代码是否可靠	把单文件 HTML demo 当成生产前端
自我校验	是否会运行、截图、比较、发现溢出并继续修正	把模型第一次停下来当作任务已经完成

这七项很少由同一个模型在一次运行中全部做好。一个页面可能艺术方向很强，却不遵守现有产品行为；也可能严格复刻设计系统，却显得安全而无聊。对旧产品“重设计”而言，正确保留哪些东西甚至比新增什么更重要。

所以，本文不把设计能力压成一个总分，而是分别观察三个阶段：方向生成、受约束执行、运行后的收口。 这也恰好解释了为什么网上会出现彼此冲突、却都真实的结论。

二、公开盲测给出的答案：模糊需求 Sol 赢，完整规范 Fable 赢

目前最值得参考的一组对比，来自 Contra Labs 在 2026 年 7 月进行的网页设计盲测。他们让 GPT-5.6 Sol、Claude Fable 5、Grok 4.5 和 Muse Spark 1.1 分别完成十个虚构客户的 landing page，由 9 名在职设计师对实时页面进行盲选，共产生 540 次两两比较与 360 份书面评价。

整体结果看似偏向 Sol：它赢得 63.3% 的对局，在四个模糊 brief 上全部第一；模糊需求下，Sol 的 Elo 为 1703，61% 的页面被认为可以直接拿给客户，而其他模型合计只有 31%。设计师称赞最多的是它对情绪、字体、配色和品牌性格的主动解释。

但当 brief 加入章节顺序、字体、网格、色板、动效时间和禁止项后，排名完全反转。Fable 在结构化 brief 上达到 1569 Elo，Sol 降至 1455；Fable 的“可交付”比例从模糊需求下的 31% 上升到 72%，并在结构化任务中 64% 的时候击败 Sol。四十个页面中，唯一获得 9 名设计师一致同意可以交付的作品来自 Fable。

Brief 状态	GPT-5.6 Sol 的表现	Claude Fable 5 的表现	更合理的解释
只有目标与情绪	主动补全字体、色彩、插画和版式，方向感强	倾向安全执行，容易显得普通	Sol 更愿意承担艺术指导责任
有明确视觉规范	仍会填补规范中的空白，结果波动变大	版式、顺序与禁用项执行更稳定	Fable 更尊重已经存在的决策
面向客户交付	不论 brief 松紧，可交付率约 61%	从 31% 跃升至 72%	Fable 的上限更依赖输入质量
典型失败	字号过大、擅自解释色板、视觉主张压过约束	模糊任务中过于保守、设计缺少记忆点	两者不是同一种失败模式

这组结果比“某模型总分第一”更有价值，因为它揭示了设计能力的条件性：Sol 的优势是替用户做决定，Fable 的优势是把用户已经做出的决定执行到底。

同时必须看到边界：这项研究只有十个 brief，每个模型每题只运行一次，而且输出是单文件 HTML。研究者自己也指出，Fable 在结构化 brief 上的优势效应较大，但统计证据仍受样本量和行业类型混杂影响。它可以说明行为倾向，不能宣布永久冠军。

三、公开榜单为什么与用户体感不完全一致

Design Arena让用户盲选单文件 HTML 结果，覆盖网站、UI 组件、游戏、数据可视化和 3D。7 月 16 日的模型快照中，Fable 5 的综合用户胜率约为 65%，Sol 约为 58%。这支持“Fable 整体视觉与代码质量更稳”的说法，但仍然没有告诉我们胜利发生在方向、细节还是交互层。

公开榜单与现实项目之间至少隔着四层差异：

一次生成与多轮项目不同。 榜单奖励首轮惊艳，真实产品需要连续修改而不破坏已有逻辑。
单文件与代码库不同。 一张页面可以没有路由、状态、设计 token、测试和历史债务，真实重设计不能。
截图偏好与使用体验不同。 大字号、强对比和动效容易在盲选中胜出，却可能损害信息密度、无障碍和长期使用。
模型与 Agent 产品不同。 Fable 在 Claude Code、Sol 在 Codex 或 ChatGPT Work 中使用的工具、规则、截图能力和上下文管理不同，用户实际比较的是整个执行系统。

OpenAI 在 GPT-5.6 发布资料中强调 Sol 的 design judgment、前端生成与多 Agent Ultra 模式，并引用 Lovable 的内部数据称，相比前一代模型，它使用更少步骤和工具调用，同时减少卡住的运行。这是平台伙伴与厂商提供的产品数据，不是 Fable 对照实验。

Anthropic 对 Fable 5 的官方定位则更强调视觉理解、复杂网页截图、长时任务、指令保持和处理歧义。它解释了 Fable 为什么适合读现有产品、品牌说明和设计系统，却同样不能直接证明它的审美优于 Sol。

官方资料告诉我们模型被训练成什么，盲测告诉我们第一眼喜欢什么，项目用户才告诉我们它在修改十轮之后还剩下什么。三者不能互相替代。

社区声量本身还带有明显偏差。同一组作品发到 Claude、Codex 与 vibe coding 社区，评论者可能分别奖励忠实、创造性与完成速度；视觉冲击强的结果更容易被转发，经过大量人工修正的“神作”又未必披露修改过程。失败运行通常被删除，成功的一次则被包装成模型常态。因此，本文所说的“用户反馈”不是按赞数投票，而是寻找跨社区反复出现、并能被盲测机制解释的行为模式。

四、真实用户案例里，差距集中在“敢改多少”和“收口多细”

最近的公开案例虽然样本小，却反复出现相似的行为模式。

一个用户让两者基于同一基础界面，为鼓机设计四套视觉方案，包括复古控制台、Teenage Engineering 风格和两个自由主题。在这组鼓机 UI 对比中，Sol 更愿意彻底改变布局，创意方向并不弱；但发帖者认为它在文字溢出、图标对齐和整体一致性上落后，Fable 的成品更像经过最后一轮设计 QA。

另一位用户要求两者把一个极简卡路里记录概念做成原生 iOS App，并明确要求运行模拟器、逐帧检查动效。这个SwiftUI 对比的观察是：两者都能排页面，真正差异在工作习惯。Sol 决策更快，并能利用内置图像能力快速推进；Fable 更慢，却更愿意逐帧回看、修正薄弱过渡。作者最终建议给 Sol 外挂严格的视觉验收，而把 Fable 用在值得精细检查的关键界面。

还有用户要求把一个二维网格游戏转成三维版本。2D 到 3D 的对比中，Fable 忠实保留原玩法和形式，只改变呈现维度；Sol 加入更强的 1980 年代风格，却把游戏变成了另一种东西。评论区对此也分成两派：有人认为 Fable 理解了“重设计不是重做”，也有人认为用户已经给了自由度，Sol 的创造性更有价值。

这些案例没有统一冠军，却共同回答了一个更重要的问题：Sol 更容易把“可以改”理解成“应该改”，Fable 更容易把“保留”视为设计质量的一部分。

这也是旧产品重设计与从零生成的分水岭。空白项目里，主动填补缺失决策是能力；已有用户、行为和品牌资产的项目里，同样的主动性可能变成回归风险。

五、Sol 的设计性格：有主见、速度快，但容易把自己放在产品前面

GPT-5.6 Sol 最明显的进步，不是终于会写 CSS，而是开始形成完整的视觉意见。面对一句不完整的需求，它会迅速确定字体尺度、配色、视觉中心和动效节奏，并把素材、交互与代码一起推进。Contra 的模糊 brief 结果说明，这种主动性不是个别 demo 的偶然。

它尤其适合三类任务：

还没有设计师、需要快速看到多个产品方向的零到一原型。
营销页、互动解释、游戏和视觉实验等允许强主张的内容。
需求明确、验收标准可自动检查，并且成本与速度重要的大批量实现。

但 Sol 的风险也来自同一个地方。它倾向于直接行动，不一定先问品牌、用户和禁区；当规范留下一个小空白，它会把空白当作授权。Contra 的测试里，它曾自行放大标题并解释色板，最终破坏首屏层级。另一位用户也报告，一句简单网站需求没有触发澄清，结果变成了通用 AI 风格页面；评论者建议明确要求模型在遇到等价选择时逐个提问，并提供参考图与长期规则。这个失败案例说明，Sol 的“有主见”并不保证每次都恰好符合用户品味。

因此，Sol 更像一个需要明确否决边界的创意负责人。不要只告诉它“做得高级”，还要告诉它哪些产品行为、品牌资产和视觉尺度绝不能动；不要只让它生成，还要要求它在真实视口截图、检查溢出、对照验收表并迭代。

六、Fable 的设计性格：读得深、收得稳，但模糊需求下可能过于安全

Fable 5 的优势不是永远更华丽，而是更容易把设计当作上下文问题。它会阅读现有 HTML/CSS、组件结构、品牌说明和内容关系，再在这些约束里重组视觉系统。一个公开的网站重设计记录显示，Fable 先读取原网站与品牌资料，再调整字体组合、标识系统和页面结构，并通过人工 Review 迭代到真实部署。这仍是单一项目自述，却比一次性 landing page 更接近现实重设计。

它更适合：

已有设计系统、组件库和用户行为，不能随意改变产品语义的重设计。
参考图、网格、字体、色板和负面约束都比较完整的品牌落地。
需要跨多文件理解、长时间保持规则，并反复视觉检查的高价值界面。

Fable 的问题是成本高、动作重，而且在方向不明时可能选择“正确但无聊”。Contra 的职业设计师盲测里，它在模糊 brief 下只有 31% 的页面被认为可以交付；给出规范后才上升到 72%。这意味着用户若期待 Fable 自动替自己找到品牌灵魂，可能得到整齐、合理，却缺少独特记忆点的结果。

社区里“Fable 更有创造力”的体感并不一定与此矛盾。在 Claude Code 的多轮工作中，Fable 会提问、探索、编排子任务并长期维护一个概念，所以整体上像更会共同思考的设计伙伴；但在单轮、无参考的视觉 brief 中，它未必比 Sol 更敢冒险。创意不是模型固定属性，它也取决于模型是否有机会理解问题、获得反馈并继续演化。

七、重设计任务里，最重要的能力不是生成，而是识别“不该改变什么”

从零做一个页面，默认目标是增加价值；重设计一个正在使用的产品，第一目标应是避免破坏已有价值。这两种任务看起来都在改 UI，风险结构完全不同。

一个合格的重设计需要先建立四份清单：

清单	需要确认的内容	更容易被模型忽视的风险
产品不变量	核心流程、数据含义、导航、快捷操作与用户习惯	为了视觉新鲜感改变行为
设计系统	字体、色板、间距、组件状态、图标和动效规则	每个页面各自“有创意”
技术边界	框架、组件库、响应式、性能、无障碍和测试	截图漂亮但代码无法维护
验收证据	桌面与移动截图、交互录像、视觉回归和真实内容	只用占位文案验证理想状态

在这个任务里，Fable 的 brief fidelity 和长上下文通常更有价值；Sol 的主动重构能力则适合被放在受控探索区，用来提出更大胆的替代方向。若项目本来就是要推翻旧产品，Sol 的冒险可能是优势；若只是改善信息层级与一致性，它的主动性必须被限制。

这也解释了为什么同一句“可以自由修改”会产生完全不同的评价。模型无法知道用户嘴里的自由，是视觉表达自由，还是产品语义也可以重写。好的设计提示词不应该扩大这种歧义，而要明确授权边界。

八、真正被比较的从来不只是模型，而是模型加工作环境

很多网络对比把 Claude Code + Fable 与 Codex/ChatGPT Work + Sol 放在一起，然后把结果全部归因于模型。这并不严谨，却也符合用户的真实购买体验：用户最终使用的本来就是模型、Agent harness、工具和额度的组合。

设计任务尤其依赖工作环境：

能不能读取现有仓库、设计 token、字体和真实内容。
能不能启动开发服务器或模拟器，并等待页面稳定。
能不能在桌面、平板和手机视口截图。
能不能比较参考图与实现，定位溢出、遮挡和对齐误差。
能不能调用图像生成、裁切、浏览器和无障碍检查工具。
修改后会不会运行测试，并避免顺手重写无关功能。

这也是为什么同一个模型在聊天框、API、Codex、Claude Code 或第三方生成平台中的表现可能完全不同。高 effort 只意味着模型愿意投入更多计算，不意味着它自动拥有更好的设计流程。没有浏览器反馈的 xhigh，可能不如能看截图并循环修正的中等 effort。

一个成熟比较的单位应该是：模型 + 提示词 + 项目规则 + 工具权限 + 推理档位 + 验收循环。 把其中任何一个隐藏掉，结论都会比作品本身更漂亮。

九、成本会改变最优选择：最好看的一次，不等于最便宜的完成

Anthropic 官方文档给出的 Fable 5 API 价格是每百万 token 输入 10 美元、输出 50 美元；OpenAI 公布的 Sol 价格为输入 5 美元、输出 30 美元。OpenAI 还声称 Sol 在部分 Agent 和 coding 评测中以更短时间、更少 token 接近或超过 Fable，但这些是厂商测试，不能直接外推到设计项目。

社区里有用户报告，Sol 在相同提示词下只消耗 Fable 约二十分之一的 token，同时承认 Fable 的质量仍略高。这份个人测试没有公开可复现实验，二十倍不能当作稳定比例；但它指出了正确的经济问题：当一次 Fable 运行的预算可以让 Sol 生成、截图和修正多轮时，最终交付质量未必仍由“单次最好看”决定。

设计项目应比较的是“每个通过验收的页面成本”，包括：

生成与思考 token。
浏览器、图像和其他工具调用。
人类澄清、Review 与返工时间。
模型破坏已有功能后产生的回归成本。
页面上线后的性能、可访问性与维护成本。

Fable 若一次做对复杂约束，贵可能是便宜；Sol 若能以更低成本生成四个方向、淘汰三个再精修一个，便宜也可能转化为更好的设计。反过来，Sol 若持续偏离产品不变量，省下的 token 会被人工返工吞掉。

十、最佳实践不是二选一，而是把两种性格排进同一条流水线

对预算允许、设计价值较高的项目，我更推荐分阶段使用，而不是让两个模型盲目互审同一份成品。

第一步：先让 Sol 扩大方向空间

输入品牌、受众、核心任务和少量不可变约束，让 Sol 提出三到四个真正不同的艺术方向。要求每个方向说明字体、色彩、层级、素材、动效与风险，而不是马上重写整个仓库。

第二步：由人确定设计决策

选择一个方向，把它变成结构化 brief：页面顺序、网格、字体尺度、色板角色、组件状态、动效时长、禁用项、移动端规则和必须保留的产品行为。这里不能外包，因为多个方向都可能合理，只有产品负责人知道哪一个值得承担。

第三步：让 Fable 在规范内落地并收口

把现有代码、参考截图、设计 token 和验收清单交给 Fable，要求它先审计再修改，并在每个目标视口上截图。Fable 的价值不是多写代码，而是尽量保持结构、限制改动范围和补齐细节。

第四步：让 Sol 做工程与反例审查

让 Sol 检查响应式、内容溢出、空状态、错误状态、键盘操作、对比度、性能和无关回归。它在明确标准下执行和审计的效率，通常比再来一轮开放式美化更有价值。

第五步：浏览器证据决定是否完成

最终验收不能由任何模型用一句“已完成”结束。至少保留真实内容下的桌面与移动截图、关键交互状态、构建与测试结果，以及一份明确的视觉缺陷清单。设计是一项可感知工作，也必须留下可检查证据。

如果只能选一个模型，可以用下面这张表做第一轮判断：

任务状态	优先选择	原因	必须补上的控制
只有概念、缺少视觉方向	Sol	能主动建立艺术方向并快速拉开方案差异	明确产品不变量，避免创意改写功能
已有设计系统与完整 brief	Fable	对结构、负面约束和上下文更忠实	要求避免过度保守，并提供优秀参考
旧产品高保真重设计	Fable	更适合先理解再局部重构	用真实用户流程和视觉回归防止暗损失
营销页、游戏、互动实验	Sol	主动性、素材组合与速度更有价值	检查字号、溢出、动效和移动端
大批量、标准明确的页面	Sol	单位成本与执行效率更可控	建立自动截图和验收规则
核心页面的最后收口	Fable	对一致性、过渡与细节检查更耐心	控制 token 预算，限制修改范围

这不是固定排名。只要 brief、工具和验收方式发生变化，最优模型也可能交换位置。

十一、这场对比真正改变的，是设计师与前端工程师的价值位置

Fable 与 Sol 都已经能生成超过普通模板水平的页面，这会继续压低“把一个明确稿子翻译成常见组件”的价格。但它们的对比也证明，模型越强，设计工作的价值越向四个上游与下游环节移动：

定义问题：用户是谁，什么行为需要改变，什么必须保留。
做出选择：多个合理方向里，哪一个符合品牌和商业目标。
写出约束：把品味转化成网格、尺度、状态、禁用项和组件规则。
验证结果：在真实数据、真实设备和真实交互里发现“看起来不错”的错误。

过去设计师用画板表达这些判断，未来还要用 brief、token、参考资产和验收规则把判断传递给 Agent。前端工程师也不会只负责把图变成代码，而会更像一个运行时设计守门人：维护组件边界、性能、可访问性和视觉回归系统。

这不是设计被模型消灭，而是低解释空间的执行劳动被压缩，高责任的判断劳动被放大。模型能生成更多选择，却不能替企业承担选错方向的代价。

结语：品味不是一个模型分数，而是一套被贯彻的选择

截至 2026 年 7 月中旬，没有足够证据支持“Fable 5 全面碾压 Sol”，也没有证据支持“Sol 已经取代 Fable 成为最强设计模型”。更接近现实的结论是：

Sol 更擅长在空白里建立方向，Fable 更擅长在约束里维持方向；Sol 用主动性换速度和惊喜，Fable 用上下文与检查换忠实和完成度。

它们都可能做出惊艳页面，也都可能制造典型 AI 设计：巨大的标题、过多的动效、空泛的文案、漂亮但错误的产品流程。差别只在于，Sol 更可能自信地替你做了一个错误决定，Fable 更可能认真地执行了一个不够好的决定。

所以这场竞争真正暴露的，不是模型有没有品味，而是用户有没有能力定义品味、表达品味并验收品味。没有 brief、设计系统、真实内容和浏览器验证，再强的模型也只是在替你抽一张更昂贵的视觉彩票。

未来最强的设计工作流，不会把所有决定交给一个“审美冠军”。它会让模型负责扩大选择、执行约束和寻找错误，让人负责决定什么值得被做，并对最终体验承担责任。