Compare
实现飞书全流程提醒：通用架构、落地步骤与选型
2026-01-29 13:49 · Zon · Issue → AI → Report
以“事项全生命周期催办/升级”为默认定义；输入微信文章链接无法在线核验，仅作参考位
飞书全流程提醒：机器人+事件订阅+催办升级方案
TL;DR
- 定义：此处“全流程提醒”=流程事项从创建→待办→临期→逾期→升级→关闭的自动提醒与闭环记录。
- 通用可靠方案：飞书自建应用（机器人）+ 事件订阅（状态变更触发）+ 定时任务（临期/逾期扫描）+ 消息卡片交互（处理/延后/转交）。
- 最小可用闭环：先只做 1 个流程（例如审批实例）与 2 类提醒（临期一次、逾期升级一次），把去重、幂等、重试做扎实。
- 复杂场景（多系统、多租户、复杂升级链）可用 n8n/Temporal/Camunda 统一编排，把飞书定位为“通知与入口”。
Key Insights
- “事件驱动”解决状态变化，“到期提醒”通常仍需要定时扫描或业务侧写入 next_remind_at；两者结合才能覆盖临期/逾期。
- 提醒渠道要分层：IM 消息卡片适合催办与交互；待办/Todo 适合追踪与统计；群/主管升级适合 SLA 兜底。
- 噪音控制比“能提醒”更重要：去重（同阶段只发一次）、静默窗口（夜间/节假日）、批量摘要（群内日汇总）能显著提升接受度。
- 安全与合规是上线门槛：最小权限 scopes、事件回调签名校验、敏感信息不落 IM 正文（只发摘要+链接）与审计日志必备。
Playbook
- 需求建模：明确“事项”是什么（审批实例/工单/表格记录），固定字段：item_id、title、owner_open_id、state、due_at、sla_level、watchers、source_link。
- 设计状态机与提醒矩阵：例如 state=待处理 时 T-24h、T-2h 提醒；逾期后每 6 小时提醒一次，超过 24 小时升级到主管/群；关闭后停止所有提醒。
- 选择触发方式：优先事件订阅（状态变更实时）；没有事件就用业务系统 webhook；两者都不行再做轮询（按更新时间增量拉取）。
- 开放平台准备：创建“自建应用”，开通机器人；申请最小 scopes（IM 发消息、必要的审批/多维表格读取权限等）；规划 token 获取与缓存（tenant/app/user token）。
- 事件接入：配置事件订阅回调 URL；实现 challenge 验证与签名校验；将事件先写入队列/表（解耦回调与业务处理，避免超时重试风暴）。
- 数据与幂等：建立 reminder 表/字段（item_id+stage 唯一键、last_sent_at、next_remind_at、last_message_id、status），保证重复事件/重试不会重复发。
- 定时提醒引擎：cron 每 1–5 分钟扫描 next_remind_at<=now 的记录，计算当前 stage（临期/逾期/升级），渲染消息卡片并调用 IM 发消息接口；失败重试+指数退避+死信队列。
- 消息卡片交互：提供“已处理/延后/转交/查看详情”按钮；回调接口更新事项状态与 next_remind_at；对“延后”写入原因与新 due_at（便于审计）。
- 升级与关闭：逾期达到阈值自动通知主管（从组织架构查上级）或固定升级群；关闭时发送完成通知并清理后续定时器/任务。
- 观测与运营：落地发送日志、到达率、点击率、平均处理时长、逾期率；设置限流（按 tenant/app/user），并迭代静默策略与模板文案降低打扰。
Diagrams
Options
- 意图假设 A：你要做“飞书审批”全生命周期催办（提交→待审批→逾期→升级→完结），并把提醒落在 IM/群/主管。
- 意图假设 B：你要做“多维表格/工单表”字段驱动提醒（负责人、截止时间、状态列变化触发），并支持卡片内一键更新字段。
- 意图假设 C：你要把公司自研系统的流程节点同步到飞书，让飞书成为统一提醒与处理入口（消息卡片跳转到内网处理页）。
- 另一种定义分支：若“全流程提醒”指“日程/会议”的邀请、变更、会前会后提醒，应优先走日历/日程能力与日程规则，而不是审批/工单事件链路。
- 实现方式 1（低门槛）：飞书内置自动化/多维表格自动化 + 机器人通知；优点是快，缺点是复杂升级链、幂等与审计能力可能不足（需按企业版本核对）。
- 实现方式 2（自建服务）：OpenAPI + 事件订阅 + 自己的 DB/队列；适合复杂规则与多系统，但需要运维与安全投入。
- 实现方式 3（工作流编排）：n8n/Node-RED（低代码）或 Temporal/Camunda（强一致工作流）统一编排；飞书只负责通知、交互与入口。
Expert Views
- 产品经理（paraphrase）：先锁定一个高频痛点流程做“闭环+指标”，例如逾期率、平均处理时长；不要一开始追求覆盖所有流程与场景。
- 平台/后端工程师（paraphrase）：可靠性来自“事件驱动+定时补偿+幂等”；把 token 刷新、重试、限流、回调验签当成基础设施而非业务代码。
- SRE/运维工程师（paraphrase）：提醒系统本质是通知平台，必须有可观测性（投递链路、积压、失败率）、降级策略（摘要/降频）和故障演练。
- 隐私与合规角色（paraphrase）：默认不在 IM 推送敏感字段，推摘要+权限内链接；对访问范围做最小化授权，并保留审计日志以应对内控检查。
Evidence & Confidence
- 飞书开放平台支持机器人发送 IM 消息并使用交互式消息卡片：high（属于开放平台核心能力，通常有稳定官方文档）。
- 事件订阅可用于接收业务事件以驱动提醒：medium（能力存在，但具体可订阅事件类型、字段与权限需按企业/应用配置核对）。
- 临期/逾期提醒需要定时计算或到期触发机制，单靠事件难覆盖：high（通用工程规律；多数平台不会为每条记录自动发“到期事件”）。
- 内置自动化适合简单提醒，复杂升级链/去重/审计可能受限：medium（取决于企业版本与可用组件；当前无法在线核验）。
- 输入的微信文章可能包含可复用模板或截图步骤：low（当前无法在线核验文章内容与适用范围）。
Next Steps
- 先确认：流程对象是什么（审批/工单/多维表格/自有系统），以及“谁在什么状态下需要被提醒”。
- 输出一页提醒策略表：节点、触发条件、频率、静默窗口、升级链、停止条件、消息模板字段。
- 选 PoC 路径：简单需求走飞书自动化；复杂需求用自建应用（事件订阅+定时扫描+消息卡片回调）。
- 同步 IT/安全：确认 scopes、数据是否可出现在 IM、日志留存周期与审计要求；避免上线后被合规卡住。
- 两周 PoC 目标：跑通“状态变更提醒 + 临期扫描 + 逾期升级 + 一键处理/延后 + 去重日志”闭环，再扩展到更多流程与渠道。
Details (Optional)
Details
TL;DR
- 定义：此处“全流程提醒”=流程事项从创建→待办→临期→逾期→升级→关闭的自动提醒与闭环记录。
- 通用可靠方案：飞书自建应用（机器人）+ 事件订阅（状态变更触发）+ 定时任务（临期/逾期扫描）+ 消息卡片交互（处理/延后/转交）。
- 最小可用闭环：先只做 1 个流程（例如审批实例）与 2 类提醒（临期一次、逾期升级一次），把去重、幂等、重试做扎实。
- 复杂场景（多系统、多租户、复杂升级链）可用 n8n/Temporal/Camunda 统一编排，把飞书定位为“通知与入口”。
Key Insights
- “事件驱动”解决状态变化，“到期提醒”通常仍需要定时扫描或业务侧写入 next_remind_at；两者结合才能覆盖临期/逾期。
- 提醒渠道要分层：IM 消息卡片适合催办与交互；待办/Todo 适合追踪与统计；群/主管升级适合 SLA 兜底。
- 噪音控制比“能提醒”更重要：去重（同阶段只发一次）、静默窗口（夜间/节假日）、批量摘要（群内日汇总）能显著提升接受度。
- 安全与合规是上线门槛：最小权限 scopes、事件回调签名校验、敏感信息不落 IM 正文（只发摘要+链接）与审计日志必备。
Playbook
- 需求建模：明确“事项”是什么（审批实例/工单/表格记录），固定字段：item_id、title、owner_open_id、state、due_at、sla_level、watchers、source_link。
- 设计状态机与提醒矩阵：例如 state=待处理 时 T-24h、T-2h 提醒；逾期后每 6 小时提醒一次，超过 24 小时升级到主管/群；关闭后停止所有提醒。
- 选择触发方式：优先事件订阅（状态变更实时）；没有事件就用业务系统 webhook；两者都不行再做轮询（按更新时间增量拉取）。
- 开放平台准备：创建“自建应用”，开通机器人；申请最小 scopes（IM 发消息、必要的审批/多维表格读取权限等）；规划 token 获取与缓存（tenant/app/user token）。
- 事件接入：配置事件订阅回调 URL；实现 challenge 验证与签名校验；将事件先写入队列/表（解耦回调与业务处理，避免超时重试风暴）。
- 数据与幂等：建立 reminder 表/字段（item_id+stage 唯一键、last_sent_at、next_remind_at、last_message_id、status），保证重复事件/重试不会重复发。
- 定时提醒引擎：cron 每 1–5 分钟扫描 next_remind_at<=now 的记录，计算当前 stage（临期/逾期/升级），渲染消息卡片并调用 IM 发消息接口；失败重试+指数退避+死信队列。
- 消息卡片交互：提供“已处理/延后/转交/查看详情”按钮；回调接口更新事项状态与 next_remind_at；对“延后”写入原因与新 due_at（便于审计）。
- 升级与关闭：逾期达到阈值自动通知主管（从组织架构查上级）或固定升级群；关闭时发送完成通知并清理后续定时器/任务。
- 观测与运营：落地发送日志、到达率、点击率、平均处理时长、逾期率；设置限流（按 tenant/app/user），并迭代静默策略与模板文案降低打扰。
Expert Views
- 产品经理（paraphrase）：先锁定一个高频痛点流程做“闭环+指标”，例如逾期率、平均处理时长；不要一开始追求覆盖所有流程与场景。
- 平台/后端工程师（paraphrase）：可靠性来自“事件驱动+定时补偿+幂等”；把 token 刷新、重试、限流、回调验签当成基础设施而非业务代码。
- SRE/运维工程师（paraphrase）：提醒系统本质是通知平台，必须有可观测性（投递链路、积压、失败率）、降级策略（摘要/降频）和故障演练。
- 隐私与合规角色（paraphrase）：默认不在 IM 推送敏感字段，推摘要+权限内链接；对访问范围做最小化授权，并保留审计日志以应对内控检查。
Options
- 意图假设 A：你要做“飞书审批”全生命周期催办（提交→待审批→逾期→升级→完结），并把提醒落在 IM/群/主管。
- 意图假设 B：你要做“多维表格/工单表”字段驱动提醒（负责人、截止时间、状态列变化触发），并支持卡片内一键更新字段。
- 意图假设 C：你要把公司自研系统的流程节点同步到飞书，让飞书成为统一提醒与处理入口（消息卡片跳转到内网处理页）。
- 另一种定义分支：若“全流程提醒”指“日程/会议”的邀请、变更、会前会后提醒，应优先走日历/日程能力与日程规则，而不是审批/工单事件链路。
- 实现方式 1（低门槛）：飞书内置自动化/多维表格自动化 + 机器人通知；优点是快，缺点是复杂升级链、幂等与审计能力可能不足（需按企业版本核对）。
- 实现方式 2（自建服务）：OpenAPI + 事件订阅 + 自己的 DB/队列；适合复杂规则与多系统，但需要运维与安全投入。
- 实现方式 3（工作流编排）：n8n/Node-RED（低代码）或 Temporal/Camunda（强一致工作流）统一编排；飞书只负责通知、交互与入口。
Evidence & Confidence
- 飞书开放平台支持机器人发送 IM 消息并使用交互式消息卡片：high（属于开放平台核心能力，通常有稳定官方文档）。
- 事件订阅可用于接收业务事件以驱动提醒：medium（能力存在，但具体可订阅事件类型、字段与权限需按企业/应用配置核对）。
- 临期/逾期提醒需要定时计算或到期触发机制，单靠事件难覆盖：high（通用工程规律；多数平台不会为每条记录自动发“到期事件”）。
- 内置自动化适合简单提醒，复杂升级链/去重/审计可能受限：medium（取决于企业版本与可用组件；当前无法在线核验）。
- 输入的微信文章可能包含可复用模板或截图步骤：low（当前无法在线核验文章内容与适用范围）。
Next Steps
- 先确认：流程对象是什么（审批/工单/多维表格/自有系统），以及“谁在什么状态下需要被提醒”。
- 输出一页提醒策略表：节点、触发条件、频率、静默窗口、升级链、停止条件、消息模板字段。
- 选 PoC 路径：简单需求走飞书自动化；复杂需求用自建应用（事件订阅+定时扫描+消息卡片回调）。
- 同步 IT/安全：确认 scopes、数据是否可出现在 IM、日志留存周期与审计要求；避免上线后被合规卡住。
- 两周 PoC 目标：跑通“状态变更提醒 + 临期扫描 + 逾期升级 + 一键处理/延后 + 去重日志”闭环，再扩展到更多流程与渠道。
Sources
- 飞书开放平台文档入口：https://open.feishu.cn/document/ （无法在线核验）
- Lark 开放平台文档入口：https://open.larksuite.com/document/ （无法在线核验）
- Lark/飞书官方 OpenAPI SDK（Python）：https://github.com/larksuite/oapi-sdk-python （无法在线核验）
- Lark/飞书官方 OpenAPI SDK（Go）：https://github.com/larksuite/oapi-sdk-go （无法在线核验）
- Lark/飞书官方 OpenAPI SDK（Java）：https://github.com/larksuite/oapi-sdk-java （无法在线核验）
- n8n（工作流自动化）：https://github.com/n8n-io/n8n （无法在线核验）
- Temporal（工作流引擎）：https://github.com/temporalio/temporal （无法在线核验）
- 输入参考（微信文章）：https://mp.weixin.qq.com/s/yR9IScQjQvSETABleArebQ （无法在线核验）
Sources
- 飞书开放平台文档入口：https://open.feishu.cn/document/ （无法在线核验）
- Lark 开放平台文档入口：https://open.larksuite.com/document/ （无法在线核验）
- Lark/飞书官方 OpenAPI SDK（Python）：https://github.com/larksuite/oapi-sdk-python （无法在线核验）
- Lark/飞书官方 OpenAPI SDK（Go）：https://github.com/larksuite/oapi-sdk-go （无法在线核验）
- Lark/飞书官方 OpenAPI SDK（Java）：https://github.com/larksuite/oapi-sdk-java （无法在线核验）
- n8n（工作流自动化）：https://github.com/n8n-io/n8n （无法在线核验）
- Temporal（工作流引擎）：https://github.com/temporalio/temporal （无法在线核验）
- 输入参考（微信文章）：https://mp.weixin.qq.com/s/yR9IScQjQvSETABleArebQ （无法在线核验）
Closing Summary
- 结论：飞书全流程提醒：机器人+事件订阅+催办升级方案
- 下一步：回复你要提醒的“具体流程类型+状态节点+升级链”，我可把事件/数据模型/接口清单细化成 PoC 任务分解。
One next action
回复你要提醒的“具体流程类型+状态节点+升级链”，我可把事件/数据模型/接口清单细化成 PoC 任务分解。
先闭环，再上强度。
— AI pipeline