先说结论
这组测试没有证明某个模型在所有场景下都更好。
它更像是一次“效果优先”和“速度、成本优先”的对照实验。
在提供的 5 个案例中，Claude Opus 5.5 的最终产出更完整。
GPT-6 Sol 的执行速度更快，使用成本和额度压力也更低。
如果任务需要长时间自主规划、连续修改和复杂界面，效果差异会被放大。
如果任务更看重快速交付、预算或日常调用频率，速度和成本就不能被忽略。
本文只讨论这组测试条件下的表现。
它不代表所有提示词、所有工具或所有项目的普遍结果。
测试问题是什么
实际问题很简单：当两个模型都能调用开发工具时，应该如何选择？
只看公开跑分，通常很难回答这个问题。
模型可能在基准题上得分接近，但在真实项目中表现不同。
例如，有的模型能生成一个能运行的页面，却没有完成关键交互。
有的模型能完成基础功能，却不会主动打开页面验证。
还有的模型会继续修改，直到主要问题被解决。
因此，这次测试把任务放到 Cursor 和 Codex 中执行。
两边尽量使用相同的提示词。
推理强度均设置为 high。
测试过程中不进行人工干预。
这种方式更接近“把任务交给模型后等待交付”的工作流。
五个案例覆盖了什么
第一个案例是用 SVG 代码绘制熊猫骑车送外卖。
它主要观察模型能否处理几何关系、动作姿态和细节补充。
第二个案例是写一段约 300 字的科普内容。
它主要观察模型是否能用自然语言解释技术概念。
第三个案例是生成重庆 3D 城市项目。
它主要观察模型的长程编码、界面设计和自我验证能力。
第四个案例是操作简易画板，临摹一张 Q 版鲸鱼娘参考图。
它主要观察模型的视觉理解和电脑操作能力。
第五个案例是复刻一个带 Editor Window 和 Agents Window 的 AI 编程工具。
它主要观察模型能否完成跨页面、跨组件和跨功能的全栈项目。
这五个案例的难度并不相同。
把它们加在一起，只能得到一个综合使用画像。
不能把总分直接理解成模型的通用排名。
SVG 案例：细节和可验证性更重要
原测试没有采用已经非常出名的“鹈鹕骑自行车”题目。
测试者改成了“画一只骑自行车送外卖的大熊猫”。
要求模型只能写 SVG 代码，不能先打开效果再修改。
据原始记录，两个模型都在 3 分钟内完成了初稿。
Claude Opus 5.5 的版本包含牙盘、链条、脚踏板和车把。
熊猫的脚放在脚踏板上，车把上还挂了一杯奶茶。
它还增加了车灯、城市背景和对话气泡。
更关键的是，原记录称这张 SVG 具备动画效果。
轮子和链条会运动，画面不只是静态轮廓。
GPT-6 Sol 的版本完成度相对较低。
这说明代码生成任务不能只看“有没有生成文件”。
还需要观察结构是否合理、元素是否对应、动画是否真的存在。
科普写作：自然不等于更准确
科普测试要求模型写约 300 字。
读者是完全不懂技术的朋友。
限制条件包括说人话、不使用书面腔、不加标题和列表。
原记录认为 Opus 5.5 的文本更像朋友解释问题。
它从 ChatGPT 和豆包等日常产品切入。
随后用“特别爱读书的学生”解释训练过程。
最后用“一个字一个字地往下接”解释生成过程。
这类比喻降低了理解门槛。
不过，科普文字仍然需要保留限制条件。
两篇文本都提醒读者，大模型可能出现编造。
这比单纯追求顺滑表达更重要。
自然的文字不能替代事实核验。
在医疗、合同、财务等场景中，模型输出仍然需要人工确认。
原记录还提到，Opus 5.5 用时约 15 秒。
GPT-6 Sol 用时约 52 秒。
这是五个案例中 Opus 5.5 唯一更快的一次。
但一次写作任务不能推导出稳定的速度优势。
如果要得出速度结论，还需要扩大样本并记录输入输出长度。
电脑操作：工具限制会改变结果
画图测试使用的是一个简易画板网页。
画板提供画笔、橡皮擦、油漆桶、直线、矩形、椭圆和吸管。
测试要求模型只能使用鼠标和键盘。
不能通过写代码直接修改画布。
Opus 5.5 在 Cursor 的内置浏览器中完成操作。
原记录显示，它前后花了约 1 小时 17 分钟。
由于拖拽行为受到浏览器工具限制，模型无法连续画线。
它把笔刷调大，然后用点击方式逐点绘制。
据记录，整个过程点击了 270 多次。
GPT-6 Sol 使用 Codex 的电脑操作能力控制真实 Chrome 浏览器。
它可以自由拖动鼠标，约 17 分钟完成。
这组结果不能简单归因于模型本身。
浏览器能力、输入设备接口和画布实现都会影响结果。
做电脑操作评测时，必须记录工具条件。
否则，模型和工具的差异会被混在一起。
成本与速度应该怎么比较
原文记录中，Opus 5.5 的五个案例累计花费超过 600 元。
GPT-6 Sol 完成整套测试所需时间约为 1 小时。
测试者还记录了 Plus 额度的消耗情况。
这些数字属于个人账号、特定任务和特定时间下的记录。
它们不能直接当作统一报价或普遍成本。
如果要复核成本，应保存以下信息：
输入 token 数量。
输出 token 数量。
工具调用次数。
重试次数。
图片或浏览器操作是否单独计费。
账号套餐和额度限制。
测试发生的日期。
只有这些信息齐全，成本比较才有可复现性。
如何根据任务选择
如果任务是一次性生成复杂项目，优先观察最终交付质量。
例如，项目需要多个窗口、终端、文件树和 Git 面板。
这类任务中，模型是否会主动验证非常关键。
如果任务是快速生成草稿，速度可能更重要。
例如，先做一个页面原型，再由开发者继续修改。
此时，较快的模型可以缩短反馈周期。
如果任务预算有限，应先设置单次调用上限。
不要因为模型更强，就把所有工作都交给它长时间运行。
更稳妥的方式是先用小任务试跑。
确认输出质量、失败率和实际费用后，再扩大任务规模。
这组测试的局限
第一，样本数量只有 5 个案例。
第二，案例主要来自个人工作流。
第三，没有公布完整提示词、日志和源码仓库。
第四，部分结果受到 Cursor、Codex 和浏览器能力影响。
第五，成本和时间记录没有经过第三方复核。
第六，模型版本和价格可能随时间变化。
因此，本文结论应理解为一组实测观察。
它适合帮助读者设计自己的测试，不适合替代正式基准。
结论
在提供的五个案例中，Claude Opus 5.5 的产出完成度更高。
GPT-6 Sol 的优势主要体现在速度、额度和成本压力较低。
如果你更在意复杂项目的最终效果，可以优先测试 Opus 5.5。
如果你更在意快速迭代和日常使用成本，可以先测试 GPT-6 Sol。
真正做选择前，最好把自己的典型任务做成一组小型回归测试。
同一套提示词、同一份输入、同一套验收标准，才有比较价值。
在官方资料和个人日志完成复核前，本文中的发布时间、价格和额度信息都应视为待核验记录。