数字：为什么管理者的待办总在丢
做过管理的人都有这个体感：
- 每周 15-20 个会议
- 每次产出 3-5 条 action
- 两天后能记住的只有 40%
- 一周后还在跟进的不到 20%
这不是因为你懒或者记忆力差——是因为会议产出的 action 没有系统化的归宿。
它们散落在：飞书群的聊天记录里、会议纪要的某个段落里、你脑子里的一个模糊印象里、或者一个你三天后打开才发现的待办 App 里。
三级管道
我的解法不是"做一个更好的待办 App"——是从数据源头到最终追踪建一条自动化管道：
三级之间完全解耦：
- 采集不做判断（原文归档，不分析）
- 分析不做治理（提取洞察，不排优先级）
- 治理不做采集（只消费上游结论）
Level 0: 采集 (meeting-collector)
做一件事：把会议原始材料存到本地。
# 采集今天的会议（自动跳过已归档的）
meeting-collector --date today它做的事：
- 调飞书 API 拿今天的视频会议列表
- 下载每个会议的逐字稿（文字记录）和智能纪要
- 按标准格式存到
meetings/{date}-{topic}/ - 幂等——重复跑不会重复存
不做的事：不分析、不提取、不判断重要性。
这个分离很关键——采集层是纯数据操作，不会因为 AI 判断错误而丢数据。
Level 1: 分析 (meeting-copilot)
从原始材料中提取结构化洞察。
每个会议分析完后，会得到：
decisions[]— 本次会议的决策列表actions[]— 待办列表（含责任人、截止日期）risks[]— 风险信号signals[]— 人员信号（某人焦虑/某人积极/某人沉默）
关键设计: 信号带置信度标签。AI 不确定的标 ⚠️[AI判断]，让人类在后续治理环节确认。
Level 2: 治理 (action-hub)
把 action 分级，然后追踪。
这是管道中最"管理者定制"的部分。所有从会议中提取的 action，进入三级模型：
| 级别 | 定义 | 处理方式 | 示例 |
|---|---|---|---|
| L1 | 确认即闭环 | Triage 列表中确认/忽略 | "转发文档给某人" |
| L2 | 需要独立执行 | 创建 issue 跟踪 | "写一个方案评审" |
| L3 | 需要方案设计 | 进入需求收敛流程 | "重构审批流程" |
为什么三级？
因为管理者的待办天然有粒度差异：
- "帮某人约个会" → 30 秒能完成，不需要 issue
- "评估团队 Q3 产能" → 需要 2 小时独立思考，要跟踪进度
- "设计新的绩效流程" → 需要方案设计、多轮讨论，是个小项目
把它们全塞进同一个 todo list 是灾难 — L1 会淹没 L2，L3 会被当成"大的 L2"永远没有启动。
回写：数据不止在管道里流
管道不止向下流——分析结果会回写到关联实体：
这意味着：
- 当我打开某人的档案，能看到他这周从会议中被分配了什么
- 当我查看某个项目，能看到最近的决策和风险
- 当我做周报时，不需要回忆——数据已经结构化地存在那里
实际效果
跑了 3 个月，57 次会议归档：
| 指标 | 之前 | 之后 |
|---|---|---|
| 待办遗忘率 | ~60% | <10% |
| 会后处理时间 | 15-30 min/会 | 2-3 min/会 |
| 周报准备时间 | 2 小时 | 20 分钟 |
| 跨会议追踪 | 靠记忆 | 自动关联 |
最大的改变是心理的——开完会不再焦虑。因为知道：采集器会存、分析器会提取、治理器会分级。我只需要在 triage 环节花 5 分钟确认一下。
设计原则
| 原则 | 说明 |
|---|---|
| 采集分析分离 | 采集不做判断，保证数据不丢 |
| 分级不分轻重 | L1/L2/L3 是粒度区别，不是优先级 |
| 回写必有证据 | 每条回写指向原始会议 |
| AI 建议人确认 | 分级是建议，用户有最终裁定权 |
| 幂等可重跑 | 采集和分析都可以重复执行 |
核心洞察：管理者的效率瓶颈不在"开不开会"——在"会后的信息处理"。一个好的管道不是让你少开会，是让你开完会后不焦虑——因为系统比你的记忆更可靠。