飞书的豆包工作产品说明包含围绕会议纪要和妙记提问、回顾结论及梳理后续安排。这为会后工作整理提供了入口。企业需要进一步规定，哪些讨论形成行动项，哪些内容仍然只是建议。飞书开发者产品说明
行动项的认定
一条可执行行动项应有具体对象、交付物、责任人和日期。如果会议只是说“可以研究一下”，整理时保留为建议；只有明确决定推进，才进入任务确认环节。
同一会议中的决定可能被后续讨论修正。系统应保留最终确认内容以及必要的变更关系，不能只截取第一次出现的日期或金额。发言人提出任务，也不一定就是执行人。
会后清单的结构
| 字段 | 记录要求 | 常见问题 |
|---|---|---|
| 任务内容 | 写出可检查的交付物 | “继续推进”没有具体结果 |
| 责任人 | 使用明确的人员身份 | 同名或简称无法可靠匹配 |
| 截止日期 | 绝对日期与必要时区 | “下周”缺少会议日期背景 |
| 前置条件 | 依赖资料、审批或外部确认 | 条件未满足就开始催办 |
| 原始依据 | 对应会议段落或纪要位置 | 找不到是谁决定的 |
| 状态 | 待确认、已创建、已完成 | 纪要写完被误当任务完成 |
人员与日期的核对
语音识别可能把姓名、型号或项目简称识别错。责任人匹配应使用组织通讯录和会议上下文；多个候选人时请会议负责人确认，不应自动选择最常联系的人。
“明天下班前”需要结合会议实际日期解释。跨时区会议还要明确截止时间按哪一地计算。对于“收到样品后三天”等条件日期，先记录触发条件，不能随意换算为固定日期。
正式任务的创建
确认清单后，按既有任务系统创建记录，并保存会议编号与任务编号的关联。同一份纪要重复处理时先查已有任务；内容发生变化则更新同一任务或生成明确的变更记录。
若创建失败或权限不足，返回待处理状态和原因。不能在总结中说已分配，却没有正式任务记录。任务创建成功后，重新读取负责人、日期和内容，确保系统实际保存的值与确认清单一致。
完成状态的判断
执行人回复“好了”可能指文件已起草，也可能指已提交审批。验收标准应在创建时写明：需要上传什么产物，由谁确认，是否依赖另一个系统的状态。
Agent 可以汇总未完成任务、提醒资料缺口和整理阻塞原因。它不应仅凭积极措辞将任务结案。需要业务验收的事项，应保留验收人和结果；已撤销事项则记录撤销原因，避免与正常完成混为一谈。
会后抽查可选择一个完整项目，逐项对照会议记录、正式任务及产物。检查漏项、重复创建、责任人错配和日期误解，按错误类型调整整理规则。
会议资料也应继承原有权限。敏感会议的行动项不能自动发到全员可见空间，任务只附完成工作所需的信息，原会议链接仍受访问控制。
已经创建的行动项在下次会议再次被讨论时，应先关联原任务。仅调整日期或补充说明的内容更新到原记录，新增交付物再单独建项。这样可以保留连续进度，也能减少每次开会都复制一批相似待办、却无人知道哪条仍有效的问题。
相近流程见微信需求整理和写后回读验证。会议资料与项目记录接入可参考企业 Agent 落地。
