代码评审要真正发挥作用，需要把一次代码提交变成有输入、有检查项、有结论、有记录的合入流程。提交者说明改了什么、影响哪里、做过哪些自测；评审者按约定清单逐项检查；合入负责人给出通过、修改或拒绝的明确结论；意见逐条关闭后才允许合入。下面按提交到合入的顺序，给出步骤表、检查清单、角色分工、完整示例和完成检查表。
要点总览（TL;DR）
- 代码评审要落地，需要把一次提交变成有输入、有检查项、有结论、有记录的合入流程，四个阶段各有明确的完成标志。
- 评审检查项按正确性与边界条件、可读性、测试证据、安全与依赖风险、可运维性分类，按变更类型裁剪到十到十五条以内。
- 提交者负责变更说明、自测记录和意见响应，评审者给出具体意见与风险标注，合入负责人裁定分歧并把关合入。
- 意见分歧以变更目标和风险为依据讨论，建议类意见允许说明理由后关闭，必须修改项关闭后才能合入。
- 判断流程是否落地，可抽查已合入变更能否还原变更说明、意见关闭状态和最终结论。
代码评审的核心步骤：从提交到合入
一次代码评审可以拆成四个阶段：提交前准备、评审发起、评审执行、结论与合入。每个阶段都要有明确的输入、动作、输出和完成标志，否则评审容易变成“看一眼就点通过”，或者在评审队列里长期挂起。
| 阶段 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 提交前准备 | 已完成的代码变更、关联需求或缺陷 | 提交者写变更说明，标注影响范围，附自测证据；控制单次变更规模，把重构与功能改动分开 | 变更说明、影响范围说明、自测记录 | 说明能让评审者不看代码就大致判断改动目的和风险面 |
| 评审发起 | 变更说明与自测记录 | 选择评审者（至少一名熟悉该模块的人），设定评审范围与期望完成时间，标注需要重点看的文件 | 评审任务、评审者名单、时限 | 评审者已确认接收，评审范围无歧义 |
| 评审执行 | 代码差异、变更说明、检查清单 | 评审者按检查项逐条给出意见，区分“必须修改”和“建议优化”，标注风险点 | 评审意见列表、风险标注、结论建议 | 每条意见有明确指向（文件、行、问题、期望），无笼统评价 |
| 结论与合入 | 评审意见、修改后的代码 | 合入负责人给出通过、修改或拒绝结论；修改后复审，逐条关闭意见；确认关闭后合入 | 评审结论、意见关闭记录、合入记录 | 所有必须修改的意见已关闭，结论已记录，代码已合入目标分支 |
三种结论的关闭条件要提前约定：通过指没有必须修改的意见，可以直接合入；修改指存在必须修改项，修改后需复审并关闭意见才能合入；拒绝指变更方向或方案不成立，需要重新设计后再提交，拒绝理由要写清楚，避免提交者反复猜测。
评审时限建议按变更规模设定，例如小变更一个工作日内给出首轮意见，大变更约定分批评审。时限的作用是让评审进入排期，而不是无限期等待。
评审检查项怎么定：一份可复用的清单
检查项的作用是把评审从凭经验判断变成按清单核对。清单不宜追求大而全，按变更类型裁剪比堆几十条更有用。下面按五类给出基础检查项，并说明适用场景。
| 类别 | 检查项 | 适用变更类型 |
|---|---|---|
| 正确性与边界条件 | 主流程是否符合需求；空值、越界、并发、异常分支是否处理；错误返回是否被调用方正确处理 | 所有变更，逻辑改动重点检查 |
| 可读性与结构 | 命名是否表达意图；函数职责是否单一；重复逻辑是否抽取；注释是否解释“为什么”而非复述代码 | 所有变更，重构类重点检查 |
| 测试与验证证据 | 是否补充或更新了测试；测试是否覆盖新增分支和边界；自测记录是否可复现 | 功能变更、缺陷修复 |
| 安全、性能与依赖风险 | 输入是否校验；权限判断是否完整；是否引入新依赖及其版本、许可证；是否有明显性能退化（循环内查询、大对象拷贝等） | 涉及外部输入、依赖升级、数据量大的变更 |
| 可运维性 | 日志是否足够定位问题；配置项是否有默认值和说明；失败时是否可回滚 | 上线相关变更 |
裁剪原则可以按变更类型执行：缺陷修复重点看根因是否找对、是否有回归测试；新功能重点看需求覆盖和边界条件；重构重点看行为是否保持不变、测试是否先行；依赖升级重点看版本兼容和影响面。纯文档或配置注释类变更可以只保留可读性检查，避免用完整清单拖慢小改动。
检查项数量建议控制在十到十五条以内，超出后评审者容易只勾选不细看。清单本身也应定期复盘：某类问题反复出现在评审意见里，就把它补进清单；某条检查项长期无人使用，就考虑删除或合并。
角色与交付物：谁提交、谁评审、谁拍板
评审责任模糊通常表现为：提交者以为评审者会发现问题，评审者以为合入负责人会把关，结果谁都没对某条风险负责。把角色和交付物写清楚，可以消除这类空档。
| 角色 | 职责 | 交付物 | 完成标准 |
|---|---|---|---|
| 提交者 | 准备变更、发起评审、响应意见、修改并复审 | 变更说明、影响范围、自测记录、意见响应记录 | 每条意见有回复（接受并修改、说明理由、提出替代方案），修改后主动请求复审 |
| 评审者 | 按清单检查、给出具体意见、标注风险、给出结论建议 | 评审意见列表、风险标注、通过或修改建议 | 意见指向具体位置和问题，区分必须修改与建议优化，在约定时限内完成 |
| 合入负责人 | 裁定分歧、确认意见关闭、给出最终结论、执行或授权合入 | 最终结论、意见关闭确认、合入记录 | 合入前确认无未关闭的必须修改项，结论和理由已记录 |
记录与留痕是三个角色共同的产出：评审结论、每条意见的处理状态、分歧的裁定理由，都应随变更一起保留。留痕的目的不是追责，而是让后来的人能查到“当时为什么这样改”，也为复盘提供依据。
小团队里评审者和合入负责人可能由同一人担任，这时仍建议把“检查”和“拍板”两个动作分开记录，避免自己审自己时省略检查过程。
一个完整示例：一次功能变更的评审过程
以下为演示情景，用于说明流程如何走通。
变更背景与提交材料。某订单服务需要新增“取消订单时释放优惠券”的功能。提交者在变更说明中写明：关联需求为“取消订单释放优惠券”，影响范围为订单取消接口和优惠券服务调用，自测覆盖了正常取消、重复取消、优惠券已过期三种情况，并附上测试记录。变更涉及两个文件、约一百二十行改动。
评审意见的类型与表达方式。评审者给出三类意见：一是必须修改——重复取消时优惠券可能被重复释放，需要加幂等判断，并指出具体方法和行号；二是建议优化——释放逻辑可以抽成独立方法，便于后续复用；三是风险标注——调用优惠券服务增加了取消接口的耗时，建议确认超时设置。每条意见都写明了问题和期望，没有出现“这里不太好”这类笼统评价。
修改、复审与意见关闭。提交者接受幂等判断意见并补充了测试；对抽取方法的建议说明当前只有一处调用、暂不抽取，评审者认可后将该条标记为已关闭；对超时风险补充了配置说明。修改完成后提交者请求复审，评审者确认必须修改项已解决，逐条关闭意见。
合入结论与记录。合入负责人核对意见关闭状态，确认无未关闭的必须修改项，给出“通过”结论并合入。记录中保留了变更说明、三类意见及处理结果、复审确认和合入时间，后续排查优惠券问题时可以直接查到这次变更的决策依据。
这个例子中值得注意的两点：分歧通过“变更目标加风险”来讨论，而不是靠职位高低决定；建议类意见允许提交者说明理由后关闭，不必全部照改，但必须留下回复。
评审记录如何承载：用工作项与文档串起流程
评审记录如果只散落在聊天记录和代码平台评论里，复盘时很难还原完整链路。更稳妥的做法是把评审挂到工作项上：需求或缺陷是源头，评审任务是从它派生的工作项，代码提交和评审结论作为记录附着在任务上，状态随评审进展流转。
具体承载方式可以按这条链路设计：需求或缺陷工作项进入“待开发”，提交者完成变更后创建或更新评审任务，填写变更说明和自测记录；评审者在任务中留下意见，必须修改项作为待办跟踪；修改完成、意见关闭后，任务状态流转到“待合入”，合入负责人确认结论后流转到“已合入”。这样，需求、评审任务、代码提交和结论之间保持关联，抽查时从一个工作项就能看到完整过程。
ONES 在这条链路中可以承担需求、任务与状态流转的承载：把评审任务与需求或缺陷关联，在任务中记录评审结论和意见关闭状态，通过状态流转标记待评审、待合入、已合入等阶段，使评审记录随工作项保留、可追溯。具体字段和流程配置需按团队实际使用的产品版本确认。
记录内容建议至少包含：变更说明、评审者名单、意见列表及关闭状态、最终结论、合入时间。分歧裁定的理由也值得单独记一条，它是后续复盘最有价值的信息。
完成检查：评审流程是否真的跑起来了
流程写在文档里不等于在跑。下面这份检查表可以逐项核对，建议每月抽查若干次已合入的变更。
| 检查项 | 核对方式 | 通过标准 |
|---|---|---|
| 每步是否有明确输入与输出 | 抽查变更记录，看是否有变更说明、自测记录、评审意见、结论 | 四个阶段的产物都能找到，缺失项有合理说明 |
| 评审意见是否有关闭记录 | 检查意见列表的处理状态 | 必须修改项全部关闭，建议项有回复或关闭理由 |
| 合入前是否确认结论 | 对比合入时间与结论记录时间 | 结论先于合入，且由合入负责人确认 |
| 流程是否可被抽查与复盘 | 随机抽取一个已合入变更，尝试还原全过程 | 能从工作项追溯到需求、评审意见和结论 |
| 检查清单是否在使用 | 看评审意见是否覆盖清单类别 | 意见能对应到清单中的类别，而非只有风格评论 |
抽查中发现的问题应回到流程本身修正：如果意见经常没有关闭记录，就检查状态流转是否缺少“意见关闭”这一环；如果评审意见集中在格式问题上，就调整清单权重，把正确性和测试放到更前的位置。流程稳定运行一段时间后，再用评审规模、意见关闭率和返工情况做趋势观察，判断流程是在持续起作用，还是逐渐退化为形式。
常见问题
小团队人手少，评审者和合入负责人由同一人担任，流程怎么简化又不流于形式？
可以由同一人兼任，但建议把“检查”和“拍板”两个动作分开记录：先按检查清单逐项留下意见，再单独记录最终结论和理由。这样即使自己审自己，也能看出检查过程是否发生。变更规模较小时可只保留正确性、测试证据两类检查项，变更说明和自测记录仍然要写，否则后续复盘无从查起。
评审意见出现分歧，提交者和评审者各执一词时怎么处理？
把讨论拉回到变更目标和风险上：这项改动要解决什么问题，两种方案各自带来什么风险。能通过补充测试或数据说明的，用证据决定；无法达成一致的，由合入负责人裁定并记录理由。建议类意见允许提交者说明理由后关闭，必须修改项则要修改并复审。分歧的裁定理由值得单独留一条记录，它是后续复盘最有价值的信息。
紧急修复需要快速上线，能不能跳过评审直接合入？
可以约定紧急通道，但要把条件写清楚：例如仅限线上故障修复、影响范围明确、有回滚方案，并指定一名评审者做快速检查，重点看正确性和回滚可行性。紧急合入后应补做完整评审或复盘，把遗漏的检查项补上。紧急通道使用频繁，说明常规评审的时限设置或变更规模控制需要调整，应回到流程本身修正。
评审记录放在代码平台评论里就够了，还需要关联到工作项吗？
代码平台评论能承载具体行的讨论，但复盘时往往需要从需求或缺陷出发还原整条链路。把评审任务挂到需求或缺陷工作项上，记录变更说明、意见关闭状态和最终结论，状态随评审进展流转，抽查时从一个工作项就能看到完整过程。ONES 可以承担需求、任务与状态流转的承载，具体字段和流程配置需按团队实际使用的产品版本确认。
检查清单用了一段时间，评审意见还是集中在格式和命名上，怎么调整？
先看清单权重：把正确性、边界条件和测试证据放在清单前部，格式类检查交给自动化工具处理，减少人工评审在风格问题上的消耗。再看意见分布，如果某类问题反复出现，把它补进清单并明确检查方式；某条检查项长期无人使用，就删除或合并。清单本身应定期复盘，保持十到十五条以内，避免评审者只勾选不细看。
