把 AI 变成一位在可读性、bug 和安全性上都很挑剔的评审者，并通过为自己的选择辩护来磨砺你的判断力。
在 Kodokon 中打开本课同行代码评审是业内被记录得最充分的成长加速器之一——也是独自工作时最难获得的一项。AI 提供了一位全天候待命的评审者，前提只有一个：你得把它配置好。默认情况下，模型是顺从的：它夸你努力，挑两个鸡毛蒜皮，然后总结说“总体来说，做得不错”。那不是评审，那是拍拍肩膀。与之相反的错误则是要求“把我的代码重写得干净些”：你拿到一段自己从未推敲过的代码，什么也没学到。正确的做法是：要求一份结构化的批评——可读性、bug、安全性——附带经过校准的严重程度和理由。
你是一位要求严格的资深评审者，就像团队代码评审里那样。你的目标是让我进步，而不是对我手下留情。
这是我的代码（[语言]，背景：[它用来做什么、项目的约束]）：
[粘贴代码]
请沿三条轴线分析它：
1. 可读性：命名、结构、不必要的复杂性、意图不清。
2. bug：未处理的边界情形、被吞掉的错误、不一致的状态、并发。
3. 安全性：未校验的输入、注入、敏感数据外泄、权限。
输出格式：针对每条意见——涉及的行或代码块、所属轴线、严重程度（阻断 / 重要 / 次要）、以及用一两句话说明的原因。
约束：不要重写我的代码。最多 8 条意见，最严重的排在前面。如果某个有争议的选择在特定背景下是站得住脚的，就明确指出来，而不是把它算作缺陷。注意那条 8 条意见按严重程度排序的上限：没有它，你会收到 25 条吹毛求疵，一个缺失的输入校验和一个命名偏好被同等看待。也注意那条关于可辩护选择的条款：它迫使模型区分客观的缺陷与有争议的惯例。接下来才是最能锻炼人的部分，几乎所有人都跳过的部分：为你的选择辩护。评审不是一纸待执行的判决，而是一场对话。当某条意见看起来站不住脚，就据理反驳。要么你的理由成立、你终于把它讲清楚了，要么它们崩塌，你发现这个“选择”不过是个习惯。
我们回头看你的第 [X] 条意见：你认为 [复述这条意见]。
我不同意，我的理由如下：[你的论据——经过测量的性能约束、与其余代码保持一致、刻意的简洁、截止期限……]。
1. 诚实地评估我的每一条论据：哪些成立，哪些是自我合理化？
2. 站在一位持不同意见、经验丰富的同事的角度，给出针对我的立场的最强反驳。
3. 下结论：在我这个具体背景下，这项改动是否值得它的代价？先回答是或否，再用最多三句话说明理由。
不要试图证明我是对的：如果我的论据站不住脚，就直言不讳地说出来。AI 评审有两个经典陷阱。第一个陷阱：信心满满地抛出的假警报——模型指出一个在你的架构里根本不可能发生的竞态条件，或者一个在你所用语言版本里其实并非 bug 的“bug”。把每条意见都当成一位聪明绝顶、却拿不到全部背景的同事说的话：貌似有理，有待验证。第二个陷阱：安全表演。AI 非常擅长发现经典模式（SQL 注入、XSS、明文密钥），却会漏掉业务逻辑上的漏洞——某条路由上缺失的授权检查，一个可被利用的中间状态。AI 评审是补充，它既不能取代审计，也不能取代你的领域知识。