WeCom Meeting Manager

企业微信会议技能

执行任何 wecom-cli 命令前，必须先读取并完成 wecomcli-shared 技能的公共前置检查。

本 Skill 负责企业微信会议的全生命周期管理，包括创建、查询、搜索、取消会议，以及会议状态和参会人的管理。

CRITICAL — 操作执行协议（每次操作必须遵循）：

1. 识别用户意图对应的操作类型（创建/查询/搜索/取消）
2. 使用 Read 工具读取该操作的参考文档（见下方"操作参考"表）
3. 严格按照参考文档中的工作流和命令格式执行
4. 禁止跳过步骤 2 直接执行命令，即使你认为已经知道如何操作 — 原因：每个操作的参数格式、可选字段和边界行为都在参考文档中精确定义，凭记忆操作极易因参数错误导致调用失败

适用范围

适用

• 创建 / 新建在线会议（含会议号 / 入会链接，可远程 / 视频参会；含"线下开 + 外地同事远程接入"的会）
• 查看 / 浏览会议列表（最近有什么会、查某时间段的会议）
• 搜索会议（按关键词、会议名找某个会议）
• 查看会议详情（主题、时间、参会人等）
• 更新 / 修改会议（改时间、加减人；不支持更新周期会议）
• 取消会议（不支持取消周期会议）

不适用

• 创建、更新、取消周期 / 重复会议（每周 / 每月 / 每天重复）→ 均不支持，引导用户在企业微信客户端手动操作
• 回复 / 拒绝会议邀请（接受 / 拒绝 / 待定，含"拒绝这个会""不参加"）→ 不支持，引导用户在企业微信客户端操作或私信发起人

易混淆场景路由

• 用户要的是不含在线会议链接的日程 / 纯线下面对面碰头（约日程、看今天有什么安排、安排纯线下会议）→ 改用 wecomcli-calendar
• 查忙闲 / 约多人共同空闲 → 改用 wecomcli-calendar
• 预订 / 查询公司会议室（订会议室、查会议室空不空、查办公楼）→ 会议室查询能力在 wecomcli-calendar 技能；创建/更新会议时若要订/换会议室，读取 wecomcli-calendar 技能 的会议室查询参考拿 meeting_room_id 传入本技能的 create/update
• 用户仅说"开会 / 约个会 / 安排个会 / xx 会"等、未明确是日程还是在线会议（创建场景）→ 必须先用文字追问消歧（固定问题"需要创建日程还是会议？"，请用户回复"日程 / 会议"），不得臆断直接创建
• 仅给了地点 / 会议室号（如"在 1605 开会""订个会议室开会"）→ 不构成"明确是会议"，仍需先用文字询问消歧，不能因带地点就跳过追问
• 查询场景的模糊表述（"最近有什么会 / 有哪些会"）→ 严禁追问，日程和会议都查并合并展示；仅当明确提到"在线会议 / 视频会议 / 入会链接 / 会议号 / 远程参会"时才只查会议

路由规则

技能边界（会议 vs 日程）[CRITICAL]：本技能只创建含在线会议链接的会议（含会议号/入会链接，供远程/视频参会）。只要涉及在线会议链接就归本技能；不含在线会议链接的纯线下面对面会议属于日程，使用 读取 wecomcli-calendar 技能。用户仅说"会议/会/开个会/约个会/安排个会/xx会/xx会议"等而未明确是日程还是会议时，必须先用文字追问，禁止默认直接创建会议：

问题与选项固定 [CRITICAL]：消歧确认时，问题与可选项都必须原文照用、严格禁止修改任何内容——问题固定为 "需要创建日程还是会议？"，可选项固定为 日程 / 会议；不得改写问题措辞、增减或改写选项、翻译，或自行设计其他表述（如"在线会议 / 线上会议 / 视频会议 / 线下会议"等）。

用文字向用户提问：需要创建日程还是会议？（请回复：日程 / 会议）

用户答「会议」→ 留在本技能创建会议；答「日程」→ 改用 读取 wecomcli-calendar 技能 创建日程。

