会议室大概是办公室里最不稀缺、却最难订的资源。房间数量不算少，但总有人订了不来、有人临时占着不走、有人为了保险一次订三间，最后真正要用的人站在走廊里刷手机。
先说清这篇的位置。站内跟「时间与空间」有关的文章已经有三篇，但都没占这个角度：OpenClaw 怎么管日程 管的是你一个人的时间——接日历、排期、会议前提醒；OpenClaw 做设备报修与维保台账 管的是房间里的设备坏了要修；用 AI Agent 做物资出入库与领用管理 管的是可以搬走的东西。这一篇管的是一个搬不走、只能按时间片共用的资源：房间本身，以及它每个时段被谁占了。
一、三样东西分开管：房间、预订单、人
很多团队的会议室管理做成一团乱麻，根子在于把三件不同的事混在一个表里。要先分开：
- 房间是资产——它长期存在，字段稳定，关心的是「能装多少人、有什么设备、可不可预订」。
- 预订单是记录——它有始有终，关心的是「谁、什么时候、占哪一间、用来干什么」。
- 人是责任人——预订必须有明确的人，不是「市场部」，否则超时释放时没人可通知。
分开之后，台账归台账、订单归订单，数据才不会互相污染。
二、房间台账要记七个字段
房间台账不做花哨的平面图，七个字段够用：
- 房间编号——贴在门上，和系统里一致，这是所有记录的锚点。
- 房间名称——别起「小会议室 2」这种名字，三个月后没人记得是哪间。
- 容纳人数——用于申请校验，人数超了要提示改订。
- 楼层与位置——方便通知里写清楚，减少找房间的时间。
- 固定设备——投影、视频会议、白板、麦克风，哪些是固定的、哪些要提前借。
- 可预订时段——是否含午休、是否支持加班时段，默认值写在台账里。
- 状态——可用、装修中、临时征用。状态不对的房间自动从可选项里消失。
三、申请单四个必填，时间粒度先定死
申请单字段不在多，在准。四个必填就够拦住大部分乱订：
- 预订人——具体到个人，不接受部门名义。
- 房间或房间类型——允许写「任意 8 人以上带视频设备的房间」，让系统去匹配，减少为保险订大房间的情况。
- 起止时间——精确到 15 分钟，并规定最小预订时长与最大时长。
- 用途与人数——用途一句话，人数用于校验容纳量。
时间粒度是这套系统的地基。粒度太粗（按小时），会出现「订一小时占两小时」；粒度太细（按分钟），大家会为了抢时段把会议切成碎片。15 或 30 分钟是常见的平衡点。表单字段的设计可以对照 OpenClaw 任务输入表单怎么设计 里那条原则：把自由描述变成可执行字段，能被规则校验的，就别留给自然语言。
四、冲突检测三条规则
冲突检测看起来简单，实际要同时管三个维度，缺一个都会有漏网之鱼：
- 同一房间时间不可重叠——最容易想到的一条，也是唯一被大多数系统实现的一条。
- 同一人在不同房间时间不可重叠——防止一个人同时出现在两场会里，这才是「订了不用」的主要来源之一。
- 缓冲时间——两场会之间留 5 到 10 分钟，用于收尾和设备切换。没有缓冲，第二场必然推迟，连锁反应一整天。
检测要在提交时就做，而不是事后发现。提交时直接给出替代方案——「该时段 3 楼 302 可用」——比一句「时间冲突」有用得多，这直接决定了大家愿不愿意用系统。
另外，校验规则要先定清楚再上线。这一点和 OpenClaw 数据质量门禁怎么设 是同一个动作：把「什么算不合格」写成可执行的规则，而不是等出问题时靠人当场判断。规则一旦写死，冲突就变成系统行为，不再是找谁协调。
五、优先级与超时释放
房间永远不够时，先定规则再谈公平，否则每次冲突都要人来裁决，系统就废了。优先级建议只分三档：
- 对外或跨部门会议优先于内部讨论。
- 人数多的会议在同等条件下优先匹配大房间。
- 提前预订的时间越早越稳，避免「临时会用提前三天订的会的人」，这也是鼓励大家早做计划。
比优先级更重要的是释放规则：会前 10 分钟未签到（或未接入线上），房间自动释放回可预订池，同时给预订人一条通知。这一条能把占用率立刻拉下来，而且不需要任何行政命令——它靠的是规则，不是纪律。
如果房间数量多、排期又密，规则之间会互相打结，这时可以直接借用 OpenClaw 自动排班 里的办法：先把「不可违反的硬约束」和「可让步的软偏好」分开，再用同一套校验逻辑跑冲突，最后一步才谈人工协调。
六、提醒、签到与自助取消
三档提醒足够，多了变噪音：
- 预订确认——立刻回执，带上房间、时间、位置和需要的设备。
- 会前提醒——提前 30 分钟发一次，带一键签到与一键取消。
- 释放通知——房间被自动释放时通知预订人，让他知道不是被人抢了。
这套定时与推送机制可以直接复用 OpenClaw 怎么定时发日报周报 里那套配置：定时任务、模板、推送渠道分开配，改文案不用动逻辑。另外，一键取消这个入口一定要显眼——大部分人不是故意占着房间，是开完会忘了取消。
七、占用率数据只回答三个问题
有了预订数据，最容易做出一堆没人看的图表。收住，只回答三个：
- 哪些房间最紧张、哪些时段是高峰——这决定了下一轮要不要调整房间用途，或者要不要错峰安排例会。
- 预订了但没用有多少——用「释放次数 ÷ 预订总数」衡量，这个数字通常比大家想象的高，也最能说服人接受自动释放规则。
- 实际使用时长和预订时长差多少——平均差得越多，说明系统里的时间粒度或者大家的预订习惯有水分。
这三个问题的共同点：指向资源配置，不指向个人。一旦做成「谁取消最多」的排名，第二个月就没人愿意诚实取消了。
八、三条边界与五个坑
边界：
- 不代替审批——需要审批的特殊场景（对外接待、外部人员进入）仍然走原有流程，Agent 只负责房间这一层。
- 不做考勤与在位判断——房间占用不等于人在岗，不要把两个数据打通做人的判断。
- 不自动改动已开始的会议——运行中的占用不允许被系统抢走，规则之外的人工协调留给人。
常踩的坑：
- 只做冲突检测，不做释放——订了不用是主要矛盾，光防重叠解决不了一半问题。
- 房间名称不规范——通知里写「小会议室 2」，人在三层楼里转圈。
- 缓冲时间设为 0——表面上提高了利用率，实际制造了连锁延误。
- 把释放做成惩罚——发一条「你已被记录」的通知，第二天开始大家宁可空着也不取消。
- 忽略线下占房——有人直接进去坐下开会，系统里房间是空的。留一个「临时占用登记」入口，比强行要求所有人走流程更现实。
适合谁：房间在 5 间以上、人一多就开始抢的团队；有多个楼层或者多个办公点的组织收益最大。只有两三间小会议室、人数不多的团队，用表格加群接龙就够，上系统反而是负担。
这类行政系统的价值不在「功能多」，而在「规则清楚、自动执行」。把释放规则跑起来的那一周，你会明显感觉到走廊里站着刷手机的人变少了。
