评审意见长期停留在待回复、无人认领或反复讨论却无结论的状态，通常指向信息、责任或流程约束上的缺口，与评审人是否认真关系不大。要解决这个问题，先界定积压范围，再按原因逐类验证，然后给出处置动作与停止点，最后用合入前检查确认恢复，并把规则写回评审流程。
要点总览（TL;DR）
- 评审意见未处理多数源于三类缺口：意见缺少可执行信息、没有明确处理人、评审标准与合入条件脱节；意见冲突无人拍板是第四类常见原因。
- 排查先固定统计口径（仓库、分支、评审单状态、时间窗），按阻断性、建议、疑问、风格分类，形成未处理意见清单作为基线。
- 处置按原因对应：提出人补充位置与期望结果、每条意见指定单一处理人、阻断性意见设为合入前置条件、冲突意见由决策人记录结论。
- 恢复验证看两项：未处理意见归零或转入明确延期状态，已合入评审单中不存在未关闭的阻断性意见；验证放在合入前检查与周期性复查。
- 复发预防落到评审模板必填字段、处理时限、合入检查与决策人设置，并用工具状态流转保留处理与确认记录。
评审意见未处理的表现与范围界定
“没人处理”是一个笼统描述，直接拿来讨论容易变成互相指责。排查的第一步是把症状拆成可观察、可计数的事实，让团队对问题有共同口径。
常见症状
- 意见长期停留在待回复：评论发出后数天甚至跨迭代没有回应，评审单状态停在“评审中”。
- 评论无人认领：意见以“这里再看看”“建议优化”等形式出现，没有指向具体处理人。
- 讨论反复但无结论：同一处代码来回多轮，最后没有明确采纳或拒绝的记录。
- 合入被搁置：评审单既不通过也不关闭，分支长期挂起，后续改动被迫叠加。
划定排查范围
范围不清会让统计结果失真。建议按四个维度固定口径：仓库、目标分支、评审单状态（未合入且未关闭）、时间窗（例如最近30天创建或更新的评审单）。统计时同时记录两个数字：未处理意见总数，以及涉及评审单数。前者反映工作量，后者反映阻塞面。
统计完成后，按意见类型分类，因为不同类型对应不同的处置紧迫度：
| 意见类型 | 典型表述 | 处置优先级 |
|---|---|---|
| 阻断性问题 | 存在缺陷、安全风险、数据一致性问题 | 合入前必须解决 |
| 修改建议 | 建议调整实现方式、补充边界处理 | 合入前确认采纳或明确延期 |
| 疑问 | 这段逻辑为什么这样写 | 回复即可闭环 |
| 风格建议 | 命名、格式、注释 | 可批量处理或转入规范 |
这份范围清单是后续排查的基线：每条意见记录所在评审单、提出人、当前状态和类型，后续验证都以它为对照。
原因假设与排除证据
原因判断需要证据支撑。下面四类假设覆盖了多数积压场景，排查时逐条验证，标注已证实、已排除或待观察，避免把最先想到的解释当成结论。
假设一：意见描述不清
意见本身缺少位置、期望结果或验收方式，处理人无法判断要改什么。验证方式是抽样20至30条未处理意见，检查是否包含具体文件与行号、期望行为描述。若大量意见只有一句模糊评价，该假设成立。
假设二：意见没有明确处理人
意见以评论形式存在，但没有指派给任何人，或指派对象不在评审参与者中。验证方式是核对评审单的指派记录与评论作者、代码提交者的对应关系。若多数意见处于“谁都可以改、谁都没动手”的状态，该假设成立。
假设三：评审标准与合入条件脱节
评审通过标准停留在口头约定，合入操作不检查意见状态，导致意见不处理也能合入。验证方式是把合入记录与意见状态做对照：抽取已合入的评审单，检查合入时是否仍有未关闭的阻断性意见。若存在这种情况，说明流程约束缺失。
假设四：评审人过多或意见冲突
参与者多、意见相互矛盾时，处理人不知道听谁的，于是选择搁置。验证方式是统计单张评审单的参与人数与意见分歧次数，并检查是否存在明确的决策人。若讨论多轮仍无拍板记录，该假设成立。
| 原因假设 | 验证证据 | 判定结论 |
|---|---|---|
| 意见描述不清 | 评论内容抽样，检查位置与期望结果 | 已证实 / 已排除 / 待观察 |
| 无明确处理人 | 评审单指派记录与参与者名单对照 | 已证实 / 已排除 / 待观察 |
| 标准与合入脱节 | 合入记录与意见状态对照 | 已证实 / 已排除 / 待观察 |
| 意见冲突无人拍板 | 参与人数、分歧次数、决策记录 | 已证实 / 已排除 / 待观察 |
四类原因可能同时存在，但处置顺序不同：信息不清和无人认领影响单条意见，标准脱节和意见冲突影响整条流程。先处理前者能快速减少积压数量，再处理后者防止复发。
按原因分类的处置步骤
处置动作要与原因对应，并明确责任人和停止条件。以下步骤可按积压规模分批执行，每批处理完再进入下一批。
意见不清：由提出人补充可执行信息
要求原提出人在原评论下补充三项内容：具体位置（文件与行号或代码片段）、期望结果（改成什么样）、验收方式（如何确认改对了）。补充完成后，处理人据此判断是修改还是说明理由后关闭。停止条件是：提出人无法补充期望结果时，由评审负责人决定该意见转为建议或撤销，并记录理由。
无人认领：明确单一处理人
每条意见指定一名处理人，通常是被评审代码的作者或该模块负责人。其余评审人转为确认角色，只负责在修改后确认是否满足原意。指派动作要落在评审单上，避免只在聊天工具里口头交代。停止条件是：处理人明确表示不处理时，必须给出理由并由评审负责人确认关闭。
标准脱节：把阻断性意见设为合入前置条件
在合入检查中增加一条规则：存在未关闭的阻断性意见时不允许合入。修改建议类意见可以合入，但需在合入前标记为“已采纳”或“延期并记录原因”。这条规则需要评审负责人和仓库管理员共同确认后生效，避免只在一张评审单上执行。
意见冲突：指定决策人并记录结论
当同一处代码出现相互矛盾的意见时，由评审负责人或模块负责人担任决策人，在评审单中写明采纳哪一方、理由是什么。结论记录后，持不同意见的一方可以保留看法，但不再阻塞合入。停止条件是：决策涉及架构方向时，升级到技术负责人，不在单张评审单内反复拉锯。
涉及回退或强制合入的风险边界
处置过程中若需要回退已合入代码或强制合入，先确认三件事：目标分支是否有备份或可回滚的提交点、当前是否处于变更冻结窗口、回退影响范围是否已通知相关方。停止条件是：备份不可用或处于发布窗口内时，暂停操作，改为在后续提交中修复。强制合入只适用于阻断性意见已确认可延期的情况，并需在评审单中记录批准人。
恢复验证与复发预防
处置完成后，需要用可核验的结果确认意见已闭环，再把临时做法沉淀为规则，避免下一轮评审重新积压。
验证检查项
- 未处理意见数量归零，或每条剩余意见都转入明确的延期状态并记录原因与复查时间。
- 合入记录与意见状态一致：已合入的评审单中不存在未关闭的阻断性意见。
- 每条意见都有处理人或明确的关闭理由，不存在无归属的评论。
- 冲突意见有决策记录，记录中包含结论与决策人。
验证时点分两处：合入前检查作为每次合入的必经环节，周期性复查按周或按迭代执行，统计未处理意见数量与平均停留时间，观察是否反弹。
复发预防规则
- 评审模板增加必填字段：意见需包含位置、期望结果、类型（阻断、建议、疑问、风格），缺项的评论在提交时提示补充。
- 明确处理时限：阻断性意见在当个工作日内响应，建议类意见在评审单合入前给出结论，超时由评审负责人介入指派。
- 把意见状态纳入合入检查：阻断性意见未关闭不允许合入，建议类意见需标记采纳或延期。
- 控制评审参与规模：每张评审单指定一名决策人，参与者按模块相关性邀请，减少意见冲突后的搁置。
这些规则要落到工具里才有约束力。在ONES中，可以用工作项承载每条评审意见，记录提出人、处理人、类型与期望结果；通过状态流转标记待处理、处理中、已确认、已延期，使意见的处理与确认过程可追溯。合入前的检查可以对照工作项状态执行，周期性复查则直接统计未关闭意见的数量与停留时间，让恢复验证有据可查。
把范围清单、原因对照表和处置记录保留下来，下一次出现积压时可以直接复用同一套口径，缩短排查时间。
常见问题
评审意见积压很多，应该先处理哪一类？
先处理影响单条意见的两类：意见描述不清和无人认领。这两类处置动作快，能直接减少积压数量。标准脱节和意见冲突影响整条流程，放在第二批处理，用于防止处理后再次积压。如果积压规模较大，可以按评审单分批推进，每批处理完再进入下一批，避免一次性铺开导致责任分散。
提出意见的人已经离职或转岗，意见还能关闭吗？
可以关闭，但需要留下记录。由评审负责人判断该意见是否仍然成立：成立则转派新的处理人，按原意见补充位置与期望结果后继续处理；不再成立则在评审单中写明关闭理由和判断人。关键是关闭动作有据可查，避免后续复查时无法解释这条意见为何消失。
阻断性意见和修改建议的合入要求有什么区别？
阻断性意见涉及缺陷、安全风险或数据一致性问题，合入前必须关闭，未关闭时不允许合入。修改建议类意见可以合入，但合入前要标记为已采纳或延期，并记录延期原因与复查时间。两类意见的区分要在评审时确定，事后补分类容易产生争议。
强制合入在什么情况下可以使用？
强制合入只适用于阻断性意见已确认可以延期的情况，并且需要在评审单中记录批准人和延期理由。操作前确认三件事：目标分支有可回滚的提交点、当前不在变更冻结或发布窗口内、影响范围已通知相关方。任一条件不满足时暂停操作，改为在后续提交中修复。
怎么判断处置之后问题没有反弹？
看两个信号：一是周期性复查时未关闭意见的数量和平均停留时间是否回到处置前的水平；二是抽查已合入的评审单，是否重新出现未关闭的阻断性意见。如果两项都保持稳定，说明规则在起作用；如果反弹，优先检查合入检查是否被绕过，以及评审模板的必填字段是否被跳过。
