主题
T6 找讨论室（Demo 场景 PRD）
| 项 | 内容 |
|---|---|
| 文档定位 | 08_移动端AI场景设计.md §4、§10 教师模块 T6 找讨论室 的场景 PRD；学生 S7 复用同一能力，只写教师侧差异 |
| 通用规范引用 | 前端形态、常驻会话、智能体边界、输出规范见 公共规范.md；本文只写 T6 场景本身 |
| 能力来源 | 空间主数据与预约系统（实时忙闲）、设备控制、space-agent 的推荐排序与冲突平替 |
| 复用关系 | 只复用能力，不复制流程：沿用 space-agent 的推荐排序与冲突平替；它原有的 Dify 槽位提取、时间归一化管道、卡片点选确认属于旧实现细节，本文按 ReAct 智能体重写为「要素 + 工具 + 判断原则」 |
| 版本 | v0.1 |
1. 场景定义
1.1 一句话
教师说一句话表达要找什么样的房间，Agent 从时间和人数等要素出发查可用房间、给候选，确认后建单，并视需要联动设备。
1.2 用户与价值
| 项 | 内容 |
|---|---|
| 用户 | 授课教师、业界导师（demo 账号 T1001） |
| 典型诉求 | 课后小组讨论、案例研讨、带企业嘉宾小范围交流 |
| 价值 | 不用翻预约系统、不用逐层选楼栋/楼层/时段；一句话拿到可选房间并完成预定 |
| 频次 | 低频、临时发起 |
| 与 S7 的关系 | S7 学生讨论室预约复用本文能力；差异只在权限与可约范围 |
1.3 触发方式
- 被动问答：用户先说一句话，Agent 理解后调用工具；无定时任务、无主动推送。
- 入口：小程序首页「AI」悬浮球 → 教师助手常驻会话。
- 一轮处理一个主需求；一句话里同时要订房和订车时，先反问优先级。
1.4 要素
这是本场景最该讲清的部分：Agent 只需要把这些要素拿齐，不必照搬旧的槽位结构。
| 要素 | 是否必填 | 说明 | 缺失时 |
|---|---|---|---|
| 时间 | 必填 | 日期 + 开始时间；结束时间可推断 | 缺开始时间必问，不默认「现在」；只说「两点」问上午/下午 |
| 人数 | 必填 | 用于容量筛选 | 问一次，不默认 2 人 |
| 空间偏好 | 可选 | 指定房间、楼栋或楼层 | 不指定则按条件在可约范围内找 |
| 设施 | 可选 | 投屏、电视、音频、视频、白板 | 不提则不限设施 |
| 时长 | 可选 | 未说按 2 小时预占并写明 | 声明即可，不追问 |
| 审批 | 系统属性 | 房间本身是否需审批 | 建单后返回状态，不让用户先猜 |
要素之间可以互相推断：说了「下午两点到四点」就不必再问时长；说了房间名且容量满足，人数仍要确认一次，用于建单。
1.5 边界
| 不做 | 原因 |
|---|---|
| 不做会议邀请、参会人管理、签到 | 属会议系统/日历能力，本场景只到「订到房间」 |
| 不做跨校区、校友/校外预约 | 本期只覆盖新院区；校友/访客归 E 类 |
| 不做审批流本体 | 只返回审批状态，不实现、不承诺时限 |
| 不做周期性/长期固定预约 | 周期规则与占用优先级未定义，本期只做单次 |
| 不在查询阶段或预定前开设备 | 设备控制有能耗与安全影响，必须建单后单独确认 |
| 不展示他人预约的主题、参会人 | 只暴露「该时段是否可用」 |
| 不渲染业务卡片/按钮 | 前端只渲染 Markdown，确认走自然语言 |
| 不硬推不符合条件的房间 | 无房时给放宽方向，不拿小房间凑数 |
2. Demo 形态
通用形态见 公共规范.md。本场景只约定：
- 教师助手会话内完成，单会话多轮：表达需求 → 看候选 → 确认 → 回执 →（可选）设备。
- 候选用 Markdown 表格呈现，最多 3 个；表格带编号只是方便指代，用户说房间名、「第二个」「就它」都算确认。
- 候选保留在当前会话上下文；用户改口「换成 4 点」「不要投屏」时重新查询，旧候选自然作废。
- 建单成功后的「查看预约」是 Markdown 链接，URL 由工具返回；demo 可用占位地址。
- 设备联动只在建单成功后询问一次，用户不回应就不执行。
3. Agent 输出设计
3.1 输出元素
| 元素 | 用途 | 约束 |
|---|---|---|
| Markdown 文字 | 结论、冲突说明、审批状态、建议 | 结论先行 |
| Markdown 表格 | 候选房间清单 | 最多 3 行 |
| Markdown 链接 | 查看预约、预约页 | URL 由工具返回 |
| 编号 | 便于指代候选 | 不强制用户回编号 |
| Mermaid | 默认不用 | 用户要求看时段占用分布时才用，最多 1 张 |
3.2 示例一：要素齐全，给候选并建单
用户
下午两点想找个能坐 30 人、能投屏的讨论室
Agent
今天 14:00–16:00（没说结束时间，按 2 小时预占），有 3 间满足「≥30 人、有投屏」：
编号 房间 位置 容量 设施 状态 1 305 案例讨论室 A 楼 3F 32 人 投屏、白板 可预约 2 201 研讨室 B 楼 2F 36 人 投屏、视频 可预约 3 401 教研讨论室 A 楼 4F 30 人 投屏 需审批 说「订 2」或直接说房间名都行；要改时间、人数或设施，也可以直接说。
用户
订第二个
Agent
已预定 B 楼 201 研讨室，今天 14:00–16:00，30 人。预约号 BK20261105002。查看预约
需要我 13:45 提前开空调或投影吗？不用的话直接说「不用」。
3.3 示例二：指定房间被占用，给替代
用户
今天下午两点，A 楼 305，30 人，要投屏
Agent
A 楼 305 在 14:00–16:00 已被占用。同时段、同规格、带投屏的替代有 3 间：
编号 房间 位置 容量 设施 状态 1 307 案例讨论室 A 楼 3F 32 人 投屏、白板 可预约 2 401 教研讨论室 A 楼 4F 30 人 投屏 需审批 3 201 研讨室 B 楼 2F 36 人 投屏、视频 可预约 要订哪间？或者换个时段也可以。
（不展示占用方是谁、开什么会。）
3.4 示例三：要素不全或时间有歧义，先追问
用户
帮我找个 30 人能投屏的讨论室
Agent
好的，哪天、几点？
用户
明天两点
Agent
明天上午两点还是下午两点？
用户
下午
Agent
明天 14:00–16:00，有 3 间满足「≥30 人、有投屏」：……（候选表）
3.5 示例四：需审批，只给状态
用户
明天下午 3 点，A 楼 501 研讨室，20 人
Agent
A 楼 501 明天 15:00–17:00 可用，这间需要审批。需要我提交预约申请吗？
用户
提交吧
Agent
已提交，待审批。进度可在预约页查看，审批结果出来后也可以直接问我。
（不承诺审批时限，不说「已预定成功」。）
3.6 异常与降级
| 情况 | 输出 |
|---|---|
| 指定房间解析不到 | 说清没识别出这间房，请补充楼栋+房间号，或改按条件找房 |
| 可用查询超时 | 「暂时查不到可用房间」，建议稍后重试或去预约页；不返回空结果假装无房 |
| 设施名称不在字典 | 忽略该设施并注明「{设施}暂未纳入筛选」，其余条件照常查 |
| 容量字段为空 | 不参与筛选，展示写「容量暂无」，不按 0 处理 |
| 建单时刚被抢占 | 说明已被占用，重新给替代，等用户再确认；不自动改订 |
| 建单超时/结果未知 | 不重试建单；先查「我的预约」核对，再告诉用户去预约页确认 |
| 审批状态缺失 | 只说「审批中」，不猜通过或驳回 |
4. 工具设计
4.1 公共约定
- 四个工具都是原子能力，由 Agent 按需组合；工具内部不做跨步骤编排，也不规定调用顺序。
- 用户身份由会话/网关注入，模型不能传任意
user_id；工具以注入身份做数据隔离。 - 时间统一
YYYY-MM-DD+HH:mm（24 小时制）；不支持跨天预约，结束时间越过 23:59 直接拒绝。 - 空值 ≠ 0：容量未知返回
null；无数据返回空数组 + 状态，不返回假数据。 - 设施入参用名称：
投屏、电视、音频、视频、白板；名称到后端标识的映射由工具服务端维护，模型只看到名称。
4.2 resolve_space
| 项 | 内容 |
|---|---|
| 作用 | 把「A 楼 305」「案例讨论室」解析为唯一 space_id；只做实体解析，不判断忙闲 |
| 复用 | space-agent 空间解析能力 |
| 入参 | query（必填）、top_k（可选，默认 3） |
| 何时调用 | 用户指定了具体房间时才调；只说「找个讨论室」不调 |
返回：
| 字段 | 类型 | 说明 |
|---|---|---|
status | enum | ok / clarify / not_found |
space_id | string | 唯一空间 ID；仅 ok 时有值 |
space_name | string | 标准房间名 |
building / floor | string | 楼栋 / 楼层 |
capacity | int / null | 容量；未知为 null |
facilities | string[] | 设施名称列表 |
candidates | array | clarify 时的候选房间 |
4.3 list_available_rooms
| 项 | 内容 |
|---|---|
| 作用 | 按时间、人数、设施查可用房间；也可校验指定房间在该时段是否可用 |
| 复用 | space-agent 可用查询 + 推荐排序（语义相似度 + 容量适配度） |
| 入参 | date、start_time、end_time、capacity 必填；facilities、space_id、top_k 可选 |
返回：
| 字段 | 类型 | 说明 |
|---|---|---|
status | enum | ok / empty / room_conflict / error |
reason | enum / null | empty 时：no_capacity_match / no_facility_match / all_busy |
rooms[] | array | 最多 top_k 个；含 room_id、room_name、building、floor、capacity、facilities、requires_approval |
conflict_room | object / null | 指定房间被占用时返回该房间信息 |
约定：
- 排序沿用现有推荐逻辑，工具只返回排好序的列表；Agent 不展示分数、不解释权重。
- 查询失败返回
error，不能当成empty告诉用户「没有房间」。
4.4 create_room_booking
| 项 | 内容 |
|---|---|
| 作用 | 用户确认后创建单次预约 |
| 入参 | room_id、date、start_time、end_time、people_count 必填；topic（默认「教师讨论」）、request_id（幂等键）必填；confirmed 必须为 true |
返回：
| 字段 | 类型 | 说明 |
|---|---|---|
status | enum | confirmed / pending_approval / conflict / failed / unknown |
booking_id | string / null | 预约号 |
approval_status | enum / null | none / pending / approved / rejected |
booking_url | string / null | 预约详情页 |
fail_reason | string / null | occupied / no_permission / system_error |
约定：
confirmed != true时拒绝建单；这是工具侧兜底，不能替代 Agent 的确认判断。- 同一
request_id重复调用返回首次结果，不产生第二张单。 status=unknown时不重试建单，先查list_my_bookings核对。
4.5 list_my_bookings
| 项 | 内容 |
|---|---|
| 作用 | 查本人预约，用于「我订的几点」「审批了吗」「刚才到底订上没有」 |
| 入参 | date_from、date_to、status、request_id，均可选 |
| 返回 | bookings[]：预约号、房间、日期、时段、状态、审批状态、详情链接 |
| 数据范围 | 只返回本人预约，不返回他人 |
5. 判断原则
5.1 缺什么问什么
一轮只问一个缺失要素；已经说过的不要再问。能从上下文补全的（如「跟刚才一样」「那明天呢」）直接补，不重复确认。
5.2 默认值必须声明
未说日期默认今天、未说时长按 2 小时预占——这两条可以直接用，但回复里必须写明，让用户有机会改。人数不说必须问，不默认。
5.3 什么时候算「确认」
- 算：指向唯一一间（房间名、「订 2」「第二个」「就它」）。
- 不算：只有「嗯」「好」「可以」而候选有多间 → 追问是哪一间。
- 改过条件（时间/人数/设施）后，旧候选作废，必须重新确认才能建单。
5.4 冲突、无房、审批
- 冲突：说明原房间已被占用，给同规格替代；不展示占用方信息；不自动改订。
- 无房：明确说「暂无满足条件的房间」，给三个放宽方向（换时段 / 减设施 / 减人数），不硬推。
- 审批：只回「已提交，待审批」或「审批中」，不承诺时限、不说成功。
5.5 设备联动
只在建单成功后问一次「要不要提前开空调/投影」；用户明确说要才调设备控制工具（单步）；失败时告知可用现场面板手动开启。不在查询阶段开，也不在预定前自动开。
5.6 不做什么
不做邀请与参会人、不做签到、不做跨校区、不做校友/访客预约、不做周期预约、不展示他人日程。
6. 定时任务配置
无。 本场景是被动问答，不需要定时触发，也不写入「本周 AI 运行洞察」卡片。
7. 权限与数据范围
| 维度 | 规则 |
|---|---|
| 角色 | 教师助手加载本能力；学生助手（S7）复用同一能力，权限配置不同 |
| 可约空间 | 教师：教研讨论室、案例讨论室、研讨室；不含普通教室、报告厅、贵宾室（待确认） |
| 学生范围 | 仅学生讨论室/研讨室；人数与时长上限更小（具体值待确认） |
| 数据范围 | 只查新院区、当前用户有权预约的空间 |
| 他人数据 | 只返回「可用/被占用」，不返回他人预约主题、参会人、部门、联系方式 |
| 操作级别 | 查询=只读；建单=执行，必须显式确认；设备控制=执行，必须二次确认 |
| 身份 | 由会话注入，模型不可指定他人身份 |
8. 验收要点
| # | 验收项 | 标准 |
|---|---|---|
| 1 | 正常找房 | 「下午两点，30 人，能投屏」返回最多 3 个候选，含房间、位置、容量、设施、状态 |
| 2 | 建单 | 用户确认某间后建单成功，回执含房间、日期、时段、人数、预约号 |
| 3 | 未确认不建单 | 未指向具体房间时不调用建单工具、不产生预约 |
| 4 | 要素不全 | 缺时间时先问；「明天两点」追问上午/下午；「下午两点」直接按 14:00 处理 |
| 5 | 默认值声明 | 默认今天、默认 2 小时都要在回复里写明 |
| 6 | 冲突替代 | 指定房间被占时说明并给同规格替代，不展示占用方信息 |
| 7 | 审批 | 需审批房间只回「已提交/审批中」，不承诺时限、不说成功 |
| 8 | 设备二次确认 | 建单成功后询问一次；未确认不调用设备控制 |
| 9 | 无房 | 说明「暂无」，给放宽方向，不硬推 |
| 10 | 数据范围 | 不出现他人预约信息、不出现跨校区房间 |
| 11 | 空值 | 容量/审批状态缺失写「暂无」，不写 0 |
| 12 | 幂等 | 同一 request_id 不产生第二张单；超时先核对再告知 |
9. 已确认与待确认
9.1 已确认
| # | 事项 | 结论 |
|---|---|---|
| 1 | 写法 | 按 ReAct 智能体的「要素 + 工具 + 判断原则」组织，不复制旧 Dify 槽位与时间管道 |
| 2 | 复用 | 推荐排序与冲突平替沿用 space-agent，本项目不重写算法 |
| 3 | 确认方式 | 自然语言确认即可，编号只作指代；多候选下「嗯/好」不算确认 |
| 4 | 审批 | 只返回审批状态，不实现审批流、不承诺时限 |
| 5 | 设备 | 建单成功后询问一次，用户确认才调设备控制 |
| 6 | 边界 | 不做邀请/参会人/签到、跨校区、校友预约、周期预约 |
| 7 | 复用关系 | S7 学生讨论室预约复用本文能力，仅权限与可约范围不同 |
9.2 待确认
| # | 事项 | 需要明确 |
|---|---|---|
| 1 | 审批流 | 是否存在？哪些房间需要？由谁定义、几级审批、状态字段与查询接口？没有审批流时删除该分支 |
| 2 | 可约范围 | 教师可约哪些楼/房间、开放时段、单次最长时长、是否允许跨天；学生与教师的差异 |
| 3 | 设施字典 | 五个设施名称与后端标识的映射；白板是否有空间标签；字典由谁维护 |
| 4 | 教务占用 | 讨论室被排课占用是否已体现在空间忙闲中，是否需另接教务课表 |
| 5 | 推荐算法 | 沿用现状；优化方案单独评审，不在本 PRD 展开 |
| 6 | 建单系统 | 写入飞书/钉钉/自有会议系统/空间预约系统中的哪一个；预约号规则与详情 URL |
10. 关联文档
| 文档 | 关联内容 |
|---|---|
公共规范.md §2、§3、§6、§8 | 前端形态、常驻会话、智能体边界、输出规范、PRD 骨架 |
08_移动端AI场景设计.md §4、§10、§11 | 教师 10:30 找讨论室、T6 模块定义、冲突与审批兜底 |
06_校友预约vs会议预定.md §2、§4 | 会议预定与校友预约的差异；预约本身不走审批 |
T1-到校前简报.md | 场景 PRD 写法样板 |
space-agent 会议室推荐算法逻辑.md | 推荐排序与冲突平替（只引用，不重写） |
注：本文与上述文档不一致时，以本文为准，回写更新对应文档。