智能会场执行方案

00先给三个判断

你这次说的东西和前几轮不一样——前面是战略，这次是现场。一个没在千人大会现场站过的人， 提不出「学员要在会场报手机号才能打印胸卡」这种细节。所以这一轮我不跟你谈战略，只谈你观察到的每一个具体现象该怎么处理。
先给三个判断，其中一个我建议你直接放弃。

判断一：放弃「AI 识别人数」，它是这十一个痛点里最不划算的一个

你在现场感觉到的是「不知道现在有多少人、有没有拥挤」，这个痛点是真实的。但你给的解法（摄像头 + AI）在 2026 年已经是死路，理由有三条，每条单独都成立：

判断二：不要自研 ESP32 硬件——最好的端侧设备，是学员口袋里那部手机

你问「选择 ESP32 的端侧设备非常多，是否有方便灵活部署的设备系统」。我的答案可能让你意外：一个自研硬件都不要。

真正需要硬件的只有两处，而且都有成熟现成品，详见 05 节：纸质胸卡打印、现场网络。

判断三：这笔账的价值不在「省人力」，在「第一次有了谁是誰来了的记录」

你说「会场人多 → 工作人员多 → 成本高，推广我这套系统成本会急剧下降」。方向对，但把钱算小了。

附带一条必须提前知道的硬规定

01你的痛点，按「值不值得做」排一遍

02签到与胸卡：瓶颈不在签到，在打印

你想做「自助机扫码打印」，方向没问题，但它没有解决真正的瓶颈。先把这笔账算清楚。

02.1 时间账：1000 人要在 60 分钟内进场

注：单人耗时与吞吐为量级推算，非实测。RFID 通道的「支持人员并排通过瞬时阅读」来自设备公开参数，通过速率为推算，需现场实测。

02.2 设备：先租不买

核实到的国内公开报价：

02.3 「登记了多少、还剩多少」——这是零成本的

你提到的第二个痛点，其实不需要任何额外设备：它本来就是签到数据的实时聚合。

// 签到看板的数据全部来自同一个事件流，不需要额外采集

  checkin_events ──▶ 实时聚合 ──▶ {
      total_registered    : 1000,      // 已报名
      checked_in          :  623,      // 已到场
      rate                : 62.3%,
      last_10min_rate     : 41 人/分,   // ★ 这就是拥挤指标
      not_arrived_vip     :   7,       // ★ 未到场的 VIP，可定向催一下
      by_gate             : [ {A: 210}, {B: 188}, {C: 225} ],
      by_sub_session      : [ ... ]     // ★ 见 04 节，这才是真正值钱的部分
  }

03为什么建议干脆不做人数识别

这一节专门用来劝退。因为「AI 识别人数」看起来最像高科技，最容易被写进方案，也最容易吃掉你最多的工期而产出最少。

03.1 三条路线，一条已死，一条麻烦，一条免费

03.2 关于你担心的火灾与突发疾病

你提到「如果发生突发火灾或心脏病，是否可以用 5G 自动部署端侧」。这个想法我理解，但必须把话说清楚：

但你可以做一个范围明确、责任清晰的东西，而且它同样很有价值：

这个模块还有个额外的好处：它正好对应安全工作方案里的「处置突发事件应急预案」， 是整个产品里最容易向承办者证明价值的一块——因为那是他们的法定义务（详见 06.2）。

04分会场：整套方案真正值钱的地方在这里

主会场结束，学员散到各个分会场——按照你的描述，这一散，主办方就什么都不知道了： 谁进了哪个场、待了多久、对什么感兴趣。而这恰恰是赞助商唯一真正想要的东西。

04.1 分会场签到：你提的那句话，是整套设计的支点

你说「每个会场应该有个二维码，学员扫码后可以收集到学员的信息」——这句话我要原样保留下来，因为它是正确的。

04.2 分会场找不到路：用蓝牙信标，不用摄像头

你提到学员在手机上找不到自己的分会场。这个问题有一个成本极低且非常成熟的解法：蓝牙信标（iBeacon）+ 微信小程序。

按公开经验值，200 ㎡ 区域约需 4~6 个信标，整套部署周期约 3~7 天。一个八分会场的场地，信标总投入大概在一两千元的量级。

04.3 抽奖：把它设计成「授权的交换」，而不是活动尾声的一个节目

你把抽奖放在最后说，但在这个商业模型里，抽奖可能是整场会 ROI 最高的一个环节——前提是你把它当成一个授权机制来设计。

 学员想抽奖
     │
     ├─▶ 扫码进入抽奖页（这一步通常很容易，几乎人人参与）
     │
     └─▶ 页面上有一个明显的勾选项：
         「我愿意把联系方式提供给本次分论坛的赞助商，以获得产品资料」
              │
              ├── 勾选 ──▶ ★ 生成一条「已授权可交付线索」
              │              （能卖给赞助商的东西终于有了）
              │
              └── 不勾 ──▶ 照常参与抽奖，只是不交付线索

04.4 分会场赞助：一条我前面十轮漏掉的收入

