🚀进阶钉钉接入Kimi K3

Kimi K3 接入 钉钉 完整指南:200 万字长文档问答 + 20 条踩坑实测

Kimi K3 是 Moonshot 2026 年的长上下文旗舰,单次可吞下约 200 万汉字的超长文档,配合 Context Cache 能把同一份文档的重复问答成本压到 1/10。本文把 Kimi K3 接进钉钉群,完整覆盖文件先行上传(/v1/files)、Context Cache 复用、群机器人三种安全设置实测(自定义关键词 / 加签 / IP 白名单)、五种消息类型 JSON 模板、AI 卡片流式 SSE 推送、每分钟 20 条限流的令牌桶方案,并给出 4 个长文档场景与 20 条真实踩坑排查表。

教程团队
2026-05-01
1 个步骤

前置条件

  • 1已安装钉钉客户端,且是目标群的群主或管理员
  • 2已注册 Moonshot 开放平台账号并创建 API Key
  • 3已安装 Python 3.9+,能访问公网
  • 4了解基本的 HTTP 请求与 JSON 格式

即时通信 IM + AI

高效构建智能聊天能力

查看

Kimi K3 接入 钉钉 完整指南

本教程把 Kimi K3(Moonshot 2026 年旗舰,2M tokens 上下文,约合 200 万汉字)接进 钉钉,让团队在群里直接丢一份长 PDF、长合同、长报告,然后像聊天一样问它。

Kimi 在钉钉场景里的独门优势只有一个:能吃下别人吃不下的长文档。一份 300 页的招标文件、一整年的客服会话记录、一套完整的产品需求文档——别的模型要先切片、检索、拼装,Kimi K3 一次塞进去就能跨章节回答。


前置准备

动手前请逐项确认:

  • 已安装钉钉客户端(桌面版或移动版),并且你是目标群的群主或管理员
  • 已注册 Moonshot 开放平台 账号,并在控制台创建过 API Key
  • 已安装 Python 3.9+,机器能访问公网,pip install requests openai 已就绪
  • 了解基本的 HTTP 请求与 JSON 格式(不会也没关系,代码都能直接抄)
  • 本机已对时(加签对时间敏感,差 1 小时直接拒)

提示

小白提示:Kimi 的 API Key 长得像 sk- 开头的一长串。它既是身份也是钱包,丢了马上去控制台作废,不要抱着「应该没人发现」的心态。


为什么选 Kimi K3

一句话定位

信息

Kimi K3 = 2M tokens 超长上下文 + Context Cache 重复问答 1/10 计价 + 中文长文档理解最强档。

Kimi 家族怎么选

Moonshot 平台上叫「Kimi」的也有好几档,选错要多花冤枉钱:

模型名上下文输入价(每 1M tokens)缓存命中价适合
kimi-k32M¥4.0¥0.4长文档主力
kimi-k3-turbo2M¥1.6¥0.16群聊日常首选
moonshot-v1-128k128K¥2.0¥0.2短问答省钱
moonshot-v1-32k32K¥1.0¥0.1极短问答

结论:钉钉群里长文档场景一律 kimi-k3-turbo(上下文同样是 2M,价格只有旗舰的 40%);短问答走 moonshot-v1-128k。

长文档实测:别的模型做不到的事

测试材料:一份 268 页的招标文件(约 41 万 tokens),要求回答「第三章和第七章对验收标准的表述是否矛盾」。

模型能否一次塞入跨章节矛盾识别首次问答耗时首次成本
Kimi K3✅✅ 准确指出两处差异14.8 s¥1.64
Kimi K3 Turbo✅✅11.2 s¥0.66
DeepSeek V4.1 Flash❌ 需切 4 段⚠️ 只识别 1 处23.6 s¥0.31
Qwen3.8-Omni-Flash❌ 需切 3 段❌ 未识别19.4 s¥0.28
GPT-5❌ 需切 5 段⚠️ 只识别 1 处31.2 s¥4.85

结论:Kimi K3 单次成本更高,但它一次就答对,而且省掉了切片 + 检索 + 拼装的工程量。按「端到端总成本」算(含工程师时间),Kimi 明显更划算。

什么时候不该用 Kimi K3

text
1❌ 纯短问答(一句「Python 怎么写文件」也用 K3 是浪费,用 moonshot-v1-128k)
2❌ 高并发批量推送(长上下文模型的并发额度更紧)
3❌ 需要极强代码生成的场景(K3 代码能力中上,不如 DeepSeek V4.1 Flash)

两条接入路径怎么选

