Kimi K3 實戰：親身體驗與 Claude Code 比較

作者的實驗結果如何#

Kimi K3 於 2026 年 7 月 16 日推出。它有 2.8 兆個參數、100 萬 token 的上下文視窗、開放權重，並在盲測前端比較中排名第一。我已在Kimi K3 與 Claude Code 完整評測中整理了架構、基準測試和價格的所有細節，因此不在這裡重複。

在那篇評測的結尾，我寫道：風險是花一天時間設定；回報則是從第二週起帳單會降低。我用自己的任務進行了實驗。

最初幾個小時確實令人興奮。模型會積極接手任務，產出連貫的前端成果，面對大型檔案也毫不遲疑。這就是我在頻道裡發文說自己感到驚喜的原因。問題是在長時間工作、多代理協作、反覆編輯，以及晚上使用終端機時浮現的。

最後，我恢復了原本的設定。以下是促使我做出這個決定的原因，並附上數據和第一手來源連結，讓你可以自行查證。

為什麼基準測試顯示 Kimi K3 勝過 Claude？#

以下是 Kimi K3 勝過 Claude Fable 5 的基準測試：

llm-stats彙整了這些基準測試；每一列都是與 Claude Fable 5 比較。

數據是真實的。同一份彙整中的全部 35 項基準測試裡，Claude Fable 5 贏了 22 項，Kimi K3 贏了 12 項，另有 1 項平手。

更有意思的是 Kimi K3 表現較差的項目。它在程式編寫基準測試中的差距不大，約為 4–5 分；但在知識和推理方面就落後了：在 HLE 上，Claude 領先將近 10 分。長時間任務正是在這裡碰壁：你得先理解，之後才能寫。

Moonshot 在發布文章的主要章節中如此描述：

為什麼實際使用時 Kimi K3 感覺慢了兩倍？#

比較採用 Claude Opus 4.8，這是 Claude 有完整速度測試數據的版本。

Kimi K3 較早開始回應，所以在短暫聊天中主觀上感覺比較快。工作時，時間花在另一件事上：等待完整回應慢慢送達。在這方面，它的速度幾乎慢了一半；回應越長，差距累積起來就會多出幾分鐘。

Kimi Code 宣稱速度可達每秒 180–260 個 token，和我的 34.7 相比，這個數字看起來很有說服力。但它指的是前一代的高速版本 K2.7 Code HighSpeed。Kimi K3 根本沒有這種版本，而獨立基準測試測量的就是 Kimi K3 本身。

如果推理無法關閉，token 都花到哪裡去了？#

你可以降低努力程度；文件列出三個等級：low、high 和 maximum。但無法完全關閉推理：文件明確指出，Kimi K3 的推理及其歷史記錄始終啟用。直接呼叫 API 時，預設為最高等級，而大多數包裝程式不會更改這項設定。

每一輪都會增加數千個輸出 token，每百萬個收費 $15。此外，Moonshot 要求你傳回助理的完整訊息，包括推理歷史；這些輸出 token 到了下一輪又會成為輸入 token。

因此，同一份推理內容你要付兩次費用：第一次是模型寫出來時，第二次是你把它傳回模型時。

在整體指標上，Kimi K3 的輸出 token 數量比前代 K2.6 少了 21%。相較於自己的前一版本，這個模型更省了。但在相同任務中，Claude 仍然用得更少。

提示「hi」會按 86 個 token 計費。底層有一段約 85 個 token 的隱藏系統提示，而且每次請求都會向你收費。

我另有一篇評測說明如何計算用量，以及在哪裡查看剩餘額度：Claude Pro 和 Max 提供多少 token。那裡的計算方式相同，只有價格不同。

模型陷入推理迴圈時會發生什麼？#

情況看起來是這樣：模型開始思考，但沒有推進思路，文字反而陷入重複：同一個詞，接著變成音節片段，無止盡地循環。token 計數器持續轉動，任務卻停滯不前。

Moonshot 已知問題中的 7 月 28 日回報描述 Kimi K3 連續六次嘗試讀取同一個檔案，收到「no-op call, file hasn’t changed since the previous read」拒絕訊息七次，接著若無其事地結束回合。在Kimi CLI issue tracker中，作者列出四種同類型的卡住情況——讀取、取代、測試和分析——並用一句話總結：