此文字消歧仅用于「创建」；查询场景严格禁止追问——明确指向在线会议时只查会议，明确是日程/安排时只查日程，模糊表述（"会 / xx会 / 最近有什么会"等）则日程和会议都查（见下文「查询消歧」）。

"会议""会""开会"等词本身不构成"明确" [CRITICAL]：这些词只表示要碰头议事，并未说明是日程还是会议。禁止仅因 query 里出现"会议"二字就默认归本技能（会议）创建，也禁止反向默认成日程——只要未明确，一律先用文字追问后再路由。只有出现"入会链接 / 会议号 / 视频会议 / 远程参会"等明确信号时才直接归会议。

同时支持线下与远程参会（如"线下开、外地同事远程接入"）时，因含在线会议链接，归本技能创建——创建会议会同时生成对应日程，无需再去 wecomcli-calendar 技能另建日程。

仅有地点/会议室号（如"在 1605 开会""到 A 座会议室碰一下""订个会议室开会"）不构成"明确是会议"——会议室里同样可能只是纯线下安排，是日程还是会议仍未知，必须先用文字询问消歧，不能因为带了地点就跳过追问。

list vs search 的选择原则：用户明确提到主题/名称关键词时用 search（把关键词传入 keywords）；只按时间范围或泛浏览时用 list，禁止把日期当 keywords 喂给 search。两者有时可组合：先search 定位，再 list 确认时间段全貌。

查询消歧（模糊查询时日程 + 会议都查）[REQUIRED]：查询场景严格禁止用文字追问"是日程还是会议"——日程/会议消歧追问仅用于创建，查询时一律按以下规则直接处理、不追问。判定分两个独立维度，不要混为一谈：

维度一：查哪一边（日程 / 会议 / 两边都查）

• 明确是在线会议 → 用户明确提到"在线会议 / 视频会议 / 入会链接 / 会议号 / 腾讯会议 / 远程参会"等在线会议专属特征时，留在本技能只查会议。
• 明确是日程 / 安排 → 用户说的明显是日程类内容（如"日程 / 安排 / 我的安排 / 日历"，且不带在线会议特征）时，改用 读取 wecomcli-calendar 技能 只查日程。
• 模糊表述无法判定（"会 / xx会 / xx会议 / 开会 / 最近有什么会 / 有哪些会 / 找下 xx会议"等，既可能是日程也可能是会议）→ 日程和会议都要查：既用本技能查会议，又 读取 wecomcli-calendar 技能 查日程。

维度二：每一边用 search 还是 list（与维度一独立，逐边各自判断）

• 有主题/名称关键词（如"找下 xx会议""搜一下项目评审会议"）→ 该边用 search（把关键词传入 keywords）。
• 只有时间/日期或泛浏览无关键词（如"最近有什么会""查一下明天的会议"）→ 该边用 list，禁止把日期当 keywords 喂给 search。
• 即使"两边都查"，也按本维度对每一边各自选择：带关键词时两边都用 search，纯时间/泛浏览时两边都用 list。

合并展示：两边都查时，合并结果后统一展示——按是否含在线会议链接分成「（会议）」（来自会议侧、或日程中 meeting.meeting_link 非空者）和「（日程）」（meeting_link 为空的纯日程）两部分，同一场会议在两边都出现时按"主题 + 时间"去重只保留一条，末尾汇总"共 N 场，其中会议 X 场、日程 Y 场"。

• 本消歧仅针对查询；创建仍按下文"日程 vs 会议"用文字追问。

触发表达示例：

• "帮我开个会" / "安排一场会议" / "创建视频会议"
• "看看我的会议" / "查一下明天的会议" / "最近有什么会"
• "搜一下项目评审会议" / "找找上周的周会"
• "取消那个会议" / "这个会不开了"
• "帮我总结下 xx 会议" / "这个会讲了啥" / "把 xx 会议纪要发我" / "看下这个会的待办" / "按决策点整理下这个会"

前置条件

