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 循環時，人們通常稱之為「產品」；第三方團隊使用同樣的方式組織模型時，才更容易被叫作「套殼」。
真正值得追問的或許，不在於一個產品有沒有調用別人的模型，而是在模型之外，它究竟創造了多少新的使用價值。
