回顾会有记录、行动项却无人跟进，常见原因是行动项只停留在会议纪要里：没有唯一负责人、没有截止时间，也没有下一次检查。要让闭环真正建立，需要同时做到三件事：每条行动项写成可跟踪、可验收的工作项；在会中、迭代中、下次回顾设置固定检查点；把推动和验收的责任分到具体角色。下面按这三点给出可直接套用的字段、步骤和检查清单。
要点总览（TL;DR）
- 闭环的最小结构是每条行动项写清问题描述、改进动作、唯一负责人、截止时间、完成标准和验证方式，把口号改写成可验收的工作项。
- 固定三个检查点：回顾会结束前当场确认负责人和日期并写入工作项系统，迭代中期核对进度并升级阻塞，下次回顾会开头逐条验收上轮行动项。
- 推动与验收分开：负责人执行并更新状态，Scrum Master 或敏捷教练维护清单和组织核对，团队共同验收，产品负责人或管理者处理资源与跨团队协调。
- 未完成项当场做继续、换人或关闭的处置决定并写明理由，不默认顺延；行动项数量控制在一个迭代能实际推进的范围内。
- 用一份检查清单在连续两到三个迭代后核对闭环是否落地，出现长期停留在进行中、负责人频繁更换、验收被跳过等信号时优先修正会中指派和中期核对。
行动项闭环的最小结构：一条记录要写清什么
行动项无人跟进，往往从写下那一刻就注定了：记录里只有一句“加强代码评审”“提升测试覆盖率”，没有负责人、没有日期、没有完成标准，谁都可以理解成“已经在做了”。闭环的第一步，是把每条行动项从讨论记录改写成一条可跟踪的工作项。判断标准很简单：换一个没参加回顾会的人读这条记录，能知道要做什么、谁来做、什么时候做完、怎么算做完。
行动项必备字段
一条合格的回顾行动项至少包含六个字段。字段不必多，但每一项都要填实，空缺的字段就是后续无人跟进的缺口。
| 字段 | 填写要求 | 常见错误 |
|---|---|---|
| 问题描述 | 回顾中识别出的具体问题或改进机会，写清发生场景 | 写成笼统的“协作不畅” |
| 改进动作 | 团队要执行的具体动作，动词开头，范围可控 | 写成目标而非动作，如“提高质量” |
| 唯一负责人 | 一个具名的人，对推进和状态更新负责 | 写“团队”“前端组”或两个人共同负责 |
| 截止时间 | 具体日期，通常落在下次回顾会之前 | 写“尽快”“本迭代内” |
| 完成标准 | 可观察、可验证的完成状态 | 写“评审更规范了”这类无法判定的描述 |
| 验证方式 | 下次回顾会上用什么证据确认完成，如文档、记录、数据 | 不写，验收时凭印象争论 |
行动项与讨论记录、需求工作的边界
回顾会记录里通常混着三类内容：对现象的描述和讨论、团队工作方式的改进动作、以及需要进入产品待办的需求类工作。只有第二类适合作为回顾行动项跟踪。讨论记录保留在会议纪要中即可，不必逐条建工作项；涉及产品功能的需求应进入需求池按正常优先级排期，不应挂在回顾行动项里，否则会被误认为“已经有人负责”。把这三类内容在会后整理时分开，行动项清单才不会膨胀到没人愿意看。
改写示例：从口号到可验收行动项
以“加强代码评审”为例，按字段改写后可以是：问题描述为“近两个迭代合并请求平均评审等待超过一天，部分合并请求只有一人看过”；改进动作为“为合并请求设定评审响应约定，并在团队内公示”；唯一负责人为某位开发人员；截止时间为下次回顾会前一周；完成标准为“团队评审约定文档发布，且连续两周的合并请求均在约定时间内获得至少两人评审”；验证方式为“下次回顾会上展示约定文档和两周的合并请求评审记录”。改写后，这条行动项有了明确的执行人、时间点和验收证据，讨论时的模糊共识变成了可检查的承诺。
未完成项的处置字段
行动项清单还需要为未完成情况预留处置字段：处置结论（继续、换人、关闭）和理由。继续表示原负责人按新截止时间推进；换人表示原负责人无法承担，改由他人接手并说明原因；关闭表示该动作已不必要或已被其他方式覆盖。三种处置都要求填写理由，避免“没做完就默认顺延”成为习惯。
从回顾会到下次回顾：三个检查点的操作步骤
字段解决“写得清”，检查点解决“有人看”。行动项从提出到验收，需要三个固定节点，每个节点都有明确的输入、动作、输出和完成标志。三个节点缺一个，闭环就会断在对应环节。
检查点一：回顾会结束前当场确认
输入是回顾会形成的改进候选清单。动作是逐条确认负责人、截止时间和完成标准，负责人当场确认接受，而不是会后由主持人代为指派；确认后的行动项写入团队日常使用的工作项系统，状态设为待处理。输出是一份字段齐全、已进入工作项系统的行动项清单。完成标志是：每条行动项都有唯一负责人和具体日期，且团队在会中能看到清单全貌。这一步的关键在于“当场”，会后补填的指派往往无人回应。
检查点二：迭代中期核对进度
输入是工作项系统中的行动项清单。动作由负责人更新状态：已完成、进行中或受阻；受阻项说明阻塞原因，需要跨团队协调或资源支持的，由 Scrum Master 或敏捷教练升级给产品负责人或相关管理者。核对以短会或异步更新的方式进行，重点是发现延期而不是逐条汇报细节。输出是更新后的行动项状态和一份阻塞清单。完成标志是：所有行动项状态在一周内被更新过，没有长期停留在“进行中”却无人说明的条目。
检查点三：下次回顾会开头逐条验收
输入是上轮行动项清单及负责人提供的完成证据。动作是团队逐条对照完成标准判定：完成的关闭并记录；未完成的当场做处置决定，选择继续、换人还是关闭，并写明理由和新截止时间。验收放在回顾会开头，而不是结尾顺带一提，是为了让上轮承诺成为本轮讨论的起点。输出是上轮行动项的验收结论和处置记录。完成标志是：每条上轮行动项都有明确的完成或处置结论，没有一条处于“未讨论”状态。
| 检查点 | 输入 | 核心动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 回顾会结束前 | 改进候选清单 | 当场确认负责人、截止时间、完成标准并写入工作项系统 | 字段齐全的行动项清单 | 每条有唯一负责人和具体日期 |
| 迭代中期 | 行动项清单 | 负责人更新状态，阻塞项升级 | 更新后的状态与阻塞清单 | 所有条目一周内更新过 |
| 下次回顾开头 | 上轮行动项与完成证据 | 逐条验收，未完成项做处置决定 | 验收结论与处置记录 | 每条都有完成或处置结论 |
角色分工：谁负责推动、谁负责验收
闭环失效的另一种典型情形是责任分散：主持人在推，负责人以为主持人在跟，团队以为负责人会汇报。把推动和验收拆到具体角色，并明确每个角色交付什么、在什么时点交接，才能避免责任落空。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 行动项负责人 | 执行改进动作，更新工作项状态，及时提出阻塞 | 状态更新、完成证据、阻塞说明 | 迭代中期核对前、下次回顾会前 |
| Scrum Master 或敏捷教练 | 维护行动项清单，组织中期核对，主持下次回顾的验收环节 | 行动项清单、核对记录、验收议程 | 每次回顾会结束前、中期核对后 |
| 团队 | 在回顾会上共同验收上轮行动项，对未完成项做处置决定 | 验收结论、处置决定及理由 | 下次回顾会开头 |
| 产品负责人或管理者 | 处理需要资源投入或跨团队协调的行动项，给出支持或明确取舍 | 资源协调结果、优先级取舍说明 | 阻塞项升级后、处置决定需要授权时 |
需要说明的是，Scrum Master 或敏捷教练推动的是机制运转，而不是替负责人完成行动项；负责人对结果负责，团队对验收负责。产品负责人或管理者介入的范围限于资源与跨团队协调，日常行动项的推进仍由团队内部完成。角色可以按团队实际情况合并，例如小团队中教练与主持由同一人承担，但“执行”和“验收”两类职责不宜由同一人独自包办。
当行动项需要进入工作项系统跟踪状态与截止时间时，ONES 可以作为承载回顾行动项的协作工具：行动项以工作项形式记录负责人、截止时间和状态，中期核对与下次回顾验收都基于同一份清单进行，减少会议纪要与实际跟踪脱节的情况。
示例：一个迭代内的行动项闭环全过程
以下情景为演示用途，用于说明字段、角色和检查点如何配合。某团队在迭代回顾会上识别出两个问题：合并请求评审等待时间长，以及新成员对发布流程不熟悉。团队决定形成两条行动项。
会中：填写字段并指派
第一条行动项：问题描述为“合并请求平均评审等待超过一天”；改进动作为“制定评审响应约定并公示”；负责人为开发人员甲；截止时间为下次回顾会前一周；完成标准为“约定文档发布，且连续两周合并请求在约定时间内获得至少两人评审”；验证方式为展示文档和评审记录。第二条行动项：问题描述为“新成员两次发布操作需要他人全程协助”；改进动作为“编写发布操作检查清单并带新成员走一遍完整流程”；负责人为开发人员乙；截止时间为下次回顾会前三天；完成标准为“检查清单文档发布，新成员独立完成一次发布”；验证方式为发布记录和清单文档。两条行动项当场由负责人确认，写入工作项系统，状态为待处理。
中期核对：发现延期并处理
迭代中期核对时，第一条行动项状态为进行中，约定文档已起草；第二条行动项因乙临时支持线上问题未启动，标记为受阻。教练将第二条升级，与产品负责人确认乙本周可投入半天完成清单编写，截止时间保持不变。核对记录中写明阻塞原因和协调结果，团队在周会上同步。
下次回顾：验收与处置
下次回顾会开头逐条验收。第一条行动项：文档已发布，评审记录显示连续两周达标，判定完成并关闭。第二条行动项：清单文档已完成，但新成员尚未独立发布，未达到完成标准。团队讨论后决定继续，由乙在下个迭代前半段安排一次独立发布演练，新截止时间定为下个迭代中期，理由记录为“文档已完成，验证环节未完成”。验收结束后，团队再讨论本轮新问题，形成新的行动项。
这个例子可迁移的规律是：每个迭代的行动项控制在两到三条，每条都能在下次回顾前完成或给出明确进展；完成标准写成可展示的证据；三个检查点固定执行，未完成项当场处置而不是默认顺延。
完成检查：判断闭环是否真的建立
机制是否落地，可以用一份清单逐项核对。建议在连续两到三个迭代后做一次检查，逐条打勾，未通过的条目对应回到前面的字段或检查点修正。
- 每条行动项都有唯一具名的负责人，没有“团队”“小组”这类集体负责人。
- 每条行动项都有具体截止日期，且落在下次回顾会之前或当天。
- 每条行动项都有可验证的完成标准和验证方式，验收时能拿出证据。
- 行动项已进入团队日常使用的工作项系统，而不是只存在于会议纪要文档中。
- 迭代中期有一次状态核对，所有行动项在一周内被更新过。
- 下次回顾会开头逐条验收上轮行动项，验收环节没有被压缩或跳过。
- 未完成项都有继续、换人或关闭的处置结论和理由，没有默认自动结转。
- 行动项数量控制在团队一个迭代能实际推进的范围内。
出现以下信号，说明闭环正在失效：行动项长期停留在“进行中”且无人说明原因；负责人频繁更换，或同一条行动项几次回顾都被重新指派；验收环节被新话题挤到会末甚至取消；行动项清单越来越长，团队不再逐条查看。这些信号出现时，优先检查会中指派是否当场完成、中期核对是否真的发生，而不是增加更多行动项。
闭环的本质不是把流程写得更复杂，而是让每条承诺都有名字、有日期、有下一次被看见的机会。字段保证写得清，检查点保证有人看，角色分工保证有人推、有人验，三者同时到位，回顾会的改进才会从记录变成团队工作方式的真实变化。
常见问题
回顾会时间紧，行动项来不及当场逐条确认负责人和日期，可以会后补吗？
会后补填的指派往往无人回应，这是行动项无人跟进的常见起点。如果会议时间确实不够，可以压缩讨论环节，把最后十到十五分钟固定留给行动项确认：逐条读出改进动作，由负责人当场接受并说出截止时间，主持人记录。实在无法当场确认的少数条目，指定一名跟进人在当天完成确认，并在团队频道公示确认结果，而不是留到下次会议再说。
行动项负责人中途离职或转岗，原来的行动项怎么处理？
在中期核对或下次回顾验收时，把这类行动项按“换人”处置：由团队重新指定负责人，写明更换原因和新截止时间，原负责人已完成的进展作为交接内容保留在工作项记录中。如果该动作已因人员变动失去必要性，也可以选择关闭并写明理由。关键是让处置发生在固定检查点上，而不是让行动项在无人认领的状态下继续挂着。
团队行动项数量总是很多，每个迭代都做不完，应该怎么控制？
先按影响范围和可执行性排序，每个迭代只保留团队能实际推进的两到三条，其余改进想法记录在待选清单中，等前面的行动项完成或关闭后再进入。判断标准是这条行动项能否在下次回顾会前完成或给出明确进展。数量过多时，验收环节会被压缩，负责人也会因为同时推进多项而顾此失彼，闭环反而更难建立。
行动项需要跨团队配合，本团队负责人推不动怎么办？
这类行动项在中期核对时标记为受阻，由 Scrum Master 或敏捷教练升级给产品负责人或相关管理者，明确需要对方提供的是资源、排期还是决策，并约定回复时点。升级后仍要在下次回顾会上验收，结论可以是完成、继续（附新的协调安排）或关闭（说明替代方式）。跨团队事项的负责人仍由本团队具名成员担任，负责跟进协调进展，避免出现“等对方回复”就无人推进的情况。
回顾会行动项和迭代待办里的任务要分开管理吗？
建议分开记录、统一跟踪。行动项针对团队工作方式的改进，迭代待办里的任务针对本迭代要交付的产品工作，两者性质不同，混在一起会让行动项被交付任务挤掉。但行动项应进入团队日常使用的工作项系统，以独立类型或独立清单存在，这样状态更新、截止时间提醒和下次回顾验收都基于同一份数据，不必在会议纪要和任务列表之间来回核对。