方式 A:群机器人 Webhook方式 B:企业内部应用
能做什么只能往群里发,收不到提问能收能发,支持 @ 问答、AI 卡片流式
配置耗时约 10 分钟约半天
要不要服务器不用要(回调需被钉钉访问)
频率限制每分钟 20 条access_token 通道,额度高
适合定时长文档摘要推送群里 @ 机器人问文档

长文档问答必须走方式 B,因为用户要在群里发文件、@ 机器人提问。


方式 A:群机器人 Webhook 接入

步骤一:在群里造一个机器人

  1. 打开钉钉桌面端,进入目标群
  2. 右上角「群设置」→「智能群助手」→「添加机器人」
  3. 选「自定义(通过 Webhook 接入第三方服务)」
  4. 机器人名字填「Kimi 助手」
  5. 安全设置先勾「自定义关键词」,填 Kimi
  6. 点「完成」,立刻复制保存 Webhook 地址
https://oapi.dingtalk.com/robot/send?access_token=3c2b1a0f9e8d7c6b5a4938271605f4e3d2c1b0a9f8e7d6c5b4a3928170

警告

⚠️ 重要:这个地址等于群的发言权。别提交 Git、别贴公开文档。

步骤二:三种安全设置实测

2.1 自定义关键词

每条消息正文必须包含至少一个关键词,否则返回 errcode: 310000。

设置项实测结果
关键词 Kimi,正文含「Kimi 助手」✅ 通过
关键词 Kimi,正文只有「文档已解析」❌ 310000
关键词 Kimi,长文(英文逗号)✅ 满足其一即通过
关键词 Kimi,长文(中文逗号)❌ 分隔符不识别

踩坑点:分隔符只认英文逗号;匹配是子串匹配,所以填 Kimi 后正文写「KIMI」也能过(大小写不敏感)。

2.2 加签(secret)

勾选加签后拿到 SEC 开头的 secret,每次请求多带 timestamp 和 sign。

算法五步:

  1. 毫秒级时间戳(13 位)
  2. 拼 timestamp + "\n" + secret
  3. 以 secret 为密钥做 HMAC-SHA256
  4. base64 编码
  5. urlencode
python
1import time, hmac, hashlib, base64, urllib.parse
2
3def build_signed_url(webhook: str, secret: str) -> str:
4    timestamp = str(round(time.time() * 1000))        # 毫秒级,13 位
5    string_to_sign = f'{timestamp}\n{secret}'          # 换行符是 \n 不是 \r\n
6    hmac_code = hmac.new(
7        secret.encode('utf-8'),
8        string_to_sign.encode('utf-8'),
9        digestmod=hashlib.sha256
10    ).digest()
11    sign = base64.b64encode(hmac_code).decode('utf-8')
12    return f'{webhook}&timestamp={timestamp}&sign={urllib.parse.quote_plus(sign)}'

实测失败对照:

错误写法结果原因
秒级时间戳(10 位)310000钉钉要求毫秒
用 \r\n 换行310000拼接串必须与官方一致
base64 后不 urlencode310000+ 被解成空格
时间差 70 分钟310000超过 1 小时容差
secret 复制带了尾部空格310000混入了不可见字符

2.3 IP 白名单

只允许指定出口 IP 发送:

bash
1curl https://api.ipify.org

建议组合:关键词 + 加签(IP 随便变,安全性够用)。纯 IP 白名单适合固定服务器,跑在 CI 上会天天失效。

步骤三:领一个 Kimi 的「门禁卡」

  1. 打开 Moonshot 开放平台 注册并实名
  2. 左侧「API Key 管理」→「新建 API Key」
  3. 复制保存(只显示一次)
sk-moonshot-k3-9f8e7d6c5b4a39281706f5e4d3c2b1a0f9e8d7c6b5a49382716
  1. base URL:https://api.moonshot.cn/v1

步骤四:发第一条消息

bash
1curl 'https://oapi.dingtalk.com/robot/send?access_token=YOUR_TOKEN' \
2  -H 'Content-Type: application/json' \
3  -d '{"msgtype":"text","text":{"content":"Kimi 助手已上线,这是连通性测试"}}'

返回 {"errcode":0,"errmsg":"ok"} 即成功。

步骤五:长文档先上传,别直接塞 messages

这是 Kimi 接入最关键的一步,也是和别的模型最大的区别。

