聊到企业微信 API 二次开发多数团队第一反应是做客户侧智能客服、自动回复、群运营。但实际做完一两年会发现客户侧的场景已经被卷得很透反倒是企业内部还有大片空白——员工日常查询、流程发起、办公辅助这些高频动作还在靠人手动操作。这篇聊聊怎么用 Eyun 企业微信 API 把内部智能助手搭起来给员工自己用。一、内部助手和外部客服的根本差异很多人拿做客服那套思路做内部助手上线就翻车。两者面向的对象、诉求、合规要求完全不同维度外部客服内部助手用户客户、陌生人员工、可识别身份交互频率低频、一次性高频、每天用数据权限仅客户自己的数据跨部门、需细粒度授权响应期待准确即可准确 快 主动失败容忍转人工兜底必须可用没人工兜底最关键的差异是权限。客服只能看一个客户自己的订单内部助手要让 HR 查全员薪资、让销售总监看全团队跟进、让财务调阅全公司预算。这套权限体系做不严直接就是个合规事故。所以做内部助手第一件事不是接 LLM是接身份系统。二、身份识别把企微消息对应到员工Eyun 企业微信 API 推过来的回调报文里单聊消息携带发送方的uin和openid但这两个值是企微侧的标识不等于公司 HR 系统里的工号。要把消息对应到具体员工需要走这么一条链路调 联系人模块 的getUserProfileDetail用 uin 列表反查员工详情。拿到详情里的corpId、userId、department等字段。用userId去 HR 系统里查工号、岗位、所在事业部。这一步看起来啰嗦但有了完整的员工档案后面所有权限判断、个性化回复才有依据。建议在数据库里维护一张企微标识 ↔ 工号映射表每天全量同步一次回调来的时候直接查表不要每次都走接口。三、典型场景哪些事适合交给助手内部助手最有价值的场景是那些做一次不复杂、但每天做就很烦的事。列几个实测受欢迎的信息查询类查本人本月考勤、剩余年假查某个客户经理名下的客户列表查某笔报销单当前审批节点查某产品当前库存流程发起类发起请假审批发起报销发起用印申请办公辅助类把会议纪要转成任务并指派自动汇总今日待办把一段语音转文字发到指定群每类场景背后都对应一组 API 调用助手做的事情就是理解员工意图 → 调对应接口 → 把结果格式化发回。听起来和外部客服差不多但内部场景的关键在于主动触发员工不问助手也该推。四、主动推送内部助手的灵魂外部客服是被动等客户问内部助手得主动推。原因很简单员工不知道要问什么的时候恰恰是最需要助手的时候。比如早上 9 点推送今日日程和待办报销审批被退回时立即提醒修改客户跟进超期自动提醒周五下午推送本周客户互动统计这些都靠 Eyun 企业微信 API 的主动消息能力实现。定时任务扫业务系统数据命中条件就调sendText或sendRichText把消息推到对应员工的会话里。技术上不难难在触发规则设计——什么时候推、推给谁、推几次、不打扰。我们踩过的坑一开始报销审批提醒每两小时推一次结果被员工集体投诉。后来改成审批被退回立即推一次 临近下班前再推一次效果好得多。频次不是越多越好是要踩在员工真正会行动的时点。五、意图识别与命令式交互内部助手因为使用频率高员工会自然演化出指令化的提问方式不是问我本月还剩多少年假而是直接发年假。这种短输入用 LLM 走意图分类反而容易翻车——上下文太短、意图空间太大。工程上更稳的做法是命令 自然语言混合以/或#开头的视为命令直接路由到对应处理函数。短输入≤4 字走关键词匹配表命中就执行没命中就反问澄清。长输入走 LLM 做意图识别和参数抽取。输入样式路由响应#请假 3天命令解析直接发起流程年假关键词表查询剩余并返回我这个月还剩多少年假LLM 识别查询剩余并返回帮我看看张三最近跟进的客户LLM 权限校验鉴权后返回列表这种分层路由能让 80% 的常见操作走快路径LLM 只处理剩下的复杂语义整体延迟和成本都可控。六、权限内部助手最大的坑前面说了权限是内部助手的核心难点具体展开数据级权限HR 能看全员薪资销售只能看本团队客户。同样是查客户列表的意图不同人查出来的范围不同。操作级权限普通员工能发起请假主管能审批请假HR 能调整额度。同样是请假命令不同岗位执行不同分支。审计要求所有跨部门数据查询要留痕谁在什么时候查了什么。工程实现上意图识别之后不要直接调业务接口中间插一层权限网关拿员工工号 意图 参数去权限中心问一次能不能做、能做哪个范围再带着这个范围调业务接口。这一层看起来多一跳但能挡住绝大多数越权事故。七、与企业内部系统的打通方式内部助手要真正有用必须连进 OA、HR、CRM、ERP 这些存量系统。连接方式有三种直连数据库最快但绕开了业务系统的权限和审计不推荐。调业务系统 API规范但很多老系统根本没有 API。走中台建一个企业服务总线助手只跟中台对话中台再去适配各业务系统。最规范但工作量大。新公司从零搭推荐方案 3。存量系统改造不了的可以用方案 2 加一层适配。除非系统要废弃了否则别走方案 1后期补权限和审计的成本远大于前期省的。八、效果度量的不同维度外部客服看 CSAT、看转人工率内部助手的度量维度完全不同渗透率多少员工至少用过一次周活每周有多少员工在用任务完成率助手处理完之后员工没有再去找人工节省工时粗略估算每个任务员工手动做要多久、助手做要多久差值乘以频次最后一项是给老板汇报时最有说服力的指标。我们内部助手上线半年每周节省工时约 320 小时相当于多了 0.8 个全职人力。这个数字比问答准确率 92%听起来直观得多。写在最后用 Eyun 企微平台 做内部智能助手是个被低估的方向。客户侧卷得死去活来的时候内部助手的场景反而空白多、价值高、容易做出差异化。难点不在 API 调用而在身份打通、权限管控、主动触发规则。把这些工程细节做扎实员工每天用一次的助手就立住了。 企业微信二次开发的新玩法：用API接口构建企业内部智能助手
聊到企业微信 API 二次开发多数团队第一反应是做客户侧智能客服、自动回复、群运营。但实际做完一两年会发现客户侧的场景已经被卷得很透反倒是企业内部还有大片空白——员工日常查询、流程发起、办公辅助这些高频动作还在靠人手动操作。这篇聊聊怎么用 Eyun 企业微信 API 把内部智能助手搭起来给员工自己用。一、内部助手和外部客服的根本差异很多人拿做客服那套思路做内部助手上线就翻车。两者面向的对象、诉求、合规要求完全不同维度外部客服内部助手用户客户、陌生人员工、可识别身份交互频率低频、一次性高频、每天用数据权限仅客户自己的数据跨部门、需细粒度授权响应期待准确即可准确 快 主动失败容忍转人工兜底必须可用没人工兜底最关键的差异是权限。客服只能看一个客户自己的订单内部助手要让 HR 查全员薪资、让销售总监看全团队跟进、让财务调阅全公司预算。这套权限体系做不严直接就是个合规事故。所以做内部助手第一件事不是接 LLM是接身份系统。二、身份识别把企微消息对应到员工Eyun 企业微信 API 推过来的回调报文里单聊消息携带发送方的uin和openid但这两个值是企微侧的标识不等于公司 HR 系统里的工号。要把消息对应到具体员工需要走这么一条链路调 联系人模块 的getUserProfileDetail用 uin 列表反查员工详情。拿到详情里的corpId、userId、department等字段。用userId去 HR 系统里查工号、岗位、所在事业部。这一步看起来啰嗦但有了完整的员工档案后面所有权限判断、个性化回复才有依据。建议在数据库里维护一张企微标识 ↔ 工号映射表每天全量同步一次回调来的时候直接查表不要每次都走接口。三、典型场景哪些事适合交给助手内部助手最有价值的场景是那些做一次不复杂、但每天做就很烦的事。列几个实测受欢迎的信息查询类查本人本月考勤、剩余年假查某个客户经理名下的客户列表查某笔报销单当前审批节点查某产品当前库存流程发起类发起请假审批发起报销发起用印申请办公辅助类把会议纪要转成任务并指派自动汇总今日待办把一段语音转文字发到指定群每类场景背后都对应一组 API 调用助手做的事情就是理解员工意图 → 调对应接口 → 把结果格式化发回。听起来和外部客服差不多但内部场景的关键在于主动触发员工不问助手也该推。四、主动推送内部助手的灵魂外部客服是被动等客户问内部助手得主动推。原因很简单员工不知道要问什么的时候恰恰是最需要助手的时候。比如早上 9 点推送今日日程和待办报销审批被退回时立即提醒修改客户跟进超期自动提醒周五下午推送本周客户互动统计这些都靠 Eyun 企业微信 API 的主动消息能力实现。定时任务扫业务系统数据命中条件就调sendText或sendRichText把消息推到对应员工的会话里。技术上不难难在触发规则设计——什么时候推、推给谁、推几次、不打扰。我们踩过的坑一开始报销审批提醒每两小时推一次结果被员工集体投诉。后来改成审批被退回立即推一次 临近下班前再推一次效果好得多。频次不是越多越好是要踩在员工真正会行动的时点。五、意图识别与命令式交互内部助手因为使用频率高员工会自然演化出指令化的提问方式不是问我本月还剩多少年假而是直接发年假。这种短输入用 LLM 走意图分类反而容易翻车——上下文太短、意图空间太大。工程上更稳的做法是命令 自然语言混合以/或#开头的视为命令直接路由到对应处理函数。短输入≤4 字走关键词匹配表命中就执行没命中就反问澄清。长输入走 LLM 做意图识别和参数抽取。输入样式路由响应#请假 3天命令解析直接发起流程年假关键词表查询剩余并返回我这个月还剩多少年假LLM 识别查询剩余并返回帮我看看张三最近跟进的客户LLM 权限校验鉴权后返回列表这种分层路由能让 80% 的常见操作走快路径LLM 只处理剩下的复杂语义整体延迟和成本都可控。六、权限内部助手最大的坑前面说了权限是内部助手的核心难点具体展开数据级权限HR 能看全员薪资销售只能看本团队客户。同样是查客户列表的意图不同人查出来的范围不同。操作级权限普通员工能发起请假主管能审批请假HR 能调整额度。同样是请假命令不同岗位执行不同分支。审计要求所有跨部门数据查询要留痕谁在什么时候查了什么。工程实现上意图识别之后不要直接调业务接口中间插一层权限网关拿员工工号 意图 参数去权限中心问一次能不能做、能做哪个范围再带着这个范围调业务接口。这一层看起来多一跳但能挡住绝大多数越权事故。七、与企业内部系统的打通方式内部助手要真正有用必须连进 OA、HR、CRM、ERP 这些存量系统。连接方式有三种直连数据库最快但绕开了业务系统的权限和审计不推荐。调业务系统 API规范但很多老系统根本没有 API。走中台建一个企业服务总线助手只跟中台对话中台再去适配各业务系统。最规范但工作量大。新公司从零搭推荐方案 3。存量系统改造不了的可以用方案 2 加一层适配。除非系统要废弃了否则别走方案 1后期补权限和审计的成本远大于前期省的。八、效果度量的不同维度外部客服看 CSAT、看转人工率内部助手的度量维度完全不同渗透率多少员工至少用过一次周活每周有多少员工在用任务完成率助手处理完之后员工没有再去找人工节省工时粗略估算每个任务员工手动做要多久、助手做要多久差值乘以频次最后一项是给老板汇报时最有说服力的指标。我们内部助手上线半年每周节省工时约 320 小时相当于多了 0.8 个全职人力。这个数字比问答准确率 92%听起来直观得多。写在最后用 Eyun 企微平台 做内部智能助手是个被低估的方向。客户侧卷得死去活来的时候内部助手的场景反而空白多、价值高、容易做出差异化。难点不在 API 调用而在身份打通、权限管控、主动触发规则。把这些工程细节做扎实员工每天用一次的助手就立住了。