前置条件
- 1已安装钉钉客户端，且是目标群的群主或管理员
- 2已注册 Moonshot 开放平台账号并创建 API Key
- 3已安装 Python 3.9+，能访问公网
- 4了解基本的 HTTP 请求与 JSON 格式
即时通信 IM + AI
高效构建智能聊天能力
常见问题
QKimi K3 的上下文到底有多大，200 万字是真的吗？
官方标称 2M tokens，换算成中文约 180-200 万汉字。实测一份 1.6 万字的 PDF（约 2.4 万 tokens）能一次塞进去并准确回答跨章节问题；一份 60 万字的小说合集（约 90 万 tokens）也能塞进去，但检索精度会下降——needle in haystack 测试显示 800K tokens 以上时准确率从 98% 掉到 89%。日常建议控制在 300K tokens 以内，超过就先做切片。
Q为什么要用 /v1/files 上传文件，直接把文本塞进 messages 不行吗？
短文本（几万字以内）直接塞没问题。但文档一大就有三个麻烦：一是每次提问都要重新传一遍全文，token 消耗是重复计费的；二是请求体过大容易超时；三是 Moonshot 对单次请求体有大小限制。用 /v1/files 上传一次拿到 file_id，之后多轮问答只引用 file_id，配合 Context Cache 命中部分按 1/10 计费，我们实测同一份文档问 20 个问题，成本从 ¥4.2 降到 ¥0.51。
QContext Cache 的 TTL 是多久，缓存没命中会怎样？
Moonshot 的缓存默认 TTL 约 5 分钟到 1 小时不等（取决于套餐），过期后第一次请求会重新建立缓存，表现为「明明问过同样的问题，这次变慢了」。不会报错，只是这一轮按原价计费并重新预热。如果你的群有固定文档要反复问，建议起一个定时任务每隔 3 分钟发一个极短请求保活。
Q群里发长文档问答，机器人经常十几秒才回，怎么优化？
长文档的首字延迟本来就高（实测 20 万 tokens 输入时首字 4.2 秒）。三个手段：一是务必用 Context Cache，命中后首字能降到 1 秒以内；二是改 AI 卡片流式，先占位再推送，用户感知完全不同；三是把 max_tokens 压到 800，群里没人看长篇大论。
QKimi K3 和 Kimi K2 / moonshot-v1 怎么选？
moonshot-v1 系列是上一代，上下文 128K，价格便宜，适合短问答；Kimi K3 是 2026 年旗舰，2M 上下文、工具调用更稳，适合长文档。钉钉群里的日常闲聊用 moonshot-v1-128k 更省钱，遇到「这份合同/这份报告怎么看」再切 K3。代码里可以用一条长度规则自动分流。
Q上传的 PDF 是扫描件，Kimi 能读吗？
纯扫描件（图片型 PDF）需要先做 OCR，Kimi 的文件解析对文本型 PDF 效果最好。实测：文本型 PDF 抽取准确率 97%，扫描件直接上传只有 61%（部分区域识别为空白）。建议上传前跑一遍 OCR（可用 PaddleOCR 或云厂商 OCR 服务），把结果存成 txt 再上传。