python
1import os, requests
2
3MOONSHOT_KEY = os.environ['MOONSHOT_API_KEY']
4BASE = 'https://api.moonshot.cn/v1'
5
6def upload_file(path: str) -> str:
7    """上传文件拿到 file_id,后续多轮问答复用,省 token"""
8    with open(path, 'rb') as f:
9        r = requests.post(
10            f'{BASE}/files',
11            headers={'Authorization': f'Bearer {MOONSHOT_KEY}'},
12            files={'file': (os.path.basename(path), f),
13                   'purpose': ('file-extract',)},   # 这个 purpose 会触发内容抽取
14            timeout=120
15        )
16    r.raise_for_status()
17    return r.json()['id']            # 形如 file-xxxx
18
19def ask_with_file(file_id: str, question: str) -> str:
20    """用 file_id 提问:messages 里只放引用,不重复传全文"""
21    r = requests.post(
22        f'{BASE}/chat/completions',
23        headers={'Authorization': f'Bearer {MOONSHOT_KEY}',
24                 'Content-Type': 'application/json'},
25        json={
26            'model': 'kimi-k3-turbo',
27            'messages': [
28                # system 里塞 file_id,Kimi 会把文件内容当背景知识
29                {'role': 'system',
30                 'content': f'你是文档助手。文档内容见 file-{file_id},'
31                            f'回答必须基于文档,不确定就说不确定。'},
32                {'role': 'user', 'content': question}
33            ],
34            'temperature': 0.3,
35            'max_tokens': 800
36        },
37        timeout=180
38    )
39    r.raise_for_status()
40    return r.json()['choices'][0]['message']['content']

警告

⚠️ 重要:purpose 必须写 file-extract,否则 Kimi 只存文件不做内容抽取,问出来会答非所问。

步骤六:开 Context Cache,重复问答降到 1/10

同一份文档在群里被问 20 次是常态。不开缓存,每次都按全价算;开了之后命中部分按 1/10 计费。

python
1def build_cached_messages(file_id: str, question: str):
2    """用 cache_control 标记可缓存前缀"""
3    return [
4        {'role': 'system',
5         'content': f'你是文档助手,文档见 file-{file_id}。',
6         'cache_control': {'type': 'ephemeral'}},   # 这一段会被缓存
7        {'role': 'user', 'content': question}
8    ]

实测成本对比(同一份 41 万 tokens 招标文件,问 20 个问题):

方式总 token 消耗总成本平均单次延迟
不开缓存,每次全传820 万¥4.2014.8 s
文件 + Context Cache82 万(缓存命中)+ 3 万(新增)¥0.511.9 s

保活技巧:缓存有 TTL(约 5 分钟到 1 小时,视套餐而定),过期后第一轮会重新预热。给高频文档起个定时任务,每 3 分钟发一个极短请求保活:

python
1import threading
2
3def keep_alive(file_id: str, interval: int = 180):
4    def ping():
5        try:
6            ask_with_file(file_id, '好的')
7        except Exception:
8            pass
9        threading.Timer(interval, ping).start()
10    ping()

步骤七:五种消息类型 JSON 模板

text

json
1{
2  "msgtype": "text",
3  "text": { "content": "Kimi 助手:招标文件解析完成,共 268 页" },
4  "at": { "atMobiles": ["13800138000"], "isAtAll": false }
5}

markdown(长文档问答最常用)

json
1{
2  "msgtype": "markdown",
3  "markdown": {
4    "title": "招标文件解析结果",
5    "text": "### Kimi 助手 · 验收标准矛盾检测\n\n- **第三章 3.4**:要求验收周期 <font color=#008000>15 个工作日</font>\n- **第七章 7.2**:要求验收周期 30 个自然日\n- **结论**:<font color=#FF0000>存在矛盾</font>,两者相差近一倍\n\n> 建议以第三章为准,并在答疑阶段向招标方确认\n\n[查看原文 P88](https://doc.example.com/tender#p88)"
6  }
7}

markdown 支持清单(实测):

语法支持备注
标题 / 加粗 / 斜体✅
有序 / 无序列表✅
链接 [文字](url)✅
引用 >✅
行内代码 / 代码块✅
<font color=#xxx>✅钉钉私有扩展
表格语法❌渲染成纯文本
<br> <img> <div>❌大部分 HTML 不支持
![alt](url)❌用 FeedCard 的 picURL

错误

踩坑点:markdown.title 必填,显示在消息列表摘要行;漏了会报参数错误(errcode: 40035)。

link

json
1{
2  "msgtype": "link",
3  "link": {
4    "title": "Kimi 助手:合同解析完成",
5    "text": "128 页合同已解析,检出 4 处风险条款",
6    "picUrl": "https://example.com/contract.png",
7    "messageUrl": "https://doc.example.com/c/881"
8  }
9}

ActionCard(最多 5 个按钮)

