·
三种打通方向定位
同一套钉钉开放平台基础之上，按交互方向划分为三类：前两类已落地上线，第三类为规划中的能力扩展。
单向
推送与取数
系统主动取数、分析后推送到群。对应场景一：客户跟进周报自动化。
已上线
双向
对话问答
群内 @ 机器人提问，机器人检索知识库后回答。对应场景二。
已上线
读写与事件
能力扩展
读写审批 / 待办 / 日程 / 文档 / 通讯录，并响应审批等事件。
规划中
1
客户跟进看板周报自动化
把维护在钉钉多维表里的客户跟进看板，每周一自动汇总为周报推送到钉钉群，全程无人工介入。
整体链路 · 四段流水线
01 取数
读多维表
调钉钉多维表接口，自动翻页一次拉全表
→
02 分析
多维度统计
按优先级、阶段、产品、地域等分类汇总
→
03 生成
组织周报
总览表 + 分布统计 + 高优清单 + 看板链接
→
04 推送
送达群里
自定义群机器人加签推送卡片
系统架构 · 分层全景
⏰ 触发层
定时任务 · 每周一 09:00到点自动触发，无人介入
手动触发 · 一键脚本一键主脚本随时可跑
▼
🧠 执行主体 · 一键主脚本
纯标准库脚本（无第三方依赖）本地 / 内网运行，串联下方四段流水线
▼
⚙️ 核心流水线
①取数钉钉多维表接口，自动翻页拉全表 → 结构化数据
→
②分析按优先级 / 阶段 / 产品 / 地域统计，识别新增与 P0 清单
→
③生成标题 + 总览表 + 分布 + 重点清单 + 看板链接
→
④推送群机器人 Webhook + HMAC-SHA256 加签送达
▼送达
📱 钉钉群
收到结构化周报卡片每周一零操作出周报
实际效果 · 图 1：周报推送到群
技术底座 · 两套凭证
| 凭证 | 来源 | 用途 |
|---|---|---|
| 群机器人 Webhook + 加签密钥 | 钉钉群设置 → 群机器人 → 自定义 | 推送消息到群 |
| 企业内部应用 AppKey / AppSecret | 钉钉开放平台创建企业应用 | 调用接口读取多维表 |
关键参数 · baseId
多维表 ID，表搬入组织后会变化，需重新提取
关键参数 · operatorId
操作人身份（管理员 unionId），多维表接口强制要求
所需权限
Notable.Base.Read.All 多维表读取 ＋ 通讯录成员读取!
一句话总结：真正的难点不在写代码，而在「表的所有权」这条生死线。一旦把表搬进签发令牌的组织、补齐 operatorId，整条「取数 → 分析 → 生成 → 推送」即可彻底自动化，每周一零操作出周报。
2
钉钉 × 乐享知识库 问答机器人
员工在钉钉群里 @ 机器人提问，机器人自动检索乐享知识库，把答案摘要与出处链接回到群里，约 2–4 秒返回。
业务流程 · 四段链路
01 用户侧
群内 @ 提问
员工在钉钉群 @ 机器人发出问题
→
02 执行侧
常驻进程
长连接收消息，去前缀后转给检索大脑
→
03 知识库
乐享语义检索
乐享知识库检索 + 重排，返回切片与文档出处
→
04 回写
返回群里
组装「答案摘要 + 出处链接」卡片
系统架构 · 分层全景
📱 钉钉群（用户侧）
员工 @ 机器人提问消息经钉钉服务端，通过 Stream 长连接推达执行进程
▼Stream 长连接（免公网域名）
🖥️ 生产服务器 · systemd 守护进程
Stream 客户端建 WebSocket 收消息，去 @ 前缀提取问题
→
检索大脑把问题转交乐享知识库，拿回结果后组装答案卡片
▼独立端点 + 静态令牌调用
📚 乐享知识库（检索侧）
语义检索 + 重排返回最相关切片与文档出处链接，可溯源、低幻觉
▲答案摘要 + 出处链接 原路返回群里
实际效果 · 图 2：群内 @ 机器人问答
关键技术决策 · 为什么这么选
| 决策点 | 选择 | 理由 |
|---|---|---|
| 大脑选型 | 乐享知识库检索（RAG） | 比裸接大模型准确、可溯源、低幻觉；比接完整 CLI 轻量、响应快 |
| 消息接收方式 | Stream 长连接 | 程序主动建 WebSocket，无需公网域名、备案、反向代理与开放端口 |
| 知识库鉴权 | 乐享独立端点 + 静态令牌 | 脱离客户端授权态，服务器进程用静态令牌即可独立调用乐享检索 |
部署形态 · systemd 守护
| 本地运行 | 生产服务器 systemd |
|---|---|
| 会话回收即终止 | 注册为系统服务，独立于任何会话 |
| 休眠 / 关机掉线 | 服务器 7×24 不关机 |
| 进程崩溃无人接管 | 崩溃自动拉起 ＋ 开机自启 ＋ 定时刷新连接 |
!
三条最值钱的经验：一是大脑选型——知识库问答场景，用「乐享知识库检索」最优；二是凭证独立性是生死线，动手前先验证服务器进程能否脱离客户端独立调用乐享；三是常驻进程必须上服务器，systemd 守护才是 7×24 在线的唯一正路。
3
能力扩展 · 读写审批 / 待办 / 日程 / 文档 / 通讯录
在前两个场景同一套企业应用与长连接底座之上，进一步打通五类读写能力，并被动响应审批等事件。本场景尚未落地，此处先呈现能力评估与串联设想，供后续决策。
底座复用 · 一进一出双通道
📤 主动通道（读 / 写）
WorkBuddy / 脚本 → 换取访问令牌 → 调用钉钉开放接口按需驱动：审批 · 待办 · 日程 · 文档 · 通讯录五类读写
▼复用前两场景的企业应用凭证
📥 被动通道（事件）
钉钉服务端 → 事件推送 → 复用场景二 Stream 长连接 → 事件处理审批状态变更等事件回流，自动播报或触发后续动作
五类能力 · 实现程度评估
👥
通讯录
可做 · 稳程度：查部门树、查成员、姓名/手机解析为 unionId、查管理员均可做，只读权限易开。场景一已部分用到。
典型场景
作为其他能力的地基：派待办、约日程前先把「姓名」解析成 unionId
自动维护一张「部门—人员」花名册
✅
待办
可做 · 最干净程度：给指定人创建待办、标记完成 / 删除、查某人待办列表均可做，几乎无卡点，只需目标人 unionId。
典型场景
周报分析出 P0 线索 → 自动给负责人派「48h 内回访」待办
会议纪要里的待办项 → 自动拆成待办分发
📅
日程
可做 · 主体程度：查某人某天日程、创建日程 / 会议、改时间 / 取消均可做。注意：查他人日程受隐私约束，可能仅能看忙闲，会议室预订依赖组织资源配置。
典型场景
「和某人约个明天下午的 30 分钟」→ 查双方忙闲 → 自动建日程
客户回访 → 自动在负责人日历落一个带提醒的日程
📄
文档 / 知识库
部分验证程度：多维表读 / 写已实测打通（场景一上线）；普通在线文档正文为富文本块结构，读取可行，精准写入排版仍是难点，需再验证。
典型场景
已落地：从多维表拉客户数据 → 分析 → 推周报
新增：把分析结论回写到多维表做留痕；资料自动归档进知识库
📝
审批
读+发起可做 · 自动签字慎用程度：查审批实例、程序发起审批、监听状态变更事件均可做；程序自动同意 / 拒绝技术可行，但等同机器人替人签字，属流程责任问题，建议永远保留人工兜底。
典型场景
报销 / 请假提交后 → 自动播报到群「某人提交报销，待审批」
超过 N 小时未审批 → 自动催办；极低风险审批满足条件自动通过
🔔
事件响应（被动）
可做 · 复用长连接程度：在场景二已有的 Stream 长连接上追加注册事件回调即可，无需新开连接。订阅审批任务 / 实例变更等事件。
典型场景
审批状态变更 → 自动播报结案 / 触发后续待办
新人入职事件 → 自动建一串入职待办并拉群
串联闭环 · 单点不稀奇，价值在串起来
五类能力单独看都不稀奇，真正的杀伤力在于把它们串成一条自动运营链路——一次客户跟进，从识别到结案全程机器人接力，人只在关键节点介入。
1
多维表分析出 P0 线索文档
复用场景一：每周自动从客户跟进看板拉数、分析，识别出高优先级线索
▼
2
解析负责人身份 → 自动派回访待办通讯录待办
把负责人姓名解析成 unionId，给其创建「48h 内回访客户」待办
▼
3
自动约回访日程日程
查负责人与客户忙闲，在双方日历落一个带提醒的回访日程
▼
4
回访完提交审批审批
回访产生的报价 / 折扣等，由负责人在钉钉发起审批走流程
▼
5
审批事件回流 → 自动播报结案事件
Stream 监听到审批通过事件，自动在群里播报结案，并可触发下一轮待办
↻ 结案数据回写多维表，进入下一周分析，形成闭环
!
一句话总结：场景三与前两个场景并非全新工程，而是同一套企业应用能力的延伸——主动通道多封装几个接口调用，被动通道在现有长连接上多注册几个事件回调。稳的是通讯录 / 待办 / 日程 / 事件响应，需谨慎的是审批自动签字与普通文档精准写入。串成闭环后，即是「钉钉里的自动运营助手」，而非五个孤立功能。