繁體中文

KIMI K3 / 推理預填

預填答案，不要預填錯推理區塊

Kimi K3 一律會思考。Partial Mode 會接續給定的 assistant 前綴，而推理輸出與最終內容可能是不同欄位。空回覆、400、思考外洩與下一輪脈絡遺失，常常都出在這條邊界。

查看相容性地圖

Kimi 官方 Chat Completions 文件說明 K3、Partial Mode 與 K2.x 的差異，但不同供應商仍可能有自己的支援範圍。

先看契約

推理和預填是兩條不同的邊界

Kimi 文件寫得很明確。社群文章可以提供供應商和 SillyTavern 的線索，但不能證明有通用繞過方式。

K3 一律推理

K3 使用頂層 `reasoning_effort`，支援 `low`、`high`、`max`。不要把 K2.x 的 `thinking` 設定直接複製到 K3 請求。

Partial Mode 接續內容

在 `messages` 末尾放入 `assistant` 訊息並設為 `partial: true`，即可引導輸出前綴。這不是官方記載的私有推理注入方式。

供應商也是測試變數

閘道可能重新命名、丟棄或拒絕 `partial`、`reasoning_effort`、`reasoning_content`。先關閉預填做同一 prompt 的對照，再修改角色卡。

欄位地圖

K3 與 K2.x 不是同一個 thinking 開關

先看模型家族，再選欄位。這張表用來排錯，不代表閘道一定會透傳所有欄位。

K3 與 K2.x 不是同一個 thinking 開關
問題	Kimi K3	Kimi K2.x
能關閉 thinking 嗎？	不能。K3 一律推理。	依模型而定。K2.6 記載 enabled 或 disabled；K2.7-code 固定 enabled。
推理控制	頂層 `reasoning_effort`：low、high、max。	`thinking.type`，預設值依模型而定。
保留歷史	K3 使用 preserved thinking。供應商要求時要回傳完整 assistant turn。	K2.x 記載 `thinking.keep`，不同模型規則不同。
預填	Partial Mode 加 `partial: true` 接續最後的 assistant 前綴。	查看模型與供應商文件，不要從 K3 範例推定支援。

若 K3 請求出現 `thinking: { type: "enabled" }`，請移除，除非供應商明確記載轉換層。

預填檢查

先跑乾淨對話，再加入前綴

一個受控的小測試，可以分辨 prompt、回應映射、歷史和供應商問題。保持模型與端點不變，一次只改一個變數。

最小 Partial Mode 結構

{
  "model": "kimi-k3",
  "messages": [
    {"role": "user", "content": "Return a status object."},
    {"role": "assistant", "content": "{\"status\":", "partial": true}
  ],
  "reasoning_effort": "low",
  "stream": false
}

程式碼展示欄位關係，不是 SillyTavern 通用 preset。不要把 API 金鑰放進程式碼。

01
1. 確認模型家族
核對供應商目前列出的模型 slug。官方 Kimi API 的 K3 別名是 `kimi-k3`，閘道可能使用其他別名。
02
2. 發出一次乾淨請求
移除 `partial`，使用一般 user 訊息，只設定文件中的 K3 推理欄位。保存最終 `content` 以及回傳的 `reasoning_content`。
03
3. 加入短 assistant 前綴
在最後一則 assistant 訊息放入短前綴並設為 `partial: true`。先用 `{"status":` 這類格式提示，不要先塞長角色扮演區塊。
04
4. 帶回完整 assistant turn
下一輪依供應商文件保留完整 assistant 訊息。不要把 reasoning block 拼進 content 前綴。

供應商與前端

OpenAI 相容只是形狀，不是保證

SillyTavern 支援自訂 OpenAI 相容端點；沒有 models 介面時也能手動填寫模型 ID。真正決定 K3 欄位能否保留的是端點。

	Moonshot 官方	閘道或 SillyTavern 路徑
