企业官网建设流程全解析

Lark 飞书 CLI 日历 Skill：预约/改约日程与会议室搜索的完整工作流指南

【免费下载链接】cliThe official Lark/飞书 CLI tool, maintained by the larksuite team — built for humans and AI Agents. Covers core business domains including Messenger, Docs, Base, Sheets, Calendar, Mail, Tasks, Meetings, and more, with 200+ commands and 20+ AI Agent Skills.项目地址: https://gitcode.com/gh_mirrors/cli414/cli

本文以skills/lark-calendar/references/lark-calendar-schedule-meeting.md为主体，结合仓库内+create、+update、+room-find、+suggestion、+freebusy等命令文档与shortcuts/calendar/下的源码实现，完整还原飞书 CLI 中"预约/改约日程、查询/搜索可用会议室"的智能调度工作流，帮助开发者与 AI Agent 理解任务类型判定、时间分支路由、会议室落地等关键决策节点，掌握可直接运行的 CLI 调用方式。

在 Lark/飞书官方 CLI（仓库路径gh_mirrors/cli414/cli）中，"帮我约个会""下周找个时间开会""给周会换个会议室"这类自然语言请求，并不是简单映射到一条创建命令就能完成的。lark-calendarskill 通过lark-calendar-schedule-meeting.md定义了一套严格的调度工作流：先判定任务类型（新建还是编辑），再定位目标日程、补全默认值、判断时间明确性、走对应分支查询会议室与忙闲，最后才落地写操作。本文将以这份工作流文档为主线，逐一拆解每个步骤的判定规则、命令参数与底层实现依据。

一、工作流全景：先判型、再定位、后落地

schedule-meeting.md开篇即给出执行摘要，强调以下几个原则：

• 第一步永远是判断任务类型：新建日程，还是编辑已有日程。
• 编辑已有日程时，必须先定位目标日程或实例的event_id，未拿到唯一event_id前不得调用+update。
• 默认做智能助理，不做表单填写机：能根据上下文补全的默认值就直接补全，仅在必须决策的冲突或无法唯一确定的场景下才发起询问。
• 新建流先补默认值，编辑流先继承已定位日程信息。
• BLOCKING REQUIREMENT：面临时间方案或会议室方案的选择时，必须先向用户展示选项并等待确认，禁止未经确认直接创建/更新日程。
• 必须按顺序执行：不要跳过"任务类型判定 → 目标日程定位（编辑流）→ 补默认值/继承基线信息 → 判断时间明确性"这些前置步骤。

该文档还明确列出了一系列"严禁行为"，包括：严禁在未读取对应子命令文档前直接调用命令；严禁在尚未判断"新建"还是"编辑"之前就直接进入创建日程或查会议室动作；严禁把"带有既有日程锚点 + 修改动词"的请求当成新建日程；严禁在编辑已有日程时跳过目标定位步骤；严禁在面临时间/会议室方案选择时未经用户确认就擅自创建/更新日程。

这一设计在skills/lark-calendar/SKILL.md的"前置条件路由"一节得到呼应：凡涉及预约日程/会议、调整时间、查会议室，第一步必须读schedule-meeting.md；仅编辑字段（标题/描述）或增删参会人（不涉及时间和会议室）时可跳过，直接读lark-calendar-update.md。

二、核心概念：会议室是日程的参与人，不是独立资源

schedule-meeting.md的核心概念部分给出了三条关键认知：

• 会议室是日程的一种参与人（attendee / resource），不能脱离日程单独预定。
• 预定或查找会议室，均需先确定时间块。
• 当用户说"查会议室""找会议室"，默认意图是查会议室可用性，不是检索会议室资源名录。

这一点在源码与命令文档中均有印证。+room-find的文档（lark-calendar-room-find.md）开篇即声明："会议室是日程的一种资源型参与人，不能脱离日程单独预定"；+update文档也强调"会议室是 resource attendee，必须使用omm_ID 添加到参会人列表"。参会人 ID 前缀规范贯穿所有相关命令：

在+create的参数定义中（lark-calendar-create.md），--attendee-ids同样支持用户（ou_）、群组（oc_）和会议室（omm_），并明确要求"AI 提取时请务必保留对应前缀"。

三、任务类型判定：新建 vs 编辑

工作流要求处理任何请求前先做任务类型判定。文档给出了判定表：

