Kimi 官方停止接受新的會員訂閱后，還有什么辦法用上最新的 K3 成了當(dāng)務(wù)之急，而且，也有一個符合直覺的答案：API。

K3 可以通過開放平臺直接調(diào)用，也能被接入 Claude Code 等第三方編程 Agent。只要準(zhǔn)備一個 API Key，再做少量配置，用戶似乎就能繞過擁擠的官方入口，把模型能力重新接到自己的電腦上。

但……真這么簡單嗎？

為 API 選一個好「殼」

Claude Code 是相對簡單的一條路，它可以通過 Anthropic 兼容接口，把原本發(fā)往 Claude 的請求直接轉(zhuǎn)到 Kimi K3，同時繼續(xù)復(fù)用 Claude Code 現(xiàn)成的文件讀寫、終端執(zhí)行和 Agent 工作流。

但是，當(dāng)我把 K3 接入 Claude Code，要求它完成一個幾乎不能更簡單的冒煙測試：檢查當(dāng)前目錄、確認 Node 和 npm 版本，再創(chuàng)建一份文本文件。八分鐘過去，Claude Code 沒有任何有效進展，旁路詢問也得不到回復(fù)。

等下，不會連 API 都卡我限額吧？讓我看看：

```text

HTTP/2 429

engine_overloaded_error

```

看來，意味著問題不在 Claude Code，也不在配置，而是 K3 的推理服務(wù)本身暫時沒有余量接收這條請求——簡單說，我充的錢太少，依然是貧民路由。

沒關(guān)系，會員買不到，充值還是可以充的，而且疊加上我以前的充值記錄，累計充值已經(jīng)超過了 50 元，賬戶從免費組升級到 Tier-1，同一條最小請求才終于返回 HTTP 200。

誠然，API 是訂閱入口之外的替代路徑，但「開放調(diào)用」和「此刻可用」不是一回事。算力緊張的 Kimi，只能是有選擇性地提供服務(wù)。

更有意思的是，即便底層調(diào)用的是同一個 K3，換一種打開方式，模型呈現(xiàn)出來的能力、習(xí)慣，甚至視覺風(fēng)格，也會發(fā)生明顯變化。這次測試使用了同一張網(wǎng)頁截圖作為參考圖，目標(biāo)不是要求模型逐像素復(fù)制，而是觀察它能否理解頁面的視覺語言，并將其重建成一個可以在瀏覽器中打開、具有基本交互的網(wǎng)頁。

參考頁面不是一個難度很高的案例，因為怕燒錢（bushi），主打一個大面積留白、襯線字體、簡潔導(dǎo)航和橫向排列的展品內(nèi)容?？傮w并不復(fù)雜，卻很適合觀察模型究竟是在理解原圖，還是只會套用一套常見的 AI 網(wǎng)頁模板。

四種測試方式分別是：

第一種是 K3 API 直連。圖片被編碼后直接發(fā)送給模型，由它一次性返回完整 HTML。

第二種是把 K3 接入 Claude Code。底層仍然是 K3，但它獲得了 Claude Code 提供的文件系統(tǒng)、終端和工具調(diào)用能力。

第三種是 Kimi 官方原生客戶端。它代表 K3 在月之暗面自己設(shè)計的系統(tǒng)提示、工具和交付流程中的表現(xiàn)。

第四種是 Codex。本來一開始的意圖是讓 K3 通過 CC Switch 接入 Codex ，但需要經(jīng)過 cc switch 路由，一直沒有成功，請求始終停留在本地轉(zhuǎn)換層的 502 錯誤。因此最終完成橫向測試的是 Codex 自己的原生 GPT 5.6 sol 和 Agent ——也行吧，正面對轟了。

總之，前三項主要比較的是同一個模型在不同 harness 中的表現(xiàn)，而 Codex 更適合作為另一套成熟編碼產(chǎn)品的外部基準(zhǔn)。

測試里主要觀察，從發(fā)送任務(wù)到出現(xiàn)可用頁面需要多久；第一次生成是否能夠直接運行；頁面對參考圖的布局和風(fēng)格理解；交互是否真的生效；以及中間需要多少次人工干預(yù)。

API 直連：黑箱，卻最先交卷

API 直連是四種方式中鏈路最短的一種，只要打開終端窗口，就能啟用。稍微特殊一點的地方是，直連 API 只會返回模型生成的文本或代碼，不會自動讀取本地圖片、保存成網(wǎng)頁文件并啟動預(yù)覽，因此需要一段腳本負責(zé)圖片編碼、請求發(fā)送、結(jié)果落盤和本地運行。腳本把參考圖和提示詞一次性發(fā)送給 K3，并要求它返回一份包含 HTML、CSS 和 JavaScript 的單文件網(wǎng)頁。

