如何把会议纪要拆成谁在什么时候交什么
周二下午的活动上线会开了 50 分钟，你花 40 分钟整理成一份纪要发进群，写得挺全，背景、结论、下一步都有。
周三你问进度，三个人给你三种理解。更麻烦的是，纪要里写着「陈默负责公众号推送」，而陈默说他会上那句是「我这边可以看看，先别排期」。
纪要回答的是「会上说过什么」，团队要的是「谁在什么时候交什么」。这一节讲怎么把前者变成后者，并且不让它替任何人做决定。
一段会议里混着 5 种东西，它们的处理方式完全不同
大多数人把整理纪要理解成「把录音缩短一点」。缩短是对的，缩完之后那一坨仍然是一坨，才是问题。
一段会议至少混着这 5 类：
一，已经发生的背景事实。二，会上确认的决定。三，有人明确承诺的行动项。四，还在讨论的建议。五，没有负责人或者日期的待确认问题。
麻烦在于人说话的时候不会给每句话贴标签。
「公众号推送我这边可以看看。」这句到底是接活，还是表达一种可能？
没人确认负责人、日期、交付物之前，它就不能进待办。 硬进了，你得到的是一份看起来完整的纪要，实际上替团队制造了一个不存在的承诺。
所以第一件要做的事是让它按这 5 类分开输出，而不是给你一段流畅的总结。
两个词决定了这件事成不成：待认领、待确认
这是整节最硬的一条。
信息不明确的时候，负责人写「待认领」，日期写「待确认」。宁可留下缺口，也不要用想象把表格填满。
对应到指令里，要写死这一句：
没有明确负责人时写「待认领」，没有明确日期时写「待确认」。
不得根据职位、语气或上下文猜测负责人和日期。
后面那半句是关键。不加，它会按职位猜：这件事听起来像市场部的活，会上市场部只有一个人在，那就是他。这个推理链每一步都合理，结论是编的。
正确的结果长这样。会上那句「公众号推送我这边可以看看，先别排期，得等客户确认主标题」，正确处理不是「陈默负责公众号推送」，而是留在待确认区，写成 3 行：
是否制作公众号推送：待确认 负责人：待认领 排期：待客户确认主标题后再定
这才叫忠于这场会，而不是把表格填得好看。
一条待办至少 4 个字段
「优化首页」「推进合作」「确认预算」，这三条都不算任务。它们看着像任务，是因为有动词，可它们缺了让人能开工的东西。
一条能执行的待办至少 4 样：动作、负责人、截止时间、验收方式。
差的写法：小王继续优化方案。
能用的写法：小王在周四 18:00 前提交首页第二版原型，由产品负责人确认是否覆盖评审提出的 3 个问题。
差别在最后那一句。没有验收方式，两个人对「做完了」的理解可以差出一周。
完整的那段指令
前面几条拼起来，就是这段。它看着长，其实只回答了 6 件事：目标、输入、动作、约束、输出、验收。
目标：
把 01_原始材料/会议转写.txt 整理成一份可核对、可确认、可继续执行的会议纪要和待办清单。
输入：
只使用 01_原始材料/会议转写.txt 中的内容。
处理规则：
1. 区分背景事实、已确认决定、正式行动项、讨论建议和待确认问题
2. 只有会议中明确承诺、或由主持人确认的事项，才能进入正式行动项
3. 每条行动项提取任务、负责人、截止时间、交付物、依赖条件、当前状态和原文依据
4. 没有明确负责人时写「待认领」，没有明确日期时写「待确认」
5. 不得根据职位、语气或上下文猜测负责人和日期
6. 保留关键数字、否定表达和时间点
7. 不修改原始材料，不发送消息，不创建外部任务，不上传任何内容
输出：
在 02_生成结果 中新建三份文件：会议纪要_v1.md、待办清单.xlsx、待确认问题.md
待办清单字段：
任务｜负责人｜截止时间｜交付物｜依赖条件｜状态｜原文时间戳
验收标准：
1. 每条决定和行动项都能回到原始转写
2. 建议不得写成已确认决定
3. 没有负责人或日期的事项不得伪造完整
4. 数字、日期、人名和否定表达与原文一致
5. 输出先作为草稿，等待参会者确认
真正决定结果好坏的不是多写几个形容词，是把「什么能做、什么不能猜」写清楚。
别一上来就让它生成，先让它只分类
生成之前多发一条只读指令，这一步看着多余，实际最省事：
请只读取会议转写文件，先不要新建或修改任何文件。
请识别并分别列出：
1. 背景事实
2. 已确认决定
3. 明确行动项
4. 仅为建议或讨论的内容
5. 缺少负责人、截止时间或交付物的信息
不要推测，不要补写。找不到依据的字段写「待确认」。
它的价值是让你先看到它是怎么理解这场会的。 分类这一步就歪了，后面生成得再漂亮也是歪的，而且到那时候你已经很难看出来歪在哪。
顺带你还能提前发现转写本身的问题：缺了谁、哪句有歧义。
转写稿本身要先核 4 类
机器转写出来的稿子不能直接当依据用。至少核这 4 类：
人名、品牌名、专业名词。 同音不同字是最常见的：「张磊」被识别成「张雷」，任务表发进群里，张雷一脸懵。处理办法是让它把提到的责任人跟参会名单比对一遍，对不上的标黄。 日期、金额、比例、数量。否定表达。 「本周不上线」和「本周上线」只差一个字，落到待办里是两个相反的决定。 说话人和时间戳。
原始转写要单独放一个文件夹，别让它覆盖。后面发现人名或数字有问题，你还得回来找依据。
讨论不等于决策
这是另一个高频错法。
只有明确说了「通过」「决定」「确认」的，才算决策。
真实的错例：会上说的是「先不做，等 Q4 再说」，出来的纪要写成「决策：Q4 启动线下活动」。这两句话的距离，是一个项目立没立项。
修补的写法很短：
只有会议中明确出现「通过」「决定」「确认」等表述的内容才能写入决策；
其余讨论一律标记为「建议」，不得写成承诺。
还有一条容易被忽略：议程不能当纪要的框架
会前发的那份议程，只在会前有用。
会后拆纪要不能依赖议程，要以实际转写的内容为准。 会开着开着跑题、临时加了个议题、原定的第 3 项压根没讨论，这些在议程里全看不出来。拿议程当框架，出来的纪要会把没发生的事写得像发生过。
不同的会，模板不一样
一套模板套所有会，出来的东西一定有一半是废的：
周会：盯阻塞。谁卡住了、卡在哪、需要谁配合。 需求评审：盯分歧和决策依据。为什么这么定，比定了什么更值得记。 复盘会：盯根因。发生了什么排第二，为什么会发生排第一。
在指令开头点名这次是哪种会，出来的东西才有重点。
生成完之后，还有一步不能省
纪要出来先发预览或者草稿，请参会者确认 3 件事：
决定有没有被写反。负责人是不是真的接下了这个任务。截止时间和交付物准不准。
确认之后，再把任务写进项目工具或者发进群。
别让它在第一轮就自动建任务、自动提醒、自动群发。 会上的一句讨论，可能还没有拿到授权。先预览、再确认、最后执行，看着多一步，返工反而更少。