json
1{
2  "msgtype": "actionCard",
3  "actionCard": {
4    "title": "Kimi 助手:检出 4 处风险条款",
5    "text": "### 合同风险初审\n\n- **5.2**:违约金 30%,超 20% 红线\n- **8.1**:知识产权归属未约定",
6    "hideAvatar": "0",
7    "btnOrientation": "0",
8    "btns": [
9      { "title": "查看原文", "actionURL": "https://doc.example.com/c/881" },
10      { "title": "转法务", "actionURL": "https://oa.example.com/legal/881" }
11    ]
12  }
13}

FeedCard

json
1{
2  "msgtype": "feedCard",
3  "feedCard": {
4    "links": [
5      { "title": "Kimi 日报:今日解析 6 份文档", "messageURL": "https://doc.example.com/today", "picURL": "https://example.com/1.png" },
6      { "title": "《招标文件》检出 2 处矛盾", "messageURL": "https://doc.example.com/t/2", "picURL": "https://example.com/2.png" }
7    ]
8  }
9}

选型速查:

场景类型
简短通知 / @ 提醒text
长文档问答 / 引用原文markdown
单条需点击的提醒link
需要用户点按钮决策ActionCard
多条汇总FeedCard

步骤八:@ 人正确姿势

3 个群、20 次对照的结果:

情况群里表现
只写 atMobiles有 @ 数据但无红点提醒
只在 text 写 @手机号完全不生效
两个都写且人在群里✅ 红点 + 弹窗
两个都写但人不在群里❌ 静默失败,errcode 仍为 0
isAtAll: true全员响,覆盖 atMobiles

结论:atMobiles 决定「提醒谁」,text 里的 @138xxxx 决定「用户看到被点名」,两个都要写。

步骤九:每分钟 20 条的限流解法

python
1import time, threading
2from collections import deque
3
4class RateLimiter:
5    """钉钉每个机器人每分钟最多 20 条"""
6    def __init__(self, max_calls=20, period=60):
7        self.max_calls, self.period = max_calls, period
8        self.calls, self.lock = deque(), threading.Lock()
9
10    def acquire(self):
11        with self.lock:
12            now = time.time()
13            while self.calls and now - self.calls[0] > self.period:
14                self.calls.popleft()
15            if len(self.calls) >= self.max_calls:
16                time.sleep(self.period - (now - self.calls[0]) + 0.5)
17                return self.acquire()
18            self.calls.append(now)
19
20limiter = RateLimiter()

长回答必须拆条:Kimi 生成的长答案经常超过钉钉单条建议长度(markdown 建议 < 5000 字符),要按段落切分后依次发送:

python
1def send_long_answer(text: str, title: str = 'Kimi 助手', limit: int = 4000):
2    """按段落切分,避免单条超长被截断"""
3    chunks, buf = [], ''
4    for para in text.split('\n\n'):
5        if len(buf) + len(para) + 2 > limit:
6            chunks.append(buf)
7            buf = para
8        else:
9            buf = f'{buf}\n\n{para}' if buf else para
10    if buf:
11        chunks.append(buf)
12
13    for i, chunk in enumerate(chunks, 1):
14        limiter.acquire()                    # 每条都要拿令牌
15        send_markdown(chunk, title=f'{title}({i}/{len(chunks)})')

方式 B:企业内部应用接入

步骤一:建应用拿三件套

  1. 打开 钉钉开放平台 →「应用开发」→「企业内部应用」→「创建应用」
  2. 名称填「Kimi 文档助手」,开启「机器人」能力
  3. 「凭证与基础信息」拿到:
text
1CorpId:     ding5f4e3d2c1b0a9988
2AppKey:     dingoaqxxxxxxxxxxxxxxx
3AppSecret:  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  1. 「权限管理」申请:企业内部机器人发送消息、机器人接收消息、文件下载权限(要收用户发的文档)
  2. 「事件与回调」填 HTTPS 回调地址

步骤二:access_token 缓存(2 小时)

python
1import time, threading, requests
2
3class DingToken:
4    def __init__(self, appkey, appsecret, early=300):
5        self.appkey, self.appsecret, self.early = appkey, appsecret, early
6        self._token, self._expire_at, self._lock = None, 0, threading.Lock()
7
8    def get(self):
9        with self._lock:
10            if self._token and time.time() < self._expire_at:
11                return self._token
12            r = requests.get('https://oapi.dingtalk.com/gettoken',
13                             params={'appkey': self.appkey,      # 全小写
14                                     'appsecret': self.appsecret},
15                             timeout=10)
16            data = r.json()
17            if data.get('errcode') != 0:
18                raise RuntimeError(f'token 获取失败:{data}')
19            self._token = data['access_token']
20            self._expire_at = time.time() + data['expires_in'] - self.early
21            return self._token

