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 循環時，人們通常稱之為「產品」；第三方團隊使用同樣的方式組織模型時，才更容易被叫作「套殼」。

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