模型	`kimi-k3`	嚴格使用供應商目前的 alias。
推理	`reasoning_effort` low、high、max	確認是否透傳、改名或丟棄。
Partial Mode	assistant 前綴加 `partial: true`	確認該模型和路徑是否接受欄位。
回應歷史	依要求保留 assistant 訊息	確認 reasoning 與 content 是否分開保留。
SillyTavern 設定	使用文件指定的 API 來源	Test Message 和 Bypass API status check 可協助隔離前端檢查。

現象到測試

讓錯誤決定下一步改什麼

這些測試會縮小排查範圍。社群報告可以提出假設，但你選定的供應商請求與回應才是證據。

匯入 K2.x preset 後 400

推理結構錯誤

移除 `thinking` 和 K2.x 歷史欄位，改用 K3 的 `reasoning_effort` 與供應商目前 alias。

看到思考後沒有答案

回應映射或歷史

檢查串流 delta 和非串流欄位，不要只保留 `content`，要按要求帶回完整 assistant 物件。

預填後變成拒答或怪回覆

Partial Mode 或供應商

關閉 `partial` 對比乾淨回應，確認該模型和路徑的文件確實支援預填。

思考文字出現在最終回答

渲染邊界

將 `reasoning_content` 與 `content` 分開顯示，不要合併兩個欄位。

下一輪遺失脈絡

歷史被截斷或編輯

記錄送出的 messages，保留完整 assistant 物件，並檢查供應商上下文上限。

思考時間很長

推理強度、prompt 或額度

嘗試供應商記載的較低強度，縮短測試歷史，再和關閉預填的結果比較。

更少設定的路徑

先讓 Kimi 貼著資料回答

如果你要查看角色設定、API 文件或研究頁面，Tabbit 可以選擇即時模型並保持資料在視野中。這個瀏覽器任務不必先接端點，SillyTavern 仍適合角色卡和擴充功能。

保持頁面或檔案開啟

用目前頁面、螢幕截圖或本機檔案作為上下文，不必先構造 prefill 請求體。

查看即時模型選擇器

清單中可用時選擇 Kimi-K3。截圖只是介面範例，實際權限取決於你的版本和方案。

比較一次乾淨回答

用側欄快速提問，或比較多個回覆。在回到供應商 Partial Mode 測試前，先建立基線。

推理預填 FAQ

下一輪出問題前先看答案

Kimi K3 支援 assistant prefill 嗎？+

官方 API 記載 Partial Mode。在 `messages` 末尾加入 assistant 訊息並設為 `partial: true`，讓 K3 接著前綴生成。具體供應商仍需個別核對。

可以預填 Kimi K3 的 reasoning_content 嗎？+

不要直接假設可以。文件中的 Partial Mode 預填的是 assistant 輸出前綴，推理輸出是另一條回應邊界，供應商可能拒絕或改寫注入嘗試。

應該送 thinking 還是 reasoning_effort？+

K3 使用頂層 `reasoning_effort`，支援 `low`、`high`、`max`。`thinking` 物件屬於 K2.x 範例，不是所有 Kimi 模型通用的開關。

為什麼預填請求回傳空回答？+

關閉預填，先發一次乾淨請求，確認 `content` 與 `reasoning_content` 是否分開回傳。同時檢查下一次請求是否保留完整 assistant 訊息。

為什麼 SillyTavern 顯示 400？+

檢查模型 alias、端點、JSON 結構和供應商支援。先移除照搬的 K2.x 欄位與不支援的 sampler，再修改 prompt。

只有 Moonshot 支援預填嗎？+

Reddit 討論中有人表示自己只在 Moonshot 找到支援，但這是使用者觀察，不是通用供應商規則。請以你使用路徑的目前文件為準。

先看清邊界，再選擇工作流

使用官方 K3 欄位，拿短前綴測試 Partial Mode，並保留供應商要求的 assistant turn。若問題來自網頁或檔案，開啟 Tabbit，從即時清單選擇 Kimi-K3。

支援 macOS 和 Windows。模型存取與額度取決於目前版本和方案。