把整场会议的原始内容一次性粘贴给 AI，典型结果是三件事同时发生：真正的决议被淹没在讨论里、跑题内容被写进纪要、待办没有负责人。更稳的顺序是让原始记录先作为一篇文档落进知识库，在文档里完成分段标注，再让 AI 在同一知识库范围内做归并——归并的职责是收敛结构，不是判断哪句话重要。

适用场景：团队已用语雀知识库，会议有可落库的原始记录（速记、转写、聊天汇总）。操作动作：原始记录先落成知识库文档 → 人工打【决议】【待办】【讨论】【噪音】标记 → AI 只做归并和格式化 → 逐条核对责任人、时间 → 定稿放回知识库并设可见范围。验证方式：在知识库内搜任一条待办的关键词能命中定稿纪要，抽查的每条待办都能在原始记录里找到原话。风险边界：原始记录里没写明的责任人和时间，保留“未明确”，不要替团队补全。

把会议原始记录拆成决议、待办、讨论三段再粘贴

AI 把不同性质的发言混成一锅，根源不在模型，在于输入没有边界。同一段文字里既有“我倾向于先做灰度”这种个人观点，也有“就这么定了，下版不做离线缓存”这种结论，模型只能按语气猜哪个更重要。人工打标就是把这个判断前置，成本很低，但决定了后面每一步的可控程度。

标记建议控制在四类，多了反而没人愿意维护：【决议】只放已经拍板的话，【待办】只放有人认领的具体动作，【讨论】放尚未成型的意见和分歧，【噪音】放闲聊、寒暄、与议题无关的段落。原始记录里不能删的内容就标【噪音】，标了但不进归并范围，比事后从纪要里挑出来改要省事。

会议：客户端发版范围对齐（脱敏示例）
参会：产品 A、客户端 B、测试 C、运营 D

【讨论】B：灰度可以先覆盖内部账号，外部用户是否同步开，我没有把握。
【讨论】C：测试人力这周排不开，如果同步开，回归要往后压。
【决议】本次发版不做离线缓存改造，推迟到下个迭代再评估。
【决议】灰度只开内部账号，外部用户等下个迭代一起决定。
【待办】整理离线缓存改造的取舍说明，负责人：B，时间：本周五前
【待办】确认灰度内部账号名单，负责人：D，时间：未明确
【噪音】午饭订哪家、上周团建照片谁发一下

这段记录粘进 AI 时，把【噪音】整段保留但声明不参与归并，比直接删掉更好用：删掉之后无法回溯原始记录是否完整，保留标记则可以在核对阶段确认“噪声确实没被写进纪要”。

在提示词里写死输出小节和顺序

结构靠提示词固定，不靠每次口头描述。下面这段可以直接作为知识库里的固定指令存起来，每次整理换掉原始记录部分即可。输出小节名必须写死，否则同一个人两次生成的纪要字段顺序都不一样，团队没法横向对比。

你是会议纪要整理助手。输入是同一场会议的原始记录，已用
【决议】【待办】【讨论】【噪音】标注。

约束：
1. 只依据输入内容整理，不得补充记录中没有的信息。
2. 【噪音】段落的内容不进入任何输出小节。

输出必须严格按以下小节和顺序，不增不减：
一、会议决议
二、待办事项（每条必须带三个字段：事项、负责人、时间）
三、未形成决议的分歧点
四、延期或未采纳的议题

规则：
- 待办的“负责人”或“时间”在原始记录中缺失时，写“未明确”，不要推测。
- 每条决议和待办后面附上对应的原始记录原话，作为出处。
- 讨论段落中的个人观点不得写入第一、第二节。
- 不要输出总结、建议、风险提示等额外小节。

待办字段固定成“事项、负责人、时间”三项之后，核对就有了抓手：任何一条三项不全，要么回原始记录补，要么明确写“未明确”，不会出现看起来完整但没人认领的条目。

把知识库里的历史纪要作为参照文档一起给到 AI

团队术语和纪要口吻靠历史纪要统一，比在提示词里列举词表更省事。在语雀编辑器里通常可以输入 @ 唤起同知识库的文档，选中上一次同主题的定稿纪要，输出里就会带上这篇文档的标题与链接；也可以直接粘贴该纪要的文档链接作为参照，让 AI 沿用其中的叫法（比如“内部账号灰度”而不是“灰度第一批”）。

需要注意的是引用的版本。如果 @ 到的是被取代的旧纪要，AI 会沿用它当时的结论和口径，把已经改掉的决议带回新纪要里。做法是给纪要文档本身带状态标记，例如标题写成“客户端发版范围对齐（已定稿·当前有效）”或“（已归档·被后续会议取代）”，只引用状态为当前有效的那一篇。核对时确认新纪要里的每个术语都能在参照文档中找到同一种写法，出现两种叫法就说明引错了版本。

逐条核对 AI 生成的待办与责任人

核对的原则只有一句：写进纪要的每一条，都要能在原始记录里指出对应原话。下面这份清单建议在定稿前过一遍，逐条打勾。

• 每条待办是否能在原始记录中找到对应原话？找不到原话的条目，多半是模型根据上下文推出来的，删掉或回问当事人。
• 责任人是否在原始记录中被明确提及？只出现“客户端同学”“测试那边”这类说法时，不要替团队指定姓名，保持“未明确”并标出待确认。
• 时间是否来自原话？原话是“下周”“这两天”时，不要自动换算成具体日期，除非记录里给了锚点。
• 决议的语气是否被改动？“暂缓”“下个迭代再评估”被写成“取消”，属于改变了结论，必须改回原话。
• 有没有把讨论中的个人观点写成团队决议？检查该句在原始记录里落在【讨论】还是【决议】标记下。
• 【噪音】段落的内容是否混进了输出小节？尤其是人名和玩笑话。
• 决议与待办是否对得上？有决议没待办说明执行动作缺失，有待办没决议说明来源不明。
• 第三、四节是否为空？两节都为空通常说明模型把分歧和延期议题也塞进了决议，需要回头看原文。

这份清单用页面行为就能验证：在知识库里搜索某条待办的关键词，命中的定稿纪要打开后，条目里的出处应指向同一知识库内的其他文档，链路是通的。

定稿后放回知识库并设置文档可见范围

归档位置按“能被谁搜到”来决定，而不是按整理者的习惯。一般把纪要放在对应项目或团队的知识库下，与该项目的历史纪要同一层级，这样搜索项目名时能一起命中；跨部门会议如果涉及多个团队，通常放中立位置（例如公司级会议纪要知识库）并在相关项目知识库里留一条指向该文档的链接，而不是复制两份——复制两份会导致后续只有一份被更新。

可见范围按成员角色对应设置，可以由文档创建者或知识库管理员调整：

• 全员或全公司：适合发版范围、流程变更这类需要跨团队知悉的定稿纪要。
• 知识库成员可见：适合单个项目组的例会纪要，组外人员默认搜不到。
• 仅协作者可见：适合涉及人员安排、薪资、客户细节等尚未公开的内容，定稿后再按需放宽。
• 外部协作方：单独建文档，只写对方需要知道的决议与待办，不带内部讨论和人员评价。

设置完成后用另一个账号或隐身窗口访问文档链接做一次验证：该看到的人能打开、不该看到的人拿到链接也打不开。这一步比在群里口头说“别外传”有效，也避免了纪要因为可见范围过宽而带来的一次性泄露。