代码评审反馈处理的关键，是把每条评审评论当成有状态的工作项来管理：先分类，再指派负责人和回复口径，最后以“评论已回复且结论已落地”作为关闭条件。本文给出一套可直接执行的流程、分类判定表、角色分工、完整示例和合入前检查清单，适用于采用拉取请求或合并请求进行代码评审的研发团队。
要点总览（TL;DR）
- 把每条评审评论当作有状态的工作项处理：分类、指派、处置、关闭四步，每步都有明确产出和完成标志。
- 反馈按处置动作分为必须修改、需要讨论、建议采纳、无需处理四类；必须修改类默认阻塞合入，讨论类需在合入前有结论或登记遗留项。
- 作者负责逐条回复并提交修改与验证说明，评审人负责确认并关闭或升级，合入者在合入前核对未关闭项。
- 关闭条件统一为“评论已回复且结论已落地”，只回复不落地或只改代码不回复都不算关闭。
- 合入前用清单逐项核对分类、修改验证、讨论结论、回复理由和遗留项登记，阻塞项未清零不放行。
核心答案：反馈处理分四步走
反馈处理可以拆成分类、指派、处置、关闭四步。四步的顺序有讲究：先定性再派人，先回复再改代码容易漏项，先改代码再回复则容易让评审人重复追问。每一步都要有明确产出，才能让下一位角色接手时不依赖口头沟通。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 分类 | 评审人提出的全部评论 | 逐条判断属于必须修改、需要讨论、建议采纳、无需处理中的哪一类，并标注是否阻塞合入 | 带类型标签的反馈清单 | 每条评论都有类型，没有“待定”项 |
| 2. 指派 | 带类型的反馈清单 | 为每条反馈指定负责人（通常是作者，涉及设计取舍时指定模块负责人或架构评审人），约定回复时限 | 带负责人和期限的反馈清单 | 每条反馈都有唯一负责人 |
| 3. 处置 | 已指派的反馈 | 作者逐条回复处置意见；必须修改类提交代码修改并附验证说明；讨论类组织结论；建议类说明采纳或暂不采纳的理由 | 回复记录、代码提交、验证证据 | 每条反馈下都有作者的明确回复 |
| 4. 关闭 | 回复记录与修改证据 | 评审人确认回复是否解决问题，满足关闭条件则关闭，不满足则退回或升级 | 已关闭或已升级的反馈状态 | 评论已回复且结论已落地 |
回复与修改的先后顺序建议统一为“先回复处置计划，再提交修改”。作者在回复中说明打算怎么改或为什么不改，评审人据此判断方向是否正确，避免作者改完一轮后才发现理解偏差。对于必须修改类，回复可以简短，但修改提交后要在同一条评论下补充提交编号和验证方式，方便评审人核对。
关闭反馈的判定标准统一为两条同时满足：评论已有作者回复，且回复中承诺的结论已经落地——修改类有对应提交和验证证据，讨论类有明确结论，无需处理类有可接受的理由。只回复不落地、或只改代码不回复，都不算关闭。
反馈分类与优先级判定
分类按处置动作划分，不按评论语气划分。评审人写得客气不代表可以不改，写得尖锐也可能只是提问。作者拿到评论后先问自己：这条反馈要求我做什么动作？答案落在哪一类，就按哪一类的规则处理。
| 类型 | 判断依据 | 典型例子 | 处置动作 | 是否阻塞合入 |
|---|---|---|---|---|
| 必须修改 | 涉及缺陷、安全风险或团队规范中的硬性要求 | 空指针未判空、SQL 拼接存在注入风险、日志打印了用户手机号、未按规范处理异常 | 提交修改，附测试或验证说明 | 默认阻塞 |
| 需要讨论 | 涉及设计取舍、接口变更、跨模块影响，单方无法定论 | 是否新增缓存层、公共接口参数是否调整、错误码体系如何统一 | 组织讨论，形成结论或登记遗留项 | 合入前需有结论或遗留项登记 |
| 建议采纳 | 不影响正确性，改善可读性与可维护性 | 变量命名更清晰、补充注释、拆分过长函数 | 采纳则修改，暂不采纳则说明理由 | 不阻塞 |
| 无需处理 | 评审人误解、意见基于已过时代码、或超出本次变更范围 | 评审人看的是旧版本、建议的功能属于下一个需求 | 回复澄清，必要时附代码位置或范围说明 | 不阻塞 |
优先级与合入阻塞的关系要在团队内事先约定，避免每次评审临时争论。常见约定是：必须修改类默认阻塞合入；需要讨论类在合入前必须给出结论，确实无法当次解决的，登记为遗留项并指定跟进人和时间；建议采纳类和无需处理类不阻塞合入，但每条都要有回复。这个约定让作者在评审当天就能判断本次变更能否合入，不必等到合入时才逐条确认。
分类存在争议时，由评审人而非作者做最终定性，因为评审人提出意见时通常已有明确意图。作者认为分类有误，可以在回复中说明并请评审人确认，确认后更新类型标签，避免同一类问题在后续评审中反复出现。
角色分工与交付物
反馈处理涉及三个角色，职责边界清晰才能避免“都以为对方会处理”。作者对每条反馈的回复和落地负责，评审人对结论的正确性负责，合入者对合入前的完整性负责。
| 角色 | 主要动作 | 交付物 | 完成时点 |
|---|---|---|---|
| 作者 | 逐条回复处置意见；提交修改；附验证说明；登记遗留项 | 回复记录、代码提交、验证证据、遗留项条目 | 所有反馈均有回复，必须修改项已提交 |
| 评审人 | 确认回复是否解决问题；关闭已解决的反馈；对未解决项退回或升级 | 关闭记录、升级说明 | 每条反馈处于已关闭或已升级状态 |
| 合入者（或模块负责人） | 合入前核对未关闭项；确认阻塞项已清零；确认遗留项已登记 | 合入检查记录 | 合入操作执行前 |
评审记录与修改记录的留存方式建议与代码托管平台绑定：评论保留在原合并请求下，修改通过提交记录关联，验证说明写在对应评论的回复中。这样任何人回看这次变更时，能从评论直接跳到提交，从提交回到评论，不需要额外整理文档。对于需要长期跟踪的讨论类结论，另存一份到团队文档或需求条目中，并在评论里注明存放位置。
角色之间容易出现的空档是“评审人提完意见就不再回看”。建议评审人在作者回复后收到通知并在一到两个工作日内确认，超过约定时间未确认的，由合入者提醒或按团队规则升级给模块负责人。这个机制解决的是反馈悬置，不涉及评审效率指标的度量。
示例：一次评审反馈从提出到关闭
以下为演示情景，用于说明各步骤的填写方式，不代表真实项目数据。
背景：某订单服务新增优惠券核销接口，作者提交合并请求，评审人提出四条评论。
| 反馈条目 | 分类 | 作者回复写法 | 修改与验证 | 关闭情况 |
|---|---|---|---|---|
| 核销接口未校验优惠券是否已过期 | 必须修改 | “确认是缺陷，今天内补充过期校验并加单测。” | 提交 a1b2c3，新增过期判断分支，补充两条单元测试覆盖过期与未过期场景 | 评审人核对提交与测试结果后关闭 |
| 核销结果是否要写审计日志，涉及跨服务约定 | 需要讨论 | “涉及审计服务接口，已约审计模块负责人明天上午讨论，结论回填本条评论。” | 讨论后确定本期先记录本地日志，审计服务对接登记为遗留项，指定跟进人和下个迭代时间 | 结论回填后关闭，遗留项单独跟踪 |
| 方法名 redeemCoupon 建议改为 redeem 更简洁 | 建议采纳 | “采纳，改为 redeemCouponV2 以区分旧接口，避免调用方混淆。” | 提交 d4e5f6 完成重命名，同步更新调用处 | 评审人确认后关闭 |
| 评审人指出未处理并发重复核销 | 无需处理 | “并发控制在网关层已做幂等，本接口不重复实现，附幂等配置位置。” | 无代码修改，回复中附配置路径 | 评审人确认后关闭 |
这个例子里，四条反馈分别走了四种处置路径，但关闭条件一致：有回复、有结论、有证据。遗留项没有混在评论里不了了之，而是单独登记了跟进人和时间，合入者据此判断本次合入不受影响。
用工作项承载反馈处理流程
评论散落在合并请求里时，合入前逐条核对容易遗漏，尤其是讨论类反馈跨天才有结论的情况。把每条反馈登记为工作项，可以让类型、负责人、状态和验证证据集中在一处，合入前按状态筛选即可。
工作项建议包含以下字段：反馈来源（合并请求编号与评论位置）、反馈类型（四类之一）、负责人、状态、处置动作、验证证据（提交编号或测试记录）、关联需求或缺陷、遗留项跟进人与时间。反馈条目通过合并请求编号与代码提交关联，通过关联需求字段与业务背景关联，回看时能同时看到“为什么改”和“改了什么”。
| 状态 | 进入条件 | 责任角色 | 离开条件 |
|---|---|---|---|
| 待处理 | 反馈已登记并分类 | 作者 | 作者开始回复或修改 |
| 处理中 | 作者已回复处置计划 | 作者 | 修改提交或讨论结论形成 |
| 待确认 | 修改已提交或结论已回填 | 评审人 | 评审人确认解决或退回 |
| 已关闭 | 评审人确认回复与落地均满足 | 评审人 | — |
ONES 可以承载这类反馈工作项：在项目内建立反馈类型的工作项，用自定义字段记录反馈来源、类型和验证证据，用状态流转对应待处理到已关闭的过程，并通过关联关系挂到对应的需求与代码提交记录上。合入前，合入者按“状态不等于已关闭且类型为必须修改或需要讨论”的条件筛选，即可得到阻塞项清单。评审中形成的通用结论，可以整理到团队文档或知识库条目中，并在工作项里留下链接，供后续评审参考。
工具承载的是记录和检索，分类标准和关闭条件仍需团队事先约定并写进评审规范。工具上线前先把四类定义和阻塞规则定下来，否则工作项只会把混乱的状态记录得更清楚。
完成检查：合入前的反馈处理核对
合入前由合入者按以下清单逐项核对，全部通过再执行合入。清单可以做成合并请求模板中的勾选项，也可以作为工作项筛选条件的补充。
- 所有反馈是否已分类并指派负责人，是否存在无类型的“待定”评论。
- 必须修改项是否已提交修改，并附有测试或验证说明，评审人是否已确认。
- 需要讨论项是否已有明确结论；未解决的，是否已登记为遗留项并写明跟进人和处理时间。
- 建议采纳项与无需处理项是否都有作者回复，回复是否说明了采纳、暂不采纳或无需处理的理由。
- 每条已关闭反馈是否同时满足“已回复”和“结论已落地”，是否存在只回复未修改或只修改未回复的情况。
- 遗留项是否已进入待办列表，是否与本次合入范围明确区分。
清单核对发现阻塞项未清零时，合入者退回给作者并注明具体条目，不自行判断“影响不大”而放行。核对通过的记录随合并请求保留，作为本次变更评审闭环的依据。
常见问题
评审人提出的意见作者不认同，应该怎么处理？
先在回复中说明不认同的具体理由，比如指出评审人看的是旧版本代码、建议超出本次变更范围，或设计取舍已有其他约束。分类的最终定性由评审人确认，作者说明后请评审人更新类型标签，避免同一问题在后续评审中反复出现。涉及设计取舍的，按需要讨论类组织相关角色形成结论，结论回填到同一条评论下。
讨论类反馈一时定不下来，本次还能合入吗？
可以，前提是把它登记为遗留项，写明跟进人和处理时间，并与本次合入范围明确区分。团队需要事先约定讨论类反馈的合入规则：合入前必须有结论，或已登记遗留项。合入者按这条规则核对，遗留项已登记且不影响本次变更的，可以放行；没有结论也未登记的，退回作者补充。
反馈处理需要留哪些记录，事后回看才查得到？
建议与代码托管平台绑定留存：评论保留在原合并请求下，修改通过提交记录关联，验证说明写在对应评论的回复中。需要长期跟踪的讨论结论，另存到团队文档或需求条目，并在评论里注明存放位置。若用工作项承载，记录反馈来源、类型、负责人、状态、处置动作和验证证据，回看时能同时看到“为什么改”和“改了什么”。
评审人提完意见后长时间不确认，反馈一直悬着怎么办？
在团队规则中约定评审人的确认时限，例如作者回复后一到两个工作日内确认。超过约定时间未确认的，由合入者提醒，或按团队规则升级给模块负责人处理。这个机制针对的是反馈悬置，让每条评论最终进入已关闭或已升级状态，不涉及评审等待时长的度量。
团队刚开始推行这套流程，应该先定什么？
先定两件事：四类反馈的定义和阻塞规则。把必须修改、需要讨论、建议采纳、无需处理的判断依据写进评审规范，并明确哪类阻塞合入、哪类需要登记遗留项。规则确定后再考虑用工作项承载，否则工具只会把混乱的状态记录得更清楚。流程运行一段时间后，再根据实际争议点补充典型例子。
