标题：说实话，kimi-k3 的代码能力比我预期强——我拿 40 道 LeetCode Hard + 多维度横评跑了三模型对比，有一类多文件重构任务排名和官方宣传完全反过来

正文：
上周 Kimi K3 正式发布，HN 热度冲到 287+，我朋友圈被刷屏了。正好手头有个 side project 需要选模型做代码生成，我就顺手把 moonshotai/kimi-k3、openai/gpt-5.5、anthropic/claude-opus-4.8 三个拉出来跑了一轮。结论先放这儿：LeetCode Hard 通过率 claude-opus-4.8 最高（82.5%），kimi-k3 紧随其后（77.5%）；但多文件重构任务 kimi-k3 与 claude-opus-4.8 并列第一，gpt-5.5 垫底——这和月之暗面官方宣传的侧重点完全反过来。

说明：moonshotai/kimi-k3 为本次测试使用的 model ID，读者使用前建议以 Moonshot AI 官方文档为准确认该标识符是否有效。

测完数据确实出乎意料，下面展开说。

评测维度

不搞"综合打分 8.5/10"的玄学评测，锁定四个可量化、可复现的指标：

维度	具体方法	为什么选这个
LeetCode Hard 通过率	40 道 Hard 题，zero-shot，提交到 LC 判定 AC	算法推理硬指标
多文件重构正确率	5 个开源项目片段（3–7 文件），给重构指令，跑测试	真实工程能力
长上下文召回率	在 60K token 上下文中插入 25 个"针"（分 5 组，每组 5 个关键信息点），问答验证	大项目必备
首 token 延迟（P50/P95）	同一 prompt 各跑 20 次取中位数和 95 分位	交互体验

测试环境统一走的 API 网关（ofox和OpenRouter 都能跑，两者手续费结构不同，具体比例建议以各平台官方文档为准）。披露：作者与该平台无商业合作关系，仅因其统一 API 格式方便横评而使用。

调用方式

三个模型统一用 OpenAI SDK 格式：

from openai import OpenAI
client = OpenAI(
    api_key="your-ofox-key",
    base_url="https://api.ofox.io/v1"
)

切模型只改 model 参数：

# Kimi K3
model = "kimi-k3"
# GPT-5.5
model = "gpt-5.5"
# Claude Opus 4.8
model = "claude-opus-4.8"

不用装三套 SDK，一个 Key 切三个模型。

评测结果

总览表

指标	kimi-k3	gpt-5.5	claude-opus-4.8	备注
LeetCode Hard 通过率	77.5%（31/40）	75.0%（30/40）	82.5%（33/40）	zero-shot，无 system prompt 引导
多文件重构正确率	80%（4/5）	60%（3/5）	80%（4/5）	kimi-k3 与 opus-4.8 并列第一，k3 改动范围更小
长上下文召回率（60K）	72%（18/25）	88%（22/25）	84%（21/25）	gpt-5.5 长上下文能力最强
首 token 延迟 P50	380ms	620ms	540ms	香港节点测试，客户端位于华南，prompt 约 200 token
首 token 延迟 P95	520ms	1100ms	780ms	gpt-5.5 的 P95 波动较大

graph TD
    A[横评：40道LeetCode Hard + 多维度] --> B[LeetCode Hard 40题]
    A --> C[多文件重构 5项目]
    A --> D[长上下文召回 60K]
    A --> E[首token延迟 20次]
    B --> B1[claude-opus-4.8: 82.5%]
    B --> B2[kimi-k3: 77.5%]
    B --> B3[gpt-5.5: 75.0%]
    C --> C1[kimi-k3: 80% 并列第一，改动最精准]
    C --> C2[claude-opus-4.8: 80% 并列第一]
    C --> C3[gpt-5.5: 60%]
    D --> D1[gpt-5.5: 88%]
    D --> D2[claude-opus-4.8: 84%]
    D --> D3[kimi-k3: 72%]

LeetCode Hard

claude-opus-4.8 在算法题上表现最稳。33/40 的通过率，错的 7 道里有 3 道是超时（逻辑对但复杂度没优化到位），4 道是逻辑错误。

kimi-k3 让我意外的是，它在图论和动态规划类题目上几乎和 opus-4.8 持平——31 道 AC 里有 12 道是 DP 题（本次测试集共含 DP 题约 18 道），全部一次通过。失败的 9 道集中在字符串和位运算，推测它对这类 trick 题的覆盖相对有限，但这只是推测，不排除其他原因。

gpt-5.5 是三者中最不稳定的。有些题给出的解法非常简洁，但也有几道题直接幻觉了一个不存在的 API，导致编译失败。

多文件重构（最反直觉的结果）

这是最值得聊的部分。我准备了 5 个真实项目片段：

1. Flask 项目拆分 Blueprint（3 文件）
2. React 组件抽取公共 Hook（4 文件）
3. Go 项目接口抽象重构（5 文件）
4. Python 数据管道重构为 DAG（7 文件）
5. TypeScript monorepo 共享类型提取（6 文件）

