Kimi 叫停新订阅后，如何用上 K3｜实测避坑

Kimi 官方停止接受新的会员订阅后，还有什么办法用上最新的 K3 成了当务之急，而且，也有一个符合直觉的答案：API。

K3 可以通过开放平台直接调用，也能被接入 Claude Code 等第三方编程 Agent。只要准备一个 API Key，再做少量配置，用户似乎就能绕过拥挤的官方入口，把模型能力重新接到自己的电脑上。

但……真这么简单吗？

为 API 选一个好「壳」

Claude Code 是相对简单的一条路，它可以通过 Anthropic 兼容接口，把原本发往 Claude 的请求直接转到 Kimi K3，同时继续复用 Claude Code 现成的文件读写、终端执行和 Agent 工作流。

但是，当我把 K3 接入 Claude Code，要求它完成一个几乎不能更简单的冒烟测试：检查当前目录、确认 Node 和 npm 版本，再创建一份文本文件。八分钟过去，Claude Code 没有任何有效进展，旁路询问也得不到回复。

等下，不会连 API 都卡我限额吧？让我看看：

```text
HTTP/2 429
engine_overloaded_error
```

看来，意味着问题不在 Claude Code，也不在配置，而是 K3 的推理服务本身暂时没有余量接收这条请求——简单说，我充的钱太少，依然是贫民路由。

没关系，会员买不到，充值还是可以充的，而且叠加上我以前的充值记录，累计充值已经超过了 50 元，账户从免费组升级到 Tier-1，同一条最小请求才终于返回 HTTP 200。

诚然，API 是订阅入口之外的替代路径，但「开放调用」和「此刻可用」不是一回事。算力紧张的 Kimi，只能是有选择性地提供服务。

更有意思的是，即便底层调用的是同一个 K3，换一种打开方式，模型呈现出来的能力、习惯，甚至视觉风格，也会发生明显变化。这次测试使用了同一张网页截图作为参考图，目标不是要求模型逐像素复制，而是观察它能否理解页面的视觉语言，并将其重建成一个可以在浏览器中打开、具有基本交互的网页。

参考页面不是一个难度很高的案例，因为怕烧钱（bushi），主打一个大面积留白、衬线字体、简洁导航和横向排列的展品内容。总体并不复杂，却很适合观察模型究竟是在理解原图，还是只会套用一套常见的 AI 网页模板。

四种测试方式分别是：

第一种是 K3 API 直连。图片被编码后直接发送给模型，由它一次性返回完整 HTML。

第二种是把 K3 接入 Claude Code。底层仍然是 K3，但它获得了 Claude Code 提供的文件系统、终端和工具调用能力。

第三种是 Kimi 官方原生客户端。它代表 K3 在月之暗面自己设计的系统提示、工具和交付流程中的表现。

第四种是 Codex。本来一开始的意图是让 K3 通过 CC Switch 接入 Codex ，但需要经过 cc switch 路由，一直没有成功，请求始终停留在本地转换层的 502 错误。因此最终完成横向测试的是 Codex 自己的原生 GPT 5.6 sol 和 Agent——也行吧，正面对轰了。

总之，前三项主要比较的是同一个模型在不同 harness 中的表现，而 Codex 更适合作为另一套成熟编码产品的外部基准。

测试里主要观察，从发送任务到出现可用页面需要多久；第一次生成是否能够直接运行；页面对参考图的布局和风格理解；交互是否真的生效；以及中间需要多少次人工干预。

API 直连：黑箱，却最先交卷

API 直连是四种方式中链路最短的一种，只要打开终端窗口，就能启用。稍微特殊一点的地方是，直连 API 只会返回模型生成的文本或代码，不会自动读取本地图片、保存成网页文件并启动预览，因此需要一段脚本负责图片编码、请求发送、结果落盘和本地运行。脚本把参考图和提示词一次性发送给 K3，并要求它返回一份包含 HTML、CSS 和 JavaScript 的单文件网页。

这个办法最明显的问题，是几乎没有过程反馈。终端只显示了一句：

```text
Sending image and prompt to Kimi K3...
```

然后就是沉默……

因为请求采用非流式模式，模型无论是在理解图片、思考布局，还是已经开始生成代码，用户都看不到，它看上去甚至比 Claude Code 更像「卡住了」，Kimi 官方费老大劲做的动画也不是没有道理。

不过，直连反而最早交付了一个能够打开的页面，提示「done」之后，就可以在指定的文件夹里找到 html 文件并且打开了。

K3 抓住了参考图最明显的视觉特征：克制的版式、博物馆式的展示氛围、衬线文字、大面积纯白背景，以及较为舒展的横向内容关系。页面整体具有一致的设计语言，至少说明它不只是识别出了「这是一个网页」，还尝试理解「这是一个怎样的网页」，更接近一次视觉风格和页面结构的重建，但没有达到像素级还原，部分元素的尺寸、位置和内容元素都与参考存在差异，图片也是生成的简略矢量图。

直连的优势也非常明确：没有庞大的 Agent 系统上下文，没有复杂的工具调用链，它只需要集中完成一次任务。对于「给我一张图，返送一个可运行 HTML」这样的需求，它可能比完整编程 Agent 更直接。

这是 Kimi 的老毛病，哪怕面对简单任务也喜欢「用牛刀」，不仅增加算力负载，也让套餐额度如奶油一般化开。

Claude Code：一直在工作，却忘了写文件

把 K3 接进 Claude Code 后，体验立刻变得更像一个真正的编码 Agent。

它可以读取参考图、检查当前目录、决定文件结构、生成 HTML、CSS 和 JavaScript，还能运行终端命令。和直连 API 相比，整个过程不再是一段沉默的等待，我可以持续看到它分析页面、组织代码和推进任务。

