北京
写代码的方式随便你。用AI、开十个并行代理、纯手写，都行。但有种说法挺奇怪：既然写代码快了，合并的门槛也该降低？这说不通。
我敢打包票，花10到15分钟认真看同事的PR，绝对值。不光是为了眼前这一处改动，更是为了你那每天新增几万行、飞速演进的代码库。听我说完。
别没看就LGTM
大家都见过：500行的PR，两分钟就收到LGTM。没人真读过，但它已经进了你的代码库。下次你用AI工具，参考的就是这段代码。
这就引出经典的"破窗效应"：烂代码越堆越多，AI工具照着同一堆混乱学（于是新写的代码，你猜怎么着，也是垃圾）。
AI完全能写好代码，但取决于两点：你给的上下文，以及代码库提供的参考范例。我们说说第二点：怎么保证参考质量。
第一步：第一次做新东西时，慢下来，花时间做对。觉得稳了，找团队提意见。迭代到大家满意为止。不用追求完美，"差不多了"就行。
第二步：下次你或同事做类似的事，模式已经有了，AI工具有了好参考。达到同样质量门槛，时间大幅缩短。PR评审？轻松过。
恭喜！即使认真评审，你的PR周转时间（从提交到获批）大致没变。
代码评审是最便宜的知识传递
AI让人效提升，团队越来越小。以前要5到6个工程师的项目，现在2个就够——一个后端、一个前端。这很好，但也导致知识集中，对这些开发产生依赖。
他们离职怎么办？生病了怎么办？（经典的"巴士因子"问题）
好的PR评审正好解决这个问题。它们帮团队分散代码库知识。评审确保多几个人至少对这段代码有基本概念，换负责人或招新人时都更容易。
这只是"共享理解"的明显好处之一。还有更多：
如果你是新人，PR评审简直是救星（声明一下——我是无神论者，这话不是随便说的）。除了帮你理解代码，评审还能让你摸清团队的思路：这里什么算"够好"、他们能接受什么权衡、等等。
而且双向有效——新眼睛看老模式，常能发现团队已经视而不见的问题。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
