PR流程：Code Review

可视化演示

展示Review关注点清单逐项审查，建设性反馈与评论礼仪，以及PR从提交到审查、批准、合并的完整流程。

评审定位：合入前的同行品尝

共享餐厅里没有谁做的菜可以跳过试吃直接上菜单。这不是不信任厨师，而是因为做菜的人容易陷入自己的火候判断，旁观者却能看到更真实的问题。Code Review 的定位完全一样：它是合并到主分支之前的“试吃会”，是 PR 流程中最重要的质量保障环节。

在一个开源项目或团队仓库中，作者完成代码只是完成了“下锅”。把分支推上来、发出 Pull Request，相当于把菜端到试吃台。评审者阅读 diff，在脑子里运行这些代码，像用舌头感受咸淡一样，从多个角度判断这道菜是否达到上菜单的标准。这个环节除了发现 bug，还承担“团队共识”的作用：评审者看设计是否与已有架构协调，作者通过回复评论解释设计意图，代码规范、边界处理、测试要求都在一次次评论中沉淀为团队默契。

可以用一个简单的指标衡量评审的产出：

小艾第一次收到 review 时觉得被冒犯，后来才明白，正是因为有人认真品尝，她的菜才能从“能吃”变成“好吃”。

关注点清单：五感一起上

试吃员不会只吃一口就说“可以”，而是看色泽、闻香气、尝味道、感受口感、留意餐具卫生。Code Review 也需要一张清单，把模糊的“看看代码”变成可执行的五感检查。

评审者对照清单逐项确认：功能正确，代码在给定输入下是否得到预期结果，边界条件是否覆盖；代码设计，模块边界、依赖方向、扩展性是否符合项目风格；可读性强，命名是否表达意图，函数是否过长，注释是否解释“为什么”而不是“是什么”；测试与安全，新增逻辑是否有单元测试覆盖，是否引入注入、越权、性能隐患。

一份清晰的关注点清单，能让评审不偏科。很多团队把它写进 CONTRIBUTING 文档或 PR 模板，作者提交前先自检，评审者收到后按清单逐项打勾。“能跑”只是及格，可维护、可测试、可观测才是生产级标准。用一个覆盖率公式来理解：

小艾后来把团队清单贴在工位，每次发 PR 前先自测一遍，评审时收到的阻塞评论明显变少了。

评论礼仪：让反馈像试吃建议

试吃员不会说“你这菜真难吃”，而会说“这道菜稍微咸了一点，减少半勺盐会更清爽”。同样的意思，表达方式决定作者是反思还是抗拒。Code Review 的评论礼仪，本质是让技术讨论保持在专业轨道上。

具体做法并不复杂：先肯定做得好的地方，比如“这个边界处理得很稳”；评论时用“这段逻辑”而不是“你”；用提问代替命令，例如“这里如果输入为空会导致异常吗？”；控制评论数量，一次性给出整份清单，而不是每隔五分钟补一条，让作者疲于应付。

礼仪不是客套，而是效率。作者情绪稳定，才会认真回应每一条评论；评论聚焦代码，讨论才有边际。很多成熟项目会在文档里写明：评审者不在 PR 里进行人身评价，作者也不把不同意见理解为否定。建设性评论可以看作三部分的组合：

小艾在开源社区收到一条“这里可以写成 with 语句，避免资源泄漏”的评论，比“你代码错了”更容易接受。

批准流程：从试吃到签字上菜单

试吃会有三个结果：可以直接上、改一下再上、这道菜重做。GitHub 和 GitLab 的 review 流程也类似，评审者可以给出三种标签：评论（Comment）、请求修改（Request changes）、批准（Approve）。没有“删除仓库”这种极端标签，也没有“批准后再骂两句”的模糊地带。

作者看到评论后要逐条回复：是解释设计意图，还是修改代码？非阻塞评论可以标记为“后续处理”，但阻塞评论必须解决。阻塞评论通常用 blocking 或“Request changes“标签显式标记，代表”不合入，因为继续推进会把风险带进主分支”。只有达到最少评审人数、且没有未解决的阻塞评论时，维护者才会点 Approve 并合并。

如果两位评审者意见冲突，不要私下僵持。邀请第三方评审，或依据团队规范、项目文档裁决。争议升级不是伤面子，而是流程的保险阀——就像餐厅里主厨和试吃员吵起来时，店长会拿着标准食谱来定夺。合并条件可以写成：

小艾的 PR 从第一次“请求修改”到第二次“批准合并”，像一道菜从返工到端上菜单。审批记录本身就是菜品的履历。

建设性反馈：把“不好吃”说清楚

只说“不好吃”的试吃没有任何帮助。建设性反馈要像美食评论一样，指出是哪一口、什么体验、可以怎么改。很多资深评审者会使用“现象—影响—建议—例子”的结构，让评论有信息量也有温度。

