SA 主动整备：消息通知通道设计方案

版本: v1.0 日期: 2026-06-26 状态: 初稿 关联文档: SA_主动整备_Agent设计.md、微信小程序_主动整备卡片_设计需求.md

1. 背景与问题

1.1 核心矛盾

主动整备 Agent 需要在会议开始前 N 分钟向预定人推送通知卡片，但智能整备的触发入口（会议预定）与通知下发通道之间存在生态割裂：

预定入口	所在生态	通知可用通道
自有会议系统 Web 端（PC 浏览器）	浏览器	无微信/飞书上下文
微信小程序（内嵌 H5 Chatbot）	微信	微信服务号
飞书应用（内嵌 H5 Chatbot）	飞书	飞书 Bot
飞书原生会议功能（飞书 Calendar 直订）	飞书	飞书 Bot

各生态的通知能力差异如下：

通道	是否需要用户预授权	能否做延后定时推送	覆盖范围
微信传统模板消息	否（但需关注 + 7天内交互）	❌ 模板审核不通过	—
微信一次性订阅消息	✅ 必须用户弹窗授权	✅ 不限时间	仅微信内可触发授权
飞书 Bot 消息	❌ 隐式授权（无需用户操作）	✅ 任意时间	所有飞书用户

1.2 本文档范围

描述四种预定场景下的通知链路，明确哪些走得通、哪些走不通、分别用什么通道。

2. 飞书项目场景

2.1 场景概览

飞书项目的核心特征：会议系统集成了飞书 Calendar，用户身份天然是飞书用户。无论用户通过飞书应用内的 Chatbot 预定，还是在飞书 Calendar 中直接预定会议，后端都能拿到飞书 open_id。

2.2 飞书项目通知链路

飞书侧有两条预定入口，通知通道统一：

说明

v1.1 变更：CONFIRM 模式已全平台移除，统一为 AUTO 自动执行 + 通知卡片。global_delay 移除，触发即执行。

3. 微信项目场景

3.1 场景概览

微信项目的核心约束：自有会议系统无移动端，纯 PC Web。用户只有在微信小程序（内嵌 H5 Chatbot）内才能获得微信生态上下文。

3.2 微信消息通道选型结论

通道	能否用于整备通知	原因
传统模板消息	❌ 不能	模板审核规则：定时提醒类模板一律驳回
一次性订阅消息	✅ 能	用户授权后不限时间下发，适合定时场景

详细对比见 §5。

3.3 微信 Chatbot 预定

授权时机

预定成功页同步弹窗引导，不可延后。原因：

一次性订阅消息的授权必须在微信客户端内完成
用户离开当前页面后再无机会触发（无其他微信触点）
错过此节点，该会议的通知将永远无法下发

授权交互

采用 OAuth URL 跳转方式（H5 可用，无需小程序原生能力）：

用户点击"订阅整备通知" →
跳转微信授权页:
  https://mp.weixin.qq.com/mp/subscribemsg
    ?action=get_confirm
    &appid=APPID
    &scene={meeting_id}
    &template_id=TEMPLATE_ID
    &redirect_url=https://your.domain/subscribe/callback
    &reserved=随机校验串
    #wechat_redirect
    ↓
用户点"同意" → 302 回调 redirect_url
    → 携带: openid + template_id + scene + action=confirm
    → 后端记录授权

发送接口

json

POST https://api.weixin.qq.com/cgi-bin/message/template/subscribe
{
  "touser": "OPENID",
  "template_id": "TEMPLATE_ID",
  "scene": 12345,
  "title": "会议室整备通知",
  "data": {
    "keyword1": { "value": "A-101 大会议室" },
    "keyword2": { "value": "2026-06-26 14:00" },
    "keyword3": { "value": "空调已开启，目标24℃" }
  }
}

3.4 自有会议系统 Web 预定 — 有缺口

用户在 PC 浏览器打开公司会议系统 → 预定会议
                                          ↓
❗ 用户不在微信环境内
❗ 拿不到微信 openid
❗ 无法调起 #wechat_redirect 授权页面
                                          ↓
❌ 无法建立微信订阅消息授权 → 该场景的通知覆盖存在缺口

结论：自有会议系统 Web 端预定的会议，微信一次性订阅消息无法覆盖。这是平台能力的客观限制，在未来自有会议系统推出移动端后可通过 Chatbot/H5 入口自然解决。