這個辦法最明顯的問題，是幾乎沒有過程反饋。終端只顯示了一句：

```text

Sending image and prompt to Kimi K3...

```

然后就是沉默……

因為請求采用非流式模式，模型無論是在理解圖片、思考布局，還是已經(jīng)開始生成代碼，用戶都看不到，它看上去甚至比 Claude Code 更像「卡住了」，Kimi 官方費老大勁做的動畫也不是沒有道理。

不過，直連反而最早交付了一個能夠打開的頁面，提示「done」之后，就可以在指定的文件夾里找到 html 文件并且打開了。

K3 抓住了參考圖最明顯的視覺特征：克制的版式、博物館式的展示氛圍、襯線文字、大面積純白背景，以及較為舒展的橫向內(nèi)容關(guān)系。頁面整體具有一致的設(shè)計語言，至少說明它不只是識別出了「這是一個網(wǎng)頁」，還嘗試理解「這是一個怎樣的網(wǎng)頁」，更接近一次視覺風(fēng)格和頁面結(jié)構(gòu)的重建，但沒有達到像素級還原，部分元素的尺寸、位置和內(nèi)容元素都與參考存在差異，圖片也是生成的簡略矢量圖。

直連的優(yōu)勢也非常明確：沒有龐大的 Agent 系統(tǒng)上下文，沒有復(fù)雜的工具調(diào)用鏈，它只需要集中完成一次任務(wù)。對于「給我一張圖，返送一個可運行 HTML」這樣的需求，它可能比完整編程 Agent 更直接。

這是 Kimi 的老毛病，哪怕面對簡單任務(wù)也喜歡「用牛刀」，不僅增加算力負載，也讓套餐額度如奶油一般化開。

Claude Code：一直在工作，卻忘了寫文件

把 K3 接進 Claude Code 后，體驗立刻變得更像一個真正的編碼 Agent。

它可以讀取參考圖、檢查當(dāng)前目錄、決定文件結(jié)構(gòu)、生成 HTML、CSS 和 JavaScript，還能運行終端命令。和直連 API 相比，整個過程不再是一段沉默的等待，我可以持續(xù)看到它分析頁面、組織代碼和推進任務(wù)。

理論上，這應(yīng)該是更完整的方案。

然而，第一輪生成結(jié)束后，Claude Code 雖然返送了很大一截代碼，卻沒有成功把頁面寫入本地文件。

只有在被明確要求「檢查當(dāng)前目錄中實際創(chuàng)建了哪些文件，并確認代碼已經(jīng)寫入磁盤」后，它才在自查中發(fā)現(xiàn)：前面的代碼生成并沒有真正轉(zhuǎn)化成文件操作。隨后，它重新調(diào)用工具，補齊文件，并最終啟動了可以訪問的本地預(yù)覽。

這個過程揭示了 Agent 產(chǎn)品中一個典型問題：Agent 外殼在擴展模型能力的同時，也擴大了它的故障面。模型不僅要生成正確代碼，還要正確選擇工具、構(gòu)造工具參數(shù)、等待執(zhí)行結(jié)果、理解執(zhí)行反饋，并在最后驗證文件是否存在。任何一環(huán)出錯，用戶都可能得到一種「它好像已經(jīng)完成了」的錯覺。

不過，Claude Code 的優(yōu)勢也在同一個地方。它雖然第一次沒有落盤，卻能夠在收到驗收要求后檢查環(huán)境并自我修正。頁面生成后，用戶也可以繼續(xù)提交實際渲染截圖，要求它比較參考圖和當(dāng)前結(jié)果，再修改已有文件。這種持續(xù)讀寫、運行和修正的循環(huán)，是一次性 API 輸出無法自行完成的。

最終生成的頁面還出現(xiàn)了一個很有意思的差異：參考圖和 API 直連版都使用了接近純白的背景，而 Claude Code 版本卻染上了一層非常淡的暖紅色，看起來頗有一點 Claude 自己的色調(diào)——怎么還出現(xiàn)了模型傳模型現(xiàn)象。

Agent harness，很是回事兒

嚴格來說，淡紅色也不能被完全歸因于 Claude Code。生成模型本身具有隨機性，推理強度、最大輸出長度和消息格式也并不完全一致。但至少這次測試證明，相同的模型名稱，并不足以保證相同的產(chǎn)品行為。

同一個模型，進入不同的殼，就不再是同一個「設(shè)計師」，這中間是 harness 的差異。

直連更像一次完整作答。模型在單次生成中形成一套統(tǒng)一方案，再從頭寫到尾。Claude Code 則更像一個分階段項目：先理解截圖，再規(guī)劃結(jié)構(gòu)，隨后寫文件、補樣式、加交互、啟動服務(wù)。每增加一個步驟，就多一次模型重新解釋任務(wù)的機會，也多一次風(fēng)格漂移的可能。

