Kimi K3 常见问题与解决方案：我踩过的坑和修复方法
一开始的问题：为什么我的 Kimi K3 效果这么差？
上个月我接了一个需求，要用 Kimi K3 处理一批法律文档的摘要和问答。第一周用下来，效果时好时坏：有时输出非常精准，有时却出现截断、幻觉，甚至直接拒答。我一开始怀疑是模型本身的问题，后来花了整整一周系统性排查，才发现大部分问题都出在我自己的使用方式上。
这篇文章把我在实际项目中遇到的高频问题、排查过程和最终解决方案整理出来，希望能帮你少走弯路。
问题一：长文档摘要输出被截断
现象
让 Kimi K3 读一份 30 页的合同并输出“逐条要点摘要”，输出到一半就停了，最后一条经常只有半句话。
排查过程
我最初的提示词是这样的：
请阅读这份合同，输出每一条款的要点摘要。
结果输出到第 12 条左右就断了。我以为是 API 出了问题，后来检查 finish_reason 字段，发现返回的是 length，也就是说——是 max_tokens 被顶满了，不是网络问题。
解决方案
两步走：
- 显式设置更大的 max_tokens。K3 支持很长的输出，别依赖默认值：
response = client.chat.completions.create(
model="kimi-k3",
messages=[{"role": "user", "content": prompt}],
max_tokens=8192
)
- 分段处理而不是一口气输出。我把任务拆成两轮：第一轮让模型只输出条款编号列表，第二轮逐段要求“针对第 X 条到第 Y 条输出摘要”。这样即使单次输出超限，也只是丢一小段，容易重试。
一个额外发现：如果提示词里写“请用表格输出”，输出长度会明显膨胀（表格语法字符多），截断来得更快。长任务里我后来都改成了纯文本条目式输出。
问题二：中文场景下的“幻觉引用”
现象
我问：“根据文档第 8.2 条，违约金比例是多少？”Kimi K3 自信满满地回答“第 8.2 条规定违约金为合同总额的 20%”——但我翻原文，8.2 条根本没提违约金，20% 是第 11 条的内容。
排查与解决
这是典型的检索式幻觉。我的对策分三层：
- 强制引用原文。在提示词里加一句硬约束：
回答时必须先逐字引用原文相关句子（用「」标出），再给出你的总结。
如果原文没有相关内容，直接回答"文档中未提及"，禁止推测。
加上这句之后，幻觉率肉眼可见地下降。因为模型要先“抄”原文，抄不出来它自己就会意识到没依据。
降低 temperature。文档问答场景我把 temperature 从默认调到 0.2，输出明显更保守。
文本块太长导致定位不准。我一开始一次塞进整份 60 页文档，模型找引用容易“串行”。改成先粗筛（让它列出相关章节号），再只把相关章节塞进去，准确率从大概七成提到了九成以上。
问题三：System Prompt 被忽略
现象
我在 system prompt 里写了“始终用简洁的 bullet points 回答，每条不超过 20 字”，但模型经常长篇大论。
解决方案
经验是：System prompt 里的规则要放在开头，并且越具体越好。“简洁”这种模糊词基本无效，我改成了：
输出格式要求（必须严格遵守）：
- 每个回答使用不超过 5 条 bullet points
- 每条不超过 20 个汉字
- 不写任何开场白和结尾语
另一个技巧是在 user 消息末尾再追加一句 [请遵守格式要求]。听起来土，但实测有效——system prompt 离生成位置太远时，约束力会衰减。
问题四：API 超时与限流
现象
批量处理 200 份文档时，随机出现 429 和超时错误，一开始我的脚本直接崩了。
解决方案
- 加指数退避重试。用
tenacity库几行就搞定：
from tenacity import retry, wait_exponential, stop_after_attempt
@retry(wait=wait_exponential(multiplier=1, max=60), stop=stop_after_attempt(5))
def call_kimi(prompt):
return client.chat.completions.create(...)
并发别开太高。我一开始开了 20 并发，429 频繁触发；降到 5 并发 + 重试后，总吞吐量反而更高，因为不用反复退避等待。
记录失败的 request_id。有一次输出内容明显异常，我拿着日志里的 request_id 去提工单，排查快了很多。这个习惯建议大家都养成。
几个实用小技巧
- 让它先列提纲再写正文，长文质量提升非常明显。
- 少样本示例比长篇指令管用：给一个“好答案”的例子，比写三段要求更有效。
- 输出 JSON 时，在提示词里直接给一个精确的 JSON 模板，并要求“只输出 JSON，不要 markdown 代码块”，解析成功率会高很多。
诚实的局限性评估
用了几周之后，我的整体评价是：Kimi K3 在中文长文档场景下确实是同类里第一梯队的，尤其文本理解能力让我印象深刻。但也有明确的短板：
- 超长上下文不等于完美记忆。文档越长，“中间内容”的引用准确率越低，关键任务一定要分段。
- 复杂多步推理偶尔会走偏，需要在提示词里明确步骤。
- 格式遵循不是百分之百，任何依赖结构化输出的管线都必须加校验和重试逻辑。
总的来说，大部分“模型不行”的体感，最后都被证明是提示词和工程管道的问题。先把 max_tokens、引用约束、分段策略这三件事做好，你能解决的问题就超过八成了。