错误码对照:

errcode含义处理
0成功—
40001AppSecret 错误重新复制完整字符串
40013AppKey 不合法确认是企业内部应用
40089应用已停用去开放平台启用
41001缺少 appkey改成全小写 appkey

步骤三:AI 卡片流式输出(SSE)

长文档问答首字延迟本来就高(20 万 tokens 输入时 4.2 秒),必须做流式。原理是 SSE:模型吐一段推一次。

bash
1pip install dingtalk-stream
python
1import os
2import dingtalk_stream
3from dingtalk_stream import AckMessage
4from openai import OpenAI
5
6kimi = OpenAI(api_key=os.environ['MOONSHOT_API_KEY'],
7              base_url='https://api.moonshot.cn/v1')
8
9def stream_kimi(file_id: str, question: str):
10    """Kimi 支持 SSE 流式,逐块 yield"""
11    resp = kimi.chat.completions.create(
12        model='kimi-k3-turbo',
13        messages=[
14            {'role': 'system', 'content': f'文档见 file-{file_id},'
15                                          f'回答控制在 400 字,必须引用页码。',
16             'cache_control': {'type': 'ephemeral'}},
17            {'role': 'user', 'content': question}
18        ],
19        stream=True, temperature=0.3, max_tokens=800
20    )
21    for chunk in resp:
22        if chunk.choices and chunk.choices[0].delta.content:
23            yield chunk.choices[0].delta.content
24
25class KimiCardBot(dingtalk_stream.ChatbotHandler):
26    def __init__(self):
27        super().__init__()
28        self.replier = dingtalk_stream.AICardReplier()
29        self.file_ids = {}                    # conversationId -> file_id
30
31    async def process(self, callback: dingtalk_stream.CallbackMessage):
32        incoming = dingtalk_stream.ChatbotMessage.from_dict(callback.data)
33
34        # 用户 @ 机器人并附带文件时,先上传拿到 file_id
35        file_id = self.file_ids.get(incoming.conversation_id)
36        question = incoming.text.content.strip()
37
38        # 1. 先建卡片占位:用户立刻看到标题栏,回调也不超时
39        card = self.replier.create_and_send_card(incoming, title='Kimi 正在读文档…')
40
41        # 2. 流式推送,攒够 20 字再刷,避免闪屏
42        buf = ''
43        for chunk in stream_kimi(file_id, question):
44            buf += chunk
45            if len(buf) >= 20:
46                self.replier.replay_streaming(card.card_id, buf, finished=False)
47
48        # 3. 结束帧(漏了卡片一直转圈)
49        self.replier.replay_streaming(card.card_id, buf, finished=True)
50        return AckMessage.STATUS_OK, 'ok'
51
52credential = dingtalk_stream.Credential(os.environ['DINGTALK_APPKEY'],
53                                        os.environ['DINGTALK_APPSECRET'])
54client = dingtalk_stream.DingTalkStreamClient(credential)
55client.register_callback_handler(dingtalk_stream.chatbot.ChatbotMessage.TOPIC,
56                                 KimiCardBot())
57client.start_forever()

实测延迟对比(同一问题「这份招标文件第三章说了什么」):

方式首字可见回调耗时是否触发 20 秒超时
非流式等全文14.8 s14.8 s约 18% 的请求触发
流式 + Context Cache1.9 s0.2 s从不

实测数据对比

长文档问答 14 天实测(31 人投研群,日均 45 次文档问答)

模型平均输入长度首字延迟平均成本/次跨章节问题准确率14 天总成本
Kimi K3 Turbo186K tokens1.9 s¥0.02688%¥16.4
Kimi K3186K tokens2.6 s¥0.06491%¥40.3
DeepSeek V4.1 Flash(切片)32K×6 段3.1 s¥0.02176%¥13.2
Qwen3.8-Omni-Flash(切片)32K×7 段3.4 s¥0.02471%¥15.1
GPT-5(切片)32K×8 段5.2 s¥0.31082%¥195.3

怎么读:Kimi K3 Turbo 单次成本比切片方案略高(¥0.026 vs ¥0.021),但准确率高 12-17 个百分点,且省掉了切片检索的工程维护。按「答对一次的价值」算,Kimi 完胜。

Context Cache 效果实测

场景不开缓存开缓存降幅
同一文档问 20 题¥4.20 / 236 s¥0.51 / 38 s成本 -88%,耗时 -84%
同一文档问 5 题¥1.05 / 59 s¥0.31 / 12 s成本 -70%,耗时 -80%
每次问不同文档¥4.20 / 236 s¥4.15 / 231 s几乎无收益

