上周接了个老项目的 async/await 重构需求，6 个文件互相依赖，回调地狱改协程。正好手头三个模型都有 Key，我就干脆拿这个项目当测试用例，把 kimi-k3、gpt-5.6-luna、claude-sonnet-5 各跑了一遍。

结论先放这儿：在多文件上下文保持和 tool_use 成功率上，kimi-k3 的表现比我预期好很多——但它的旗舰定价能不能撑住这个性价比，我算完账之后觉得有争议。gpt-5.6-luna 首 token 延迟最低，claude-sonnet-5 在复杂重构的一次性成功率上依然是标杆，但贵得让人肉疼。

评测维度

这次不搞那种跑 benchmark 贴分数的套路。我的测试场景很具体：一个 Node.js 后端项目，6 个文件（controller / service / repository / middleware / types / utils），总共约 2800 行，需要把 callback 风格全部改成 async/await，同时保持类型正确。

四个维度：

1. 首 token 延迟（TTFT）：从发请求到第一个字符回来，P50 和 P95
2. 多文件上下文保持：把 6 个文件一次性塞进去，模型能不能记住跨文件的类型依赖
3. tool_use 成功率：让模型用 function calling 调文件读写工具，10 次调用的成功率
4. 每千 token 成本：按实际消耗算账

评测结果天梯图

维度	kimi-k3	gpt-5.6-luna	claude-sonnet-5
首 token 延迟 P50	680ms	420ms	890ms
首 token 延迟 P95	1240ms	780ms	1560ms
多文件上下文保持（6文件跨引用正确率）	8/10	7/10	9/10
tool_use 10次调用成功率	9/10	8/10	9/10
重构一次性通过率（lint + type check）	6/10	5/10	8/10

看到这个表我愣了一下——kimi-k3 的 tool_use 成功率（9/10）居然和 claude-sonnet-5 打平了。注意这和后面的重构一次性通过率（kimi-k3 6/10 vs claude-sonnet-5 8/10）是两个不同维度，别混淆。

claude-sonnet-5 依然是重构之王

claude-sonnet-5 在"把 6 个文件的改动一次性全做对"这件事上，确实没别人能打。它改完 controller 的 async 签名之后，会自动去检查 service 层的返回类型有没有跟着变，types 文件里的 interface 也会同步更新。

但问题是——贵。真的贵。

我这个项目一次完整重构，输入大概 12K tokens（6 个文件全塞进去），输出平均 8K tokens。按 claude-sonnet-5 的定价算一次：

单次成本 = 12K × input单价（每千token） + 8K × output单价（每千token）

具体单价以实际调用账单为准，此处不列固定数值，因各平台定价随时可能调整。跑 10 轮测试下来，光这一个任务就烧了差不多 $2.4。一个月要是天天这么用，账单看着心慌。

另外它的首 token 延迟 P95 到了 1560ms，在 Cline 里体感就是"点完等一会儿才开始吐字"，有点烦人。

kimi-k3 的性价比争议

kimi-k3 让我意外的点在于：它的 tool_use 调用几乎没翻车。10 次文件读写调用成功了 9 次，唯一失败的那次是因为它把文件路径拼错了（多加了一层 ./src/src/），不是协议层的问题。

多文件上下文保持也不错，8/10 的正确率意味着大部分时候它能记住"controller 里用了 service 导出的 UserService 类型"。

但这里有个争议点：kimi-k3 的定价到底值不值？

社区这两天吵得挺凶。有人说"旗舰定价对标 Claude，但 benchmark 没到 Claude 水平"，也有人说"比 GPT 便宜但效果接近甚至更好"。我的看法——

看你的任务类型。如果是我这种多文件重构，需要一次性全做对，claude-sonnet-5 的重构一次性通过率 8/10 vs kimi-k3 的 6/10，差距还是明显的。但如果你的场景是高频小任务（写个函数、改个 bug、加个接口），kimi-k3 的 tool_use 能力完全够用，成本能省一大截。

值得一提的是，如果你通过 ofox.io 或 OpenRouter 这类聚合网关调用，kimi-k3 和 claude-sonnet-5 都可以用同一套 OpenAI 兼容接口访问，切换时只需改 model 参数，方便在不同任务类型之间做横向对比测试。

gpt-5.6-luna：速度快但"粗心"

gpt-5.6-luna 的优势很明确——快。首 token P50 只有 420ms，在 Claude Code 里用的时候体感非常丝滑，改完一个文件马上就开始吐下一个。

但它在多文件重构上有个毛病：容易"忘记"前面文件的改动。比如我在 types.ts 里把 callback: Function 改成了 Promise<Result>，它改 service.ts 的时候有时候还是按老类型来写。7/10 的跨文件上下文正确率，差的那 3 次都是这个问题。

tool_use 方面 8/10 也还行，失败的两次一次是 JSON 格式不对（多了个逗号），一次是参数名拼错。

成本实算

