会议行动项写得含糊，往往不是记录速度问题，而是分派时缺少固定字段：任务动作、负责人、截止时间、交付物、验收标准。把每条行动项写成这五项齐全的一句话或一张卡，交付物落成可打开、可查看的具体对象，验收标准落成能逐条判断“通过/不通过”的条件，并注明验收人，会后争议会明显减少。这套写法尤其适合讨论容易发散、结论需要当场收敛的会议。
要点总览（TL;DR）
- 会议行动项按“任务动作、负责人、截止时间、交付物、验收标准”五要素写全，并注明验收人，缺一项就容易在会后变成模糊待办。
- 交付物写成可打开、可查看的具体对象并注明存放位置，例如“含三套备选方案的对比表，放在项目文档库方案评审目录”。
- 验收标准写成能逐条判断通过与否的条件，写明验收人和验收时点，记录中区分“完成”与“验收通过”两个状态。
- 讨论发散的会议在收尾环节统一收敛：记录候选动作、改写成具体动词、追问“做完能看到什么”、当场确认负责人和截止时间。
- 清单发出前按检查表逐项核对，五要素不全、交付物不可定位、验收标准不可判断的条目先补齐或标为待定。
一条合格的会议行动项包含哪五个要素
行动项要能被执行、被检查，字段结构需要固定下来。推荐用五要素加一个附属字段：任务动作、负责人、截止时间、交付物、验收标准，以及验收人。前五项缺一项，行动项就容易在会后变成“知道有这件事，但不知道做到什么程度算完”。
| 字段 | 填写要求 | 常见含糊表述 |
|---|---|---|
| 任务动作 | 动词开头，说明做什么，一条只含一个主要动作 | “跟进一下”“推进方案”“关注风险” |
| 负责人 | 写具体姓名或岗位，只写一人主责 | “产品组”“相关同事”“大家” |
| 截止时间 | 写明确日期，必要时加具体时点 | “下周”“尽快”“这周内看情况” |
| 交付物 | 写成可打开、可查看的具体对象，并注明存放位置 | “整理一下”“发给大家”“出个东西” |
| 验收标准 | 写成可逐条判断通过与否的条件 | “质量达标”“内容完整”“没问题” |
| 验收人 | 写明由谁判定验收通过，以及验收时点 | 不写，默认由负责人自己判断 |
交付物和验收标准是两个不同位置的内容。交付物回答“做完后能看到什么对象”，是一个名词性的产出；验收标准回答“这个对象满足哪些条件才算通过”，是一组判断条件。例如交付物是“三套备选方案对比表”，验收标准是“每套方案包含成本、周期、风险三项，且经产品负责人和技术负责人确认”。只写交付物，验收时仍要重新解释；只写验收标准，验收人找不到检查对象。
验收人作为验收标准的附属字段，需要与标准同时确定。验收标准由谁提出、由谁判定，最好在分派时就说清楚。负责人自检通过不等于验收通过，这两个状态在记录中应分开表达。
从发散讨论中收敛出可验收的行动项
讨论发散的会议，问题通常出在收尾环节：话题停下来了，但没有把讨论转成“决定什么、谁来做、做到什么程度”。现场收敛可以按三步走，主持人在会议最后留出固定时间执行。
- 记录候选动作。讨论过程中，记录人把出现的动作性表述先记成候选清单，不急于判断是否成立。例如“要看一下竞品”“需要确认接口能力”“得让设计出个稿”。
- 收尾统一收敛。主持人逐条过候选清单，把“要关注”“要推进”改写成具体动作动词，如“对比”“确认”“输出”“评审”。对每条追问一句：“做完能看到什么？”答案就是交付物的雏形。
- 当场确认责任与时间。负责人和截止时间在会上直接确认，由本人应答，避免会后默认分派。负责人不在场的，标注待确认，并指定由谁在什么时间前补齐。
现场追问可以固定成几个问题：这件事的产出是一个文档、一张表、一个原型，还是一封确认邮件？这个产出放在哪里，谁能打开？做到什么程度算通过，由谁来判断？如果当场定不下验收标准，就把这条标为待定项，写清补齐责任人和补齐时间，不要用“会后再说”结束。
收敛的完成标志是：候选清单中每一条都有了明确去向，要么转成五要素齐全的行动项，要么明确取消，要么进入待定项并有人负责补齐。会议结束时，行动项数量不宜过多，优先保留与本次会议结论直接相关的条目。
交付物怎么写：从抽象名词到可查看的对象
交付物的写法规则是：写成名词性的具体对象，并给出存放位置或提交方式。文档、表格、清单、原型、邮件、决策记录都可以作为交付物，关键是验收人能够找到并打开它。
“发给大家”“同步一下”这类表述缺少落点，应改成具体位置，例如“放在项目文档库的会议纪要目录下”“提交到需求管理工具对应条目”“以邮件形式发送给评审组并抄送负责人”。写明位置后，验收人不必再问“东西在哪”。
一条行动项只保留一个主交付物。过程产物和最终交付物要区分：讨论稿、会议记录属于过程产物，评审通过的方案文档才是最终交付物。如果一项任务确实需要多个产出，拆成多条行动项，或标注主次，避免验收时对“到底交哪个”产生分歧。
| 模糊表述 | 改写后的交付物 |
|---|---|
| 整理一下方案 | 输出含三套备选方案的对比表，放在项目文档库“方案评审”目录 |
| 确认一下接口 | 提交接口能力确认清单，列明可用接口、限制条件和对接人，附在需求条目下 |
| 让设计出个稿 | 提交首页改版高保真原型，上传至设计协作空间并附版本说明 |
| 把结论同步给大家 | 发出一封决策记录邮件，写明本次会议的三项决定及生效时间，发送至项目组邮件列表 |
改写时可以用一个简单检验：把交付物名称读给未参会的人听，对方能否据此判断去哪里找、打开后看到什么。如果答案是否定的，说明还需要补充对象类型或存放位置。
验收标准怎么写：可逐条判断通过与否
验收标准写成条件句或检查项，每一条都能被验收人判断为通过或不通过。常用维度包括内容完整性、覆盖范围、格式与篇幅、评审通过情况、数据口径。标准不必追求数量多，覆盖关键判断点即可。
每条标准尽量包含可核对的依据。例如“覆盖三个业务场景”比“覆盖主要场景”更容易判断；“经产品与测试双方评审确认”比“评审通过”更明确；“数据取自最近一个完整季度，口径与财务报表一致”比“数据准确”更可核查。
验收人和验收时点要与标准一起写明。验收时点可以设在截止时间当天或之后一个工作日内，由验收人按标准逐条判定并反馈结论。记录中区分“完成”和“验收通过”两个状态：负责人提交交付物后标记完成，验收人判定通过后才标记验收通过。未通过时，写明未通过的具体条目，行动项回到负责人处继续处理。
| 模糊标准 | 改写后的验收标准 |
|---|---|
| 质量达标 | 覆盖三个业务场景，每个场景写明输入、处理规则和异常情况，经产品与测试双方评审确认 |
| 内容完整 | 对比表包含成本、周期、风险三项，每套方案均有数据来源，缺项不超过一项 |
| 大家认可 | 在评审会上获得参会评审人过半数同意，异议项记录在文档末尾 |
| 数据没问题 | 数据取自最近一个完整季度，与财务报表口径一致，抽样核对五个条目无差异 |
角色分工与会议记录模板
行动项从会上产生到验收关闭，涉及四类角色。角色清楚，格式才有人维护，验收才有人负责。
| 角色 | 职责 |
|---|---|
| 会议主持人 | 在收尾环节逐条过行动项，确认五要素齐全，当场确认负责人和截止时间 |
| 记录人 | 会中记录候选动作，会后按统一格式发出行动项清单 |
| 行动项负责人 | 按交付物和截止时间执行，提交后回复确认；对验收未通过项继续处理 |
| 验收人 | 在约定时点按验收标准逐条判定，反馈通过或不通过及具体原因 |
会后流转可以固定为：记录人在会后一个工作日内发出清单，负责人逐条回复确认或提出修改，验收人确认验收标准可执行，清单进入跟踪状态。记录表建议包含以下字段，可直接复制使用。
| 编号 | 任务 | 负责人 | 截止时间 | 交付物 | 存放位置 | 验收标准 | 验收人 | 状态 |
|---|---|---|---|---|---|---|---|---|
| A-01 | 输出三套备选方案对比表 | 示例：李明 | 示例：3月14日 | 方案对比表 | 项目文档库/方案评审 | 含成本、周期、风险三项，经产品与技术负责人确认 | 示例：王芳 | 待开始 |
| A-02 | 确认支付接口能力 | 示例：陈晨 | 示例：3月12日 | 接口确认清单 | 需求条目附件 | 列明可用接口、限制条件、对接人，无缺项 | 示例：李明 | 进行中 |
行动项需要进入日常跟踪时，可以把清单中的每条记录转为工作项，保留负责人、截止时间、交付物和验收标准字段，让状态从待开始、进行中、待验收到验收通过逐步流转。ONES 支持将会议、反馈和文档转化为可执行需求，并可基于项目目标、范围和关键交付物生成结构化计划与责任分工；在 Wiki 页面、附件等资料中建立统一知识上下文，便于会后查找交付物和决策记录。具体字段配置与状态设置需结合团队现有流程确定。
完整示例：一次发散会议的行动项落地
以下为演示情景。某团队召开需求评审会，讨论从新功能范围延伸到竞品做法和排期压力，会议临近结束仍没有明确结论。主持人留出十分钟收尾，记录人先列出候选动作：“看一下竞品”“确认支付接口”“设计出个首页稿”“把结论告诉大家”。
主持人逐条追问“做完能看到什么”，收敛出三条行动项：
| 要素 | A-01 | A-02 | A-03 |
|---|---|---|---|
| 任务动作 | 输出竞品支付流程对比表 | 确认支付接口能力并提交清单 | 提交首页改版高保真原型 |
| 负责人 | 示例：李明 | 示例：陈晨 | 示例：赵婷 |
| 截止时间 | 示例：3月14日 | 示例：3月12日 | 示例：3月18日 |
| 交付物 | 竞品支付流程对比表 | 接口能力确认清单 | 首页改版高保真原型 |
| 存放位置 | 项目文档库/竞品分析 | 需求条目附件 | 设计协作空间/首页改版 |
| 验收标准 | 覆盖三家竞品，每家的支付步骤、异常处理和到账时间均有记录，经产品负责人确认 | 列明可用接口、限制条件和对接人，技术负责人确认无遗漏 | 覆盖登录前后两种状态，标注交互说明，经产品与设计负责人评审通过 |
| 验收人 | 示例：王芳 | 示例：李明 | 示例：王芳 |
会后，记录人按记录表格式发出清单，三名负责人逐条回复确认。3月12日陈晨提交接口清单，李明按标准核对后标记验收通过；3月14日李明提交对比表，王芳发现缺少一家竞品的异常处理记录，标记未通过并写明缺项，李明补充后再次提交并通过。原先“把结论告诉大家”的候选动作，被改写为一条决策记录邮件，写明本次会议确定的范围和暂缓事项，发送至项目组。
这个示例中常见的错误有两处：一是最初把“看一下竞品”直接当成行动项，缺少交付物和范围；二是验收标准写成“对比清楚”，导致验收时无法判断。修正方式分别是补上对比表这一具体对象，以及把标准拆成覆盖数量、记录字段和确认人三个可核对条件。
发出前的完成检查清单
散会前和清单发出前，记录人可按以下条目逐项检查。标注为阻断项的条目未满足时，该行动项不应直接发出，应先补齐或标为待定。
| 检查项 | 判断方式 | 是否阻断 |
|---|---|---|
| 五要素齐全 | 任务动作、负责人、截止时间、交付物、验收标准逐项存在 | 是 |
| 任务动作可执行 | 动词开头，一条只含一个主要动作 | 是 |
| 交付物可定位 | 写明对象类型和存放位置，未参会的人也能找到 | 是 |
| 验收标准可判断 | 每条标准能回答通过或不通过，不含“达标”“认可”等模糊词 | 是 |
| 负责人已确认 | 负责人本人回复确认，而非默认分派 | 是 |
| 截止时间已确认 | 写明具体日期，负责人认可 | 是 |
| 验收人与验收时点明确 | 记录中写明由谁在何时判定 | 否，可会后一个工作日内补齐 |
| 待定项有补齐安排 | 每条待定项写明补齐责任人和补齐时间 | 是 |
| 状态字段可用 | 记录表能区分待开始、进行中、待验收、验收通过 | 否 |
检查完成后，记录人发出清单并保留版本记录。后续每次验收结论回填到同一张表，会议行动项就从一段讨论变成了可追溯的交付过程。
常见问题
会上定不下验收标准，这条行动项还能发出去吗？
可以发出，但要标为待定项，并写清补齐责任人和补齐时间，例如“验收标准由王芳在会后两个工作日内补充，补充后负责人确认”。待定项在记录表中单独标记，避免和已确认的行动项混在一起。补齐前，这条行动项不进入执行状态；补齐后按正常流程确认负责人和截止时间。
负责人不在场，行动项怎么确认？
由主持人指定一名对接人代为转达，并在记录中标注“待本人确认”，写明确认截止时间。负责人回复确认前，这条行动项保持待确认状态，不默认视为已分派。如果负责人对交付物或验收标准有异议，由提出方和验收人在确认环节协商修改，修改结果回填到同一张记录表。
一条行动项涉及多个交付物，是拆开还是合并？
优先拆成多条行动项，每条只保留一个主交付物，这样验收时能逐条判断。如果几个产出确实属于同一件事且必须一起验收，可以合并，但要标注主交付物，并在验收标准中分别写明每个产出的判断条件。合并后验收未通过时，要指明是哪个产出不满足条件，避免整条行动项反复退回。
验收未通过后，行动项怎么流转？
验收人写明未通过的具体条目，行动项退回负责人处继续处理，状态回到进行中，截止时间由负责人和验收人重新约定。补充提交后再次验收，结论回填到同一张记录表，保留每次验收的时间和结果。这样一条行动项从分派到验收通过的全过程都可追溯，也便于复盘哪些验收标准写得不够清楚。
行动项需要进入日常跟踪时，怎么和会议记录衔接？
把记录表中的每条行动项转为工作项，保留负责人、截止时间、交付物和验收标准字段，状态按待开始、进行中、待验收、验收通过流转。ONES 支持将会议、反馈和文档转化为可执行需求，并可基于项目目标、范围和关键交付物生成结构化计划与责任分工；在 Wiki 页面、附件等资料中建立统一知识上下文，便于会后查找交付物和决策记录。具体字段配置与状态设置需结合团队现有流程确定。