• 需要企业微信账号且已登录
• 取消/更新操作不预先按"是否本人创建"拦截，直接执行命令、由接口返回结果判断能否操作
• 参会人 userid（前缀为 wo）组装为 [{"userid": "woxxx"}] 对象数组格式传入；用户提供的是姓名时通过 读取 wecomcli-contact 技能 解析为 userid

核心场景

1. 新建会议

以当前用户为发起人创建一场新会议。

CRITICAL — 执行前必须先读取参考文档：收到创建会议意图后，第一步立即读取 meeting-create，按其中的完整工作流（参数补全 → 参会人解析 → 参会人忙闲检查 → 调用创建接口 → 获取详情展示）逐步执行，禁止在未读取参考文档的情况下直接发起任何操作。

参会人忙闲检查 [REQUIRED]：创建 / 更新会议时须在时间敲定前查忙闲，避免约到冲突时间。忙闲接口不在本技能，须 读取 wecomcli-calendar 技能 的 忙闲查询参考 调free list。创建会议时：查询对象 = 当前用户自己 + 其他内部参会人（wo 前缀），只有自己也要查（避免约到自己已占用的时段）；外部联系人（wm，忙闲不可查）不纳入查询对象、但不因此跳过整体检查；仅忙闲接口调用失败时降级放行。给已有会议加人、不改时间时：忙闲查询只针对新增参会人、且查会议原时段，禁止把当前用户（自己/创建者）和已有参会人纳入——他们正被本会议占用、必然显示"忙"，纳入会误报冲突（详见 meeting-update 工作流）。

会议室预订 [REQUIRED]：用户创建会议时提到"订会议室 / 在 1605 开 / 找个会议室 / 某栋楼的会议室"等意图时，会议室查询能力不在本技能——须 读取 wecomcli-calendar 技能 的 会议室查询参考（buildings list + rooms search）查到真实会议室，拿 meeting_room_id 传入 meeting create（占用）。禁止把会议室名仅写进 location、禁止凭记忆/猜测编造 meeting_room_id；先订房后建会，详见 meeting-create 步骤 4。

详见 meeting-create

2. 查询会议列表

CRITICAL — 执行前必须先读取参考文档：收到查询会议列表意图后，第一步立即读取 meeting-list，按其中的完整工作流（时间范围确定 → 拉取列表 → 批量获取详情 → 反查参会人姓名 → 合并输出）执行，禁止在未读取参考文档的情况下直接发起任何操作。

模糊查询必须日程 + 会议都查 [CRITICAL]：若本次是"会 / xx会 / xx会议 / 最近有什么会 / 有哪些会 / 找下 xx会议"等模糊查询（见上文「查询消歧」），无论会议列表是否查到结果，都必须同时 读取 wecomcli-calendar 技能 用相同时间范围拉日程 list，把两边结果合并、按是否含在线会议链接分「（会议）」「（日程）」两部分汇总展示（同一场会议按主题 + 时间去重），禁止因会议已查到就跳过日程查询。仅当用户明确指向在线会议（入会链接 / 会议号 / 视频会议 / 远程参会等）时才只查会议；此时若查无，再兜底去日程查一把（命中则说明「这是一条日程」，两边都无再告知）。

详见 meeting-list

3. 搜索会议

根据关键词匹配会议主题或内容。有关键词时不执行特定追问操作补全时间，直接搜索。适合用户知道会议名称或关键词的场景。

模糊搜索必须日程 + 会议都搜 [CRITICAL]：若用户搜的是"会 / xx会 / xx会议"等模糊目标（非明确在线会议），无论会议是否搜到，都必须同时 读取 wecomcli-calendar 技能 用同样关键词搜日程，把两边结果合并分「（会议）」「（日程）」汇总展示；仅当明确指向在线会议时才只搜会议，此时搜不到再兜底去日程搜（命中则说明「这是一条日程」，两边都无再告知）。

详见 meeting-search

4. 取消会议

