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 都卡我限额吧？让我看看：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 的单文件网页。

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

Sending image and prompt to Kimi K3...

然后就是沉默……

因为请求采用非流式模式，模型无论是在理解图片、思考布局，还是已经开始生成代码，用户都看不到，看上去像卡住了，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 Key 一起端出来。

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

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

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

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

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

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

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

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

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