手上只有一個常用模型時，官方API通常最省事；如果需要在同一個專案切換不同廠商的模型，才值得再設定聚合API。這篇以Kimi K3.1 Pro為例，適合已經有API Key、想在Kimi Code Desktop使用外部模型的工程師；沒有可用金鑰、只想免費對話，或不準備管理呼叫額度的人，不需要這一步。資料與介面核對日期為2026年11月10日。
Kimi Code可以讀取專案、修改檔案、執行指令並檢查結果，外部供應商則負責提供模型呼叫入口。下面用8個畫面整理kimi-k3.1-pro的設定方式，再用Kimi Code獨立工作階段與直接API請求驗證，避免把「選到模型」誤認為「已經呼叫成功」。
Kimi Code設定Kimi K3.1 Pro前，先確認三個欄位
開始之前，先準備Base URL、API Key與Model ID。本文以Crazyrouter為例，你也可以使用自己經常用到的聚合API；更換服務時，這三個欄位都要以對應平台為準，不能只改供應商名稱。
| 欄位 | 本文範例 | 設定重點 |
|---|---|---|
| 供應商名稱 | crazyrouter |
只是本機顯示標籤，可以自訂 |
| API Protocol | OpenAI |
本文使用OpenAI相容協定，不要混用Anthropic原生位址 |
| API Key | 自己的金鑰 | 用來鑑權，不要放進公開截圖或文章 |
| Base URL | https://api.crazyrouter.com/v1 |
OpenAI相容用戶端保留到/v1 |
| Model ID | kimi-k3.1-pro |
從模型廣場直接複製，不憑記憶輸入 |
| Display name | kimi-k3.1-pro |
只影響介面顯示，不改變實際請求模型 |
| Context | 依模型文件填寫 | 是用戶端的上下文預算，不是擴大能力的開關 |
截圖中的Context範例是1048576，但本次沒有驗證1M長上下文。換成其他模型時，要重新確認實際上限，不建議整列照抄。
三個核心欄位可以分開記：Base URL決定「送到哪裡」，API Key決定「你是誰」，Model ID決定「呼叫哪個模型」。因此，401優先檢查金鑰，路徑錯誤先查Base URL，模型不存在則回到模型廣場重新複製ID。Display name只是給自己看的別名，即使改成其他名稱，也不會改變實際請求的模型。
第一次設定時，不建議一次加入整排模型。每多一個模型，就多一組ID、上下文與能力差異要核對。先讓Kimi K3.1 Pro跑通，再逐個增加，後續出問題時比較容易判斷是哪一項設定造成的。
第一步：開啟Kimi Code設定，準備加入Kimi K3.1 Pro
打開Kimi Code Desktop，在主畫面左下角按一下齒輪圖示。外部模型必須先透過供應商設定加入，不能只在對話框輸入模型名稱。
如果目前版本的選單位置略有不同，先確認使用的是Desktop，再找相同的設定入口。後面的協定與模型ID觀念仍然相同。
第二步：在Kimi Code新增Kimi K3.1 Pro的供應商
在設定左側選擇Model Providers，右側會看到Kimi Subscription與自訂供應商區域。按一下右上角的Add provider，開始新增模型來源。
供應商負責儲存協定、位址與金鑰，模型則掛在供應商下面。了解這層關係後，之後要在同一個入口加入第二個模型，就不需要重複建立供應商。
第三步：在Kimi Code填入Kimi K3.1 Pro使用的協定與位址
在新增頁面選擇Custom，依序填入供應商名稱、API Protocol、API Key與Base URL。本文選擇OpenAI，Base URL填寫下面這個位址：
https://api.crazyrouter.com/v1
Crazyrouter的API端點說明也提到，OpenAI相容用戶端會在Base URL後面接上/chat/completions或/models，所以位址保留到/v1即可；Anthropic原生用戶端才使用根網域。若錯誤訊息出現/v1/v1，通常代表路徑重複。
不同用戶端要求的位址長度可能不一樣：有些只要根網域，有些要填到/v1，手寫HTTP請求才需要完整端點。不要因為某個地址在另一款工具裡能用，就直接搬到Kimi Code；先看這個表單要求的協定與Base URL格式，能少走很多排錯彎路。
API Key請完整貼上，但不要在金鑰可見時截圖。若懷疑金鑰已外洩，應到對應平台更換，而不是只刪掉圖片。
第四步：把Kimi K3.1 Pro的模型ID複製到Kimi Code
開啟Crazyrouter模型廣場，搜尋目標模型或透過Moonshot篩選，按一下模型卡片上的複製按鈕，再回到Kimi Code貼到Model ID欄位。
標題使用Kimi K3.1 Pro是為了方便閱讀，實際請求ID則是kimi-k3.1-pro。其他文件中的k3.1-pro屬於另一套設定口徑，不能直接替換。前綴、大小寫、點號與連字號都可能影響路由。
複製後再讀一次，確認仍以kimi-開頭，且沒有帶入首尾空白。這個小動作通常比事後從錯誤訊息猜模型名稱更快。
第五步：檢查Kimi Code裡的Kimi K3.1 Pro並儲存
回到自訂供應商頁面，檢查Model ID、Context與Display name。Display name可以保留為kimi-k3.1-pro，方便在模型清單辨識。第一次只加入一個常用模型，確認能用之後再按Add model增加其他模型，最後按Save。
清單出現模型，只代表本機設定已儲存，不代表每個模型都已通過實際呼叫。截圖雖然展示多個模型，第一次設定不需要全部照加。
第六步：為Kimi K3.1 Pro開啟Kimi Code完整模型清單
儲存後回到主畫面，按一下輸入框右下方的模型選擇器，再按清單底部的More models...，開啟完整的模型切換視窗。
這裡仍然看到內建模型，不代表剛才儲存失敗。自訂供應商下面的模型，需要在下一層視窗選擇。
第七步：讓Kimi Code切換到Kimi K3.1 Pro
在Switch model視窗上方選擇剛加入的crazyrouter標籤，再按kimi-k3.1-pro。模型較多時，可以在搜尋框輸入完整ID，減少找錯版本的機會。
選好之後，輸入框右下方會顯示kimi-k3.1-pro。建議開啟新的工作階段再開始任務，避免舊工作階段的模型上下文影響結果。
如果這裡沒有新模型，先回到Model Providers確認是否已按Save，再重新開啟選擇器；仍然沒有時，可以重新啟動Desktop。不要連續建立多個同名供應商，否則之後很難判斷實際使用的是哪一個。
第八步：在Kimi Code實際呼叫Kimi K3.1 Pro確認設定成功
畫面顯示模型名稱，只代表已選中，不能單獨證明呼叫成功。我在2026年11月10日透過本機Kimi Code桌面服務建立獨立工作階段，將模型綁定為crazyrouter/kimi-k3.1-pro，請模型把設定驗收整理成三項核對。工作階段最終狀態為completed，回傳了非空內容：
- 模型ID要從模型廣場完整複製，避免憑名稱或記憶手填導致呼叫失敗。
- Base URL要與所選協定相符，按服務商文件確認路徑及是否包含
/v1。 - 最後送出真實提示詞，檢查實際回傳內容與產生結果，不要把連線成功當成設定成功。
接著，我再透過https://api.crazyrouter.com/v1做一次非流式API檢查。模型清單包含kimi-k3.1-pro，聊天請求回傳HTTP200，回應模型一致，結束原因為stop。如果想先核對自己金鑰可用的模型，可以使用Crazyrouter模型清單介面。
這次API請求總用量為691個token，其中451個為推理token。可見回答雖然很短，產生過程仍包含推理消耗，因此不能只用答案字數判斷token用量。
桌面工作階段證明Kimi Code能使用已儲存的外部供應商完成實際生成，直接API記錄則提供回應模型、HTTP狀態與用量依據。這些結果仍不代表1M長上下文、檔案修改、指令執行或長期穩定性已經驗證，實際開發時應繼續用小任務逐項檢查。
如果要繼續驗證專案能力，我會把工作拆成三層：第一層讓模型解釋一個現有檔案，檢查它是否找對入口與依賴；第二層給出邊界清楚的小修改，要求同時更新對應測試；第三層才允許它執行指令，並根據測試輸出繼續修正。每一層都保留人工核對點，不要剛設定成功就直接開放大型重構。
測試時一次只改一個變數。模型沒有答對時，先記錄題面、實際輸出與失敗類型，再決定是調整提示詞、檢查上下文，還是更換模型。這樣才知道改善來自哪裡，也不會把用戶端設定問題與模型能力問題混在一起。
如果只是想確認日常文件工作是否好用，也可以準備一段有固定答案的會議紀錄，要求模型整理負責人、事項與日期。這類任務不需要大型專案，卻能快速看出它有沒有漏資訊、亂補日期或改變原意，比只問「你能不能使用」更有判斷價值。
Kimi Code裡的Kimi K3.1 Pro無法使用時怎麼查
清單找不到模型。先檢查是否按過Save，再確認自己是否位於自訂供應商標籤。模型ID相似時，以模型廣場複製結果為準，不要自行增減前綴。
回傳401或鑑權錯誤。檢查API Key是否完整、仍然有效，以及是否屬於目前Base URL對應的服務。不要把某個平台的金鑰配到另一個平台的位址。
回傳403或沒有模型權限。模型ID存在不等於目前帳號可以呼叫，需要核對帳號可用的模型範圍與限制。
回傳404、模型不存在或路徑錯誤。重新複製模型ID，並檢查Base URL是否出現/v1/v1。OpenAI相容設定與Anthropic原生設定不要混用。
HTTP成功但沒有正文。不要只看狀態碼，還要檢查最終文字欄位、結束原因與輸出上限。推理模型可能先消耗推理token，輸出上限太小時，要特別留意是否沒有留下可顯示的內容。
切換後效果或快取異常。Kimi Code官方建議切換模型或思考程度後開啟新工作階段，因為既有提示詞快取會失效，不同模型的上下文也可能互相影響。若模型要求思考模式，應保持Thinking開啟，不要把這類錯誤誤判為Base URL問題。
設定Kimi K3.1 Pro後，Kimi Code與Kimi有什麼不同
普通Kimi適合網頁或App裡的問答、閱讀、搜尋與日常Agent任務；Kimi Code則把模型放進具體專案與工作目錄。兩者不是簡單的誰比較高級，而是工作對象不同。
| 比較項目 | 普通Kimi對話 | Kimi Code |
|---|---|---|
| 主要工作對象 | 對話、上傳資料、網頁資訊與一般任務 | 本機或遠端專案、程式碼庫、終端與開發流程 |
| 檔案處理 | 較著重理解對話中提供的材料 | 可讀取專案結構、跨檔案搜尋並修改多處程式碼 |
| 執行與驗證 | 不一定直接操作目前電腦環境 | 可依權限執行指令、建置與測試，再根據結果繼續 |
| 模型選擇 | 以Kimi內建體驗為主 | 可設定多家供應商，透過相容協定切換外部模型 |
| 工作流程擴充 | 以產品內建能力為主 | 支援MCP、Skills、Hooks、外掛與子代理 |
| 使用形態 | 網頁或App | Desktop、CLI、VS Code及第三方Agent工具接入 |
設定Kimi K3.1 Pro後，可以讓它協助梳理陌生專案、完成小型功能開發、執行測試與修正、批次整理文件，也能在同一個工作流程中比較不同模型的結果。透過MCP或外掛連接外部服務、用Skills儲存專案規範，則屬於進階用法，需要逐項檢查權限與結果。
如果只是偶爾問答或閱讀一份材料，普通Kimi更省事；如果需要AI理解整個專案、操作檔案並根據執行結果繼續推進，Kimi Code會更合適。外部模型設定完成後，先讓一個答案容易核對的小任務跑通，再逐步擴大任務範圍與工具權限，會比一開始就交給它大型修改更穩妥。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
