Theo 的 AI 模型排行榜：能力、成本与编程工作流

现在有很多能力很强的模型，但一张排行榜会掩盖任务、价格、速度和行为上的重要差异。我还是要做一份，依据的是我在 2026 年 8 月自己的编程和智能体工作流程。这是个人快照，不是通用或永久的基准。

我从 GPT-5.6 Sol 开始，排行榜应用本身就是用它制作的。第一版漏掉或处理错了几个标志；我给它看截图后，它修好了。这种令人印象深刻的能力与仍需要我发现的错误并存，所以我最初把它放在 A 档。

Sol 是我处理许多长时间任务的默认选择。我曾用它在一个线程里完成 T3 Code 移动应用的 SwiftUI 重写。以我的经验，它比前代进步很大，尽管在打算合并的重要代码上，我仍有另一个更喜欢的模型。

GPT-5.6 Terra 的输出 token 单价低于 Sol，但它可能使用更多 token。在我查看的基准图表中，它的每项任务成本可以更低，有时按每美元表现也有竞争力。不过，在自己的工作流程中，我一直很难找到会选择它而非其他模型的任务。

对我而言，想节省成本时通常会选 Luna，想更快响应时会选择低推理强度的 Sol。这是对我自己用法的判断，并不能证明 Terra 没有适合的场景。随着档位增加，榜单后来也发生了变化。

GPT-5.6 Luna 因不同原因获得较高位置：它处理后台任务又快又便宜。我用它生成标题、状态和分类，把上下文转换为结构化 JSON，而不是依赖它处理重要代码修改。

Luna 可以调用工具、收集信息，但我不会在没有监督的情况下让它执行不可逆操作。它对我的价值在于低成本处理大量小型、可撤销的任务。订阅可用性和促销 API 价格都有时间限制。

DeepSeek V4 Flash 是另一个低成本选择。我讨论的是较新的快照，因为同名 V4 模型有多个行为不同的版本。它提供开放权重，只要有合适硬件，用户就可以选择自己运行。

我觉得 V4 Flash 适合摘要和后台任务，但以我的经验，它比 Luna 更容易循环或偏离方向。自己托管带来灵活性，也有硬件成本；开放权重并不意味着运行大型模型免费。

了解到我考虑的版本不支持图像输入后，我把 V4 Flash 排在 Luna 之后，因为我经常粘贴截图。我对同样缺少视觉能力的 V4 Pro 评价尤其严厉，原因是它的规模和价格。可用性与多模态支持取决于具体版本和端点。

Kimi K3 让我印象深刻：它是一个能够处理较长、多步骤工作和视觉任务的开放权重模型。我喜欢它的一些设计和 3D 结果。我把它放在 B 档前列而不是 Sol 之上，主要因为它在我的工作流中实际成本比许多人预期的高。

开放权重模型不一定便宜好托管。我比较自己使用的设置时，K3 的每项任务成本可能高于 xhigh 设置的 Sol，尽管其标称 token 单价更低。结果取决于供应商价格、输出长度、推理强度和任务。

我展示的 OpenRouter 价格中，当时许多供应商的输入价格集中在每百万 token 3 美元、输出价格为 15 美元，也有例外。我推测托管经济因素和许可可能是原因，但我没有证实供应商私下协议的条款，因此这只是解释，并非调查结论。

我仍然认可 K3 推动了开放权重模型的能力。但在日常工作中，成本和行为让我通常回到 Sol。应当根据预期部署检查具体价格、许可和可用模型快照。

以我的经验，GLM-5.3 比 5.2 有进步：它更能专注任务，循环更少。尽管如此，我还是不常选它，而我讨论的版本没有视觉能力，降低了它在我榜单上的位置。这里指的是 GLM-5.3，不是后来推出的 Flash 模型。

Cursor 的 Composer 2.5 在技术上令人印象深刻，尤其是速度，但我并不经常使用它。我在视频中更正了自己：Composer 2 和 2.5 都基于 Kimi K2.5。可用范围有限，以及宣传中的快速版本与便宜的慢速版本之间的差异，都影响了我的排名。

