00:00:00大多数 AI 编程模型的共同痛点就是——它们完全搞不定 Swift。
00:00:06我们都见过那些惊艳的演示：AI 助手能在几秒钟内构建网页应用和 JavaScript 工具，
00:00:11但一旦涉及 Swift 代码，一切就迅速崩盘了。
00:00:16究竟为什么全球最聪明的模型会在 iOS 开发上栽跟头呢？
00:00:22这就是我们今天视频要探寻的主题。
00:00:25今天，我将让顶尖的编程助手接受同一项 Swift 应用编程挑战，看看
00:00:30哪些模型能真正胜任，而哪些只是徒有其名的“网页开发单面手”。
00:00:36先剧透一下——其中一个模型竟然完美通过了测试。
00:00:40到底是哪一个，稍后在视频中见分晓。
00:00:43这会很有趣，让我们开始吧。
00:00:50首先，我们来分析一下核心问题。
00:00:52为什么 AI 编程模型在 Swift 开发方面表现不佳？
00:00:56明确一点，这不只是我的个人观察。
00:00:59一项名为《评估大语言模型的代码生成能力——对比研究》的课题，
00:01:05针对 Python、Java 和 Swift 进行了测试，发现包括 GPT 和 Claude 在内的所有模型，
00:01:12在 Swift 上的表现始终低于 Python 或 Java。
00:01:17究其原因，主要有三大瓶颈，在 AI 触及苹果生态时限制了其发挥。
00:01:24首先是数据鸿沟。
00:01:25网络上充斥着开源的 JavaScript 和 Python 代码，但大量专业的
00:01:31Swift 代码都保存在私有或商业库中，秘不外宣。
00:01:36其次是 API 迭代过快。
00:01:38苹果以快速更新和推倒重来著称。
00:01:42SwiftUI 和 Swift 的并发模型在过去三年里的变化，比某些
00:01:47网页标准在十年里的变化还要大。
00:01:49由于大多数 AI 模型都有知识截止日期，它们往往会尝试用
00:01:54过时的规则编写 Swift 代码，这在最新版本的 Xcode 中根本无法运行。
00:01:59最后是基准测试偏向。
00:02:02我们今天测试的大多数模型，如通义千问（Qwen）或 Grok，都是针对特定测试进行训练的。
00:02:08它们被优化以通过像 HumanEval 这样的大型基准测试，而这些测试几乎完全侧重于
00:02:13Python 和基于网页的逻辑。
00:02:16由于缺乏针对复杂 iOS UI 的主流基准测试，这些模型
00:02:21在构建功能性应用的能力上并没有得到充分磨练。
00:02:25于是，我挑选了一些市面上最热门的 AI 编程模型，并给它们
00:02:30发送了完全相同的提示词。
00:02:32我要求它们使用 Swift 构建一个类似 Tinder 的简单应用，名叫 Dogtinder，
00:02:38在应用中会通过 Dog CEO API 展示不同的狗狗。
00:02:43你可以左右滑动来选择喜欢的狗狗，如果有匹配，
00:02:47就可以打开聊天界面，与匹配的狗狗交换有趣的私信。
00:02:52这个应用既可爱又足够简单，理论上助手可以完成，但也包含一些
00:02:58有趣的挑战，比如在原生 Swift 中实现滑动动画功能。
00:03:03测试过程我们将从表现最差的模型开始，一直排到最优秀的模型。
00:03:09排名垫底的是新款 Qwen 3 Coder Next 模型。
00:03:15通义千问一直宣传该模型是 Kimi 或 Claude 等重量级产品的开源替代品，
00:03:20模型尺寸更小但性能更强。
00:03:25虽然这在网页应用上可能是真的，但可惜在 Swift 挑战赛中它并没撑住。
00:03:32我尽可能地使用了该模型自带的 CLI 工具，
00:03:37在这个案例中，我使用 Qwen CLI 工具来执行挑战。
00:03:42生成代码后，我根本无法打开 Qwen
00:03:46生成的项目文件。
00:03:48于是我提示它修复尝试打开文件时出现的错误。
00:03:53但即便如此，Qwen 还是无法修复错误，反而给了我一份长长的自述文件，
00:03:58教我如何从头开始手动构建项目，然后将文件复制到
00:04:03项目文件夹中。我不想在这项挑战中手动操作，
00:04:08因为那会违背测试初衷。
00:04:09稍后你会看到，我注意到一些模型很难生成
00:04:14最终的完整项目文件集，以便我们能一次性成功打开。
00:04:20所以对于像 Qwen 这样的情况，我决定给它一个更简单的挑战。
00:04:26我手动创建了一个新的 iOS 应用项目，并认为现在是
00:04:31尝试 Xcode 最新版本内置的编程智能功能的好时机。
00:04:38这非常酷，因为 Xcode 终于有了自己的 AI 助手功能。
00:04:43我把它连接到我的 OpenRouter 账户，从下拉菜单中选择了 Qwen 3 Coder Next 模型，
00:04:49再次尝试挑战。
00:04:52即便有这么多辅助，Qwen 依然无法在第一次尝试中生成成功的项目，
00:04:57因为它在准确设置 Swift 模型方面遇到了一些问题。
00:05:02现在利用新的 AI 助手功能，我们可以高亮所有这些问题，
00:05:07然后让助手一次性生成所有选中问题的修复方案。
00:05:12最终，经过几轮提示让 Qwen 修复剩余问题后，我们终于
00:05:16得到了一个能运行的 Dogtinder 应用，但老实说，效果很差。
00:05:23它甚至无法从 Dog CEO API 加载图片，整个 UI 也非常
00:05:29原始且毫无吸引力。
00:05:32更不用说匹配部分还有一个漏洞，导致所有的匹配项
00:05:36都没有显示出来。
00:05:37所以遗憾的是，Qwen 完全没能通过 Xcode 应用挑战赛。
00:05:42接着是倒数第二名，Grok 的 Grok-Code-Fast 模型。
00:05:48这个模型我尝试通过 VS Code 上的 VS Copilot 扩展来使用，结果
00:05:53再次遇到了同样的问题：Grok 无法生成完整 Swift 项目包所需的
00:05:59所有项目文件。
00:06:02相反，它只给了我手动复制文件的说明。
00:06:06因此，我不得不再次回到 Xcode 的 AI 助手，通过 OpenRouter
00:06:12调用 Grok 模型。
00:06:14Grok 也遇到了一些问题，所以我不得不提示它两次来修复剩余的
00:06:19错误。
00:06:20但在那之后，它成功完成了应用。
00:06:23乍看之下，Grok 的设计做得非常糟糕。
00:06:27设计毫无新意，甚至没有
00:06:32查看匹配项的版块。
00:06:33我把 Grok 排在 Qwen 前面的唯一原因是，至少从功能角度看，
00:06:38一切都在运行，包括聊天功能。但坦白说，它们
00:06:44的表现同样糟糕，不相上下。
00:06:48这个应用没有任何吸引人或美观的地方。
00:06:51我不会说 Grok 挑战失败了，但它拿到的分数绝对是及格线边缘。
00:06:58排行榜的下一位是 Kimi 的最新款 Kimi K2.5 模型。
00:07:04Kimi 遇到了和 Qwen 同样的问题：使用原生 CLI 时虽然生成了
00:07:08项目文件，但我无法打开。
00:07:11即使通过 CLI 修复，问题依然存在。
00:07:15所以我再次在 Kimi 的测试中使用了内置的 Xcode AI 助手功能，
00:07:20由 OpenRouter 提供 Kimi K2 支持。
00:07:23Kimi 的表现与 Qwen 和 Grok 类似，因为第一次尝试也没能完成
00:07:29挑战。
00:07:31我不得不再次提示它修复剩余问题。
00:07:34但仅经过一轮修复，Kimi 就拿出了最终结果。
00:07:39这个版本比 Qwen 和 Grok 有了明显进步，至少我们得到了一个
00:07:44看起来真像 Tinder 的应用。
00:07:47它现在有了不错的左右滑动动画，以及侧面的“喜欢”和“没兴趣”标签，
00:07:53匹配时还有一个华丽的弹窗。
00:07:57但动画非常不稳定，有很多 Bug。
00:08:00有时候我甚至看不到图片，因为它漂浮在屏幕外。
00:08:05但至少 Kimi 能够正确存储匹配项。
00:08:08我们确实有了一个可以查看匹配项的版块，并能打开其中任何一个
00:08:12开始与特定的狗狗聊天。
00:08:14所以这比 Qwen 和 Grok 进了一大步。
00:08:18但如果与稍后在视频中看到的其他示例相比，我认为
00:08:22这仍然是一个平庸的结果。
00:08:25这就是为什么我把 Kimi 排在较低的位置。
00:08:29接下来是 Gemini 3 Pro。
00:08:31这很有意思，因为同一个模型在自带 CLI 和在
00:08:36Xcode AI 助手上的表现完全不同。
00:08:41先来看看使用 Gemini CLI 的结果。
00:08:45CLI 显示该模型仍处于预览模式。
00:08:49也许这就是核心问题所在。
00:08:50再次强调，当我使用给所有模型的相同提示词时，
00:08:55它最终没能给我项目文件。
00:08:59这是因为要创建 Xcode 项目文件，你必须先创建一个包含项目详情的 YAML
00:09:04文件，然后运行 CodeGen CLI 命令来生成。
00:09:09但出于某种原因，有些模型拒绝这样做或不知道该怎么做。
00:09:14不过，当我专门提示 Gemini 创建该文件时，它照办了。
00:09:18我只需要给它执行 CodeGen 命令的权限。
00:09:22打开项目后，出现了一个资源错误。
00:09:25但 Gemini 很快就修复了。
00:09:28解决之后，应用终于可以编译了。
00:09:31但结果出奇地糟糕，令人惊讶。
00:09:35它是崩坏的。
00:09:37匹配系统无法正常工作，到处都是 Bug。
00:09:41到这一步，我都打算给 Gemini 一个不及格了。
00:09:45但出于好奇，我决定再给 Gemini 一次机会，利用
00:09:50Xcode 原生 AI 助手运行通过 OpenRouter 调用的 Gemini 3 Pro 再次测试。
00:09:56结果这一次，它第一次尝试就成功了。
00:10:01不仅如此，应用还做得惊人地出色。
00:10:04我是说，设计非常棒。
00:10:06功能也全部到位。
00:10:08它甚至在顶部加了一个漂亮的小图标。
00:10:10老实说，这个版本的应用挑不出任何毛病。
00:10:14我很纳闷，为什么同一个模型的同一个提示词，通过
00:10:20不同的 AI 编程工具会产生如此截然不同的结果。
00:10:24但无论如何，Gemini 通过 Xcode 工具给出的版本让我印象深刻，
00:10:29而且我必须强调，是一次性生成的。
00:10:32因此我把 Gemini 的排名往上提了提，因为最终结果
00:10:37确实非常棒。
00:10:38好，接下来是排行榜第二名，GPT 5.3 Codecs。
00:10:43既然 OpenAI 有自家的 Codecs 应用，我决定在
00:10:48他们的应用里进行挑战。
00:10:49与之前看到的模型不同，GPT 5.3 确实能够
00:10:55在第一次尝试时就生成最终的成品。
00:10:58这已经是一个巨大的跨越。
00:11:00但我得说，应用本身并不怎么令人兴奋。
00:11:03它采用了非常单调的蓝色主题。
00:11:06最令我困扰的问题是，它无法让图片宽度自适应
00:11:11应用的边框。
00:11:13导致某些狗狗的图片容器过度拉伸，超出了
00:11:18应用的边界。
00:11:20这是 Codecs 无法正确处理的一个重大设计缺陷。
00:11:25但应用本身功能齐全，具备所有必要的 UI 元素。
00:11:29匹配版块也能正常运行，我们可以和狗狗聊天。
00:11:34我之所以给 GPT 5.3 这么高的排名，是因为它是
00:11:40第一个能在没有任何辅助、且无需预先设置 Xcode 项目的情况下，
00:11:46生成完整 Swift 项目包的模型。
00:11:50总体来看还不赖，但也不够出彩。
00:11:54最后，我们来看排行榜的第一名。
00:11:57我先给大家留点时间猜猜会是哪个模型。
00:12:01没错，我想大家都心里有数。
00:12:04当然是 Opus 4.6，它首轮就完美通过了挑战。
00:12:11我使用了与其他模型相同的提示词，但用的是他们自家的 Claude Code CLI
00:12:17工具，我只需要提供必要的权限。
00:12:20模型自动完成了一切，包括创建一个功能齐全的 Xcode 项目文件，
00:12:27完全不需要我预先设置。
00:12:29不仅如此，应用本身非常精美。
00:12:34设计感十足。
00:12:35动画流畅且自然。
00:12:37匹配版块和聊天窗口也都能正常工作。
00:12:41唯一缺少的只是像 Gemini 在前几个版本中生成的
00:12:46那种华丽图标。
00:12:48除此之外，这是所有版本中最漂亮的一个。
00:12:52而且它也是一次性生成的。
00:12:55所以我认为 Opus 的表现远超其他所有模型。
00:13:01它绝对实至名归，稳坐排行榜首位。
00:13:05等等，还没完。
00:13:07给大家准备了一个小福利。
00:13:09还有一个模型需要测评，它还没出现在
00:13:13排行榜上。
00:13:14就在我制作视频时，GLM 宣布发布了
00:13:18最新的 5 号模型，而且他们大胆宣称，这个模型在
00:13:23编程方面的得分甚至超过了 Opus 4.6。
00:13:26显然，我必须在同一个 Swift 挑战赛上对它进行测试。
00:13:31由于 GLM 没有自家的 CLI 工具，我再次通过 OpenRouter 连接 GLM 5，
00:13:37使用了 Xcode 的 AI 助手工具。
00:13:41首先，GLM 没有在第一次尝试中完成挑战。
00:13:45这就已经说明它的表现不如 Opus 4.6 了。
00:13:49其次，我经历了三轮 Bug 修复才终于让它成功编译。
00:13:56让我们看看 GLM 5 的最终结果。
00:13:59如你所见，在我看来这已经是不及格了。
00:14:03它似乎无法加载任何狗狗图片。
00:14:06没有滑动功能。
00:14:08更糟的是，它只循环显示了三只狗，然后就提示
00:14:13没有更多狗狗了。
00:14:15此外，在匹配版块，无法点击任何匹配项来
00:14:20打开与狗狗的聊天界面。
00:14:23显然，这一部分还没完工。
00:14:25根据这个结果，我们要把 GLM 排在什么位置呢？
00:14:29恐怕只能把它排在倒数第二，仅略高于 Qwen，
00:14:36因为这种表现完全无法接受，远不如其他模型。
00:14:42所以说 GLM 5 比 Opus 4.6 强，是一个相当大胆的说法。
00:14:47虽然我还没在其他编程任务上测试过这个模型，
00:14:52也许对于简单的网页开发项目，它的表现能和 Opus 4.6
00:14:57持平甚至更好。
00:14:59但它绝对不是一个适合 Swift 编程的模型。
00:15:02那么我们今天学到了什么？
00:15:04显然，虽然 AI 革命正以光速前进，但 Swift 问题对于这些模型而言
00:15:10依然严峻。Opus 4.6 和 GPT 5.3 证明了如果模型足够大、推理能力
00:15:18足够强，就能克服开源 Swift 代码数据的匮乏。
00:15:23但对于 Qwen 和 Grok 这样的模型，之前提到的数据鸿沟和
00:15:29API 迭代对它们的打击显然很大。
00:15:31我也很惊讶 Xcode 新的 AI 助手对 Swift 应用开发竟然如此有帮助。
00:15:36这在 Gemini 两个应用版本的差异中可见一斑。
00:15:40所以如果你是 iOS 开发者，使用苹果内部的 AI 工具
00:15:46可能会得到更好的结果。
00:15:47以上就是全部内容，希望你们喜欢这次排行榜解析。
00:15:51我认为这引发了一个更广泛的讨论：也许我们
00:15:55应该开始拥有特定语言的模型。
00:15:57因为显然很多模型更倾向于网页应用、JavaScript
00:16:03或 Python 项目。
00:16:04但对于一些特定的编程方案，我们可能需要定制化的编程模型。
00:16:09你对此有什么看法？
00:16:11请在下方评论区告诉我们。
00:16:13朋友们，如果你喜欢这个视频，请点击视频下方的
00:16:18点赞按钮让我知道。
00:16:19也不要忘记订阅我们的频道。
00:16:22我是来自 Better Stack 的 Andris，我们下个视频再见。