企业官网建设流程全解析

影刀RPA实操指南：钉钉/企微/飞书三端通知统一封装方案

一个流程要同时给钉钉群、企业微信群、飞书群发通知，三套指令三套参数三套格式，每个流程里写一遍，改个样式要改十几处——这是流程多了之后必然会遇到的通知管理难题。影刀RPA自带「钉钉群通知」「企业微信群通知」「飞书群通知」三条指令，把它们的差异吃透之后封装成一个统一通知子流程，所有流程调用同一个入口，这事就一劳永逸了。

我管理着十来个采集流程，早期每个流程里各写各的通知，有一次换钉钉机器人的webhook，改了三个晚上。这篇实操指南把三端差异对照、统一封装的设计、踩过的坑一次讲完，照着做你能得到一个可复用的通知模块。

先说设计目标：调用者只传"发到哪个端、标题、正文、@谁"四个参数，端与端之间的格式差异全部在子流程内部消化。

三端指令差异对照：参数和格式的真实区别

先把三条指令的参数摆在一起看，差异比想象的大：

三个关键差异展开说：

1. 钉钉的密钥是机器人安全设置里加签一栏SEC开头的字符串，开了加签就必须填，否则发送直接失败
2. 钉钉的@人是「@某人」参数里填手机号码，支持多个手机号和@所有人，这是三端里最省事的
3. 飞书的消息格式类型里没有markdown，要用富文本或消息卡片，@人写法是at标签，@所有人固定写all

变量与JSON设计：统一的消息数据结构

封装的核心是定义一个所有端通用的消息结构。我用字典承载，调用时构造好传进子流程。

# 输入：无# 输出：msg，统一消息结构，传给通知子流程# 渠道 channel：dingtalk / wecom / feishu，可多选传列表msg={"channel":["dingtalk","feishu"],# 要发往的端"title":"采集任务日报",# 标题，钉钉markdown和飞书卡片用"body":"今日采集 1200 条，失败 3 条",# 正文"at_mobiles":["13800000000"],# 钉钉@的手机号列表"at_all":False# 是否@所有人}

Python的字典和列表操作在这里够用，拼接正文时数字转字符串别偷懒，报"Array to String"这类类型错误多半是这里混了类型。飞书at标签里的引号嵌套建议用单引号包外层、双引号留内层，转义写错发出去的就是一段乱码。

流程控制：子流程内部的分支路由

统一通知子流程 fy_统一通知 的内部逻辑是一个条件分支路由：

1. 判断 msg.channel 里包含哪些端
2. 包含钉钉→调用「钉钉群通知」，消息格式选markdown，标题填msg.title，@某人参数填msg.at_mobiles
3. 包含企微→调用「企业微信群通知」，消息格式选markdown
4. 包含飞书→调用「飞书群通知」，消息格式选富文本或消息卡片，at标签拼进正文
5. 每个分支外面套Try-Catch，某端失败只「输出日志」记录，不阻断其他端的发送

某端挂了不影响其他端，这条很重要。我有次飞书机器人被移出群，钉钉和企微的通知照常发出，定位问题时日志里只有飞书分支的报错，一分钟就找到了。

元素定位与网页自动化：通知内容的来源

通知内容大多来自采集流程的运行数据，这部分依赖网页自动化基本功。列表数据用「获取相似元素列表」批量提取，异常提示用XPath文本模糊匹配抓报错文案。

# 捕获元素：页面上的失败提示，作为通知正文的报错详情 //*[contains(text(),'失败') or contains(text(),'错误')] # 捕获元素：数据加载完成标志，作为发通知前置条件 //div[@class='summary-bar']

等待策略统一用「等待元素出现」加超时，弹窗先判断再处理。这些采集到的信息先写进运行统计字典，流程收尾时统一交给通知子流程，业务逻辑和通知逻辑彻底分离。

数据处理与鼠标键盘图像：发通知前的最后一层加工

• 统计加工：把采集数、成功数、失败数、耗时用Python拼成摘要段落，三端共用同一段文字
• 截图投递：企微和飞书支持图片类型，异常时把「截图」指令的产物发出去；钉钉端不支持图片通知，就用文字描述替代
• 图像兜底：通知环节本身用不到鼠标键盘和图像识别，采集端元素彻底定位不到时才启用图像点击，边界要划清楚

数据量大时摘要别把全量明细塞进去，通知是给人扫一眼的，明细放多维表格，通知里带一句"详情见表格"即可。

进阶技能：HTTP请求直发webhook的替代方案

三条群通知指令之外，「HTTP请求」指令可以按POST方式直接向三端webhook发消息体，遇到指令不支持的消息类型（比如钉钉的特殊卡片）时这是唯一的出路。做法是请求方式选POST，消息体按各端官方的JSON格式拼好发送，返回码200即成功。

我的原则：指令能覆盖的场景用指令，覆盖不了才上HTTP请求，代码里注释写清楚用的哪种方式，后人接手不困惑。

平台实战与系统联动：通知体系的三层设计

跑久了我总结出三层通知体系：第一层即时告警，异常时@值班人，走钉钉；第二层日常播报，任务完成发汇总，走企微；第三层数据沉淀，结果写入飞书多维表格，配合定时任务每晚跑一轮。三端各司其职，谁也不是摆设。

定时任务配置在影刀客户端的计划任务里，错峰设置运行时间避免多流程抢机器，夜间任务记得关电脑睡眠。高级任务计划还能用Webhook触发流程，通知和触发形成闭环。

工程化规范与调试：封装的纪律

• 子流程只暴露四个输入参数，webhook和密钥全部存在子流程内部，换机器人只改一处
• 命名规范：fy_统一通知，版本号写在流程说明里
• 调试：右键加断点单步执行，变量面板里逐层看字典内容，三个分支各跑一遍再上线
• 版本选择：社区版每天30分钟不够跑带通知的长流程，创业版无限制

统一封装最大的收益不是省代码，是收敛：所有通知长一个样、走一个口子，排查问题永远只看一个地方。

易错速查表

学习资源与延伸阅读

三条群通知指令的官方参数说明都不长，建议直接通读，各端机器人的申请流程官方帮助里也有图文。统一通知子流程的完整源码我放在代码仓库 home.linyan.cloud，可以直接参考改造，把你的三端webhook填进去当天就能用。

#影刀RPA #RPA自动化 #钉钉 #企业微信 #飞书 #消息通知

作者：林焱