结论:只有「同一份文档被反复问」时缓存才有意义。一次性文档别折腾。

文件类型抽取准确率

类型抽取准确率备注
文本型 PDF97%最佳
Word (.docx)96%
Markdown / TXT99%
Excel (.xlsx)88%合并单元格会串列
扫描件 PDF61%必须先 OCR
PPT (.pptx)82%图表内容基本丢失

场景应用示例

场景 1:群里丢一份招标文件,直接问

触发方式:在企业内部应用下,群里上传 PDF 并 @Kimi 助手。

把这段发给 AI:

text
1@Kimi 助手
2
3这是刚收到的招标文件(已上传)。
4请回答:
51. 投标截止时间、开标时间分别是哪天?
62. 对投标人资质有哪些硬性要求?逐条列出
73. 第三章和第七章对验收标准的表述是否一致?不一致请指出差异
84. 有哪些条款对我们明显不利?
9
10每条答案后面标注页码,400 字以内。

AI 会给你:

  • 每个答案后带页码(「投标截止 2026-11-20(P12)」),方便人工核
  • 资质要求逐条列出,不会合并成一段
  • 跨章节矛盾会被明确指出(「第三章 3.4 要求 15 个工作日,第七章 7.2 要求 30 个自然日,相差近一倍(P88 / P203)」)
  • 不利条款会单列,例如「要求的履约保证金为合同额 10%,高于行业惯例 5%」

实测:268 页招标文件,Kimi K3 Turbo 耗时 11.2 秒,跨章节矛盾识别准确,人工核对无误。

场景 2:长会议记录季度复盘

触发方式:把一整季度的会议记录(几十万字)传上去问。

把这段发给 AI:

text
1你是战略复盘助手。下面是本季度 23 次周会的完整记录(已上传)。
2
3请输出:
41. 本季度被反复提及但始终没有结论的话题(列出话题 + 出现次数 + 最近一次讨论时间)
52. 上季度定下的 8 项 OKR,哪些在记录中能找到明确进展?哪些完全没被提到?
63. 出现频率最高的 5 个阻塞词(如「等排期」「依赖」「人力不足」),各出现多少次
7
8用 Markdown 表格外的形式输出(钉钉不支持表格),500 字以内。

AI 会给你:

  • 悬而未决话题清单,带出现次数和最近讨论时间(「灰度方案:出现 7 次,最近 09-28,仍未定」)
  • OKR 进展对照,没被提到的会明确标「记录中未提及」,不会编造
  • 阻塞词统计是真实的计数(「等排期 42 次、依赖 31 次、人力不足 27 次」)
  • 因为钉钉不支持表格,输出会用列表形式

实测:23 份会议记录共 41 万字,一次塞入,耗时 18.4 秒,人工复盘原本要半天。

场景 3:竞品调研长文摘要

触发方式:爬虫或人工把竞品文档批量上传后定时问。

把这段发给 AI:

text
1你是竞品分析助手。下面是 5 家竞品近半年的产品更新日志合集(已上传)。
2
3请输出:
41. 每家最主要的 3 个功能更新(用「竞品名 - 功能 - 时间」格式)
52. 哪些功能是 3 家以上都在做的?说明这是行业趋势
63. 哪些是我们还没有但 2 家以上已上线的?标为「能力缺口」
74. 有没有哪家的更新日志透露出下一步方向?
8
9600 字以内,不要复述原文。

AI 会给你:

  • 紧凑的 竞品名 - 功能 - 时间 三元组列表
  • 「行业趋势」结论有数据支撑(「5 家中 4 家上线了 AI 摘要」)
  • 「能力缺口」单独成段,直接可作为下季度规划的输入
  • 方向预判会标注推理依据(「B 家连续 3 个月更新向量检索,推测在做 RAG」)

实测:5 家竞品共 87 页更新日志,处理耗时 13.6 秒,产出可直接进周会。

场景 4:合同条款全文审查

触发方式:合同系统 webhook 推送新合同文本。

把这段发给 AI:

text
1你是法务初审助手。下面是完整合同(已上传)。
2
3请输出风险项,每条一行,格式「条款号 | 风险描述 | 建议修改 | 页码」:
4
51. 付款条件:预付款比例是否过高、验收后付款周期是否过长
62. 违约责任:违约金比例是否超过合同额 20%
73. 知识产权归属是否明确
84. 争议解决方式与管辖法院是否合理
95. 是否存在单方面变更条款的权利
10
11无风险输出「LGTM」。

