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 的推理服务暂时没有足够的资源处理这条请求。通俗地说，就是充值金额太少，依然在“低优先级队列”中排队等待。

没关系，会员订阅虽然暂停，但 API 充值依然可行。加上之前的充值记录，累计充值超过 50 元后，账户从免费组升级到 Tier-1 级别，再次发送同一条最小请求，终于返回了 HTTP 200 状态码。

API 确实是订阅入口之外的替代方案，但“开放调用”与“立即可用”并非同一概念。算力资源紧张的 Kimi 只能有选择性地提供推理服务。

更有趣的是，即使底层调用的都是同一个 K3，只要换一种调用方式，模型展现出的能力、习惯甚至视觉风格都会产生显著差异。本次测试使用同一张网页截图作为参考，目标并非要求模型逐像素复制，而是观察它能否理解页面的视觉语言，并将其重建为一个可在浏览器中打开、具备基本交互功能的网页。

参考页面并非一个难度很高的案例。由于担心消耗过多费用，设计上以大面积的留白、衬线字体、简洁导航以及横向排列的展品内容为主。整体并不复杂，却非常适合用来观察模型是真正理解原图，还是仅仅套用了一套常见的 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 外壳，确实大有讲究

严格来说，淡红色也不能完全归因于 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 的复刻几乎达到了 1:1 的还原度，最多只是有一些间距上的差异。

这说明 API 兼容并不仅仅是更改 Base URL 和模型名称。只要两端的请求协议、思考内容、工具调用或流式格式存在差异，中间转换层就可能成为新的故障源头。通过对比可以看出，原生客户端的价值并不在于保证模型每次都能生成最漂亮的页面，而在于替普通用户完成大量他们看不到、也不应该分心处理的工作。

套壳依然具有价值

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

有是有。虽然充值 API 也不能保证一定可用，但至少提供了一条途径。充值开放平台后，可以将 K3 接入 Claude Code 等开发工具。从技术意义上讲，模型能力依然存在，并未随着订阅入口的暂停而消失。

但这次测试也表明，通过 API 迁移出来的只是模型的推理和生成能力。客户端中已经调优的系统提示、工具编排、文件管理、错误恢复和交付方式，并不会随着 API Key 一并提供。

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

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

这还引出了一个更深层次的问题。

过去几年，市场常以“套壳”来形容那些没有自研基础模型、仅通过调用 API 来构建的产品。与之相伴的判断是“模型即产品”——当模型变得足够强大，它迟早会吞噬所有中间应用。

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

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

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

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

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