业务背景
客户需要定期组织医生线上学术讲座。原本的做法是在微信群里发通知收集报名，场次、名额、医生信息、会议地址全部散落在聊天记录里。
人少时能撑，场次一多就失控：名额超了没人知道，医生信息格式混乱无法核对，会议地址被刷掉后医生找不到进会链接。
解决思路
核心判断是：这不只是把报名表搬到线上，而是要让「报名—建会—通知—进会」变成一条有状态的链路。
所以设计上没有只做客户端，而是同时做了运营侧。原因很简单——如果运营还要手工在腾讯会议建会、复制地址、回填后台、通知医生，那系统只解决了三分之一的问题。
四端结构
客户端 H5（嵌入微信服务号）
- 按日期与时间段筛选的预约日历，实时显示剩余名额
- 预约信息填写：姓名、医院、职称、照片、备注
- 我的预约列表与状态跟踪
- 会议地址查看与一键进会
登录采用微信网页授权静默获取 openid，用户无需注册。这一步省掉的不只是填写时间，更是整个账号体系的开发和维护成本。
飞书提示机器人
新订单实时推送到运营飞书群，卡片包含医生信息与所约场次。
关键设计：卡片内直接回填腾讯会议地址和运营备注。运营不需要切换到另一个后台，在聊天窗口里就能完成处理。这是整个系统效率提升最明显的一环。
飞书内嵌运营台
用于批量操作和复杂配置：
- 订单查看与筛选
- 会议主题管理
- 场次设置（日期、时间段、名额）
- 字段配置（哪些字段显示、哪些必填）
- 标记完成、关闭场次
后端服务
- 场次与名额管理，并发预约防超卖
- 微信网页授权对接与用户身份关联
- 飞书应用消息推送与卡片回调处理
- 三端统一接口与数据一致性
关键技术决策
为什么用 H5 而不是小程序
医疗类小程序审核严格，改一次要重新提审，节奏不可控。H5 嵌在服务号里，推文可直接放链接，医生点开就用。代价是失去模板消息能力，但本项目通知可通过服务号与飞书侧解决。
飞书卡片回调是效率核心
飞书开放平台的交互式卡片支持表单回调，让运营在聊天窗口内完成「回填地址」这个高频动作。这一处设计直接决定了运营愿不愿意用这套系统。
场次与字段全部可配置
换会议形式、加减字段不需要改代码。验收后甲方新增一个「科室」字段，后台点两下即可，不产生二开费用。
项目前置门槛
这个项目有两件事必须在开发启动前就开始办，否则会卡上线：
- 微信服务号认证 —— 需要企业或个体户资质，有审核周期
- 飞书企业主体与自建应用 —— 注册认证免费，但需要时间
这类前置事项建议在合同里明确由甲方负责，且等待时间不计入开发工期。
交付结果
系统已上线运行，四端协同工作。医生通过服务号进入 H5 完成预约，运营在飞书内完成全部后续处理。
在线体验：可通过下方入口体验演示版本。演示数据为构造的示例信息，非真实业务数据。