PicoBot/.agents/skills/lark-vc/references/vc-domain-boundaries.md
ooodc a7883dbed9 refactor(todo): 重构待办事项管理逻辑及更新状态规则
- 移除 TodoItem 中的 priority、created_at 和 updated_at 字段
- 强制每个任务都必须有唯一 id,且由用户负责生成
- 修改合并模式逻辑,merge=true 下保留未提及的旧任务
- 支持已完成和已取消任务重新激活(状态改回 pending 或 in_progress)
- 禁止 in_progress 状态退回到 pending,必须标记为 completed 或 cancelled
- 优化状态转换校验,允许特定状态间合法切换
- 简化任务变更消息,移除详细的新增/更新/移除统计
- 更新文档和示例,明确 id 必须由用户生成和使用
- 修复和补充测试,增强状态转换和合并模式验证
- 调整任务时间戳生成逻辑,统一使用当前时间及索引
- 该变更提供更合理的任务状态机械及管理模式,提升稳定性和易用性
2026-06-13 09:22:33 +08:00

10 KiB
Raw Blame History

Calendar/VC/Doc 跨领域关联关系、领域知识和职责边界说明

本文档说明飞书日历Calendar、视频会议VC、云文档Doc三个域之间的关联关系帮助理解跨域数据流转和产物依赖。

Calendar 域

  • lark-calendar skill 负责日历与日程管理,包括创建、查询、修改、删除日程等操作。
  • 日程与会议的关系:日程可以用于提前预约会议,确定会议时间、参与人、会议室、会议主题等信息。日程上可以关联飞书/Lark 视频会议。
  • 并非所有会议都通过日程发起:即时会议不经过日程预约,直接创建。因此,仅查询日程数据无法覆盖所有会议,搜索历史会议应优先使用 vc +search
  • 日程上的用户会议纪要用户可以在日程上绑定自己的会议纪要文档MeetingNotes用于手动记录会议相关信息。该文档与 AI 生成的智能纪要(note_doc_token)是不同的文档,相互独立。

路由规则:查询过去已结束的会议 → lark-vc;查询未来日程/待开的会 → lark-calendar;查询"今天有哪些会议" → 两者结合(vc +search 查已结束 + calendar 查未开始)。

VC 域

  • lark-vc skill 负责视频会议管理,包括搜索历史会议、查询会议产物(智能纪要、逐字稿、妙记等)、查询参会人快照等操作。
  • 会议类型:会议可以是日程会议(由日程发起,有对应的 calendar_event_id),也可以是即时会议等其他类型。

会议产物

会议产物取决于会中开启的功能,分为两条独立链路:

链路一开启「AI 总结」

会中开启「AI 总结」功能后,产生以下产物:

产物 Token 字段 本质 说明
智能纪要 note_doc_token 飞书文档 AI 生成的会议总结与待办
逐字稿 verbatim_doc_token 飞书文档 完整的逐句发言记录(含说话人、时间戳)— note_display_type=normal 时是可读的独立文档unified 纪要的逐字稿用 note +transcript --note-id <note_id> 拉取(见下方 Note 域
共享文档 shared_doc_token 飞书文档 会中投屏共享的文档信息

此外,还存在用户会议纪要MeetingNotes,对应 meeting_notes 字段。这是用户主动绑定到会议的纪要文档,通常用于会前记录会议相关内容,与智能纪要文档相互独立。仅通过 +notes --calendar-event-ids 路径返回。

链路二:开启「录制」

会中开启「录制」功能后,产生妙记产物minute_token)。注意:妙记不一定是会中产生的,用户上传音视频文件或录音也会产生妙记。妙记本身包含以下子产物:

子产物 说明
Summary总结 对整场会议的智能总结
Todo待办 会议中识别出的待处理任务列表
Chapter章节 按讨论话题划分的核心内容摘要
Transcript文字记录 整场会议最原始的逐人发言记录

两条链路的独立性

  • 智能纪要AI 总结链路)和妙记(录制链路)相互独立、互不影响
  • 一场会议可能同时拥有两类产物,也可能只有其中一类,也可能都没有。
  • 当两者都存在时Summary/Todo 内容可能重叠,应根据用户意图选择优先读取哪个。

产物选择决策

  • AI 产物 vs 原始记录:智能总结、待办、章节都属于 AI 分析产物,可能只包含最终结论和关键信息。
    • 用户要求"提炼/总结/重新总结/整理/回顾"会议内容时内容总结必须从逐字稿/文字记录出发,基于原始对话独立分析。禁止直接搬运 AI 纪要的总结作为最终输出——那只是对 AI 产物的重新排版不是独立提炼。AI 纪要可作为补充参考,但不能作为内容总结的唯一信息源。
    • 用户要求查看待办或章节时应参考 AI 产物的待办和章节,因为 AI 产物的待办更友好(包含提出人和负责人),章节按话题划分更结构化。
    • 用户只想直接看 AI 总结结果 → 使用 AI 产物的总结。
  • 链路优先级:如果用户没有明确偏好,对于重复的内容(如智能总结、待办),优先查询智能纪要Note不存在时再降级到妙记Minutes

逐字稿与文字记录的格式