kimi-k3 在第 4、5 题上的表现值得关注。它不光改对了，而且改动范围最小——只动了该动的地方，import 路径全部正确，没有过度重构。opus-4.8 也做对了，但它倾向于"顺手"多改几处它认为可以优化的地方，导致有一处引入了新的循环依赖。

gpt-5.5 在多文件任务上翻车最严重。第 3 题（Go 接口抽象）生成了一个不存在的 interface 方法签名，测试直接编译失败；第 5 题漏掉了一个文件的 import 更新。

长上下文召回：gpt-5.5 的主场

我在 60K token 的代码库上下文里埋了 25 个"针"，分 5 组，每组 5 个关键信息点（关键配置项、隐藏的 TODO 注释、特定变量赋值），然后问模型这些信息在哪里、值是什么。

gpt-5.5 召回率 88%，几乎每个都能精确定位到行号。opus-4.8 也不差（84%），漏掉的主要是埋在注释深处的信息。

kimi-k3 在这项上明显弱一些（72%），尤其是超过 40K 之后的内容，召回率出现明显下降。kimi-k3 标称支持 128K 上下文（需以官方文档为准），但实际有效注意力范围可能存在限制。这也可能与我的测试方法有关，后续有时间再验证。

延迟：kimi-k3 快得明显

首 token 延迟这项，kimi-k3 的 P50 380ms 领先明显（测试节点位于香港，客户端位于华南，prompt 约 200 token，仅供参考，不同网络环境下结果会有差异）。写代码时"打完回车立刻有反应"的感觉确实流畅。gpt-5.5 的 P95 到了 1100ms，偶尔等一秒多才出第一个字，波动较大。

不同需求怎么选

你的场景	推荐模型	原因
刷算法题 / 竞赛辅助	claude-opus-4.8	Hard 通过率最高，逻辑最严谨
日常工程重构	kimi-k3	改动精准、不过度重构、延迟低
大型代码库理解 / 检索	gpt-5.5	长上下文召回率最高
预算敏感 + 高频调用	kimi-k3	延迟低 + 价格最低（本轮测试约为 gpt-5.5 的 1/40）
需要最高正确率不差钱	claude-opus-4.8	综合最稳

价格现实

跑完 40 道题 + 重构 + 长上下文测试，三个模型的花费差距：

模型	本轮测试总花费（估算）	备注
kimi-k3	约 ¥8.5	—
gpt-5.5	约 ¥340	长上下文测试吃了大头
claude-opus-4.8	约 ¥95	中等偏贵

架构说明：网络上流传 kimi-k3 采用 MoE 架构、激活参数约 320B，但截至本文发布时 Moonshot AI 未公开相关技术细节，上述数字无官方来源支撑，不应作为事实引用。价格低的原因可能有多种，不宜直接归因于特定架构参数。

kimi-k3 本轮花费不到十块，gpt-5.5 三百多块，两者相差约 40 倍（约 1.6 个数量级）。如果高频使用 gpt-5.5，成本压力不小。

踩坑记录

跑测试过程中遇到的几个问题：

1. kimi-k3 偶尔输出截断

大概跑到第 28 题的时候，kimi-k3 返回了一个不完整的代码块，最后一行 return 语句直接没了。重试一次就好了，但这种非确定性截断需要注意。

2. gpt-5.5 的 JSON mode 和代码混用时偶发格式错误

让它返回 {"code": "...", "explanation": "..."} 格式，有两次它在 code 字段里的字符串没正确转义换行符，导致 JSON parse 失败：

json.decoder.JSONDecodeError: 
Expecting ',' delimiter: line 3 column 45

3. claude-opus-4.8 在 Go 代码生成时偏好旧语法

opus-4.8 生成的 Go 代码有时候还在用 interface{} 而不是 any（any 是 Go 1.18 引入的 interface{} 别名，编译完全兼容）。为什么会这样不确定，训练数据分布是一种可能的解释，但这只是推测。

我的最终选择

测完这一轮，我自己的 side project 决定主力用 kimi-k3 做日常编码（延迟低 + 便宜 + 重构能力够用），遇到复杂算法问题切 claude-opus-4.8。gpt-5.5 只在需要理解超大代码库的时候偶尔调一下，那个价格确实需要按需使用。

三个模型都是通过 ofox 统一调用的（也可以用 OpenRouter、Together AI 这类聚合平台），好处是一个 Key 切三个模型只改 model 参数，不用分别注册三家账号。调用平台的管理后台能看到每个模型每天的花费，对账方便。

最后补一句：kimi-k3 在多文件重构上能打出这种成绩，确实让我对月之暗面这个团队有了新的认识。长上下文召回率是它目前最明显的短板——如果你的场景是 RAG + 大代码库检索，gpt-5.5 或 claude-opus-4.8 可能更合适。不同场景优先级不同，选最适合自己需求的就行。