H5活动分桌先核正式人数，再把同行不拆组、必须分开与同桌偏好分层，最后逐桌检查容量。WorkBuddy可用AI整理授权沟通和候选安排，让运营看清冲突；总人数没超上限不代表一定排得下，草案还须由现场负责人确认。
报名联系人说我们四位一起，未必已经明确不能拆开；说想坐朋友旁边，也可能只是有条件时优先。运营若统一当成硬要求，容易无解；若全部当随便安排，又会忽略已经答应的同行条件。
先向对应联系人核实会影响安排的关键要求，把组别、人数及适用范围写清。现场桌位、可用座位、通行与接待条件由负责人另行确认，不能拿宣传页面上的最大人数直接排位。
整理内部草案使用示例组别或受控编号，不将客户身份、联系方式和个人需要印进公开桌表。需要特殊接待的，由对应岗位在必要范围内接续。
知你AI助手可查询授权客户、历史会话与消息。限定H5活动、联系人和本次报名，读同行要求的上下文及后来修改。会话表达用于找条件；已经受理的人数与实际桌位由运营另行提供，不能从群成员数推定。
WorkBuddy按当前MCP说明完成通用连接与授权后，可提出：“从本次活动沟通提取同行组、明确不拆组要求、同桌偏好和后续变更，每项附出处。对照我提供的正式组别及桌容量，先列冲突，再给可检查的分桌草案；逐桌列人数，不猜身份或改报名状态。”
相同昵称先核稳定对象，同行组跨几段会话也不要重复加入。正式名单与聊天不一致时，交受理人员核实当前有效人数，再进入分配。
下图为MCP连接后台布局示意，分桌在AI客户端准备，并非产品内置席位管理页面。
以下组别、人数和规则全部虚拟，只演示草案验算。正式名单为甲四人、乙四人、丙二人、丁二人，四组均已确认不能拆开；现场负责人确认本次可用两张桌，每桌六人。丙、丁都更希望与甲同桌，此项仅为偏好。
可以先形成下面一版：
| 桌位 | 同行组 | 人数验算 | 偏好取舍 |
|---|---|---|---|
| 第一桌 | 甲与丙 | 四加二等于六 | 满足丙希望与甲同桌 |
| 第二桌 | 乙与丁 | 四加二等于六 | 丁的偏好未满足，需说明 |
四组各出现一次，没有拆组，两桌均不超六，总计十二人。若改成甲与丁、乙与丙，也满足硬条件，只是换了哪项偏好被满足。AI应并列两版差别，运营按实际协商选择，而非写某位客户更重要。
现在假定受理人员确认新的正式人数变成甲四、乙四、丙三、丁一，其余条件不变。总数仍为十二，但不能按原草案把丙挤进第一桌：四加三是七，超过六。
在不拆组前提下，任意一桌都无法组成六人：四配一只有五，四配三为七，两个四为八，三配一为四。因此两张六人桌无法装下这四组。草案应明确指出不可行，交负责人核实能否变更真实资源，或取得相关组明确同意后调整条件，不能偷偷拆组来凑满。
下图为AI客户端辅助检查流程，分配与人数均为虚拟示例。
负责人复核时按顺序检查：
知你AI助手帮助找回零散条件，WorkBuddy辅助枚举与验算。现场安排由负责人确定，确认后的对客通知只说明参与者需要知道的桌号、到场方式与联系路径，不分享别组私人需求。人数临时变化，回到同一份草案重查受影响范围。
不一定，同行不拆组等条件可能使现有容量无法组合，需逐桌验算。
先核原意，偏好与必须满足的条件分开，不替客户升级要求。
聊天用于找表达，当前正式名单由受理人员核实提供。
并列偏好取舍与影响，由负责人结合实际协商确认。
还需检查同行组、具体桌位及其他条件，重新核对受影响安排。
活动分桌把正式人数、硬条件和偏好放在一起，再逐桌检查。先选一场规模清楚的活动，用AI准备两版可回查草案，让运营在通知之前发现容量冲突，也把不能同时满足的偏好解释清楚。
如果活动同行与同桌要求分散在H5多轮沟通里，可以了解知你AI助手官网，让AI先整理有出处的条件，再协助准备可逐桌检查的安排草案。
也可以扫码交流你的客服数据整理需求：
全渠道智能客服系统，聚合微信、小红书、抖音等平台咨询，支持自动回复与多客服协同。
知你AI助手官网 >AI 驱动的智能接待助手，基于知识库生成可确认的推荐回复，提升响应效率。
知你快回官网 >浏览器插件，为小红书、抖音、网页客服场景提供快捷话术库与 AI 自动回复。