為了觀察 K3 在原生環(huán)境中的表現(xiàn)，我們還用了一個最高級別的老賬號，以及配備原生 GPT 5.6 Sol 的 Codex 復(fù)刻同一個任務(wù)。

一方面，這是因為 K3 接入 Codex 的過程沒有順利完成，Codex 主要使用 Responses API，而 Kimi 提供的是另一種兼容接口。通過 CC Switch，可以在本地對請求和流式響應(yīng)進行轉(zhuǎn)換。但在這次測試中，即便 Kimi API 直連已經(jīng)恢復(fù)正常，Codex 發(fā)往本地轉(zhuǎn)換端口的請求仍然反復(fù)返回 502。

從結(jié)果來看，兩個原生果然都完成得更好，更細致。Kimi 的官方有一些小的「改動」，換掉了一些字體，更貼近他們一貫的風(fēng)格。GPT 的復(fù)刻幾乎到了一比一的程度，頂多是有一些間距上的不同。

這說明 API 兼容并不只是把 Base URL 和模型名稱改掉。只要兩端的請求協(xié)議、思考內(nèi)容、工具調(diào)用或流式格式存在差異，中間轉(zhuǎn)換層就可能成為新的故障源。相比較就能知道，原生客戶端的意義，并不是保證模型每一次都生成最漂亮的頁面，而是替普通用戶完成大量他們看不見、也不應(yīng)該分神處理的工作。

「套殼」依然有價值

回到最初的問題：Kimi 暫停新訂閱后，還有沒有辦法用上 K3？

有是有。雖然充 API 也不能保證，但至少可以用。充值開放平臺后，也可以把 K3 接入 Claude Code 等開發(fā)工具。在技術(shù)意義上，模型能力仍然存在，并沒有隨著官方訂閱入口的暫停而消失。

但這次測試也說明，API 并不是官方產(chǎn)品的等價復(fù)制。

通過 API 遷移出來的，是模型的推理和生成能力。官方客戶端中已經(jīng)調(diào)好的系統(tǒng)提示、工具編排、文件管理、錯誤恢復(fù)和交付方式，并不會隨著 API Key 一起被下載到用戶電腦上。

用戶獲得了更大的模型選擇權(quán)，也同時接手了穩(wěn)定性、協(xié)議、運行環(huán)境和驗收責(zé)任。對于需要模型讀取真實項目、編輯多個文件、運行命令并持續(xù)修改的人，Claude Code 一類 Agent 外殼更合適，但它也會引入新的執(zhí)行錯誤和產(chǎn)品偏好。

對于不熟悉環(huán)境變量、Python 腳本和本地服務(wù)器的普通用戶，等待官方原生入口恢復(fù)，仍然可能是成本最低的選擇。

這還讓我想到了一個更深層次的問題。

過去幾年，市場經(jīng)常用「套殼」形容那些沒有訓(xùn)練基礎(chǔ)模型、只是在外面調(diào)用 API 的產(chǎn)品。與之相伴的判斷是「模型即產(chǎn)品」，當(dāng)模型變得足夠強，它遲早會吞掉所有中間應(yīng)用。

這種判斷對于最薄的一層產(chǎn)品確實成立。如果一個應(yīng)用只是把用戶輸入轉(zhuǎn)發(fā)給模型，再換一個界面展示答案，那么模型廠商只要在原生客戶端增加一個功能，就可能覆蓋它的全部價值。

但 harness 并不必然只是一個聊天框，一個成熟的 harness 需要決定模型如何理解任務(wù)、能夠操作哪些工具、怎樣拆解步驟、如何保存狀態(tài)、什么時候檢查結(jié)果，以及失敗后怎樣恢復(fù)。它還可能接入企業(yè)數(shù)據(jù)、組件庫、權(quán)限系統(tǒng)、品牌規(guī)范和真實生產(chǎn)流程。

K3 并沒有因為進入 Claude Code 而獲得新的視覺知識，但它獲得了讀寫文件和運行終端的能力；與此同時，它也出現(xiàn)了沒有落盤、視覺風(fēng)格漂移等新的問題。這說明殼并不是被動包裝。它在組織能力，也在制造能力，同時還會制造新的故障。

官方客戶端本身同樣是一種 harness。只是當(dāng)模型公司自己提供系統(tǒng)提示、工具、記憶和 Agent 循環(huán)時，人們通常稱之為「產(chǎn)品」；第三方團隊使用同樣的方式組織模型時，才更容易被叫作「套殼」。

真正值得追問的或許，不在于一個產(chǎn)品有沒有調(diào)用別人的模型，而是在模型之外，它究竟創(chuàng)造了多少新的使用價值。