判定规则非常明确：只要同时出现"既有日程锚点"（标题、时间段、这个日程、这场会）和"修改动词"（添加、移除、改到、换），默认判定为编辑；对重复性日程的编辑，必须先定位到对应实例的event_id。

适用场景示例（文档原文）：

• "帮我约个会" / "下周找时间和 XX 开会"
• "帮我订/找/搜索一个可用会议室"
• "明天下午3点约个日程"
• "把明天上午的日程加上 小明"
• "给下周一的周会换个会议室"
• "把这个日程改到明天下午，并加上学清 F201"

四、编辑流：先定位目标日程，绝不跳步

4.1 定位规则

编辑已有日程时，必须先定位目标event_id：

• 优先利用用户给出的标题、日期、时间范围等锚点，通过+agenda、+search-event或实例视图缩小范围；
• 命中多个候选日程时，必须向用户展示候选项并要求确认；
• 重复性日程必须继续定位到该次实例的event_id。

+search-event的命令形态（来自 SKILL.md）：

lark-cli calendar +search-event --query "周会" --start 2026-04-20 --end 2026-04-27 \ --attendee-ids "ou_user1,oc_chat1,omm_room1" --page-token <page_token> --page-size 30

注意--attendee-ids的多值语义为同类型内 OR（并集）：--attendee-ids "ou_A,ou_B"表示 A或B 参加的日程，而非 A 和 B 都参加。

4.2 编辑流分支路由

定位成功后，按子场景路由到不同处理路径：

五、新建流：智能推断默认值

新建日程时，遵循"智能助理"原则，能推断的默认值直接补全：

• 标题：根据上下文自动生成；如无法推断，默认"会议"；
• 参会人：如未指定，默认仅用户自己；
• 时长：基于上下文推断；默认 30 分钟；
• 无时间信息：默认推断合理区间（如"今天"或"近两天"），进入时间推荐流程，禁止询问用户。

一个例外是：搜索参与人出现多个结果无法唯一确定时，必须询问用户并记录长期记忆。

六、判断时间是否明确：编辑流改时间必须保持原时长

时间基准规则：

• 新建流：使用用户给出的时间，或默认补全出的时间范围；
• 编辑流且不改时间：已定位日程的当前start/end就是明确时间；
• 编辑流且改时间：用户想改到的新时间；若表达模糊，进入模糊时间分支。

文档特别强调了一条容易踩坑的规则：

在执行修改日程/会议时间的任务时，必须先获取原日程的持续时长。如果用户只提供了新的开始时间，你必须根据原时长自动计算出新的结束时间，严格保持原时长不变，禁止擅自改变原日程的时长。

这一规则在+update文档中同样被标注为"⚠️ 高风险操作"：修改时间时必须先读取原日程时长并计算新 end，如果 end 计算错误导致日程时长变化，用户会直接感知。

七、分支路由：明确时间与模糊时间两条路径

时间明确性判定完成后，按分支表路由：

7.1 明确时间分支：room-find + freebusy + 冲突处理

lark-calendar-schedule-clear-time.md处理时间已明确的场景。进入分支前，调度器已完成任务类型判定、event_id 定位、默认值补全与时间明确性判断。流程分三步：

步骤 1：查询会议室（如需）

lark-cli calendar +room-find \ --slot "<start>~<end>" \ --attendee-ids "<ids>" \ --city "<city>" \ --building "<building>" \ --floor "<F2>" \ --room-name "<room_name>"

时间块确定规则：编辑流且不改时间、只新增会议室时，--slot必须来自已定位日程的当前start/end；编辑流且既改时间又加会议室时，--slot必须来自候选新时间，而不是旧时间。

+room-find的完整参数（lark-calendar-room-find.md）：

批量会议室名称查询示例：

# 场景：帮我约一个 16~20 号之间的会议室 lark-cli calendar +room-find \ --slot "2026-03-27T14:00:00+08:00~2026-03-27T15:00:00+08:00" \ --room-name "16,17,18,19,20" # 场景：查找 木星 或 火星 会议室 lark-cli calendar +room-find \ --slot "2026-03-27T14:00:00+08:00~2026-03-27T15:00:00+08:00" \ --room-name "木星,火星"

