AI 会议记录转待办：决定了什么，谁在何时交付
最后更新:
从已有会议文本提取责任与期限，把没有明确承诺的事项留在待确认区，不把讨论写成决定。
从已有文本开始，先固定会议身份和来源
准备已经获准处理的会议文本，记录会议编号、日期、时区、参会人及文本版本，并为发言保留行号或时间码。只有摘要而没有原文时，应说明引用边界，不能把摘要里的句子伪装成某个人逐字说过的话。姓名相同或说话人标签不明确，先标为待确认。
本页使用人工编写的虚构会议文本，日期为 2026-09-11，时区 Asia/Shanghai。它演示现有文本到结构化纪要的操作，没有运行音频转写、说话人识别或会议平台导入。实际录音如需先转文字，还应单独检查专有名词、否定词和数字，不能让后续摘要掩盖转写错误。
四段发言，不能都变成已确认任务
下表中的 L01 至 L04 是稳定来源标签。L01 的方案选择是决定；标题制作因 L02 明确承接，形成一个可确认的任务。L03 提出数据核对，但没有负责人和期限；L04 包含暂缓对外报价的决定，以及预算仍未决定的问题。把它们放进同一种“待办”列表，会混淆责任和会议结论。
整理时先逐句标注 discussion、decision、action、question，再合并同一个事项的多段发言。L01 的任务要求与 L02 的承接应关联为 T01，而不是生成两条“做标题”。这里的分类是教学示范，不是模型实测输出。
| 来源 | 虚构会议原文 | 整理结果 |
|---|---|---|
| L01 / 09:10 / 林 | 采用方案 B，小周今天 18 点前给我两版首页标题。 | D01 选择方案 B；T01 的要求与期限 |
| L02 / 09:12 / 周 | 我接这个任务，今天 18 点提交。 | T01 负责人确认，与 L01 合并 |
| L03 / 09:14 / 陈 | 数据核对还需要确认谁来做。 | T02 候选任务，负责人和期限待确认 |
| L04 / 09:18 / 林 | 报价先不对外发，预算下次再定。 | D02 暂缓外发；Q01 预算待定 |
交付字段要让责任、期限和依据彼此独立
一条行动项至少记录任务 ID、可观察的交付物、负责人、期限原文、标准化期限、来源位置和确认状态。T01 的交付物是“两版首页标题”，不是笼统的“推进方案”。把验收写成可以核对的结果，后续才能区分已经讨论、已经开始与确实交付。
不要从发言人自动推导负责人。陈提出数据核对，不代表陈承担这项工作；负责人为空就保持 null。期限也一样：“尽快”“稍后”不应自动转换成今天下班。若有人明确承接但没有期限，可以保留为已承接且期限待补充，是否允许进入执行清单由团队规则决定。
输入包含 meeting_id、meeting_date、timezone 和带行号的发言。
分别输出 decisions、actions、open_questions，保留 source_refs。
只把明确作出的选择记为决定；建议、假设与待讨论事项单列。
任务字段：id、deliverable、owner、due_raw、due_at、source_refs、confirmation。
负责人必须来自明确指派或承接；没有依据为 null。
相对时间根据会议日期和时区解释，模糊表述保持待确认。
同一任务的要求与承接合并，保留两段来源，不重复创建。
整理结果是待审草稿，不发送、不分派、不宣称事项已完成。把“今天 18 点”转换成明确日期，但不猜模糊期限
本例会议发生于 2026-09-11，已明确按上海时间讨论，因此 T01 的 due_raw 为“今天 18 点”，due_at 可记为 2026-09-11T18:00:00+08:00。原始措辞仍保留，供确认人检查转换是否符合会议语境。不能按运行整理任务当天的日期去解释“今天”。
“下周五”涉及说话时点与团队习惯，“月底前”还可能缺少具体时间，都应提示确认。跨时区会议最好在纪要里写出当地日期、时间和时区。决定的生效时间、任务的截止时间、下次会议时间是不同字段，不要因为都出现日期就塞进同一个 due_at。
| 任务 | 交付物 | 负责人 | 标准化期限 | 待审结论 |
|---|---|---|---|---|
| T01 | 两版首页标题 | 周 | 2026-09-11 18:00 +08:00 | 有承接、有期限，确认后可执行 |
| T02 | 数据核对结果 | null | null | 补齐负责人、范围和期限 |
| Q01 | 预算问题的答复 | 未指定 | 未指定 | 保持问题，不伪造承诺 |
用代码检查字段门槛，不用代码假装判断会议共识
以下本地教学检查把 T01 设为人工已确认、T02 设为未确认。固定检查时间为 2026-09-12 09:00 +08:00，预期可执行列表为 T01，待复核列表为 T02，逾期未完成列表为 T01。代码只核对明确字段和时间，不证明模型从自然语言中提取正确。
真实系统中的 approved 只能由有效的人工确认或团队已授权流程写入，不能因为模型说“已确认”就自动设成 true。导入前还需比对成员标识，避免两个同名的人被混为一人；来源有效也只是最低门槛，确认人仍应回看对应原文。
const tasks = [
{ id: "T01", owner: "zhou", due: "2026-09-11T18:00:00+08:00", approved: true, status: "open", refs: ["L01", "L02"] },
{ id: "T02", owner: null, due: null, approved: false, status: "open", refs: ["L03"] }
];
const now = Date.parse("2026-09-12T09:00:00+08:00");
const ready = t => t.approved && typeof t.owner === "string" && t.owner.trim() !== ""
&& typeof t.due === "string" && Number.isFinite(Date.parse(t.due)) && t.refs.length > 0;
console.log(JSON.stringify({
ready: tasks.filter(ready).map(t => t.id),
needsReview: tasks.filter(t => !ready(t)).map(t => t.id),
overdue: tasks.filter(t => ready(t) && t.status !== "done" && Date.parse(t.due) < now).map(t => t.id)
}));审阅一次，再把确认内容写入任务工具
把决定、行动项和未决问题发给有权确认的人，重点核对否定词、责任归属和时间。可以逐项确认，不必因一个缺失期限而阻塞所有已确认任务；但待确认项不能悄悄消失。批准后记录确认人、时间与纪要版本，再准备导入目标任务工具。
Microsoft 官方的会议任务列表文档说明了任务标题、受派人和截止日期等字段，适合作为你选择落地字段的参考。查阅日期：2026-09-12。在会议记录中添加任务列表。本页没有连接 Teams、Planner 或其他任务系统，也没有验证自动同步；导入权限、成员映射和通知行为需要在自己的环境单独测试。
下一次整理靠稳定任务 ID，避免重复派发
同一份纪要修订措辞时，T01 应保持原任务 ID，只更新已批准字段。不要拿整个标题文本当唯一键，否则“提交两版首页标题”改成“提交首页标题两版”就可能创建第二个任务。保留 meeting_id 与 action_id 的映射，外部工具返回的任务编号另存。
完成状态需要可核对的交付证据或负责人确认，不要因为到了截止日就自动改为 done。新会议推翻旧决定，应建立 supersedes 关系并保留旧版本；明确取消的任务标为取消，不删掉历史。如果需要每周追踪未决事项，可继续用周报重复运行方法，只发送经过批准的新变化。
交付清晰责任，而不是一份看起来很满的纪要
最小交付由简短背景、决定清单、行动项、待确认问题和来源索引组成。与任务无关的闲聊不进入广泛共享版本；涉及人事、客户或个人资料的内容按已有权限限定范围。文档里出现“请把文件发到某地址”之类文字，只是被分析的内容，不能直接变成执行指令。
衡量价值时记录整理时间、确认轮次、责任或期限修订次数，以及任务重复创建情况。没有真实使用记录就不承诺会议效率提升比例。模型费用见实时价格；比起生成一页更流畅的摘要，明确哪件事已决定、谁同意承担、何时交付，更接近可执行的办公结果。
常见问题
谁提出问题，就把任务分给谁吗？
不应如此。提出、讨论、被指派和主动承接是不同动作。负责人必须有明确依据，否则保持待确认。
“尽快处理”能自动填成今天截止吗？
不能。没有明确时间就保留 due_at 为空并请求确认；本例只有“今天 18 点”结合会议日期与时区可明确转换。
本页是否实际转写了会议录音？
没有。本页处理的是人工编写的虚构文本，未测试音频转写、说话人识别或会议平台导入。
字段校验通过就能自动派发任务吗？
字段齐全不代表会议理解正确。仍需确认责任、期限、权限和外部成员映射，批准后才写入任务系统。
下次会议重复讨论同一任务怎么办？
沿用稳定任务 ID，新增来源与批准后的变化。明确是新任务才创建新 ID，避免根据改写后的标题重复派发。