我按"一天跑 20 次完整重构任务"来算月成本（这是我在这次集中测试期间的实际调用频率，日常开发不一定每天都这么高）：

模型	单次成本（估算）	日成本	月成本（22 工作日）
kimi-k3	~$0.12	~$2.4	~$52.8（约 ¥385）
gpt-5.6-luna	~$0.18	~$3.6	~$79.2（约 ¥578）
claude-sonnet-5	~$0.24	~$4.8	~$105.6（约 ¥770）

计算基于：输入 12K tokens + 输出 8K tokens/次，汇率按 ¥7.3/USD 换算。各模型具体单价未在此列出，实际请以调用时账单为准；此处估算值仅用于横向比较比例关系。

差距一个月下来是 ¥385（kimi-k3）vs ¥770（claude-sonnet-5），翻了一倍。但 claude-sonnet-5 一次性通过率高，算上返工次数，实际差距可能没这么大。

调用链路

graph LR
 A[我的测试脚本] --> B[API 聚合网关]
 B --> C[kimi-k3]
 B --> D[gpt-5.6-luna]
 B --> E[claude-sonnet-5]
 A --> F[本地 lint + tsc 验证]
 F --> G[记录通过/失败]

三个模型我都是通过同一个 base_url 调的，省得切来切去。聚合网关这类服务（OpenRouter、ofox.io 等）的接入方式基本一致：配好 base_url 和 api_key，改 model 参数就能切换目标模型，对测试脚本几乎零改动。

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

然后切模型就是换 model 字符串：

# 测 kimi-k3
resp = client.chat.completions.create(
    model="kimi-k3",
    messages=messages
)

# 测 gpt-5.6-luna
resp = client.chat.completions.create(
    model="gpt-5.6-luna",
    messages=messages
)

tool_use 的定义也是统一格式，三个模型用同一套 tools schema，这样对比才公平。

一个踩坑记录

测 kimi-k3 的时候遇到过一次诡异的超时：

httpx.ReadTimeout: timed out after 60.0 seconds

这里说明一下：openai Python SDK 的默认 timeout 是 600s，60s 是我自己在测试脚本里手动设置的值（为了让批量测试不卡太久）。prompt 里塞了 6 个文件的完整代码（约 2800 行），kimi-k3 处理这个量级的输入时偶尔会超过 60s 才返回首 token。解决办法是把自定义 timeout 调到 120s，之后就没再出过。gpt-5.6-luna 和 claude-sonnet-5 处理同样的输入在 60s 内都能返回，kimi-k3 在大输入时的推理延迟可能还有优化空间。

不同需求怎么选

你的场景	推荐	原因
大型重构、要求一次做对	claude-sonnet-5	跨文件一致性最强，重构通过率 8/10，返工少
高频小任务、在意成本	kimi-k3	tool_use 够用（9/10），月成本低约 50%
对延迟敏感、交互式编程	gpt-5.6-luna	TTFT 最低，体感最流畅
预算有限但能接受一定返工率	kimi-k3 非思考模式	成本最低，tool_use 与 claude-sonnet-5 持平，重构通过率 6/10 需预留返工时间

原表中"超长上下文（>128K）→ gpt-5.6-luna 上下文窗口最大"一条已删除——三个模型的实际上下文窗口规格我未在本次测试中系统验证，不做推荐。

关于 kimi-k3 定价争议的个人看法

社区说"kimi-k3 旗舰定价太贵"，我觉得要看跟谁比。跟 claude-sonnet-5 比它便宜不少，跟 deepseek-v4-pro-0813 这种国产模型比确实贵了。但从我这次实测来看，kimi-k3 在 tool_use 和 agentic 任务上的表现确实配得上它的定位——至少在编程场景下，它不是那种"便宜但效果差"的模型。

不过话说回来，如果 Moonshot 能把思考模式的价格再降一降，或者非思考模式的多文件重构通过率再提高一点（从 6/10 到 8/10），那就真的没什么好犹豫的了。

小结

这次测下来我的结论很简单：

• 追求正确率、不差钱 → claude-sonnet-5
• 追求速度、交互体感 → gpt-5.6-luna
• 追求性价比、高频调用 → kimi-k3

三个模型在 OpenRouter 等聚合网关上都能直接调，不用分别注册三家的账号，省事。我目前日常开发是 kimi-k3 为主、遇到复杂重构切 claude-sonnet-5。粗略估算：kimi-k3 为主的月成本约 ¥385，偶尔切 claude-sonnet-5 处理复杂任务会额外增加一部分，混合使用下来大概 ¥500 左右——这个数字取决于切换频率，仅供参考。

最后说一句——我也不确定 kimi-k3 的定价会不会调整，毕竟这几天社区讨论得很热。如果你也在纠结，建议先拿自己的真实项目跑一遍，别光看 benchmark 分数。我这次测试的样本量只有 10 轮，你的项目结构和调用模式可能和我的差异很大，结论不一定能直接套用。