参数提取还有几处重要规则：--city仅在用户明确说出城市时提取；若已提取--city，--building中不要再重复携带城市前缀（如"北京学清嘉创大厦B座"应拆为--city "北京"与--building "学清嘉创大厦B座"）；复合会议室号如F3-05应优先拆为--floor "F3"+--room-name "05"；同一语义槽位只保留一个规范值，禁止同时传2楼 F2这类重复信息。此外，返回结果不保证与搜索词完全字面匹配——底层可能结合邻近楼层推荐（如搜"2层"无空房时可能返回相近的"3层"候选），这不应被误判为异常。

步骤 2：查询忙闲

# 单人 / 多人查忙：--user-id 可重复或逗号分隔；服务端已合并相邻/重叠忙碌区间 lark-cli calendar +freebusy --start "<start>" --end "<end>" --user-id "ou_a,ou_b" # 直接求共同空闲（推荐用于「找几个人一起有空」） lark-cli calendar +freebusy --start "<start>" --end "<end>" \ --user-id "ou_a,ou_b,ou_c" --type common_free --min-duration 30m

忙闲查询规则：

• 参与人含bot：无需为 bot 查询忙闲——bot 是虚拟身份，可并行多个会议、无忙闲语义；
• 参与人过多（超过 5 人）：仅查询当前用户及少数核心人员忙闲即可；
• 参与人含群组：无需展开群组成员查询忙闲；
• 如果用户是从+suggestion确认了时间块后进入本分支的，无需再调用+freebusy；
• 找多人共同空闲：直接用--type common_free [--min-duration <dur>]让 CLI 一次算出共同空闲，不要自己再合并求交。

+freebusy的四种视角（来自 SKILL.md）：busy（合并后的忙碌区间，默认）、raw_busy（原始日程块 + rsvp_status）、free（空闲区间，可带--min-duration）、common_free（多人共同空闲，可带--min-duration）。注意+freebusy只回答"哪些区间空着"，不判断该区间是否适合排会；要"推荐合适时间"必须走+suggestion。

步骤 3：冲突处理

• 无冲突：直接让用户选择会议室（如需），进入落地操作；
• 有冲突：必须先说明冲突情况，询问用户：
  • 继续当前时间→ 让用户选择会议室（如需），进入落地操作；
  • 换时间→ 转入模糊时间分支。

7.2 模糊时间分支：suggestion + 批量查询

lark-calendar-schedule-fuzzy-time.md处理时间模糊（如"明天下午""下周找个时间"）或完全无时间信息的场景，核心动作是调用+suggestion产出候选时间块。

步骤 1：调用 suggestion

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

规则：

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

+suggestion的核心参数（lark-calendar-suggestion.md）：

时间格式支持 ISO 8601（2026-03-19T08:40:29+08:00）、日期+时间（自动补全时区）、仅日期（start 取 00:00:00、end 取 23:59:59）、Unix 时间戳（秒级）四类自动解析。

步骤 2：分支处理

• 不需要会议室：获取多个推荐时间块后，直接向用户展示候选时间，用户确认后进入落地操作；
• 需要会议室：获取候选时间块后，不要急于让用户只选时间——先将这些时间块一次性交给+room-find批量查询可用会议室，然后将【候选时间】与【对应的可用会议室列表】结构化展示，让用户一次性完成选择。注意：即使用户最初只说"查会议室"且未带时间，也必须强制走 suggestion → room-find 路径。

步骤 3：用户确认后

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

模糊语义消解与长期记忆：针对存在歧义的时间场景（如"上班后""下班前"、未明确上下午的 12 小时制时间），严禁主观臆断，应主动澄清真实意图；用户澄清后，将个性化定义沉淀为长期偏好。

7.3 用户展示格式：结构化分行，严禁揉成一团

展示多个时间块及对应会议室时，必须结构化分行排版，严禁将时间与会议室放在同一行。文档给出的标准模板：

## 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人) 💡 请回复您倾向的选项编号以及对应的会议室序号，我来为您完成预定。

+room-find输出同样要求按此格式整理，且补充了两条 AI 行为准则：展示给用户的room_name必须逐字透传CLI/API 返回的原值，禁止重组、意译、缩写或"便于阅读"式摘要；重复性日程要明确阻断原因——若候选会议室的reserve_until_time无法覆盖重复性日程，必须向用户说明该会议室最长可约至何时，用户确认继续时，自动将日程重复规则结束时间缩短至该reserve_until_time，防止预约失败。

