会议纪要不是对转写稿做摘要。真正有用的纪要要回答：做了什么决定、谁负责什么、什么时候完成、还有哪些问题没有解决。
先确认数据和授权
会议记录可能包含个人信息、客户资料和商业秘密。处理前确认参会者知情、资料有权使用，并把无关敏感内容从练习材料中移除。
保留原始录音或转写稿的只读副本，WorkBuddy 只在工作副本上处理。
整理输入材料
把材料分为：
- 议程与会前资料。
- 参会者名单和角色。
- 录音转写或文字记录。
- 会中共享文件。
- 已确认的项目术语和背景。
多份转写稿先统一时间和说话人标记。无法识别的发言保留 [说话人待确认]，不要自动归给最可能的人。
用 Ask 提取事实骨架
第一轮只输出：
- 会议主题和时间。
- 每个议题的讨论要点。
- 明确表达的决定。
- 行动项、负责人和截止日期。
- 争议与未决问题。
- 转写中无法确认的信息。
要求每个关键结论附上原始时间戳或段落引用，便于回听和纠错。
区分四种信息
| 类型 | 判断标准 | 纪要处理 |
|---|---|---|
| 决定 | 明确达成一致或由有权人确认 | 写入结论 |
| 提议 | 有人提出但未确认 | 标为建议 |
| 行动项 | 有动作、负责人、时间 | 进入行动表 |
| 未决 | 缺信息或仍有分歧 | 进入待确认 |
模型最容易把讨论中的强烈观点写成集体决定，这一步必须人工抽查。
生成标准纪要
请根据已核验的事实骨架生成正式会议纪要。
结构包含：会议信息、议题、关键结论、行动项、风险与未决问题；
没有明确负责人或截止时间的字段写“待确认”，不得猜测；
每条结论保留原始记录的时间戳；
同时输出一份适合项目跟踪的行动项表格。纪要正文适合阅读，行动表适合执行，二者不要混成一长串段落。
行动项至少包含六列
| ID | 动作 | 负责人 | 截止日期 | 依赖 | 状态 |
|---|
动作使用可验证动词，例如“提交测试报告”，而不是“跟进一下”。每项只设一个直接负责人，其他参与者放进协作者或依赖。
生成会后消息，但先不发送
让 WorkBuddy 根据纪要写一封简短跟进草稿，包含结论、行动项和待确认问题。发送前核对：
- 收件人是否正确。
- 是否包含不应扩散的内容。
- 负责人和日期是否经过确认。
- 链接和附件是否有访问权限。
- 是否明确了反馈截止时间。
连接邮箱或消息平台后，也应先预览再发送。
把纪要变成持续跟进
在项目中保存确认版纪要和行动表。下一次会议前，让 WorkBuddy 读取上次行动项，按完成、延期、阻塞和待确认分类，生成会前状态清单。
只有当来源和格式稳定后，才考虑自动化提醒。自动化不能替代负责人更新真实状态。
常见失败
**纪要过于简短：**要求按议题输出结论、依据和行动，而不是笼统摘要。
**把建议写成决定：**回到时间戳核验，并增加信息类型标签。
**负责人被猜错：**任何缺失字段都标待确认。
**会后无人执行：**将行动项放进团队实际使用的项目或跟踪系统，不只留在文档里。
完成检查
- 原始记录和处理副本分开保存。
- 关键结论可以回到时间戳核验。
- 决定、提议、行动项和未决问题明确区分。
- 行动项有负责人、日期、依赖和状态。
- 会后消息在人工确认后才发送。