代码评审正在成为软件工程中最重要的决策环节，但它已经远远超出了“看diff”的范畴。过去我们默认代码评审是为了抓bug，可它真正的工作其实是品味、判断力，以及组织流程的把关：这真的是我们产品该有的东西吗？ 如今AI几分钟就能生成几千行代码，工程师根本不可能逐行审完。于是团队被夹在两个坏选项之间：跳过评审，冒险把劣质代码推到线上；或者坚持逐行审，结果自己变成瓶颈。这就是为什么关于“如何评审AI代码”的讨论总是原地打转——因为每个人争论的其实是代码评审的不同部分。 把逐行检查剥掉，代码评审仍然有三个团队必须依赖的职责。 第一，它是协作的场所。团队在这里共同决定什么东西应该进入产品。第二，它是对齐和知识共享的机制。每一次评审都在构建关于代码库变化和背后业务需求的共同上下文。这种上下文对人、对AI智能体都越来越重要，承载着产品和组织的制度知识、历史考虑。第三，它是验证：代码正确吗？能工作吗？风险是什么？ “代码只是媒介，评审才是我们行使判断力的地方，这依然重要。” 这三个工作不会因为代码由AI生成而消失。相反，它们变得更加重要，因为需要评审的代码量增长比评审人手快得多。代码评审从来就不只是“审代码”。这个名字还合适吗？代码是媒介，但评审是行使判断力的地方，它依然重要。 规划与评审正在融合。代码评审正是工程团队确认“我们有信心这就是正确方案”的收尾仪式。

打开网易新闻 查看精彩图片