Kimi K2.5 对比 Opus：一次充满希望的评测
摘要
本文作者对比评测了 Kimi K2.5 和 Opus 在编码任务上的表现。在构建一个 Next.js 地球查看器应用时，Kimi K2.5 在初始构建阶段表现接近，但需要更多文件修改和修复时间；而在添加身份验证、PostHog 集成等复杂功能时，Opus 表现出更强的端到端处理能力和稳定性，Kimi K2.5 则遇到了困难。尽管如此，作者认为 Kimi K2.5 对于许多中等难度编码任务和非编码任务而言已足够优秀且成本更低，是构建 Agentic 产品的理想选择。
正文
我一直在将 Opus 用于几乎所有的代码相关工作，而 Kimi 则用于其他所有事情，从写作到头脑风暴。坦白说，Kimi 是情商最高的模型。
本月初的发布公告引起了不小的轰动。它在多项任务上击败了前沿模型，同时成本却低得多。所以，我想知道我是否可以用 Kimi K2.5 完全取代 Opus，这样可以省很多钱，哈哈。我不做硬核的东西；任何能以远低于 Opus 的成本解决中等难度编码任务的模型都受欢迎。
我尝试过 Deepseek v3 special，它很不错，但还没达到我的期望。
所以，这是我的发现。
代码库 + 任务
我创建了一个 Next.js Web 应用，一个使用 Cesium 的类似 Google Earth 的地球查看器。两个模型都从同一个干净的提交开始，并接收了相同的提示。
任务 1 是构建实际的地球应用（Cesium 地球、平移/缩放/旋转、底图层和基本 UI）。任务 2 是真正的考验：添加身份验证，通过 Composio 连接 PostHog（我想测试我们新的 PostHog 集成），在登录后捕获用户位置，然后在单击时显示带有姓名/电子邮件的活动用户标记在地球上。
两个模型都使用了 Claude Code 环境。
结果
任务 1（地球构建）： 两者都接近完成；都需要一次修复。
- Kimi-K2.5： 约 29 分钟 + 9 分 43 秒修复，15.9k 输出 token，429 个文件更改
- Opus 4.5： 约 23 分钟 + 约 7 分钟修复，22 个文件更改（此运行未提供 细分）
任务 2（身份验证 + Composio + PostHog）：
Kimi 首先尝试在浏览器中运行一个仅服务器的包，导致身份验证失败。然后它尝试了 NextAuth，结果也搞砸了。修复循环只是让事情变得更糟，并且输出混乱。与此同时，Opus 顺利地完成了端到端的整个流程，并且有效。这是预料之中的。
- Kimi-K2.5： 约 18 分钟 + 5 分 2 秒 + 1 分 3 秒修复，24.3k 输出 token，21 个文件更改
- Opus 4.5： 40+ 分钟，21.6k 输出 token，6 个文件更改
我在博客中提供了演示、提示和 .patch 文件，以便您可以本地应用确切的更改并自行判断：Kimi K2.5 vs. Opus 4.5: David vs. Goliath
就代码质量和输出而言，我知道答案；将这两个模型放在一起比较甚至有点不公平。但是 Kimi k2.5 实际上足以应对许多任务。它绝对优于 Sonnet，并且非常适合那些成本是考量因素的其他非编码任务。我非常确定这是目前构建 Agentic 产品的最佳模型。
我很想听听您使用 Kimi K2.5 构建的经验，任何能充分发挥其潜力的技巧和窍门都欢迎。我想取消我的 Max 订阅，哈哈。