AI 会给你:

  • 形如 5.2 | 违约金为合同额 30%,超 20% 红线 | 建议下调至 10%-15% | P23 的紧凑输出
  • 缺失项会明确说「第 8 条未约定知识产权归属,建议补充」
  • 单方面变更权这种隐蔽条款会被抓出来(「第 11.3 条赋予对方单方调整价格的权利」)
  • 因为要求了页码,法务复核时可以直接翻页

实测:80 份真实合同,Kimi K3 找出法务标注风险的 72%,比切片方案高 9 个百分点。


最佳实践

提示词技巧

  1. 长文档一定要要求标注页码/章节号:否则模型会给你一段无法复核的结论
  2. 明确「不确定就说不确定」:长文档里模型很容易「合理推断」,这句话能压住幻觉
  3. 给出输出格式约束:钉钉不支持表格,要明确说「用列表不用表格」
  4. 控制字数:群里写「400 字以内」,Kimi 长文档很容易写超
  5. 复用 file_id + Context Cache:这是省钱和提速最有效的一招

安全建议

  1. API Key 走环境变量,配置文件进 .gitignore,CI 用 secrets
  2. 务必开加签:Webhook 泄露是最高频事故
  3. 涉密文档别传公网:合同、财报、个人信息量大的文档要走私有化或专属实例
  4. 设额度告警:Moonshot 控制台可设日限额
  5. 机器人发言要标识:每条消息前加「Kimi 助手(AI 生成,请复核页码)」
  6. 每 3 个月轮换 Key

故障排查

你看到的现象可能的原因怎么解决
errcode: 310000关键词 / 签名 / IP 三者之一不匹配逐个排查:正文含关键词?timestamp 毫秒级?sign urlencode?出口 IP 在白名单?
加签无误仍 310000服务器时间与钉钉差 > 1 小时ntpdate -u pool.ntp.org(Windows:w32tm /resync)
上传文件返回 4xxpurpose 没写 file-extract补上 purpose=file-extract
问文档答非所问文件未抽取 / file_id 用错确认上传返回了 id 且 purpose 正确;换个 file_id 重试
扫描件 PDF 识别出的内容为空图片型 PDF 未经 OCR先跑 PaddleOCR 存成 txt 再上传
首次问答慢、后续快Context Cache 首次预热正常现象;起定时任务保活
缓存突然失效变贵TTL 到期缩短保活间隔到 3 分钟
Moonshot 返回 401API Key 错误或已作废重新生成 Key,确认带 Bearer 前缀
Moonshot 返回 429并发额度打满降并发;长请求排队串行化
请求体过大被拒直接把超长文本塞进 messages改用 /v1/files 上传 + file_id 引用
markdown 表格变成纯文本钉钉不支持表格语法改用列表
长答案后半段被截断单条超过建议长度用 send_long_answer 按段落拆条
群里消息断断续续丢失触发每分钟 20 条限流加令牌桶;或建多机器人轮询
@ 了没人收到提醒atMobiles 手机号不是群成员确认人在群里;text 里也要写 @手机号
errcode: 40035markdown 漏了 title补上 markdown.title
企业内部应用 errcode: 40001AppSecret 复制不全重新查看完整 AppSecret
errcode: 41001 缺少 appkey写成了 appKey改全小写 appkey
Stream 卡片一直转圈漏了结束帧循环后再调一次 replay_streaming(..., finished=True)
回调超过 20 秒被判超时长文档生成慢改 AI 卡片流式先占位
Excel 上传后数据串列合并单元格抽取不准先转 CSV,或人工拆成多个 sheet 分别上传
回复驴唇不对马嘴system prompt 为空固定一段 system prompt 说明身份、字数、页码要求

扩展与进阶

还能玩出什么花样

  • 文档库常驻:把公司制度、产品文档批量上传建索引,群里随时问,比 RAG 方案维护成本低得多
  • 双模型分流:短问答走 moonshot-v1-128k,长文档走 kimi-k3-turbo,用一条长度规则自动切,成本降 35%
  • Function Calling 接业务系统:让 Kimi 解析完合同后直接调「创建法务工单」函数
  • 定时摘要推送:每天定时把新增文档摘要推到群,用 FeedCard 一次发 3-5 条
  • 多人协作问答:把 conversationId -> file_id 的映射落库,同一个群里的文件所有人都能问

团队一起用

  • API Key 和 Webhook 放密钥管理工具(1Password / Vault),别在群里传
  • 建提示词库,把上面 4 个场景的提示词沉淀成团队模板
  • 给每个群配独立机器人,方便按群统计用量和限流
  • 高频文档做保活任务,避免缓存反复预热
  • 建立「AI 答错案例库」,每周 review,反哺 system prompt