理论上，这应该是更完整的方案。

然而，第一轮生成结束后，Claude Code 虽然返送了很大一截代码，却没有成功把页面写入本地文件。

只有在被明确要求「检查当前目录中实际创建了哪些文件，并确认代码已经写入磁盘」后，它才在自查中发现：前面的代码生成并没有真正转化成文件操作。随后，它重新调用工具，补齐文件，并最终启动了可以访问的本地预览。

这个过程揭示了 Agent 产品中一个典型问题：Agent 外壳在扩展模型能力的同时，也扩大了它的故障面。模型不仅要生成正确代码，还要正确选择工具、构造工具参数、等待执行结果、理解执行反馈，并在最后验证文件是否存在。任何一环出错，用户都可能得到一种「它好像已经完成了」的错觉。

不过，Claude Code 的优势也在同一个地方。它虽然第一次没有落盘，却能够在收到验收要求后检查环境并自我修正。页面生成后，用户也可以继续提交实际渲染截图，要求它比较参考图和当前结果，再修改已有文件。这种持续读写、运行和修正的循环，是一次性 API 输出无法自行完成的。

最终生成的页面还出现了一个很有意思的差异：参考图和 API 直连版都使用了接近纯白的背景，而 Claude Code 版本却染上了一层非常淡的暖红色，看起来颇有一点 Claude 自己的色调——怎么还出现了模型传模型现象。

Agent harness，很是回事儿

严格来说，淡红色也不能被完全归因于 Claude Code。生成模型本身具有随机性，推理强度、最大输出长度和消息格式也并不完全一致。但至少这次测试证明，相同的模型名称，并不足以保证相同的产品行为。

同一个模型，进入不同的壳，就不再是同一个「设计师」，这中间是 harness 的差异。

直连更像一次完整作答。模型在单次生成中形成一套统一方案，再从头写到尾。Claude Code 则更像一个分阶段项目：先理解截图，再规划结构，随后写文件、补样式、加交互、启动服务。每增加一个步骤，就多一次模型重新解释任务的机会，也多一次风格漂移的可能。

为了观察 K3 在原生环境中的表现，我们还用了一个最高级别的老账号，以及配备原生 GPT 5.6 Sol 的 Codex 复刻同一个任务。

一方面，这是因为 K3 接入 Codex 的过程没有顺利完成，Codex 主要使用 Responses API，而 Kimi 提供的是另一种兼容接口。通过 CC Switch，可以在本地对请求和流式响应进行转换。但在这次测试中，即便 Kimi API 直连已经恢复正常，Codex 发往本地转换端口的请求仍然反复返回 502。

从结果来看，两个原生果然都完成得更好，更细致。Kimi 的官方有一些小的「改动」，换掉了一些字体，更贴近他们一贯的风格。GPT 的复刻几乎到了一比一的程度，顶多是有一些间距上的不同。

这说明 API 兼容并不只是把 Base URL 和模型名称改掉。只要两端的请求协议、思考内容、工具调用或流式格式存在差异，中间转换层就可能成为新的故障源。相比较就能知道，原生客户端的意义，并不是保证模型每一次都生成最漂亮的页面，而是替普通用户完成大量他们看不见、也不应该分神处理的工作。

「套壳」依然有价值

回到最初的问题：Kimi 暂停新订阅后，还有没有办法用上 K3？

有是有。虽然充 API 也不能保证，但至少可以用。充值开放平台后，也可以把 K3 接入 Claude Code 等开发工具。在技术意义上，模型能力仍然存在，并没有随着官方订阅入口的暂停而消失。

但这次测试也说明，API 并不是官方产品的等价复制。

通过 API 迁移出来的，是模型的推理和生成能力。官方客户端中已经调好的系统提示、工具编排、文件管理、错误恢复和交付方式，并不会随着 API Key 一起被下载到用户电脑上。

用户获得了更大的模型选择权，也同时接手了稳定性、协议、运行环境和验收责任。对于需要模型读取真实项目、编辑多个文件、运行命令并持续修改的人，Claude Code 一类 Agent 外壳更合适，但它也会引入新的执行错误和产品偏好。

对于不熟悉环境变量、Python 脚本和本地服务器的普通用户，等待官方原生入口恢复，仍然可能是成本最低的选择。

这还让我想到了一个更深层次的问题。

过去几年，市场经常用「套壳」形容那些没有训练基础模型、只是在外面调用 API 的产品。与之相伴的判断是「模型即产品」，当模型变得足够强，它迟早会吞掉所有中间应用。

这种判断对于最薄的一层产品确实成立。如果一个应用只是把用户输入转发给模型，再换一个界面展示答案，那么模型厂商只要在原生客户端增加一个功能，就可能覆盖它的全部价值。

但 harness 并不必然只是一个聊天框，一个成熟的 harness 需要决定模型如何理解任务、能够操作哪些工具、怎样拆解步骤、如何保存状态、什么时候检查结果，以及失败后怎样恢复。它还可能接入企业数据、组件库、权限系统、品牌规范和真实生产流程。

K3 并没有因为进入 Claude Code 而获得新的视觉知识，但它获得了读写文件和运行终端的能力；与此同时，它也出现了没有落盘、视觉风格漂移等新的问题。这说明壳并不是被动包装。它在组织能力，也在制造能力，同时还会制造新的故障。

官方客户端本身同样是一种 harness。只是当模型公司自己提供系统提示、工具、记忆和 Agent 循环时，人们通常称之为「产品」；第三方团队使用同样的方式组织模型时，才更容易被叫作「套壳」。

真正值得追问的或许，不在于一个产品有没有调用别人的模型，而是在模型之外，它究竟创造了多少新的使用价值。