AntheaLaffy 代码评审
主线：评审是异步地「谈论代码」——有人提出改动，其他人思考它、像头脑风暴一样讨论好在哪、坏在哪。它关乎这段代码在此项目、此目的、此刻是否合理，与写代码的人无关。评审不是官僚负担：它在代码入库前抓 bug、在团队内传播知识，也是最快的学习方式之一——既能看到要避免的错误，也能学到好模式。新鲜眼睛能抓到资深开发者忽视的东西。commit 拆分质量（git add -p）是评审的常规检查项，标准见 writing-for-readers。
给出评审
- 评审代码，不评审人：「这个函数读起来费解」而非「你写的代码很难懂」。评审体验决定贡献者是否愿意回来——每次开口都是挑错，没人想再来第二次。
- 给可操作的建议：「这里能否改用配置 dataclass，而不是全局变量？这样测试可以并行跑」而非「别用全局变量」。
- 提问而非命令：「如果这里 X 为 null 会怎样？」而非「把 null 情况处理掉」——促进讨论，也让对方自己意识到问题。
- 解释为什么：「这里用常量吧」不如「用常量，方便按环境调整超时时间」。
- 区分阻断性问题与建议：说明哪些必须修改、哪些只是偏好；非阻断的按惯例标
nit:，让对方能按优先级分诊。 - 评论别泛滥：一百条评论里，可能一半在头五十条改完后已经失效；对方也不知道哪条最重要。重复出现的模式只评第一处：「这是本仓库的变量命名规范，请在全代码库统一使用」，而不是逐行炮轰。
- 肯定做得好的地方：指出巧妙的解法或干净的实现——结对编程时如果每次开口都是说对方做错了，那会是很糟的体验，评审同理。它让评审更平衡，也让对方更有动力改你要求的部分。
- 知道何时收手：盯住大问题，小问题必要时自己事后顺手清理。
- AI 只能做第一道筛查，不能替代人工评审：LLM 做的是 zero-context review——只看 diff 和描述。而评审真正重要的部分（这个改动对整体代码库、产品方向、版本策略是否是好主意？是不是还没准备好发 breaking change？）恰恰需要它没有的上下文；给它塞上下文也常常只是复述模式而非真正理解。AI 说没问题 ≠ 维护者会同意。
收到评审
- 「代码不是你本人」：审核者是在让代码更好，不是批评你。
- 不同意就提澄清问题——也许你能学到东西，或者他们能学到。
练习
学习材料在 exercises.md。
改编自 MIT The Missing Semester 课程 Lecture 8: Beyond the Code（讲义 + 口播稿，CC BY-NC-SA 4.0）：https://creativecommons.org/licenses/by-nc-sa/4.0/ · 课程站点：https://missing.csail.mit.edu/ · 讲座视频：https://www.youtube.com/watch?v=2DOEATfXT8k