Moonshot 直接說明了原因。模型是在保留推理歷史的模式下訓練的，而且需要完整收到過去的推理內容。如果收到的歷史不完整，模型就會試著重建答案，產生相同的工具呼叫，然後再次陷入迴圈。

第三方請求路由器中的一篇分析作者也提出相同診斷：Kimi 嚴格到會拒絕推理歷史不完整的請求。外部包裝程式不知道它有這項嚴格要求，於是截斷了歷史。

為什麼多代理設定在 Kimi K3 上會崩潰？#

Moonshot 官方文件明確指出：他們的 API 尚未支援 WebFetch。換句話說，通常會連線到網路擷取網頁的 Claude Code，在 Kimi K3 上無法這麼做。替代方法是手動貼上內容，或連接第三方工具。

Claude Code 可以按需求載入工具，並在歷史記錄中放入 tool_reference 類型的服務區塊。Kimi 不接受這種類型，並回傳 400 錯誤。錯誤訊息沒有指出欄位或原因：

{"error":{"type":"invalid_request_error","message":"Invalid request Error"},"type":"error"}

作為比較，以下是 Anthropic 原生 API 遇到相同錯誤時的樣子；至少伺服器會指出欄位，並列出接受的類型：

messages.166.content.0.tool_result.content.0: Input tag 'tool_reference' found
using 'type' does not match any of the expected tags: 'document', 'image',
'search_result', 'text'

這個差異很重要。第一則訊息根本無從診斷：用戶端和背後的人都無法判斷是哪個區塊遭到拒絕。報告作者抱怨的正是這件事。提供者切換工具的開發者已經建議，對 Kimi 預設停用工具延遲載入，或將 Moonshot API 標記為不接受這些區塊。

另一份報告描述了後果；報告於 7 月 17 日建立，至今仍未獲回覆。作者在單一工作階段中遇到這項錯誤七次。工作階段撐過了前六次，第七次則徹底崩潰：此後即使輸入純文字「continue」，也會讓它崩潰。作者另外指出，當時距離上下文上限還遠得很，因此「歷史太長」的解釋並不成立。

以下整理 Moonshot API 接受與拒絕的區塊類型：

這裡的「相容」只描述請求格式。其他一切都不同：接受哪些區塊類型、歷史記錄必須包含什麼，以及究竟有哪些工具可用。

使用 Kimi K3 時有哪些東西無法沿用？#

發布文章的限制事項章節原文如下：

模型開發者的意思是：請使用我們的用戶端；我們不保證其他人的用戶端會如何運作。

同一章節的第二點，則解釋了另一件我原本歸因於模型固執的事：

我的 CLAUDE.md 是按照相反的習慣撰寫的：先提問、展示計畫，然後等待確認。指示仍在那裡，但現在讀取它的是一個個性不同的模型。

如果你想讓多個代理共用一份規則檔，我在Claude Code、Codex 和 Cursor 共用一份指示檔中另有介紹這種設定。

Kimi K3 的實際花費是多少？#

首先是對 Kimi K3 有利的價格：

Kimi 的價格來自上下文快取文件；右欄列的是截至 2026 年 7 月 30 日 Claude Opus 5 的價格。

Kimi 的快取是自動啟用的，無法停用，並以請求開頭的雜湊值識別。只要編輯系統提示或工具清單，訊息快取就會完全清除。

Claude Code 在一般工作日會做以下事情：

1. 隨著任務進展連接和中斷外部工具。
2. 在需要時按需求載入工具。
3. 使用不同的工具組啟動子代理。
4. 將指示檔加入系統提示。
5. 壓縮上下文時重建歷史記錄。

清單中的每一項都會重設請求的開頭，因此也會重設快取。輸入 token 的價格會從每百萬 30 美分再次回到 $3，貴了十倍。除此之外，持續推理的輸出 token 每百萬要 $15，而相同的 token 下一輪又會作為輸入傳回。這就是標價低的模型也可能產生超出預期帳單的原因。