你说「每个会场还可以拉取企业的赞助，解决礼品经费，同时赞助费对我平台本身也是一种收益」—— 这一条我承认以前没算进去。前面几份文档算招商收入，算的都是主展区的标准展位（按公开招商报价在万元级）， 漏掉了分会场这一层。

05网络与设备：ESP32 这个问题的答案

05.1 先回答你的原问题：不建议自研任何 ESP32 端侧

05.2 真正需要的硬件只有两样

05.3 关于网络：比带宽更重要的一件事

你问「是否可以 5G 自动部署端侧，或从会议的一个网口接入后其他端侧无线组网」。技术上都可以，但我要指出一个更关键的点：

// 签到端：离线优先。网络是锦上添花，不是前提

async function checkin(sessionId, attendeeToken) {
  const rec = { sessionId, token: attendeeToken,
                 ts: Date.now(), synced: false };

  await localQueue.push(rec);        // ① 先落本地，永不丢
  showLocalSuccess();                  // ② 立刻给用户反馈（关键）

  try {
    await api.post('/checkin', rec);
    await localQueue.markSynced(rec.id);
  } catch (e) {
    scheduleRetry(rec);                // ③ 失败不影响本次签到体验
  }
}

06三颗合规雷

这一部分请你务必看完。三颗雷里有两颗是你明确说要做的事（抽奖、大会扩规模）， 而且罚款金额都足以吃掉一场会的全部利润。

06.1 第一颗：抽奖（你明确要做的）

所以抽奖模块必须内置四条：

• 硬校验：奖品价值录入时超过 5 万直接拒绝保存（不是提醒，是拒绝）
• 公示页：自动生成符合要求的公示页面，>500 元奖项实时更新兑奖状态
• 档案留存：设奖规则、结果、获奖人自动归档，保留两年以上
• 不可篡改：中奖结果写入后只读，且留操作日志（这既是合规要求，也是自证清白的手段）

06.2 第二颗：1000 人是一道法定门槛（T4 客户必然踩到）

06.3 第三颗：摄像头与人脸识别

你已经在现场感觉到「安装摄像头比较麻烦」——这个直觉是对的，而且比你想的更有道理。

• 公共区域采集人脸、识别身份，在《个人信息保护法》下有明确约束，需有合法必要性并设置显著提示标识
• 实践中已有大量相关争议与判例，作为可选增值功能去冒这个风险，性价比极低
• 而且按上面的条例，千人以上活动的场地管理者本来就有法定的监控与留存义务（录像留存不少于 30 日）—— 这块是场地方的责任，不该由你来做，也不需要你重复做

07抽奖：怎么把它做成生意而不只是节目

07.1 奖品形态决定毛利

07.2 抽奖是全场最后一个数据收口

把它放在哪个时间点，决定了你能拿到多少东西：

建议放在分会场结束前五分钟——这一刻学员刚听完、还在座位上、情绪最好， 而你一个小页面可以同时拿到三样东西：对这场内容的评分（下一届议程优化）、 对赞助商的线索授权（可以直接变现）、是否愿意明年还来（复购预测）。

08数据到 CRM：真正的商业模式在这一节

你说「可以把这些数据接入到总平台后再接入到服务商的 CRM 系统中」—— 这一句里有两个必须做对的工程决策，做错了整套东西就交付不出去。

08.1 决策一：授权必须是「逐家」而不是「一次性」

08.2 数据模型：一张表决定合法与否

CREATE TABLE lead_consent (
  id                BIGSERIAL PRIMARY KEY,
  tenant_id         BIGINT       NOT NULL,   -- 多租户隔离，不可省
  event_id          BIGINT       NOT NULL,
  sub_session_id    BIGINT       NOT NULL,   -- 哪个分会场产生的
  attendee_id       BIGINT       NOT NULL,
  sponsor_id        BIGINT       NOT NULL,   -- ★ 授权给「这一家」

  granted_at        TIMESTAMPTZ  NOT NULL DEFAULT now(),
  -- 必须支持撤回（《个人信息保护法》要求，不是可选项）
  revoked_at        TIMESTAMPTZ,

  -- 最小化原则：明确记录授权了哪些字段，不要默认全给
  fields_granted    JSONB        NOT NULL,   -- ["name","phone","company","title"]

  -- 交付留痕：给哪家的 CRM 送过、什么时候送的
  delivered_to      JSONB        NOT NULL DEFAULT '[]'::jsonb,
  evidence_hash     TEXT                     -- 授权凭证哈希，用于事后自证
);

08.3 决策二：和 Chatwoot / EspoCRM 怎么接

你前面说过要用这两个开源件。这里要延续前面已经确定的边界，避免出现运行不可控的问题：

09开工清单

09.1 按优先级（做完一条就能用一条）

09.2 下一场真实大会之前，必须做完的四件事

• 离线签到已上线——断网也能扫，这是预案的底线
• 抽奖奖品价值已校验 < 5 万，公示页与档案导出已就绪
• 已与实际客户/法务确认：平台不是承办者，且已在合同中体现
• 已测算过入场吞吐：按 02.1 的表，算清楚这场会需要几个取卡台 / 几台自助机

09.3 本件未能验证的部分（如实标注）