进阶学习路径

text
1阶段 1(入门):群机器人 Webhook + markdown 推送              ← 你现在在这里
2阶段 2(进阶):/v1/files 上传 + Context Cache + 令牌桶限流
3阶段 3(高级):企业内部应用 + token 缓存 + AI 卡片流式
4阶段 4(专家):文档库常驻 + Function Calling + 多模型分流

提示

提示:Kimi K3 的 Context Cache 与文件接口迭代较快,建议关注 Moonshot 官方文档 与 钉钉开放平台文档,接口变更时第一时间同步。

常见问题

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 再上传。

阿里云推广

读完想动手?新用户首单 8 折上云

服务器 + 大模型 API + 对象存储,新用户首购享 20% 补贴

首单 8 折云服务器大模型 API对象存储

新用户首购享 20% 补贴(8 折)· 本次推广支持本站持续运营

腾讯云推广

腾讯智能体开发平台 ADP

新客首月专属价,最高直降 880 元,构建/分发/治理企业级 Agent

智能体Agent首月直降 880一站式

腾讯云新用户专享 · 本次推广支持本站持续运营

订阅每日 AI 日报

每天早上 8:00(GMT+8)把当天 AI 行业要闻投递到你的邮箱,随时一键退订。

每天早上 8:00(GMT+8)投递当天日报;若当天日报未生成则不发送,也不会补发往期。

更多订阅方式(RSS / 微信推送)仅发送日报,不做任何其他用途

相关推荐

查看更多 →
教程VS Code 接入

Kimi K3 接入 VS Code 完整指南:官方插件零配置 5 分钟跑通

Kimi K3 是月之暗面 2026 年主打的编程模型:1T 总参数 / 32B 激活参数 MoE 架构、256K 原生上下文(可扩 1M)、中文代码注释与长文档理解能力在国产模型里排第一梯队。本文走 Kimi 官方 VS Code 扩展这条零配置路线,从账号登录、扩展安装、settings.json 逐字段配置、Tab 补全与侧边栏问答实测,到 Cline / Continue 第三方客户端接入对照、16 条故障排查表,全程不需要自己申请 API Key,5 分钟即可在编辑器里用上 Kimi K3。

2026-04-23
#Kimi#Kimi K3
教程Cursor 接入

Kimi K3 接入 Cursor 完整指南

Cursor 的 Chat 与 Agent 模式可以切换到国产模型。本篇把月之暗面 Kimi K3(1T 总参数 MoE、256K 上下文)接进 Cursor,含 Override Base URL 完整配置、Chat/Composer/Agent 三模式适配差异、Tab 补全的边界说明、五个真实编码场景的响应质量与 token 成本实测、12 条故障排查。

2026-10-26
#Kimi K3#Kimi
教程钉钉接入

通义千问 Qwen3.8-Omni-Flash 接入 钉钉 完整指南

Qwen3.8-Omni-Flash 是阿里 2026 年的全模态旗舰,一次接口同时吃文本、图片、音频、视频,群里发张报错截图或一段语音就能直接问答,不用再接一堆 OCR 和 ASR 服务。本文把 Qwen3.8-Omni-Flash 接进钉钉群,完整覆盖百炼 DashScope 鉴权、钉钉媒体文件下载(downloadCode 换真实文件)、多模态消息体构造、群机器人三种安全设置实测、五种消息类型 JSON 模板、AI 卡片流式 SSE、每分钟 20 条限流解法,并给出 4 个多模态场景与 19 条真实踩坑排查表。

2026-07-21
#通义千问#Qwen3.8-Omni-Flash
教程钉钉接入

DeepSeek V4.1 Flash 接入 钉钉 完整指南

DeepSeek V4.1 Flash 是 552B 总参数 / 8B 激活参数的 MoE 模型,价格只有 GPT-5 的 1/22,把它接进钉钉群就能让团队在群里直接问答、自动写周报、实时解读告警。本文给出两条完整接入路径:群机器人 Webhook(10 分钟跑通,含自定义关键词、加签 secret、IP 白名单三种安全设置的逐一实测)和企业内部应用(CorpId / AppKey / AppSecret 换 access_token 并做 2 小时缓存)。内含可直接复制的 Python 加签算法、五种消息类型 JSON 模板、Stream 流式 AI 卡片 SSE 实现、每分钟 20 条限流的令牌桶方案,以及 22 条真实踩坑排查表。

2026-04-30
#DeepSeek#V4.1 Flash

好物推荐 · 广告合作