3.5 微信项目通知链路图

4. 授权机制详细设计

4.1 飞书侧：隐式授权

飞书 Bot 推送不需要额外授权步骤：

步骤	说明
权限	Bot 应用安装时获取 `im:message` 权限
身份来源	飞书 Calendar 创建事件中携带预定人 `open_id`
授权时效	长期有效，应用不卸载即可一直推送

不需要额外的授权记录表。

4.2 微信侧：一次性订阅消息授权

scene 设计

scene 是授权 + 发送的唯一关联凭证：

text

scene = meeting_id (0-10000 的整型值)

每个 meeting_id 作为一个独立 scene
用户为 meeting_id=123 授权一次 → 只能发 1 条
下次会议 meeting_id=124 需要重新授权
同一用户在同一个 scene 下的多次授权不累积

边界：如果后续需要同一个会议发多条消息（如整备完成 + 即将开始），需要拆成 {meeting_id}_1 和 {meeting_id}_2 两个 scene。目前仅会前一条，直接用 meeting_id 即可。

授权记录表

sql

CREATE TABLE wechat_subscribe_auth (
  id                INT AUTO_INCREMENT PRIMARY KEY,
  openid            VARCHAR(64) NOT NULL       COMMENT '用户微信 openid',
  template_id       VARCHAR(64) NOT NULL       COMMENT '订阅消息模板 ID',
  scene             INT NOT NULL               COMMENT '场景值 = meeting_id',
  meeting_id        VARCHAR(64) NOT NULL       COMMENT '会议 ID（冗余字段，便于查询）',
  room_id           VARCHAR(64) NOT NULL       COMMENT '会议室 ID',
  status            ENUM('authorized','consumed','expired') DEFAULT 'authorized'
                                                      COMMENT '授权状态',
  created_at        DATETIME NOT NULL          COMMENT '授权时间',
  consumed_at       DATETIME DEFAULT NULL      COMMENT '消息下发时间',
  UNIQUE KEY uk_scene_openid (scene, openid),
  INDEX idx_meeting (meeting_id),
  INDEX idx_status_scene (status, scene)
);

状态流转

authorized：已授权，等待发送
consumed：消息已下发，该 scene 不可再发
expired：会议已结束，授权未使用，自动过期（由定时任务清理）

谁写谁读

操作	谁负责	说明
写入授权记录	Chatbot 后端	微信回调后写入，状态 `authorized`
读取+消费	整备 Agent / 消息中心	Cron 到达 prep_window 时读取，发送后更新为 `consumed`
清理过期	定时任务（每日凌晨）	将已过期会议且未消费的记录标记为 `expired`

5. 微信消息通道对比

5.1 传统模板消息 vs 一次性订阅消息

对比维度	传统模板消息	一次性订阅消息
官方定位	用户操作当场即时的业务回执凭证	用户主动授权后的按需下发通知
用户授权要求	仅需关注公众号	必须弹窗授权，单次订阅仅允许下发 1 条
推送时机限制	仅能在用户交互瞬间发送；定时推送一律审核驳回	不限时间，授权后可延后任意时长下发
会议室整备场景适配	❌ 完全不匹配：会前定时推送，模板永久无法过审	✅ 完全匹配：预约时授权，会前下发
长期使用风险	新增同类模板 100% 驳回；存量模板可能被下线	符合运营规范，无审核拦截风险

5.2 官方依据

模板消息需要用户与业务之间存在实际交互行为，即时触发即时触达相应服务结果，用户触发一次下发一条对应的服务消息，仅作为反馈相关服务结果的凭证依据，不可作为提醒或短信用途。
预警类、提醒类场景建议通过以下方式实现： 服务号订阅通知功能、小程序订阅消息功能
— 微信开放社区官方 FAQ (2026-02-01)

一次性订阅，指用户订阅一次，认证服务号可不限时间地下发一条对应的订阅通知。
— 订阅通知介绍

5.3 传统模板消息审核红线（直接与本场景冲突）

摘自模板消息运营规范：

不允许发的模板消息：
群发推广类消息模板 — 课程提醒类通知、车辆出行类通知、天气播报类通知、文章更新类通知等一些用户无接收预期并引起用户相关投诉的通知
模板审核标准③：易被用作群发，标题或关键词不能简要说明具体服务行为或使用场景的模板不能通过 — 管理员类通知、公告类通知、系统通知

