00:00:00本月初，阿里巴巴发布了 Qwen 3.5，包含一个 4000 亿参数的模型以及
00:00:05一个“最大思考版”，声称其基准测试表现优于 Opus 4.5，但对
00:00:11本地运行的配置要求非常高。
00:00:12但就在本周，他们发布了 Qwen 3.5 中型系列模型，其性能
00:00:17几乎与最大版一样强大，并能在现代 MacBook Pro 上本地运行，同时声称
00:00:22基准测试也优于 Sonnet 4.5。对此我深表怀疑，所以请点击订阅，
00:00:27让我们对这两个模型进行实测。
00:00:31大多数开发者都会承认 Sonnet 4.5 是一款出色的模型，与 Claude
00:00:35Code、Co-Work 以及整个 Anthropic 套件配合得天衣无缝，体验非常高级。
00:00:40但你必须在线才能使用这些模型，而且价格并不便宜。
00:00:44Qwen 3.5 的中型系列旨在改变现状，让在本地运行
00:00:49与 Sonnet 4.5 一样出色的模型成为可能，推特上的网友都炸锅了。
00:00:54但我并不确信它真的能和 Sonnet 4.5 媲美。
00:00:58因此，我将针对简单、中等和困难任务对这两个模型进行测试，看看
00:01:02哪一个表现更好。
00:01:04但在开始测试之前，我得先坦白一件事。
00:01:07我实际上不会在本地运行 Qwen 3.5，因为我那台可怜的 M1 MacBook Pro
00:01:12没有足够的统一内存来正常进行推理。
00:01:15所以我将在 OpenRouter 上使用连接到 OpenCode 的 Qwen 3.5 35b，
00:01:21而在 Claude Code 中以“纯净模式”运行 Sonnet 4.5，这样它就不会使用我的
00:01:25任何技能、插件或 MCP 工具。
00:01:27我们先从简单的开始，让模型使用 React 和 Vite 从头构建一个待办事项列表。
00:01:32如果我们看 Sonnet 4.5 的成果，可以看到它采用了标志性的“AI 紫色”。
00:01:36我可以添加待办事项，也可以标记为已完成。我有清除功能，
00:01:40而且如果我刷新页面，内容依然存在，因为它使用了本地存储 (local storage)。
00:01:44再看 Qwen 3.5，两者的风格相似，都没有覆盖
00:01:48Vite 默认自带的样式。
00:01:51但同样，我可以添加待办事项。
00:01:53这里我们还有一些其他选项。
00:01:54我们可以选择它所属的类别，可以选择……我想应该是严重程度，
00:01:59或许还有一个待办日期或截止日期。
00:02:02我可以输入“去购物”，它会显示日期、严重程度和
00:02:06所属类别，这真的很酷。
00:02:08让我们来看看代码。
00:02:09这是 Sonnet 的代码。在这里，它使用了 useEffect，我想是为了处理
00:02:13下面的本地存储。
00:02:15我觉得还行，但我更倾向于用另一种方式来实现。
00:02:17这里使用了 add to-do 函数，这边还有一些执行操作的函数。
00:02:22比如切换状态 (toggle)、删除 (delete)。
00:02:25这些看起来都很棒。
00:02:26有一点让我比较惊讶的是上面提到 JSON 解析的部分。
00:02:32它似乎是把数据作为 JSON 保存到本地存储然后再解析。
00:02:35如果能把这段代码放在一个独立的函数里会更好，这样如果你想
00:02:38添加更多功能，就不会让顶部的代码显得太乱。
00:02:42现在看 Qwen，它有一些类别，看起来没用到 useEffect，
00:02:46这很好。
00:02:48往下翻，我们看到了 handle submit，这是我更喜欢的命名方式。
00:02:51还有 handle updates、handle delete 以及 handle toggle completed。
00:02:55我非常喜欢的一点是，它把待办事项放在了一个独立的组件里。
00:02:59它没有弄乱主组件（即主待办应用组件），而是创建了
00:03:03一个新组件，并在下面的 App 部分调用，因为会有多个
00:03:07待办事项。
00:03:08所以这一局 Qwen 胜出，因为它生成的待办列表功能多得多。
00:03:13但在运行完这些测试后，我意识到 Qwen 在 OpenCode 中
00:03:18启用了“超级大招”技能。
00:03:19于是我在关闭该技能的情况下又测了一次，结果如下。
00:03:23所以我觉得这局应该算 Sonnet 赢。
00:03:25让我们进入第二个测试：使用 React、Vite 和 Three.js
00:03:29构建一个交互式太阳系。
00:03:31Claude 仅用一次尝试就完成得好得多。
00:03:33好吧，虽然漏掉了几颗行星，但我可以点击已有的那些。
00:03:37点击太阳，会显示相关信息。
00:03:39点击下面的天王星，也会显示相关信息。
00:03:44网站的交互动作也非常流畅，我可以平移、旋转、放大缩小
00:03:48等等。
00:03:49而这是 Qwen 生成的。
00:03:50没错，一个白板。
00:03:51如果看控制台，可以看到这里有一个报错，我多次把错误发给 Qwen，
00:03:56但它都没能解决。
00:03:58事实上，整个创建过程非常繁琐。
00:04:01Qwen 中途“罢工”了好几次，我不得不重新唤醒它，而且它在反复尝试
00:04:05修复错误时显得非常吃力。
00:04:06更不用说，看看 Qwen 生成的文件，这里有一个 package.json，
00:04:10一个 package-lock 和一个 node_modules 目录，但完全没被用到，因为
00:04:15主项目在 solar-system 目录下，那里有专门的 package.json
00:04:20和 node_modules 目录。
00:04:21所以，第二个测试也是 Claude 获胜。
00:04:23在最后的测试中，我让这些模型修改现有的代码库，以便在用户
00:04:28在应用内粘贴 URL 时，能截取推文的截图。
00:04:32先看 Claude，它生成了这里的屏幕页面。
00:04:35给了我更改背景和边距 (padding) 的选项。
00:04:38第一次运行的时候确实报错了，但我让 Claude 修复了它。
00:04:42我要复制这条 JSON 推文的 URL，粘贴进去，然后点击“捕捉”。
00:04:47几秒钟后，我们在下面得到了图片，并有下载选项。
00:04:51这是 Qwen 的结果，也有一个屏幕页面。
00:04:54同样，我要复制这条推文并粘贴。
00:04:56它写的是“提取视频”而不是“提取截图”，然后开始捕捉，看起来有戏。
00:05:01但过了一会儿，出现了 60 秒超时，这和我们之前
00:05:06在 Sonnet 上遇到的错误类似。
00:05:07我让 Qwen 修复，它确实延长了超时时间，但并没能修复
00:05:11导致问题的根本原因。
00:05:13所以看起来 Sonnet 4.5 在三项测试中完胜。
00:05:17因此，尽管从纸面上看 Qwen 3.5/35b 应该优于 Sonnet 4.5，但在现实世界的测试中，
00:05:24情况似乎并非如此。
00:05:26别误会，能在现代 MacBook 上本地运行一个 350 亿甚至 270 亿
00:05:31参数的模型，确实令人印象深刻。
00:05:34但无论推特上的人怎么吹，在编程任务上，它绝不可能
00:05:38超过 Sonnet 4.5，正如你从我刚才的测试中看到的那样。
00:05:42那为什么基准测试会让它看起来这么强呢？
00:05:45很有可能 Qwen 3.5 在后期训练中针对特定的基准测试问题
00:05:51（如 Swee-bench verified）进行了优化，以便在这些题目上取得高分。
00:05:55而像 Sonnet 4.5 这样的模型则会在更广泛、更稳健的数据集上进行后训练，
00:06:01使其能够处理更细微、复杂的任务。
00:06:03更不用说，我测试的 Qwen 模型虽然有 350 亿参数，但在推理过程中
00:06:08只使用了 30 亿。
00:06:09相比之下，虽然 Anthropic 没有公布数据，但据估算，
00:06:14Sonnet 3 的训练参数可能就有 700 亿，毫无疑问，Sonnet 4.5
00:06:18的参数量会大得多。
00:06:19因此，仅凭基准测试来比较这些模型并不公平。
00:06:23做自己的调研并运行自己的评估总是很重要的。
00:06:26我的意思是，Qwen 3.5 没有被列入 OpenCode Go 的模型名单是有原因的。
00:06:31既然说到 Qwen，他们的 TTS 模型最近也发布了，Joss
00:06:35拍了一个很棒的视频，介绍了它的语音克隆、情感表达等功能，
00:06:39你可以在这里查看。