Kimi K3.1 Pro 深度解析：長程程式開發、3D 能力與實際使用成本

Kimi K3.1 Pro 值得關注的地方，在於它能不能把長任務持續做完：讀懂專案、修改程式碼、呼叫工具，再根據失敗的回饋繼續修正。漂亮的第一個畫面只是其中一小段。對開發者來說，更有價值的問題是：改到第十輪之後，原本的功能還在不在，交付成果能不能通過驗收？

本文討論的正式型號是 Kimi K3.1 Pro，以及高速版本 Kimi K3.1 Pro Highspeed。資料核對至 2026 年 10 月 23 日；數值取自官方公開資料，Folkbench 這次沒有呼叫模型、沒有重跑基準測試，也沒有替它新增獨立評分。

先把模型認清楚

型號與定位見官方模型列表，精確的上下文數值見計費文件，API 功能見串接指南。官方技術部落格把它描述為 K3 的後訓練版本，並列出了權重發布計畫。因此，不宜只憑版本號推斷它換了底層架構，也不宜把開放權重的計畫直接寫成已經可以在本機部署。

兩項基準測試，各自回答一個問題

下表及附圖採用 Kimi 技術部落格刊出的同一組對照數值。競爭模型的數據也來自該頁，不是 Folkbench 在統一環境下重新測得的結果。

官方註腳預設使用 max 推理強度；Kimi 的 Terminal-Bench 使用 Claude Code 作為執行框架，競爭模型那幾欄則彙整自發布資料或排行榜數據。BenchCAD 的開放模型測試使用 1,000 個樣本的子集，工具模式同樣使用 Claude Code。這些條件需要和數值一起保留。

長程程式開發：分數接近，還不能取代專案驗收

65.7% 與 66.4% 相差 0.7 個百分點。這說明兩者在這張官方表格裡的表現接近，但在沒有相同執行預算、重複次數和不確定性範圍的情況下，不能寫成「能力相同」。同樣地，單項分數高於另一個模型，也不足以推論它在所有程式開發任務上都比較強。

在真實專案裡，更值得觀察的是錯誤復原。一項任務可能要求修改介面、更新呼叫端、保留相容行為，而且不能破壞既有功能。模型第一次產生多少程式碼，並不能回答這些問題。它必須看懂失敗的測試到底指出了什麼，而不是靠刪除斷言、放寬條件或跳過功能來製造「通過」。

如果打算把它接進程式開發流程，可以挑一項已經解決、驗收條件明確的歷史任務來重播：固定儲存庫版本和需求，讓各個候選模型獨立處理，再核對測試結果、修改範圍與人工修補量。這樣的紀錄，比「看起來很會寫」更能決定要不要遷移。這裡描述的是建議的驗收方式，並不是本文已經執行過的實驗。

3D：幾何接近，不等於作品已經可以交付

BenchCAD 這一列衡量的是 Voxel IoU。92.7% 不能改寫成「92.7% 的建模任務成功」，更不能當成藝術品質的評分。幾何重建與材質、燈光、動畫、可編輯性、製造公差，是不同的驗收問題。

如果用途是網頁裡的 Three.js 場景，驗收應該包括互動是否有效、在裝置上是否流暢、資源能否載入。如果用途是可修改的零件，則應檢查尺寸關係、修改參數後的形狀，以及匯出的檔案。一個渲染角度看起來很漂亮，仍可能掩蓋背面的缺口、結構互相穿插或無法使用的模型拓撲。

從這兩項官方數據出發，Folkbench 的編輯判斷是：它值得列入長程程式開發與程序化建模任務的候選名單。能不能取代現有方案，應該由目標專案的交付結果來決定。

百萬上下文：容量解決的是放不放得下

1,048,576 tokens 能裝下多少實際檔案，取決於內容與分詞方式；它不是固定的字數或程式碼行數。更關鍵的是，容量並不會自動保證模型找到了正確的證據、記住了先前的限制，或在幾十輪工具呼叫之後仍然堅守原本的目標。

對大型專案來說，把整個儲存庫塞進請求也許很方便，但也會把生成的檔案、過時的文件和互相矛盾的說明一起帶進去。比較好的輸入應該寫明目前的版本、目標檔案、不能改變的行為和驗收入口。模型需要的是可用的上下文，而不只是更多上下文。

