K3 始终推理
K3 使用顶层 `reasoning_effort`，支持 `low`、`high`、`max`。不要把 K2.x 的 `thinking` 设置复制到 K3 请求。
简体中文
KIMI K3 / 推理预填充
预填答案，不要预填错推理块
Kimi K3 始终会思考。它的 Partial Mode 会接着给定的 assistant 前缀继续生成，而推理输出和最终内容可能是两个字段。很多空回复、400、思考泄漏和下一轮上下文丢失，都出在这个边界上。
Kimi 官方 Chat Completions 文档说明了 K3、Partial Mode 和 K2.x 的差异，但不同渠道仍可能有自己的支持范围。
先看契约
推理和预填是两条不同的边界
Kimi 文档写得很具体。社区帖子可以提供渠道和 SillyTavern 的线索，但不能证明存在通用绕过方式。
Partial Mode 继续内容
在 `messages` 末尾放置 `assistant` 消息并设置 `partial: true`，即可引导输出前缀。这不是官方记录的私有推理注入方式。
渠道也属于测试变量
网关可能重命名、丢弃或拒绝 `partial`、`reasoning_effort`、`reasoning_content`。先关闭预填做同一 prompt 的对照，再修改角色卡。
字段地图
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 仍然适合角色卡和扩展。
01
保持页面或文件打开
用当前页面、截图或本地文件作上下文，不必先构造 prefill 请求体。
02
查看实时模型选择器
列表中可用时选择 Kimi-K3。截图只是界面示例，实际权限取决于你的版本和方案。
03
对比一次干净回答
用侧栏快速提问，或比较多个回复。在回到渠道 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。模型访问与额度取决于当前版本和方案。