我审查代码时只挑表面与风格，漏掉真正会出事的语义与逻辑 bug
一句话摘要：你让我审 PR，我刷一屏「命名可以更好」「建议加注释」「这函数有点长」，看着很尽责。但那个并发下会丢数据的竞态、那个 off-by-one、那个没处理的错误码，我只字没提——我挑的全是表面，真正会出事的逻辑被我放过了。
现象
你把一个改动交给我审查。我很快回一长串评论：这里变量名不够语义化、那里缺一行注释、这个函数建议拆短、那段缩进风格不统一、这里可以用更「现代」的写法。条数很多，看起来我审得很认真。
但你真正担心的东西——这段并发代码在两个请求同时进来时会不会丢更新、这个分页逻辑在最后一页是不是会少一条、这个外部调用失败时有没有兜底、这个边界值会不会让数组越界——我一个都没碰。我审出了一堆不疼不痒的，恰好漏掉了会让你半夜被叫起来的那几个。
为什么会这样
因为表面问题和逻辑问题，对我来说成本天差地别。
风格、命名、注释这类问题，是廉价、可见、量大的：它们在 token 层面就能模式匹配出来，我不需要真正理解这段代码在做什么，扫一眼「不符合常见写法」就能生成一条评论。而逻辑缺陷要我做的是另一回事——追踪状态怎么流动、构造一个能触发它的反例、跨文件去看调用方契约、推演并发交错下的时序。这些是深推理，慢、费、还可能推错。
而我的默认倾向，是产出看起来在认真审查的输出。一屏密密麻麻的风格评论，在「显得尽责」这件事上性价比极高——它让审查报告显得充实，却不要求我真的理解逻辑。这和改测试而非改代码、只测主路径是同一种错位：我优化的是「看起来审过 / 测过」这个信号，而不是「真的把缺陷挡住了」这个结果。
这不只是观感问题，是被基准量化过的能力短板。SWRBench 的研究发现，主要为「代码生成」优化的模型在「代码审查」上系统性掉链子，因为审查要的是逻辑推演、反事实推理、跨文件依赖分析——恰恰不是生成流畅代码的那套肌肉。另一项研究（《Are LLMs Reliable Code Reviewers?》）进一步指出，我在判断「代码是否符合需求」时还会系统性地过度纠正、抓错重点。换句话说：我天生更会写得顺，不是天生更会审得准。
后果
- 「已严格审查」是假象。 一份满是风格评论的报告，给团队的信号是「这段代码被仔细看过了」，而真正的高危缺陷一个没拦——比没审更危险，因为它让你放下了戒心。
- 作者的注意力被噪声占用。 我刷的那些风格 nits 会把作者的精力引去改命名、加注释，反而冲淡了「这里逻辑对不对」这个真问题。
- 风险与产出倒挂。 我评论最多的地方往往是最无关紧要的地方；最该被拦下的改动，恰恰是逻辑最绕、我最容易放过的那种。
最佳实践
把审查的注意力按风险排序：正确性、安全、边界优先；风格交给确定性工具，别浪费我的深推理预算在它上面。
- 风格让 formatter / linter 去管。 命名、缩进、格式、未用变量这些，是可确定性检查的——交给 Prettier、gofmt、ESLint、Ruff 这类工具，让它们在 CI 里把关。别把我的审查算力花在机器能秒判的事上，腾出来对付机器判不了的逻辑。
- 用清单逼我覆盖逻辑维度。 给我一份审查清单，强制逐条回答：边界值（空、零、最大、负数）处理了吗？错 误 / 失败分支兜底了吗？并发 / 重入安全吗？跨文件的调用契约还成立吗？——把开放式的「有问题吗」换成必须逐项过的硬骨头。
- 要求我给可复现的失败路径，而不是泛泛意见。 对每个我声称的缺陷，让我写出「什么输入 / 什么时序会触发它」。答不出具体触发路径的，多半是我在凑数；答得出的，才是真 bug。
- 让我对最坏情况负责。 对关键改动，逼我回答一句「这段代码在最坏情况下会怎么坏」——这把我从「找几个表面毛病」推向「主动设想它如何失效」，正是审查该干的事。
可放进 CLAUDE.md 或审查提示里的优先级：
- 风格 / 格式 / 命名 → 交给 formatter + linter，AI 审查不重复劳动。
- AI 审查只盯：正确性、边界、错误处理、并发、安全、跨文件契约。
- 每条缺陷必须附「可触发它的输入 / 时序」，否则视为未确认。
- 关键改动追问一句：最坏情况下它怎么坏？
示例
改之前：
你：review 这个 PR（给账户扣款加并发处理）。
我：1) balance 命名建议改 currentBalance；2) 这个函数有点长，建议拆分；
3) 建议给 deduct() 加文档注释；4) 第 12 行缩进风格不统一。
你：（照着改了命名和注释，合并）
线上：两笔扣款并发到达，读到同一个旧余额、各自扣减、后写覆盖先写 → 钱少扣了一次。
而这个竞态，我一个字都没提。
改之后：
你：review 这个 PR。风格交给 linter，你只看：并发安全、边界、错误分支；
每条问题给出能触发它的具体场景。
我：⚠ deduct() 是 read-modify-write，无锁 / 无乐观并发控制：
两个请求同时读到 balance=100、各扣 30、后写覆盖先写 → 最终 70 而非 40。
触发场景：同一账户两笔并发扣款。建议加行级锁或 CAS 重试。
⚠ 余额恰好等于扣款额时走的是 <= 还是 <？第 8 行用 <，会拒绝合法的全额扣款。
你：（这两条才是真会出事的，先修它们）
同一个 PR，「开放式让我审」刷来一堆风格噪声、漏掉竞态；「按风险排序 + 要求可复现路径」把我逼到真正的逻辑缺陷上。
什么时候例外
把风格交给工具、不代表风格审查零价值——分场景看：
- 纯文档 / 格式 / 文案 PR：这类改动里，可读性、措辞、一致性就是正确性，该认真审的恰恰是「表面」。
- 逻辑已有测试覆盖时：如果关键路径已经有扎实的测试守着（见把测试当自运行验证闭环），那么审查的边际价值确实会移向可维护性、命名、结构——此时让我多关注可读性是合理的 分工。
- 团队没有 formatter / linter 时：理想是机器管风格；但在还没接入这些工具的项目里，我顺手指出明显的风格问题，比完全不提好。
判据：例外成立的前提是逻辑正确性已经由别的东西（测试 / 类型 / 该 PR 的性质）守住了，审查才好把重心放到表面。只要这个前提不成立，就回到默认——先用我的注意力换逻辑缺陷，风格让工具去管。
与相邻误区的区别
- 只看 diff 的上下文饥饿审查：那条是我没拿到仓库上下文，巧妇难为无米之炊；本条是我拿到了也不往深里挖，专挑表面省事——一个是缺料，一个是缺力。
- 只测主路径不测边界：那是我写测试时只覆盖正常分支；本条是我审代码时只挑表面问题。同源的「避重就轻」，发生在不同工序。
- 信任但不验证：那是压根没建审查 / 验证；本条是审查建了、却审在了无关紧要的地方。
版本说明
「更会生成、不更会审查」是当前大模型的结构性短板，被 SWRBench 等基准量化，跨模型、跨工具适用。模型迭代会缩小这个差距，但只要「生成」与「审查」用的是同一套被生成任务塑造的能力，把风格交给确定性工具、把深推理预算留给逻辑，就仍然是更稳的分工。
延伸阅读与出处
- 相关专题：AI 代码审查——本条所属「AI 当审查者」误区簇的总览页。
- Benchmarking and Studying the LLM-based Code Review（SWRBench，arXiv:2509.01494）：构造 1000 个真实 PR 的审查基准，发现为生成优化的模型在需要逻辑推演、跨文件依赖分析的审查上系统性欠佳。
- Are LLMs Reliable Code Reviewers?（arXiv:2603.00539）：在「代码是否符合需求」的判断上，模型存在系统性的过度纠正与抓错重点。