模糊时间 / 无时间信息分支：suggestion + 批量查询

本文档处理时间模糊（如"明天下午""下周找个时间"）或完全无时间信息的场景。核心动作是调用 +suggestion 产出候选时间块，再根据是否需要会议室决定后续步骤。

前置条件

进入此分支前，调度器（schedule-meeting.md）已完成：

任务类型判定（新建 / 编辑）
编辑流：目标 event_id 已定位
新建流：默认值已补全
时间已判定为模糊或无时间信息

流程

1. 调用 suggestion

详见 lark-calendar-suggestion.md。

lark-cli calendar +suggestion \
  --start "<range_start>" \
  --end "<range_end>" \
  --attendee-ids "<ids>" \
  --duration-minutes <n> \
  --event-rrule "<rrule>"

规则：

用户完全没有提供时间信息时，先默认一个合理区间（如"今天剩余时间"或"近两天"）再调用
编辑流中，若用户说"改到明天下午""下周找个时间再约"，基于用户期望的新时间范围调用，不要沿用旧时间
不要在用户完全没给时间时反问"你想约什么时候" — 先补合理区间再进入 suggestion

2. 分支处理

不需要会议室

获取多个推荐时间块后，直接向用户展示候选时间，用户确认后进入落地操作。

需要会议室

获取候选时间块后，不要急于让用户只选时间。先将这些时间块一次性交给 +room-find 批量查询可用会议室，然后将【候选时间】与【对应的可用会议室列表】结构化展示，让用户一次性完成选择。

注意：即使用户最初只说"查会议室"且未带时间，也必须强制走 suggestion → room-find 路径。

详见 lark-calendar-room-find.md。

3. 用户确认后

用户选中 +suggestion 返回的时间块后，无需再次调用 +freebusy，直接进入落地操作
BLOCKING REQUIREMENT：必须先向用户展示选项并等待确认，禁止在未获用户确认时直接创建/更新日程

模糊语义消解与长期记忆

针对存在歧义的时间场景，严禁主观臆断。典型例子：

"上班后" / "下班前"
未明确上下午的 12 小时制时间

处理规则：

主动澄清真实意图，不自行猜测
用户澄清后，将个性化定义沉淀为长期偏好

用户展示格式

向用户展示多个时间块及对应会议室时，必须结构化分行排版，严禁将时间与会议室放在同一行：

## 2026-03-27 周五

[选项 1] 14:00 - 15:00（参会人均空闲）
  可用会议室：
  1. 学清嘉创大厦B座-F2-02🎦(7人)
  2. 学清嘉创大厦B座-F2-05🎦(10人)

[选项 2] 16:00 - 17:00（参会人均空闲）
  可用会议室：
  1. 学清嘉创大厦B座-F3-01🎦(6人)
  2. 学清嘉创大厦B座-F3-06🎦(8人)

💡 请回复您倾向的选项编号以及对应的会议室序号，我来为您完成预定。

落地

根据任务类型：

新建 → +create
编辑 → +update

落地规则详见 schedule-meeting.md § 落地日程变更。

3.3 KiB Raw Permalink Blame History Unescape Escape