"会前整备提醒"在审核视角归类为"管理员/系统通知 + 定时提醒"，三者同时触犯红线。

6. 综合对比总结

预定场景	通知通道	是否覆盖
飞书项目 — 飞书应用内 H5 Chatbot 预定	飞书 Bot 消息卡片	✅ 全量覆盖
飞书项目 — 飞书原生 Calendar 直订	飞书 Bot 消息卡片	✅ 全量覆盖
微信项目 — 微信小程序内 H5 Chatbot 预定	微信一次性订阅消息	✅ 覆盖
微信项目 — 自有会议系统 Web 预定	—	❌ 缺口

7. 待定项 (Open Questions)

#	问题	影响
1	微信一次性订阅消息的模板 ID 是否需要走审核？审核周期多长？	影响上线排期
2	飞书项目的通知卡片是否与微信侧卡片保持完全一致的交互，还是各有平台特色？	影响前端开发工作量
3	用户拒绝授权订阅后，是否需要提供降级方案（如 Chatbot 内消息气泡提醒）？	影响用户体验统一性

第三方日历集成

访客预约

01-设计

02-知识库

设计方案

语料

03-场景与数据

01-调研

SA 主动整备：消息通知通道设计方案

1. 背景与问题

1.1 核心矛盾

1.2 本文档范围

2. 飞书项目场景

2.1 场景概览

2.2 飞书项目通知链路

说明

3. 微信项目场景

3.1 场景概览

3.2 微信消息通道选型结论

3.3 微信 Chatbot 预定

授权时机

授权交互

发送接口

3.4 自有会议系统 Web 预定 — 有缺口

3.5 微信项目通知链路图

4. 授权机制详细设计

4.1 飞书侧：隐式授权

4.2 微信侧：一次性订阅消息授权

scene 设计

授权记录表

状态流转

谁写谁读

5. 微信消息通道对比

5.1 传统模板消息 vs 一次性订阅消息

5.2 官方依据

5.3 传统模板消息审核红线（直接与本场景冲突）

6. 综合对比总结

7. 待定项 (Open Questions)

设计方案

语料

SA 主动整备：消息通知通道设计方案 ​

1. 背景与问题 ​

1.1 核心矛盾 ​

1.2 本文档范围 ​

2. 飞书项目场景 ​

2.1 场景概览 ​

2.2 飞书项目通知链路 ​

说明 ​

3. 微信项目场景 ​

3.1 场景概览 ​

3.2 微信消息通道选型结论 ​

3.3 微信 Chatbot 预定 ​

授权时机 ​

授权交互 ​

发送接口 ​

3.4 自有会议系统 Web 预定 — 有缺口 ​

3.5 微信项目通知链路图 ​

4. 授权机制详细设计 ​

4.1 飞书侧：隐式授权 ​

4.2 微信侧：一次性订阅消息授权 ​

scene 设计 ​

授权记录表 ​

状态流转 ​

谁写谁读 ​

5. 微信消息通道对比 ​

5.1 传统模板消息 vs 一次性订阅消息 ​

5.2 官方依据 ​

5.3 传统模板消息审核红线（直接与本场景冲突） ​

6. 综合对比总结 ​

7. 待定项 (Open Questions) ​

SA 主动整备：消息通知通道设计方案

1. 背景与问题

1.1 核心矛盾

1.2 本文档范围

2. 飞书项目场景

2.1 场景概览

2.2 飞书项目通知链路

说明

3. 微信项目场景

3.1 场景概览

3.2 微信消息通道选型结论

3.3 微信 Chatbot 预定

授权时机

授权交互

发送接口

3.4 自有会议系统 Web 预定 — 有缺口

3.5 微信项目通知链路图

4. 授权机制详细设计

4.1 飞书侧：隐式授权

4.2 微信侧：一次性订阅消息授权

scene 设计

授权记录表

状态流转

谁写谁读

5. 微信消息通道对比

5.1 传统模板消息 vs 一次性订阅消息

5.2 官方依据

5.3 传统模板消息审核红线（直接与本场景冲突）

6. 综合对比总结

7. 待定项 (Open Questions)