智能纪要的逐字稿(normal 纪要的 verbatim_doc_token 文档、unified 纪要的 note +transcript 输出和妙记的文字记录Transcript都记录了用户原始对话内容格式一致

发言人名称 相对时间戳
<发言内容>

示例:

张三 00:00:00.195
我们接下来讨论一下项目进度。
  • 第一行为发言人信息,包含用户名称和发言的相对时间(从会议开始计算的偏移量)。
  • 后续行为该发言人的发言内容,直到下一个发言人标记出现。

会议总结和分析流程

Step 1: 定位会议

根据关键字、组织者、参与人、会议室等条件搜索会议,获取会议列表。

不要把纪要标题当会议线索: 如果用户说“查询 xx 纪要的逐字稿 / 原始记录 / 谁说了什么”,且没有 meeting_idcalendar_event_id、会议号、参会人或时间范围,先用 drive +search --query <标题> 搜索纪要文档,拿到 Docx URL/token 后再 docs +fetch --api-version v2。若返回 <vc-transcribe-tab vc-node-id="...">,提取 note_id 后进入 Note 域判断 normal / unified;若没有该 block但有“文字记录/逐字稿” Docx 链接,直接用 docs +fetch --api-version v2 读取该链接。

lark-cli vc +search --start "<YYYY-MM-DD>" --end "<YYYY-MM-DD>" --format json

详细用法请阅读 lark-vc-search.md

Step 2: 根据 meeting_id 查询产物

获取会议产物
lark-cli vc +notes --meeting-ids '<meeting_id1>,<meeting_id2>'

可获取会议的所有产物信息,包括:

  • 纪要标识(note_id)与展示类型(note_display_typeunknown / normal / unified)— 决定逐字稿走哪条路由
  • 智能纪要(note_doc_token)— AI 生成的总结和待办信息
  • 逐字稿(verbatim_doc_token)— 完整的会中发言记录(仅 normal 纪要可直接读取该文档)
  • 共享文档(shared_doc_token)— 会中投屏共享的文档
  • 妙记 Tokenminute_token)— 如存在录制产物则返回

详细用法请阅读 lark-vc-notes.md

如果返回了 minute_token,可通过以下命令获取妙记的详细信息(总结、待办、章节、文字记录):

lark-cli vc +notes --minute-tokens '<minute_token1>,<minute_token2>'

可获取妙记的总结、待办、章节、文字记录等信息。详细用法请阅读 lark-vc-notes.md

Step 3: 按 note_display_type 拉取正文 / 逐字稿

智能纪要(note_doc_token)是飞书文档,使用 docs +fetch --api-version v2 读取正文内容;逐字稿的读取方式由 note_display_type 决定

# 纪要正文(两种展示类型都适用)
lark-cli docs +fetch --api-version v2 --doc <note_doc_token> --doc-format markdown

# note_display_type=normal逐字稿是独立文档
lark-cli docs +fetch --api-version v2 --doc <verbatim_doc_token> --doc-format markdown

# note_display_type=unified逐字稿不是独立文档按 note_id 拉取
lark-cli note +transcript --note-id <note_id>

详细用法请参考 lark-doclark-note skill。

Step 4: 判断用户需要的产物内容

  • 根据用户诉求(总结/待办/章节/完整发言记录等),选择合适的产物进行分析和信息提取
  • 如果两种产物都不存在或没有权限,需如实告知用户

Note 域

  • VC 只负责从 meeting_id / calendar_event_id / minute_token 定位会议产物和 note_id
  • 已知 note_id 后切到 lark-note;逐字稿路由以 lark-notenote_display_type 规则为准。
  • 只有自然语言纪要标题时,先走文档搜索与 docs +fetch --api-version v2;只有 <vc-transcribe-tab vc-node-id="...">vc-node-id 可以进入 Note 域。
  • doc_token / Docx URL 不是 note_id。没有 vc-node-id 时不要反推 Note继续按 Doc 域读取正文或正文中明确给出的逐字稿文档。

Doc 域

  • lark-doc skill 负责飞书云文档管理,包括获取文档元信息、读取文档内容、创建和编辑文档等操作。
  • 会议产物的文档本质:智能纪要(note_doc_token)和 normal 纪要的逐字稿(verbatim_doc_token)都是飞书文档,需要通过 lark-doc 的 APIdocs +fetch --api-version v2)查询其内容和元信息;unified 纪要的逐字稿不是独立文档,用 note +transcript 拉取(lark-note)。
  • 文档元信息查询获取文档名称、URL 等基本信息时,使用 drive metas batch_query;获取文档正文内容时,使用 docs +fetch --api-version v2

三域关联总览

Calendar (日程) ──── 发起预约 ────► VC (会议)
                                       │
                    ┌──────────────────┤
                    │                  │
              AI 总结链路           录制链路
                    │                  │
                    ▼                  ▼
            智能纪要 (Doc)        妙记 (Minutes)
            逐字稿 (Doc)         ├── Summary
            共享文档 (Doc)        ├── Todo
            用户纪要 (Doc)        ├── Chapter
                                └── Transcript
  • Calendar 提供会议预约入口,但并非所有会议都来自日程。
  • VC 是会议数据的中心,管理会议记录和产物关联。
  • Doc 是会议产物的载体,智能纪要和逐字稿都以飞书文档形式沉淀,需通过 Doc 域 API 读取。