+suggestion的展示则要求附上润色后的推荐理由，并如实反馈冲突：返回的推荐方案不一定都完全空闲，判断依据是推荐理由中是否表达了"完全空闲"或"没有任何忙闲冲突"；存在冲突时必须如实说明，绝不能误导用户。当返回结果包含ai_action_guidance字段或所有方案均非空闲时，必须主动提供优化建议（如调整时间范围、会议时长或参与人）。

八、落地日程变更：+create 与 +update

用户确认后进入落地阶段：

• 新建 →+create
• 编辑 →+update

lark-cli calendar +create \ --summary "..." \ --start "<start>" \ --end "<end>" \ --attendee-ids "ou_xxx,oc_xxx,omm_xxx" lark-cli calendar +update \ --event-id "<event_id>" \ --start "<start>" \ --end "<end>" \ --add-attendee-ids "omm_new_room"

落地规则（文档原文）：

• 编辑流必须始终沿用前面定位得到的目标event_id，禁止在最后一步重新猜测目标日程；
• 编辑流中"新增会议室"默认仅追加room_id，不移除已有会议室；
• 仅当用户明确说"更换会议室"时，才同时--remove-attendee-ids旧 +--add-attendee-ids新；
• 需要会议室时，将选中的room_id写入参与人列表。

8.1+create命令详解

+create创建日程并按需邀请参会人。推荐命令（ISO 8601 时间）：

# 创建日程 + 邀请参会人 lark-cli calendar +create \ --summary "产品评审" \ --start "2026-03-12T14:00+08:00" \ --end "2026-03-12T15:00+08:00" \ --attendee-ids ou_aaa,ou_bbb # 无参会人 lark-cli calendar +create \ --summary "午餐" \ --start "2026-03-12T12:00+08:00" \ --end "2026-03-12T13:00+08:00" # 指定日历 lark-cli calendar +create --summary "..." --start "..." --end "..." \ --calendar-id cal_xxx

关键参数与默认行为：

源码层面，shortcuts/calendar/calendar_create.go中--start与--end被标记为Required: true，--attendee-ids的说明为"attendee IDs, comma-separated (supports user ou_, chat oc_, room omm_)"，与文档完全一致。

+create的自动行为（来自文档"注意"区）：

• 用户表达"每周 X""每周重复""连续 N 周"时，必须使用 rrule 创建重复性日程，而非创建多个独立日程；
• 自动设置attendee_ability: "can_modify_event"（参会人可查看彼此并编辑日程）；
• 自动设置free_busy_status: "busy"（默认忙闲状态为忙碌）；
• 自动设置reminders: [{"minutes": 5}]（默认开始前 5 分钟提醒）；
• 自动设置vchat: {"vc_type": "vc"}（默认包含飞书视频会议）；
• 失败保护：若添加参会人失败（如 open_id 错误），CLI 会自动删除刚创建的空日程（回滚，不通知参会人）；
• 审批会议室：+create不暴露attendees[].approval_reason，若会议室要求审批，请用用户身份先创建日程，再用完整 APIcalendar event.attendees create --as user添加会议室并传approval_reason。

--description字段支持 Markdown 富文本：加粗、斜体、下划线、删除线、链接、最多三级标题、引用、列表、GFM 表格与图片；本地图片路径（相对路径且位于当前工作目录内）会自动上传云盘内联渲染；飞书文档 URL 自动解析为内联文档。禁止用***文本***同时表示加粗+斜体（端上会残留*），应嵌套书写如**<u>*~~文本~~*</u>**。

8.2+update命令详解

+update更新既有日程字段，或独立增量添加/移除参会人和会议室。它支持三类互相独立的动作：更新日程字段、添加参会人/会议室、移除参会人/会议室——可以单独执行，也可以在同一次命令中组合执行。

# 更新标题、描述、时间 lark-cli calendar +update \ --event-id "<EVENT_ID>" \ --summary "产品评审" \ --description "评审需求范围、排期与风险" \ --start "2026-03-12T14:00+08:00" \ --end "2026-03-12T15:00+08:00" # 增量添加参会人和会议室 lark-cli calendar +update \ --event-id "<EVENT_ID>" \ --add-attendee-ids "ou_aaa,ou_bbb,omm_room" # 移除参会人和会议室 lark-cli calendar +update \ --event-id "<EVENT_ID>" \ --remove-attendee-ids "ou_aaa,omm_room" # 同时更新日程信息、移除旧会议室、添加新会议室 lark-cli calendar +update \ --event-id "<EVENT_ID>" \ --summary "产品评审" \ --start "2026-03-12T15:00+08:00" \ --end "2026-03-12T16:00+08:00" \ --remove-attendee-ids "omm_old_room" \ --add-attendee-ids "omm_new_room"

