会议纪要只记录过程，通常不是记录人不认真，而是模板没有给结论和行动项留出固定位置：讨论、决定、待办混在一段文字里，会后很难分清哪句已经拍板、由谁执行。本文给出一套可直接套用的三区块纪要模板，说明如何把讨论收敛为决议、把决议拆成可验收的行动项，并附角色分工、填写示例和发出前检查清单。
要点总览（TL;DR）
- 在会议纪要模板中把讨论、决议、行动项分成三个独立区块：讨论区只记分歧和依据，决议区只写已确认的判断，行动项区从决议逐条派生。
- 现场用四步把讨论收敛为决议：确认议题范围、提炼分歧点及依据、主持人给出可判断真假的结论表述、标注生效条件和影响范围。
- 行动项要具备动作描述、唯一负责人、截止时间、验收标准、关联决议编号五个字段，动作描述用动词开头，验收标准写成可观察的完成状态。
- 记录人整理初稿、主持人确认决议口径、行动项负责人回执时限与验收标准、跟踪人会后核对状态，判断责任分散到对应角色。
- 纪要发出前按决议完整性、行动项字段、讨论区残留、待定事项、角色确认逐项核对，阻断项未通过时暂不发出。
模板里先分区：讨论、决议、行动项各占一块
让纪要产出结论的第一步，是在模板结构上把三类信息分开。讨论区承载过程，决议区承载判断，行动项区承载执行。三个区块各自有填写边界，记录人不需要在写作时反复判断“这句话该不该留”。
讨论区的填写边界是：记录议题、各方观点、分歧点和支撑依据，不写“最终决定”。会上出现的结论性表述，先记在讨论区并标注“待确认”，等主持人收敛后再移入决议区。这样做的价值是保留决策依据，同时避免把某位参会人的个人意见误当成会议结论。
决议区只写已经确认的判断和取舍。一条决议应当能被判断真假，例如“本期采用方案A上线，方案B延后评估”，而不是“大家讨论了方案选择”。决议区不重复讨论过程，需要追溯依据时回看讨论区对应议题即可。
行动项区从决议逐条派生。一条决议可以对应多条行动项，例如一项上线决议可能派生开发排期、测试验证、对外通知三条行动项。行动项不直接来自讨论中的零散提议，避免出现“会上提过就立项”的情况。
三个区块的字段清单如下，可直接作为模板表头使用：
| 区块 | 字段 | 填写要求 |
|---|---|---|
| 基本信息 | 会议名称、时间、参会人、记录人、议题清单 | 议题编号供后续决议和行动项引用 |
| 讨论区 | 议题编号、各方观点、分歧点、依据材料 | 只记过程，结论性表述标注“待确认” |
| 决议区 | 决议编号、关联议题、结论表述、生效条件、影响范围 | 只写已确认的判断，一句一条 |
| 行动项区 | 行动项编号、关联决议编号、动作描述、负责人、截止时间、验收标准、协作人、状态 | 从决议派生，一条行动项一个负责人 |
模板定下来之后，记录人的工作从“整理发言”变成“按字段归位”，会后遗漏字段的情况会明显减少。
从讨论到决议：四步转化动作
分区解决的是“写在哪里”，现场收敛解决的是“怎么得出决议”。以下四步可以在会议进行中同步完成，也可以由记录人在会后整理时按顺序执行，每一步都有明确的完成标志。
第一步：复述议题并确认讨论范围
输入是议程上的议题条目，动作是由主持人复述本次要解决的问题和不在本次讨论范围内的事项，输出是讨论区的一条议题记录。完成标志是参会人对“这次要定什么”没有异议。范围不清时，讨论容易扩散到相邻议题，结论也就无从收敛。
第二步：提炼分歧点，记录各方依据
输入是讨论中的发言，动作是把观点归并为若干分歧点，每个分歧点下列出各方立场和依据（数据、客户反馈、排期约束等），输出是讨论区的分歧清单。完成标志是每个分歧点都能对应到具体依据，而不是“有人同意有人反对”。这一步只记录，不做裁决。
第三步：主持人收敛为一句可判断真假的决议表述
输入是分歧清单，动作是由主持人给出取舍并说明理由，记录人将其写成一句结论，输出是决议区的一条决议。完成标志是这句话可以被追问“是否已决定”并得到明确回答。常见问题是把决议写成过程描述，例如“关于排期做了讨论”，应改为“本期排期压缩两周，砍掉非核心需求X”。
第四步：为决议标注生效条件和影响范围
输入是决议表述，动作是补充这条决议在什么条件下生效、影响哪些团队或交付物，输出是带生效条件和影响范围的完整决议。完成标志是受影响的团队能从纪要中认出自己需要做什么。例如“方案A上线”需要注明适用版本、涉及的系统模块和需要同步的协作方。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 确认范围 | 议程议题 | 主持人复述问题与边界 | 议题记录 | 参会人对议题无异议 |
| 提炼分歧 | 发言内容 | 归并分歧点并附依据 | 分歧清单 | 每个分歧点有具体依据 |
| 收敛决议 | 分歧清单 | 主持人取舍，记录人成句 | 决议表述 | 可判断真假、可被追问 |
| 标注条件 | 决议表述 | 补充生效条件与影响范围 | 完整决议 | 受影响方能识别自身动作 |
从决议到行动项：字段怎么填才可执行
决议回答“定了什么”，行动项回答“谁在什么时候做到什么程度”。一条行动项要能被直接派发和验收，需要五个必填字段：动作描述、唯一负责人、截止时间、验收标准、关联决议编号。
动作描述用动词开头，写清对象和结果。例如“输出新版接口文档并同步给前端组”，而不是“接口文档相关事宜”。动词加对象加结果的写法，让执行人一眼知道交付物是什么。
验收标准写成可观察的完成状态。例如“文档评审通过且前端组确认收到”，而不是“尽快完成”“质量达标”。可观察意味着第三方也能判断是否完成，减少事后争议。
一条行动项只设一个负责人，协作人另列。多人共同负责容易造成相互等待，负责人对结果负责，协作人提供支持，职责边界清晰。
未定事项不要硬填。会上无法确定负责人或时间时，标注待定原因和确认时点，例如“负责人待定，原因：需与运维组确认排班，确认时点：本周五前由主持人指定”。待定项进入跟踪清单，避免在纪要里被当成已定事项。
| 字段 | 不合格写法 | 合格写法 |
|---|---|---|
| 动作描述 | 跟进一下测试问题 | 整理本期测试遗留缺陷清单并标注优先级 |
| 负责人 | 研发组共同负责 | 负责人：张工；协作人：测试组李工 |
| 截止时间 | 尽快 | 本周四18:00前 |
| 验收标准 | 完成即可 | 缺陷清单发出且在评审会上逐条确认 |
| 关联决议 | 无 | 关联决议D-02 |
行动项定稿后需要进入可跟踪的载体，否则字段填得再完整也会停在文档里。ONES 的工作项可以承载行动项的动作描述、负责人、截止时间和状态，把纪要中的行动项区与后续跟踪衔接起来，负责人更新状态、跟踪人查看逾期项都在同一处完成。是否引入工具取决于团队已有的协作习惯，行动项数量多、跨团队协作频繁时收益更明显。
角色分工：谁记录、谁确认、谁跟踪
纪要从讨论转化为可执行内容，涉及四个角色。把判断责任分散到对应角色，记录人就不必独自承担“替会议下结论”的压力。
| 角色 | 职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 记录人 | 整理讨论区，起草决议与行动项初稿 | 三区块纪要初稿 | 会议结束当天 |
| 主持人 | 确认决议表述口径和优先级 | 确认后的决议区 | 初稿发出前 |
| 行动项负责人 | 确认时限与验收标准可接受 | 行动项确认回执 | 纪要发出后一个工作日内 |
| 跟踪人 | 会后核对状态，推动逾期项 | 行动项状态清单 | 按约定周期更新 |
记录人的关键动作是把讨论区中的“待确认”表述提交给主持人，而不是自行判断哪句算结论。主持人对决议口径负责，遇到表述含糊时应当场或会后补充明确。行动项负责人对时限和验收标准有异议时，应在回执中提出，由主持人与负责人协商调整，调整结果回写纪要。跟踪人通常由会议组织者或项目协调人担任，负责在约定周期内核对状态，对逾期项提醒负责人并上报主持人。
示例：一次需求评审会的纪要转化
以下为演示情景，用于说明字段填写方式，不代表真实项目数据。
背景：某产品团队召开需求评审会，议题是“下个版本是否纳入批量导出功能”。参会人包括产品经理、研发负责人、测试负责人和客户成功代表。
讨论区原始记录片段：
- 议题R-01：批量导出功能是否进入下个版本。
- 客户成功代表：三家客户在续约沟通中提到导出需求，依据为近期沟通记录。
- 研发负责人：完整实现预计增加两周工作量，当前排期已满，依据为排期表。
- 产品经理：可以先做基础导出，高级筛选延后。
- 分歧点：是否本期做完整功能，还是只做基础版本。
收敛后的决议表述：
- 决议D-01：下个版本纳入基础批量导出功能，高级筛选能力延后至再下一个版本评估；生效条件为研发负责人在本周内确认工作量不超过一周；影响范围为产品、研发、测试三个小组及已提出需求的客户。
由决议派生的行动项：
| 编号 | 动作描述 | 负责人 | 截止时间 | 验收标准 | 关联决议 |
|---|---|---|---|---|---|
| A-01 | 输出基础批量导出的需求说明 | 产品经理 | 本周三18:00前 | 需求说明经研发负责人确认可排期 | D-01 |
| A-02 | 评估基础导出工作量并回复确认 | 研发负责人 | 本周五18:00前 | 工作量结论写入排期表并回复产品经理 | D-01 |
| A-03 | 向提出需求的客户同步版本计划 | 客户成功代表 | 下周一18:00前 | 三家客户均收到书面回复 | D-01 |
这个示例体现的规律是：讨论区保留了客户依据和排期约束，决议区只写取舍和条件，行动项区按受影响方逐条派生。可迁移的做法是，每条行动项都能回溯到决议编号，读者不需要重读讨论过程就能知道为什么做这件事。
完成检查：发出前逐项核对
纪要发出前，记录人按以下清单逐项核对。清单中的阻断项未通过时，纪要暂不发出，先回到对应角色补齐。
| 检查项 | 通过标准 | 未通过时的处理 |
|---|---|---|
| 决议完整性 | 每条决议有明确结论表述和影响范围 | 阻断发出，提交主持人补充口径 |
| 行动项字段 | 每条行动项具备负责人、时限、验收标准、关联决议 | 阻断发出，向负责人确认后补齐 |
| 讨论区残留 | 讨论区无未标注的结论性表述 | 移入决议区或标注“待确认” |
| 待定事项 | 每项待定事项标注原因和确认时点 | 补充确认时点，否则转为跟踪项 |
| 角色确认 | 主持人已确认决议，负责人已回执 | 未回执项在纪要中标注待确认状态 |
检查通过后，纪要按“决议在前、行动项居中、讨论附后”的顺序发出，方便读者先看结论再看依据。会后跟踪阶段，跟踪人只需核对行动项状态字段，逾期项按负责人逐条提醒，决议本身不再反复讨论，除非生效条件发生变化需要重新确认。
常见问题
会上没有形成明确结论，纪要该怎么写？
把这类议题留在讨论区，标注“待确认”并写明未收敛的原因，例如各方依据不足、需要补充数据或需要更高层级决策。同时在待定事项中写明确认时点和确认人，会后由主持人推动补充。不要把讨论中的倾向性发言直接写成决议，也不要在纪要里留空，否则读者无法判断这件事是否已有结论。
一条决议派生多条行动项时，如何避免重复或遗漏？
按受影响的对象逐条拆分：每个交付物、每个协作方、每个需要确认的节点各对应一条行动项，并在每条行动项上填写同一个关联决议编号。拆分完成后回看决议的影响范围，逐一核对范围内每个团队是否都有对应行动项。行动项编号与决议编号建立引用关系，后续跟踪时按决议编号汇总查看，就能发现遗漏。
行动项负责人当场无法确认截止时间怎么办？
在行动项中标注待定原因和确认时点，例如“截止时间待定，原因：需与运维组确认排班，确认时点：本周五前由负责人回复”。该行动项进入跟踪清单，由跟踪人在确认时点后核对是否补齐。纪要中保留待定状态，可以避免把未确认的时间当成承诺，也便于会后追责到具体环节。
纪要用文档发出后，行动项状态怎么持续跟踪？
行动项数量少、协作范围小时，可以在文档中维护状态列，由跟踪人按约定周期更新。行动项数量多或跨团队协作频繁时，把行动项录入工作项管理工具，负责人直接更新状态，跟踪人按负责人查看逾期项。ONES 的工作项可以承载行动项的动作描述、负责人、截止时间和状态，把纪要中的行动项区与后续跟踪衔接在同一处。
会议中临时提出的新事项，要不要写进行动项？
先判断它是否属于本次议题范围。属于范围内且已形成决议的，按决议派生行动项；属于范围内但未讨论充分的，记入讨论区并标注待确认；超出本次议题范围的，记入待办议题清单，留待后续会议讨论，不直接派发行动项。这样处理可以避免会上临时提议被当成已定事项，也能保留有价值的议题线索。
