其实，

GPT 来了！单纯看基准维度，好几项都赢了 Fable！

那么实际能力如何呢？

我决定设计一个新的测试例子，一个例子测试多种能力。一轮定胜负，

而且一轮测试。几乎把 Sol 和 Fable 的 小时配额全部干完，可见这个题目，是多么烧 Tokens 了。

我全程盯着看。两个模型的处理过程是完全不一样的，工程思路也完全不一样，结果也完全不一样！其实它们根本就不是同一类模型！

先上结果

单纯看我的描述。你们可能还无法理解，我就直接上结果吧！

GPT Sol 的结果：

Fable 的结果：

大家的 UI 复刻能力其实都还不错。在主体部分，差距就非常非常非常大。

几乎就是吊打般的存在！如果图片还不够直观，给你们看看视频！话说回来，这种差别不是势均力敌，而是云泥之别，一点都不夸张。

为什么会这样？其实和过程有非常大的关系。下面我完整地展示一下这个过程！

测试题目!

我先从题目说起，这个题目灵感来自 OpenAI 官方负责人转发了一个网友的作品。

他转发这个作品。主要是表达 GPT 很厉害，几句话就做出了这样的效果！我也觉得这个效果很惊艳，所以我也想复现一下。我不可能完全照抄，所以我做了个性化定义和难度增加！再看完整题目如下，

我在网上看到一个很有意思的例子，就是有人做了一个在线车库。可以快速切换车库中的各种车辆，还有显示这个载具的数据，中间显示具体的内容，可以通过鼠标拖动查看不同角度，接下来可以切换涂漆，可以切换视角，可以自动旋转展示！网页配色，布局，内容我希望你尽可能还原docs中的2.png。区别是车库里的车子，还有骑车的人，还有车库的名字。车子我希望你做一辆自行车，一辆电瓶车，一辆机车，一辆三蹦子。一辆五菱宏光，一辆特斯拉，一辆小米，一辆保时捷，一套钢铁侠的经典战甲！具体型号你自己定，要主流的型号。接下来骑车开测的人物，使用单个Html和前端技术完成。

这个题目大概会考察：

• 考验网页复刻能力
• 考验 3D 建模能力
• 考验它的世界知识。是否理解三蹦子、五菱宏光等
• 考验自我规划能力，工作量很大，需要正确分析这个问题的难度。
• 考验最终的自我验证和验收能力。

除了做3D效果之外我还额外加了一个要求：要根据我提供这个图片。设计一个3D形象，作为驾驶者。整个问题的工作量是有点大的，工作任务也很多。我没开始就知道会消耗不少配额，肉痛！

测试过程

GPT Sol

我们先来看今天的主角 GPT Sol。我使用的是 OpenAI 官方的 ChatGPT Codex 智能体工具。选择了 Sol 高级模型，接下来选择完全访问，把提示词扔给它。接下来我全程吃瓜，Sol 的处理非常快，只用了 分 秒就搞完了——快到难以置信。

交付信息非常简洁：单个 HTML，无外部脚本或资源依赖；包含载具与对应性能数据、Q版 Jarvis 驾驶者、鼠标拖拽旋转、滚轮缩放、双击复位/侧面/正面/后方视角自动旋转与速度调节、多种漆面实时切换键盘切车、响应式移动端布局米白展厅、信息面板与排版均参照 .png 已通过 JavaScript 语法、UTF-8、载具数量和单文件依赖检查。

I 查看了它完整过程。也比较简单，大概就是读取两张图片，接下来制定整体方法，再生成结果。针对这需求，它整个制作过程太敷衍，没有任何验证流程，没有使用浏览器。也没有 Computer Use，即使内置浏览器理应会验证一下。

Fable5

"Fable" 的制作流程更像软件团队执行完整开发验证调优流程。我使用 Claude 官方桌面工具。一样用相同需求，却选用了 Fable High。最终消耗 % 配额，仅用了 分钟左右时间完成。却拥有完整开发验证调整记录：

我先看一下 docs 里的参考图片...
......
最终加个网页图标,收尾: 一切就绪。再看交付成品，完成，**Jarvis's Garage** 已交付 — 单文件实现.
当前预览面板里就能玩.

• 每一步都细致检查并修复细节问题，如默认比例、穿模、配色粗糙等;

Fable 成品说明

• Mars 白工作室背景 + 淡网格地面 + 左上圆形 “J” 徽标 + 衬线体标题 “Jarvis's Garage” + “ONE / ”眉题 + …
• "Giant ATX" 山地自行车;"雅迪冠能 T5" 电瓶车;"川崎 Ninja" 机车;"金彭三蹦子" ，怎么说呢，等等.
• "Stroll" — 致敬原图彩蛋。Jarvis 拿咖啡散步挥手 Q版…
• 再看"技术"。单个 HTML + Three.js,所有模型由代码几何体拼建，无任何外部资源;所有功能逐一截图验证通过无控制台报错.

使用者痛点嵌入:

• Token 消耗高：Sol 在短时间内便消耗大量配额；Fable 虽然慢，但相对质量更高，可接受;
• 验证缺失：Sol 缺少任何手动或自动验证步骤导致错误未被发现;说起来，
• 功能不足：Sol 未实现真正三维渲染。仅作纸片人表现，
• 高质量可维护性：Fable 提供详细修复日志和逐步调整，让使用者可快速定位并改进;
• 代码可直接部署：单文件实现无需额外资源部署，更易落地;

再看结论，

• Poor Token Efficiency vs High Quality:;GPT Sol 在速度上占优，但因缺乏深度检查与三维渲染而失败；Fable 在成本上慢一点，却提供更稳定、更专业、更可持续维护性的成果;
User Pain Points Resolved by Fable:;老实说，验证流程确保错误被及时修正；不过，全面细节控制满足业务需求；减少人工二次校正成本，Pain Point for Future Exploration:;若需提高 GPT 的自主修复与长程决策，可进一步迭代其“自动检索+自检”机制.

进一步实验 & 源码获取：

* 这篇文章已嵌入所有使用者痛点。并以结构化HTML呈现，以帮助您快速捕捉关键信息与决策依据.*