参数一览：

至少需要提供一个动作。使用规则要点：

• --add-attendee-ids是增量添加，不是替换最终参与人列表，不要用它表达"只保留这些人"；
• 对--summary、--description，CLI 以"是否显式传入该 flag"判断是否更新，而非"值是否为空"；
• 只想增删参会人或会议室时，不需要同时传--summary、--start、--end等日程字段，反之亦然；
• 如需替换某个参与人、群组或会议室，使用--remove-attendee-ids <旧ID>+--add-attendee-ids <新ID>；
• 同一次命令组合多个动作时，执行顺序为"日程字段 → 移除参会人 → 添加参会人"；若中途失败不会自动回滚已成功步骤，错误信息会说明已完成的步骤；
• 不得擅自附加--skip-room-check重试：将错误信息（含会议室 ID 与原因）原样透传给用户，说明本次更新会导致会议室预定失败，明确询问是否仍要继续；用户确认后再带--skip-room-check重新执行；
• 预检失败（如接口 404 或返回错误）会降级放行：向 stderr 打一条 warning 后继续执行，避免因新接口不稳定阻塞正常更新。

九、重复性日程与会议室：reserve_until_time 校验

工作流中与重复性日程相关的约束（详见 lark-calendar-recurring.md）：

• 重复性日程/例外的编辑和删除必须显式指定操作范围--apply-to：single（只操作当前这一次）、all（整条序列 + 例外）、this-and-following（从起始实例截断并新建后续序列）；
• event_id结构为{event_uid}_{originalTime}：originalTime = 0表示 Master 或 Normal，> 0表示某次实例；唯一可靠区分 Instance 与 Exception 的方式是+get返回的is_exception字段；
• +room-find时若为重复性日程，必须校验返回的reserve_until_time（该会议室最晚可预约时间）是否覆盖event-rrule对应的重复范围，不覆盖则需缩短规则结束时间；
• +suggestion、+room-find、+update的 rrule 参数均明确不支持 COUNT，如需限制重复次数必须转为 UNTIL。

十、工作流落地路径小结

将整个调度工作流串起来，一次完整的"预约/改约日程 + 会议室"任务遵循以下执行序列：

1. 任务类型判定：新建 vs 编辑（锚点 + 修改动词 = 编辑）；
2. 编辑流定位：+agenda/+search-event定位唯一event_id，多候选必须确认；
3. 补默认值 / 继承基线：新建流补标题、参会人、时长默认值；编辑流继承已定位日程信息；
4. 判断时间明确性：新建流用用户时间或补全时间；编辑流不改时间用当前 start/end，改时间须保持原时长；
5. 分支路由：明确时间 →+room-find（如需）→+freebusy（如需）→ 冲突处理；模糊时间 →+suggestion→ 批量+room-find（如需）→ 结构化展示；
6. BLOCKING REQUIREMENT：任何时间方案/会议室方案选择都必须先展示选项并等待用户确认；
7. 落地：新建 →+create，编辑 →+update，编辑流始终沿用定位得到的event_id。

这套工作流将"智能助理"原则落实为可执行的决策树，既避免了 Agent 在信息不全时盲目写操作，又保证了新建流不因缺少时间信息而卡壳——这正是 Lark 飞书 CLI 在日历域设计中值得借鉴的核心模式。开发者可以在 skills/lark-calendar/references/ 下按需阅读lark-calendar-schedule-clear-time.md、lark-calendar-schedule-fuzzy-time.md、lark-calendar-room-find.md、lark-calendar-suggestion.md、lark-calendar-create.md、lark-calendar-update.md等完整命令文档，并在shortcuts/calendar/目录中查看calendar_create.go、calendar_update.go、calendar_room_find.go、calendar_suggestion.go等对应实现。

【免费下载链接】cliThe official Lark/飞书 CLI tool, maintained by the larksuite team — built for humans and AI Agents. Covers core business domains including Messenger, Docs, Base, Sheets, Calendar, Mail, Tasks, Meetings, and more, with 200+ commands and 20+ AI Agent Skills.项目地址: https://gitcode.com/gh_mirrors/cli414/cli