根據 OpenCode 的彙整數據，在將近 280,000 個即時工作階段中，Kimi K3 每個工作階段的平均費用為 $1.86，平均用量為 3.1 million 個 token。這個數字以 93% 的輸入 token 命中快取為前提。只要更改請求開頭，這個數字就不適用於你。

Kimi 方案價格為 $19、$39、$99 和 $199。額度來自整個會員共用的額度池，每週重設且未使用的額度不會累積，並採用滾動式五小時區間。方案評測指出，四個終端機同時執行推理常開的 Kimi K3，很快就會用完五小時區間的額度。

$99 方案的程式編寫額度與 Anthropic 的 $200 方案相當，這與我的看法相反。Kimi 的 token 單價較低，但到了晚上的帳單上，你就看不出這項差別了。

Kimi K3 客觀上擅長什麼？#

1. 前端。 在現職開發者參與的盲測中排名第一。它能整齊地建立版面，品味也不錯。
2. 處理量。 100 萬 token 的上下文視窗，長檔案也難不倒它。分析大型儲存庫並描繪全貌，正是它擅長的任務。
3. 首次回應。 回傳第一個 token 所需時間是 Claude 的一半。在短對話中，差異明顯而且令人愉快。
4. 每個 token 的價格。 約為 Claude Opus 5 價格的 60%。如果請求開頭沒有變動，就能在大量重複工作中真正省錢。
5. 開放權重。 不會被綁定在單一提供者上。

最後一點有個但書。要在家裡執行這種規模的模型並不實際：即使經過壓縮，權重仍有數 TB。此處所說的開放，代表不依賴單一提供者。

如何在一個晚上親自測試以上內容#

1. 按照說明設定存取方式。 我在Kimi K3 與 Claude Code 評測中說明了三個環境變數，以及各層級的模型替換方式。用 /status 命令檢查設定：Kimi 不會出現在模型選擇選單中，因為選單內建了別名清單，而且你不需要動它。
2. 移除舊的金鑰。 如果你先前設定過 ANTHROPIC_API_KEY，請將它移除。它與 ANTHROPIC_AUTH_TOKEN 一起使用會造成衝突，讓你無故收到授權錯誤。
3. 立即關閉工具延遲載入。 第一次執行前就要做，而不是等第一個工作階段中斷後才做。
4. 不要在任務途中切換模型。 如果你以 Kimi K3 開始，就用 Kimi K3 完成。反過來也一樣。這是 Moonshot 的直接要求，我已在上文引用。
5. 使用自己的真實任務。 選一個你昨天做過、還留著各種混亂和未完成事項的任務。貪吃蛇遊戲看不出差異：差異只會在長時間使用後出現。
6. 記下兩個數字。 花了幾分鐘，以及那個晚上花了多少錢。與平常使用 Claude 的夜晚相比。
7. 另外追蹤閒置時間。 代理卡住、反覆讀取相同檔案，或回傳錯誤時，這些也算成本的一部分。

如果晚上的帳單比預期高，幾乎總是快取造成的：算算那個晚上請求開頭被重設了多少次。token 單價與此關係不大。

最後我保留了什麼#

和我一起測試模型的頻道讀者，也各自得出了相同的設定：讓 Kimi K3 檢查儲存庫並提供第二意見，主要工作則交給他們熟悉的代理。這種設定行得通，因為不必遷移包裝程式，也不會破壞已經正常運作的部分。

可以這麼說：完整的單一任務交給 Kimi K3；涉及工具和子代理的長流程交給 Claude Code。任務需要在工具之間切換的次數越多，使用 Kimi K3 的成本越高，工作階段出問題的機會也越大。

我另有一篇評測說明如何為兩個代理分配角色而不混淆：使用兩個代理的三種方式。

基準測試回答的是「在實驗室條件下誰比較強？」這個問題。你當晚的帳單和已完成工作清單，回答的則是「對你來說誰比較強？」當兩個答案不一致時，請相信第二個：這是你自己計算的，不是行銷部門算的。

檢視完這一切後，我自己做出了決定：不管大家怎麼說新模型，領先者仍然是領先者。Claude Code 仍是我的主引擎。