八款 Kimi API 实测：结构化输出谁可用

同一份企业任务，交给 8 个 Kimi API 模型，最新旗舰没有按时交付，最快完成的却是处于迁移期的旧型号。作者这次测试最有价值的地方，是把模型能力、接口返回和业务可用性分开看了。

对准备接入 AI 代码审查、合同提取或需求检查的程序员来说，结论很直接：排行榜可以帮你选候选模型，能否上线，还得看自己的请求能不能稳定拿到完整结果。不过，这轮每个模型只跑了一次，结果只能作为复测起点。

8 个模型里，为什么只有 3 个算完成

作者在 2026 年 11 月 10 日，通过同一个 OpenAI-compatible 聚合 API，向 8 个模型发送了相同的三合一任务：

• 检查 JavaScript 折扣函数，找出它按数组顺序覆盖折扣率、没有选择最高合格档位的问题。
• 从合成采购合同中提取文档类型、日期、总金额、双方主体、付款条款和保修条款。
• 审查一份互相矛盾的夜间批量导入需求，列出冲突和待确认问题。

请求使用非流式 Chat Completions，设置 max_tokens=5000，不设置 temperature，超时为 180 秒，每个模型只调用一次。Base URL 为 https://api.crazyrouter.com/v1。这是聚合平台的调用结果，不能直接当成官方直连接口的表现。

评分中，代码分析占 30%，文档提取占 25%，需求审查占 25%，格式与调用可靠性占 20%。零分表示本轮没有可评估的交付，不代表模型没有相关能力。

最终 7 个模型返回 HTTP 200，但只有 3 个给出完整 JSON：

模型	耗时	主要表现
kimi-k2.7-code-highspeed	8.48 秒	三项任务全部完成
kimi-k2.7-code	36.53 秒	需求审查更深入
kimi-k2.5	32.26 秒	代码与合同准确，需求分析较浅

最快的 kimi-k2.7-code-highspeed 找到了数组顺序问题，还给出无序档位、恰好达到门槛、没有合格档位、无效规则四类回归测试。合同里，它没有混淆 ¥186,500 的总额、¥55,950 的预付款和 ¥130,550 的尾款；需求里，它识别了重复记录冲突，以及 23:00 到午夜约一小时的处理窗口。

kimi-k2.7-code 则进一步发现：失败记录重跑与防止重复付款之间，存在幂等性问题，并列出 8 个待确认问题。kimi-k2.5 只找到 1 个冲突和 3 个待确认问题，却用了 4,930 个输出 token，接近上限。

输出更长，不等于审查更深入。

HTTP 200 之后，还要检查什么

其余 5 个模型的情况，更接近接入工作里真正难处理的失败。

kimi-k2.8-preview 完成了可审阅的代码分析和合同提取，但在需求部分中途停止，最终 JSON 对象不完整，作者给了 3.6 分。原文没有交代完整评分尺度，因此这个分数不适合单独拿来比较。

kimi-k3、kimi-k3.1-pro-highspeed 和 kimi-k2.6 都触及 5,000 token 输出上限，却返回空 content；kimi-k3.1-pro 则超过了 180 秒超时。

原文没有提供足够的原始响应、token 明细或网关诊断，无法进一步确定空内容发生在哪一层。不能据此认定是模型推理消耗了全部预算，也不能直接归咎于聚合平台。

对接入方而言，HTTP 200 只证明请求在接口层面返回了。业务还要继续检查 content、finish_reason 和 JSON 解析结果，必要时验证字段是否齐全、金额是否一致。

这里还有个容易忽略的约束：据作者引用的官方文档，K3.1 Pro 始终启用 reasoning，可以降低 effort level，但不能关闭推理。原文没有给出具体参数名和值，接入时不能自行猜一个开关。

作者建议拆分任务后复测，这个方向合理。三个任务共享同一个输出预算时，前两项写得过长，就可能挤压最后一项的空间。但拆分能否解决本轮失败，作者尚未验证。

