某 AI 创新赛的参赛作品，选题是大型活动通信保障智能体——代号「保障大脑」。一句话：给定一场活动的规模（人数等），算出要给现场临时加多少基站、多少应急通信车，再把这套部署方案讲清楚。
定位的核心是一个判断：计算的归计算，AI 的归 AI。 「要加多少基站」这种数字，绝不能让大模型「估」——必须由确定性的工程公式算出来，否则评委一句「这个数怎么来的」就崩了。所以架构上把系统劈成两半：硬数字由公式算，AI 只负责把数字翻译成人能读的方案文字。AI 碰不到计算过程，也就编不了数字。 这是整件事可信度的根。
计算引擎：Erlang B 语音 + 吞吐量数据，双轨
- 语音腿：Erlang B 话务模型，按话务量算需要多少信道 → 载频 → 基站。用递推式算（避免阶乘溢出），并用标准 Erlang B 表的 8 个点校验数学正确性。
- 数据腿：按「每用户带宽 × 活跃比 × 人数」反推总吞吐，除以单小区 5G 容量，算需要多少小区 / 站。
- 顶层 planner：取两腿较大值 + 冗余 + 应急通信车，得出最终部署量。
三个设计决策
一、计算与 AI 分离（上面那条，可信度的地基）。 二、异构双 AI 交叉验证。 方案生成用一个模型（国产 GLM，SSE 流式吐字），方案验证用另一个异构厂商的模型（Azure GPT）。验证模型不知道生成模型写了什么，做独立的「第二意见」，专抓生成里的硬伤和不一致。用两个不同源的模型，是为了避开同源模型的同源错误。 三、Provider 抽象层。 换模型只改环境变量，不动业务代码。
真实坑：参数失真，5 万人跑出 201 个基站（现象 → 根因 → 解法）
这是整个项目最硬的一段料。最早跑「5 万人演唱会」场景，引擎吐出 含冗余 201 个基站、67 辆应急通信车——而公开的真实演唱会保障案例只用了约 4 个临时基站。量级差了几十倍。 评委只要一对照真实案例，作品当场就被否。
根因是默认参数太激进，逐个反推校准：
- 数据腿「每用户 4Mbps」是企业 SLA 的口径，而活动保障要的是「基本通信顺畅」不是给每人保 4M——降到 1Mbps；
- 「活跃比 0.5」偏高——降到 0.3；
- 「单小区 600Mbps」是 4G 水平、低估了 5G——提到 1200Mbps；
- 语音腿每用户话务量取 0.02 Erl 的下限。
每个参数都在注释里写明对标来源。校准后同一场景落到 基础 13 站 → 含冗余 16 站 + 6 辆应急车，回到真实案例的量级。
这个「差几十倍 → 找公开案例反推参数 → 把量级拉回来」的过程，比那个漂亮的最终数字更值钱——它是把一个会被一眼戳穿的作品救回来的过程。
量化与上线
5 万人场景 16 站 / 6 车（对标公开演唱会案例约 4 个临时基站，同量级）；Erlang B 标准表 8 点校验通过；三段式 pipeline（生成 / 验证 / 可视化）端到端跑通；React + Leaflet 前端把部署点位和覆盖圈画在地图上；Docker 打包部署到云容器服务，已上线 guard.zdwktlj.top。
诚实边界
- 只是「同量级」，不是精确复刻真实案例。 差异来自「从零规划 vs 在已有基站上叠加」——真实活动现场本就有基站，我算的是「还要加多少」，口径不完全可比。不美化成「精准吻合」。
- 地图上的部署点位和覆盖圈是几何估算的可视化，不是真实射频规划。 真做要考虑地形、频率干扰、实测——这些没做。
- 参数是公开标准 + 行业经验反推，不是内部真实工参。 量级对，但别当工程设计依据。
小结
这个项目最说明问题的不是「AI 能写保障方案」，是那条「计算与 AI 分离」的判断：凡是要被追问「这个数怎么来的」的地方，就别让 AI 碰。 让公式算、让 AI 写、再让另一个异构 AI 验——可信度是设计出来的，不是模型大出来的。而那个把 201 站校准回 16 站的过程，是整件事里我最该写下来的硬料。