多輪任務還有一項容易被忽略的成本。官方思考模型文件要求保留歷史 assistant 訊息中的推理內容；這部分會持續佔用上下文並列入計費。單次回覆看起來很短，不代表整次執行的 Token 用量很少。

API 串接：幾個參數就能改變使用體驗

推理強度文件說明，K3.1 Pro 一律會進行推理，預設強度為 max。low 是降低強度，並不是關閉思考。比較速度之前，要先把這個參數設成一致；否則「比較慢」的結果，可能只是用了不同的預算。

遷移時有三處值得單獨核對：

1. 使用頂層的 reasoning_effort，不要照搬 K2 的 thinking 設定。
2. 多輪工具呼叫時，原樣保留完整的 assistant 訊息，包括 reasoning_content 和 tool_calls。只保留最後的正文，會遺失 API 要求的歷史資訊。
3. 視覺輸入請依串接指南使用 base64 或 ms:// 檔案參照；不要預設任何公開網路上的圖片 URL 都能直接傳入。

透過中轉服務時，還要另外核對：請求欄位有沒有被保留、回應有沒有被截斷、模型名稱有沒有被重新對應，以及用量欄位是否完整。模型 API 能正常回覆，不代表上層 Agent 的工具迴圈已經正確運作。

成本：先算一次任務，再談 CP 值

這次抓取的官方價格頁及其 Markdown 版本，都沒有回傳 K3.1 Pro 可供核對的完整單價列。因此，本文不填寫美元單價，也不借用 K3 或第三方中轉站的價格。這個核對結果不代表官方一定沒有公布價格；它的意思是，本文沒有足夠的證據把某個數字寫進報價表。

能夠核對的是計費結構：API 依用量計費，與 Kimi 會員和 Kimi Code 分開；快取寫入依 TTL 區分，命中讀取與未快取輸入分開計算。串接指南的說法是不依上下文長度分級。快取文件則是核對重複使用規則和有效期限的入口。

這表示長上下文任務需要拆開來看：哪些輸入沒有命中，哪些觸發了快取寫入，哪些依快取讀取計費，以及最後產生了多少輸出。工具服務、執行環境和失敗重試也可能增加總支出。計算時應該依照帳單上的實際分類，避免把同一批 Token 重複算進好幾個項目。

一個適合用於採購和遷移討論的指標是：這批任務的總支出 ÷ 通過驗收的任務數。失敗的嘗試同樣留在分子裡；如果全部失敗，就沒有可以報告的成功任務單價。這是本文建議的比較方式，不是 Folkbench 已經測出的結果。

官方模型列表把 Highspeed 描述為能力相同、速度約 2–3 倍的版本。這是供應商的說法，不能直接換算成整個工作流程快 2–3 倍。如果模型生成只佔總耗時的一半，即使這一半縮短到原本的三分之一，整體也只是從 1 降到約 0.67，大約是 1.5 倍的速度。這是用來說明瓶頸的假設算例，不是 Kimi 的實測延遲。

哪些任務值得優先嘗試

前三類符合它的官方定位，但定位不等於品質保證。尤其是研究任務，文字流暢和引用數量都不能取代逐項核對：來源是否真的支持結論，年份和單位是否一致，試算表公式能不能重新計算。至於簡單分類，預設跑 max 的旗艦模型也未必是最划算的選擇。

Folkbench 的判斷

Kimi K3.1 Pro 的官方資料，給出了值得認真驗證的能力訊號：長程程式開發和程序化建模，都已經進入高水準的對照區間。它的實際價值，要看這些能力能不能在您的輸入、工具和預算下，穩定轉換成可以通過驗收的交付成果。

目前仍缺少本文自己的呼叫紀錄、重複實驗、失敗分布和可核對的單價，所以這裡不發布綜合分數，也不下「CP 值最高」的結論。串接指南中部分基準測試段落仍留有佔位文字，而且與技術部落格存在不同版本的說法；本文的兩項數值只採用技術部落格同一頁的對照，沒有拼湊不同版本。

如果您正在評估程式開發流程，可以繼續閱讀 [Folkbench 軟體工程評估指南](/zh-Hant/blog/ai-api-relay-software-engineering-evaluation-guide)。比較其他模型的資料範圍，可參考 [Claude Opus 5.5](/zh-Hant/blog/claude-opus-5-5-review-pricing) 和 [GPT-6.1 Sol](/zh-Hant/blog/gpt-6-1-sol-review-pricing)；後者不是上表中的 GPT-6 Astra，型號與分數不能混用。