把会议笔记转成行动项，不编造承诺

用 AI 整理会议上真正定下来的事，而不是编出一份看起来完整的计划。每个行动都应能追溯到笔记。没有负责人的事项、不确定的日期和建议，在有人确认之前都要清楚地保留下来。

这个方法只使用你粘贴到 Reunified 的 Mono 对话中的文字，不涉及录音、转写、日历事件或与任务应用同步。Mono 还没有正式推出，你可以先加入候补名单，同时用任何文字助手试用这套方法。

1. 准备简短且日期明确的原始材料

删掉个人信息和跟进时用不到的内容。保留会议日期、项目名称，以及看懂谁答应了什么所需的人名。如果笔记里混着几次会议，先分开再请助手提取行动项。

用下面这份虚构的笔记做例子：

项目：帮助页面更新。会议日期：2026 年 10 月 9 日。
[1] Lina 会在 10 月 12 日前（含当天）发出草稿。
[2] Omar 会在 Lina 发出后审阅。
[3] 周五发布？与团队确认。
[4] 也许委托制作新截图；未约定负责人。

行号是你自己加的标记。有了它们，不用在改写过的摘要里翻找也能核对结果。保留问号以及“也许”“之后”这类词，不要把笔记“整理”成更确定的承诺。

2. 先要求提取，再考虑规划

把笔记和一条清楚、有边界的指令一起粘贴：

只提取这些笔记里明确约定的行动项。
每项列出行动、负责人、期限或依赖关系，以及来源行号。
缺失信息写“未说明”。
将开放问题、建议与已约定行动分开。
不要指派人员、编造日期、创建任务或发送消息。

最后一行告诉助手你想要什么，但它不能代替检查工具权限。如果助手提议在其他服务里执行操作，要单独审查。第一个有用的结果，是一张可以和笔记对照的草稿表。

在核对提取结果之前，不要让它“把每一项都变成可执行任务”。这种说法可能让它猜出负责人或期限，看起来比笔记里的更确定。

3. 将结果与原始笔记逐项比较

这个例子对应的准确表格如下：

发布日期属于开放问题。新截图属于建议，没有负责人。两者都不应悄悄变成笔记里名字离得最近的那个人的任务。

检查表格每一行是否都有笔记中的某一行作依据。再反过来查：有没有明确的承诺被漏掉？动词要保持准确。“审阅”“批准”和“发布”是不同的责任，即使摘要把它们混在一起。

4. 补充缺失信息，但不改写历史

准备具体的跟进问题：“发布说的是哪个周五？”以及“要不要委托做截图？如果要，由谁负责？”这些问题要由人来回答，而不是让模型去填空。

“草稿到了之后”是依赖关系，不是日期。在负责人给出时间之前，就保持这样写。如果年份是根据会议日期推断的，要注明；如果笔记跨了年，要再确认。

把原始笔记和每一项已确认的修改放在一起保存。会后做出的决定，要标明是会后决定，并写上日期。否则，更新后的清单可能会让人以为会议定下了其实没定的事。

5. 准备别人能接手的记录

核对完后，整理一份简短的记录：

项目和会议日期：
已确认行动：行动 / 负责人 / 时间 / 来源
开放问题：问题 / 谁能确认
等待决定的建议：
会议后确认的变更：日期 / 决定
下次审查：

使用读者认得的人名和日期。分享前删掉对方不需要的细节。如果通过其他服务发送，要确认发往哪里、谁会收到；写好记录并不等于已经发送。

你可以把它存为 Markdown 笔记，或用 Markdown 导出保存整段对话。保存笔记不会在任何已连接的服务里添加事件或任务。

6. 重复使用前先测试流程

试三种情况：没有负责人的笔记、后来被否决的提议，以及没有会议日期的相对期限，比如“下周五”。好的回答会保留不确定或否决，而不是用猜测填满每一格。

如果回答混淆了会议、编造了承诺或漏掉了依赖，就少给它一些文字，再核对一次。事实核查指南介绍了证据表的方法。只有当核对后的结果一直有用时，才值得把它做成保存的提示词或你向 Mono 描述的任务。自动化能省时间，但每个人仍要自己确认自己的承诺。