CRITICAL — 执行前必须先读取参考文档：收到取消会议意图后，第一步立即读取 meeting-cancel，按其中的完整工作流（定位会议 → 状态检查 → 周期判断 → 执行取消 → 按返回结果判断）执行，禁止在未读取参考文档的情况下直接发起任何操作。

详见 meeting-cancel

5. 更新会议

CRITICAL — 执行前必须先读取参考文档：收到更新/修改会议意图后，第一步立即读取 meeting-update，按其中的完整工作流（定位会议 → 周期判断 → 参数收集 → 执行更新 → 按返回结果判断）执行，禁止在未读取参考文档的情况下直接发起任何操作。

详见 meeting-update

6. 查询会议转写原文

CRITICAL — 执行前必须先读取参考文档：收到查询会议转写原文（"原话/逐字记录/完整对话/转写/转录/第几段"等）意图后，第一步立即读取 meeting-original-get，按其中的完整工作流（定位会议 → 确定段落 → 拉取转写 → 翻页拼接 → 原样输出）执行，禁止在未读取参考文档的情况下直接发起任何操作。

转写原文 ≠ 智能纪要 [CRITICAL]：转写原文（original_data，逐句原始发言）与 meeting get 里 AI 总结的 notes（纪要/待办）是两种不同内容，禁止用纪要替代转写原文。media_index 默认不传——不传时接口返回全部段转写，仅当用户明确要"第 N 段"时才传 N-1（从 0 开始），不主动追问要哪一段。has_more 为 true 时必须翻页到底并按序拼接，输出时原样保留时间戳+说话人的逐行格式，不总结、不裁剪。

详见 meeting-original-get

7. 会议总结（纪要 / 待办）

用户要"总结某场会议"——包括要会议纪要、问"这个会讲了啥"、要会议待办、"总结下待办"等，本质是对已有的 meeting get（现成纪要/待办）与 meeting original get（转写原文）两个接口做编排，没有新接口。纪要与待办同属此逻辑，处理方式一致。

CRITICAL — 执行前必须先读取参考文档：先按 meeting-list 定位会议并（无自定义要求时）取 get；需回到原文加工时读取 meeting-original-get。

唯一分叉维度：本次总结是否带「自定义要求 / 描述」

只要用户在"总结"之外附带了任何自定义的要求、描述、角度、范围、结构或风格，一律走原文生成；只有纯粹地说"总结下 / 讲了啥 / 纪要发我 / 看待办"、不带任何额外描述时，才返回已有的现成内容。

• 只说"总结下"（无任何自定义描述）：仅泛泛地要一份总结/概要/待办，没有附加任何要求。触发语如"总结下 xx 会""这个会讲了啥""纪要发我""看下这个会的待办""有哪些待办"。
  1. 先调 meeting get，取目标字段：要纪要 → 看 notes[].note_content；要待办 → 看 notes[].todo_content。
  2. 可用则直接返回官方现成内容（判定：has_note_permission == true 且目标字段有实质内容），无需再调用转写原文接口。
  3. 不可用（目标字段空 / has_note_permission == false）→ 转下方原文兜底。
• 带了任何自定义要求 / 描述：只要用户附加了结构、角度、聚焦范围、风格或长度等任意描述，就归此类。触发语如"按决策点整理""用三段式""列出每人发言重点""重点讲预算那部分""写成正式会议纪要""一句话概括""结合上次的会说说进展"等。
  • 跳过 get，直接 meeting original get 拉全部转写，按用户的要求/描述加工总结。理由：官方 notes 是固定视角的成品，满足不了任何定制诉求，必须回到原文重新加工。

原文兜底顺序 [REQUIRED]：凡需要走原文（get 不可用，或带自定义要求），一律先调 meeting original get（翻页到底），再按结果处理：

• 接口报错（无权限/其他）→ 按接口返回如实提示，不静默失败。
• 成功但 original_data 为空 → 告知"该会议暂无智能纪要，也没有转写原文（可能未开启会议转写、会议未开始或无发言记录）"，不编造。
• 成功且有内容 → 按默认或用户指定的结构总结（此时 original get 允许加工总结，区别于"要原话/逐字记录"时的原样输出）。