新旗舰值得测，旧型号却未必值得长期接

按照原文，K3.1 Pro 于 2026 年 10 月 23 日发布，是 K3 的后训练升级，总参数量仍为 2.8 万亿。主要变化来自代码、3D 创作、金融研究和多步 agent 任务上的强化学习扩展。

作者引用的官方数据里，内部困难样本测试的声明级幻觉比例，从 K3 的 23.4% 降到 K3.1 Pro 的 8.3%。这不是日常使用错误率。开源权重还主动移除了部分中期训练和强化学习阶段的网络安全数据，内部 xdev-bench-hard 成绩从未过滤检查点的 90.5% 降到发布版的 81.0%，属于明确披露的能力取舍。

外部成绩同样需要保留语境：The Decoder 引述 Artificial Analysis，称 K3.1 Pro 发布时的 Intelligence Index 为 55，比 K3 高 11 分，当时排名第四。它在 Terminal-Bench、OfficeQA Pro v2 上高于 DeepSeek V4.1 Flash，在 DeepSWE 上略低；BenchCAD 则仍由 Claude Opus 5.5 占优。原文没有提供这些项目的具体分数，不能据此算出业务收益。

作者检查了 moonshotai/Kimi-K3.1-Pro 的模型卡，确认已有权重和 Kimi K3.1 Pro License，但没有下载部署，也没测试百万 token 上下文、图片或视频输入。

更现实的问题是生命周期。按作者核对的官方信息，K2.5 已退役，K2.6 和 K2.7 Code 已停止接收新用户，并计划于 2026 年 12 月底全面退役。聚合目录还能看到 ID，不等于官方支持期限延长。

价格也要分开看。作者在 2026 年 11 月 10 日核对的官方人民币每百万 token 标价中，K3.1 Pro 比 K3 约低三分之一，两者 Batch API 均为标准价格的 60%。原文没有列出具体单价，也没有给出本次测试账单。

Kimi Code 是另一套订阅：Plus、Pro、Max、Ultra 分别从 ¥99、¥199、¥699、¥1,399/月起，年付折算更低。Go 没有 Kimi Code 额度，Plus 才能入门，Highspeed 和最高 1M 上下文档位要求 Pro。它与开放平台按 token 计费互不混用。

我的判断

这篇最值得保留的是交付视角：模型最后有没有返回业务能消费的对象，比接口亮绿灯更接近上线标准。

但它还不足以证明某个型号「最稳定」。每个模型只有一次调用，任务又混合了三种能力，没有重试统计、延迟分布和官方直连对照。旧型号领先的结果很具体，也很脆弱。

把 kimi-k2.7-code-highspeed 作为同类任务的复测基线，我赞同；因为一次 8.48 秒的完整交付，就把它写进新项目的长期配置，我不赞同。生命周期已经构成实际约束。

同样，旗舰超时不能被公开榜单自动解释成偶发问题，也不能被一次失败判成不可用。提高预算、降低推理强度、拆分请求，都是可测试的方案；作者没有给出对照数据，它们目前仍是经验建议。

能拿来做什么

• 给 Node 接入层定义完整的成功条件：同时检查 HTTP 状态、content、finish_reason、JSON 解析和必填字段，并记录失败类型，避免空内容进入后续流程。
• 把原文三项任务拆开复测，保留相同输入，再比较合并请求与独立请求的完整率、耗时和实际 token 成本。
• 把折扣函数的四类回归场景，以及失败重跑与重复付款的幂等性冲突，加入自己的 AI 审查样本，检查模型是否持续覆盖关键问题。
• 为模型配置同时记录渠道、ID 和生命周期。Kimi Code 的 k3.1-pro、k3.1-pro-highspeed、k3、k3-256k、kimi-for-coding、kimi-for-coding-highspeed 属于客户端命名空间，不能直接照搬聚合 API 的路由 ID。