Grok 4.6 能编排多个任务，以我的经验在某些方面比 4.5 有进步。但它使用更多 token、感觉更慢，削弱了前代对我的速度吸引力。我把它放在 C 档附近，仍可能用它处理助手类工作。

Muse Spark 对我来说也在 C 档附近。我不如喜欢 Grok 的代码那样喜欢它的代码，但我发现它整理 PR 很快。它的低价贡献者选项涉及数据用于训练，因此需要同时考虑价格和数据条款。

我对榜单中的 Gemini 模型评价更负面。我过去很看重 Gemini 2.0 Flash 的低成本、速度和多模态输入，但对于我评估的任务和价格，我觉得后续版本吸引力下降了。这是我的判断，并不是说它们在任何场景都没有用。

我的成本论点不仅涉及每个 token 的价格。推理也可能增加输出 token 数量。即使 token 单价低，如果一个模型产生的文本或推理远多于另一个模型，它完成每项任务仍可能更贵。

视频展示了 Gemini 3.7 Flash 的介绍期价格，以及折扣结束时间。这些是录制时画面上的历史数字，并不是当前报价。做决策前应查看供应商最新的价格和条款。

Gemini 3.1 Pro 在我自己的 Skatebench 上表现不错，也曾有用处很大的视觉能力，尽管我不喜欢它作为智能体的行为。这说明一个排名无法概括所有长处：模型可能熟悉某个主题，却仍让特定工作流程很不顺手。

当模型完成同一任务所需的 token 数量不同时，每秒 token 数也可能误导人。我更愿意比较实际工作的耗时、质量和总成本，而不是假设 token 流最快的模型一定最先完成。

在画面所示的 DeepSWE 图表中，Sol 在 high 推理强度下每项任务约使用 28,000 个输出 token，max 则约 60,000 个，而得分差距较小。我检查的 Gemini 配置在该基准中使用更多 token。这些只对应具体测试设置，并不保证所有工作负载都有同样表现。

Sonnet 5 在我的 Claude Code 订阅内有有限用途，包括一些带视觉功能的小型子智能体实验。针对我的任务，我觉得它的 API 价格缺乏吸引力，因此排得较低。订阅和 API 的经济性可能带来不同选择。

Opus 5 最初凭借详细计划和有用观察让我印象深刻。后来我合并它写的代码时，体验就没有那么好了：我发现自信、复杂的表述并不总能转化成我想发布的代码。我根据这段经验把它放在 D 档。

Fable 5 在我的榜单上位居最高档。它并不完美：有时会走捷径、失去任务脉络或碰触我不希望修改的内容。但在我使用过的模型中，它为我提供了最好的代码和困难问题上的帮助。

Sol 仍然是我的日常默认选择。如果只能留一个，我说过我会更想念 Sol，尽管在重要代码质量和深入讨论上我把 Fable 排得更高。默认偏好和最强专长之间的区别很难用一张榜单表达。

Fable 的访问限制和拒答让我沮丧，但我足够重视它，因此维持多个订阅。以我自己的用量，我不会支付它完整的 API 价格；我的偏好部分取决于订阅的经济性。我对未发布内部模型的猜测并未得到证实。

各档之间的差距并不相等。使用 K3、Luna 和 V4 Flash 等模型时，我通常更贴近任务，并在工作推进时审阅。使用 Sol 和 Fable 时，只要有验证与审查，我更愿意给出范围较宽的请求。

Fable 往往更能理解我的意图，产出的代码也更让我愿意合并；Sol 工作细致，对我来说更容易引导，而且我发现它在 iOS 工作上更强。这些是我在自己项目中的观察，不代表每个人都会得到同样结果。

重要工作中我大多使用 Fable 和 Sol，特定后台任务则使用较便宜的模型。合适的选择取决于工作负载、可用工具、隐私要求、速度和每次结果的成本。模型和价格都会变化，所以应把这份榜单看作我在当时的体验记录。