详见 meeting-list（定位 + get）与 meeting-original-get（拉原文并加工）。

核心概念

• 会议（Meeting）：企业微信会议实体，含主题、起止时间、参会人、入会链接等属性。
• 会议 ID（meeting_id）：API 使用的会议唯一标识，较长的字符串（mt 前缀）。
• 会议号（meeting_code）：9 位纯数字，仅用于用户入会，不能作为 meeting_id 使用。
• 周期会议（Recurring）：按规则重复的会议，update/cancel 均不支持（见「已知限制」）；仅 original get 查询转写原文某场时需指定 sub_meeting_id。
• 参会人（Attendee）：以 userid（wo 前缀）标识。用户提供的是姓名时通过 读取 wecomcli-contact 技能 解析为 userid。

核心规则

规则 1: userid 获取

• attendees 字段格式为 [{"userid": "woxxx"}, {"userid": "woyyy"}] 对象数组，不接受姓名，不接受平铺字符串数组。
• 用户提供的是姓名时，通过 读取 wecomcli-contact 技能 解析为对应 userid；多候选人时用文字让用户选择，不自行猜测。
• 禁止把姓名当 userid 拼接，禁止凭记忆或猜测编造 userid。
• open_vid 和 userid 是同一概念的不同叫法，其他系统返回的 open_vid 可直接作为 userid 使用。

规则 2: 写操作直接执行

• 创建会议、取消会议时，参数就绪后直接执行，无需向用户展示摘要或询问确认。
• 结果返回时禁止暴露 userid，只展示人名。
• 原因：上层交互已完整展示操作内容并完成确认，此处再展示一遍会造成冗余；userid 是系统内部标识，对用户没有实际意义，展示反而容易造成困惑。

规则 3: 参数补全

任何操作中，当必要参数不明确或需要用户做出选择时，必须用文字直接向用户提问，禁止自行猜测或使用默认值代替询问。提问时把可选项 / 候选值一并写进文字里，让用户直接回复。

以下情况均适用此规则：

• 必填参数及参会人缺失：操作所需的参数无法从上下文中推断（如创建会议时 subject/begin_time 缺失、参会人 attendees 缺失、搜索时 keywords 缺失）时必须用文字询问；其余非必填参数（地点、会议室等）用户未明确指定时不追问，走默认值；end_time（时长）缺失时不追问，默认时长 1 小时（begin_time + 1h）；仅描述参会方式或动作的词（如「视频会议 / 开个会 / 远程接入」）不构成有效 subject，按缺失处理走文字询问，禁止当主题直接创建
• 多候选项需用户选择：搜索/查询返回多个匹配项、wecomcli-contact 技能搜索到多个同名候选人
• 操作范围需确认：如更换会议室时查到多个 bookable 候选，需用户选定具体一个

文字询问的约束：

• 列出的可选项 / 候选建议以 2~4 个为宜。可选候选多于 4 个时（如同名候选人、多个匹配会议），取最相关的前 4 个列出，并提示用户可进一步缩小范围（输入更精确的关键词 / 完整姓名 / 具体时间），不要一次性罗列 5 个及以上候选。
• 询问时间时，列出的候选时刻必须是精确到分钟的具体时刻（如"明天 14:00"、"后天 09:30"），禁止给出"上午/下午/傍晚/午间/上班后/下班前"等模糊时间选项——模糊选项会导致用户回复后仍需二次追问具体几点，必须一次问到可直接落为 begin_time 的精确时刻。

各场景具体的提问话术和候选项见对应操作的参考文档。

规则 4: 权限判定交给接口

• 取消 / 更新会议不预先按"是否本人创建"拦截，也不区分 created_meetings / attended_meetings——直接执行 cancel / update，能否操作由接口返回结果判断。
• 返回成功即操作完成；返回权限类错误则说明当前用户无权操作该会议，告知用户并建议联系会议发起人。