现象：在哪个文件哪一行，代码做了什么。影响：可能引发什么 Bug、性能问题或维护困难。建议：给出可选方案，比如换 API、加测试、提取函数。例子：附上最小复现或伪代码，让作者一眼看懂。四者缺了任何一块，评审者都可能陷入无休止的“为什么”追问。

反馈不是命令。如果作者不同意，把“你必须改”换成“我建议这样改，你怎么看？”让作者拥有最终决定权，反而更容易达成共识。毕竟作者对自己的代码上下文理解更深，评审者提供的是一条线索，而不是最终答案。好评论的公式如下：

有一次 reviewer 给出了最小复现示例，小艾立刻理解了问题。从此她也学着把评论写得像食谱，步骤清晰、可执行、不夹带情绪。

学习成长：让每次试吃都变成课程

在餐厅后厨，新厨师最快的学习方式不是只看自己的菜，而是尝遍老师傅的菜、读他们的笔记。Code Review 也是最好的真实课堂，因为每一份 PR 都是活教材，每一次 review 都是免费的一对一辅导。

持续学习可以从四件事开始：阅读优秀 PR，到知名开源项目看 merge 过程，注意维护者为什么提意见、作者怎么回应；复盘评论，每月重看自己收到的 review，把高频问题记下来；沉淀清单，把团队常犯的坑写进 CHECKLIST，下次评审快速对照；结对评审，新手跟着老手一起看 PR，边看边问，把隐性知识变成显性经验。

从评审者视角看，写评论是在训练表达；从作者视角看，被评审是在训练谦逊与反思。经验不是吃过的 PR 数量，而是每次 review 后沉淀下来的清单。可以用迭代公式表示这个过程：

小艾把第一年收到的 60 条评论整理成一份自己的《避坑清单》，后来她成了团队里最受欢迎的 reviewer。

生产实践：让评审跑得比做菜快

试吃会如果拖三天，客人早就饿走了。生产环境中的 Code Review 最怕慢：PR 越堆越大，评审者越不想看；评审者响应越慢，作者越容易同时开一堆 PR，反而让质量更差。因此工程化实践的目标是缩短评审周期、降低认知负担。

四条关键实践：小步 PR，一个 PR 只做一件事，尽量控制在 200 行左右，reviewer 更容易给有效反馈；及时评审，评审者每天留出固定时间处理 PR，避免堆积；自动化辅助，让 lint、format、单测、CI 静态分析先跑一轮，人工聚焦设计；度量改进，记录首次响应时间、修改轮次、合并耗时，每月复盘数据并调整流程。

自动化不能替代人，但能把人从“格式检查”这类低级劳动中解放出来。生产级评审是“机器做初筛、人类做决策”的分层防线。团队也可以约定 SLA，例如“工作日 4 小时内给出首次评论”，把评审当作用餐高峰的翻台率来管理。评审周期可以拆解为：

小艾团队引入 CI 后，评审时间从两天缩短到四小时。她说，机器负责擦桌子，人才能专心品菜。

AI 应用场景

Python 演示

"""一个极简 Code Review 助手：用清单记录评审意见，并给出批准/请求修改结论。"""class ReviewHelper:    def __init__(self, author, pr_title):        self.author = author        self.pr_title = pr_title        self.comments = []        self.blocking = []     def add_comment(self, file, line, concern, severity, suggestion):        self.comments.append({            "file": file,            "line": line,            "concern": concern,            "severity": severity,            "suggestion": suggestion        })        if severity == "block":            self.blocking.append(concern)     def summary(self):        if self.blocking:            msg = "请求修改：请先解决 %d 个阻塞问题：" % len(self.blocking)            return msg + "、".join(self.blocking)        if self.comments:            return "批准合并：保留 %d 条非阻塞建议，可后续优化。" % len(self.comments)        return "批准合并：未发现问题。"  if __name__ == "__main__":    r = ReviewHelper("小艾", "修复模型推理时的内存泄漏")    r.add_comment("infer.py", 42, "手动 close 可能遗漏", "block", "改用 with 语句")    r.add_comment("test_infer.py", 7, "缺少空输入用例", "suggest", "补充边界测试")    print(r.summary())

1. self.comments.append({...})把每条评审意见以结构化字典存入列表，方便追溯。
2. if severity == "block":只有阻塞问题才加入 blocking 列表，非阻塞建议不阻止合并。
3. if self.blocking:有阻塞问题就返回请求修改，这是批准流程的核心判断。
4. "请求修改：请先解决 %d 个阻塞问题：" % len(self.blocking)明确告诉作者必须处理哪些项。
5. if __name__ == "__main__":让脚本既能被导入，也能直接运行演示。

常见误区

面试题