人仔细看。我当时的第一反应是人力不够。后来想明白了不是人力的问题是人力被用在了效率最低的地方。Code Review 里有大量机械性的工作——找空指针、查边界条件、验证错误处理逻辑——这些事 AI 比人做得更专注、更不会因为赶时间而漏看。这篇文章记录的是我们把 Claude Code 嵌入 Code Review 流程两个月的完整过程包括用什么姿势做、REVIEW.md 怎么配、Prompt 模板直接给你、成本怎么控制以及什么情况下 AI Review 会失准——这部分尤其重要网上几乎没有人认真说过。先搞清楚 Claude Code 的 Code Review 有几种用法很多人以为 Claude Code 做 Code Review 就是在聊天窗口把代码贴进去问「这段有没有问题」。这是用法之一但效率最低的那种。Claude Code 目前有三种做 Code Review 的方式适用场景完全不同搞混了会很痛苦。第一种本地命令/code-reviewv2.1.147 之前叫/simplify在本地 Claude Code 会话里对当前 diff 运行/code-review命令。它分析你本地未提交或未推送的改动把问题直接报在终端里。速度快适合提交前的自检。这种用法的局限是它只看当前 diff不读整个仓库的上下文。如果你改的一个函数在另一个模块里有副作用它可能看不出来。但作为提交前的「最后一道门」它能拦住大多数低级错误。第二种GitHub Actions 自动化通过配置.github/workflows在 PR 打开时自动触发 Claude Code Review。这是「自托管」的方式可以用在 GitHub Enterprise 或者不想开托管服务的团队。配置稍复杂但灵活度最高。可以控制触发条件、选择运行环境、集成进已有的 CI 流水线。第三种Claude Code Review GitHub App托管服务Anthropic 提供的托管服务在 Team 和 Enterprise 订阅里可用。安装 GitHub App 后可以给每个仓库单独配置触发方式每次 PR 创建触发一次、每次 push 触发、或者手动评论claude review触发。多个 Agent 并行检查代码平均 18-20 分钟出结果每次 review 成本约 $15-25。这三种用法不互斥我们现在的实践是本地/code-review做提交前自检GitHub App 在 PR 开后自动 review 一次。两道门覆盖不同粒度的问题。图三种用法的定位、适用场景和成本对比从零开始第一周我们做对了什么、做错了什么第一周我把 GitHub App 装好给几个核心仓库开启了「每次 push 触发」模式然后就等着 AI 把问题找出来。结果是噪音太多有用信号被淹没了。每次 pushClaude 都会 review 一遍包括 WIP 提交、格式修正、只改注释的 push。comment 量暴增团队成员开始忽略 Claude 的评论因为「反正里面很多是废话」。这正是最糟糕的结局——把一个可能有用的工具训练成了没人看的背景噪音。第一个教训触发策略比什么都重要。我们做了三个调整把大多数仓库从「每次 push」改成「PR 创建后触发一次」WIP 提交不 review对个别高风险仓库保留「每次 push」但在 REVIEW.md 里设了 nit 上限draft PR 不触发Claude 默认就支持这个手动触发claude review例外改完之后每个 PR 最多看到一次 review团队的注意力集中了很多。第二个教训没有 REVIEW.md 的 review 等于没有调教的员工。Claude 的默认 review 策略是「找所有正确性问题」它不知道你们仓库的特殊规则也不知道哪些问题是 CI 已经在检查的。等我配好 REVIEW.md 之后误报率明显下降找到的问题也更贴合我们的实际关注点。关于 REVIEW.md 的配置下一节详细说。REVIEW.md 配置实战这个文件决定 AI 的 Review 质量REVIEW.md 是放在仓库根目录的文件内容会被注入到每个 review agent 的系统 prompt 里优先级最高。它和 CLAUDE.md 的区别是CLAUDE.md 是给所有 Claude Code 任务用的REVIEW.md 只影响 Code Review 行为。一个没有 REVIEW.md 的 review和一个配好 REVIEW.md 的 review产出质量的差距大概是这样的没配置时Claude 会评论你的变量命名不够语义化、某个 import 可以简化、一个 method 可以抽成 util 函数。这些不是错但在一个实际工程团队里这类评论会被忽略因为大家有更重要的事。配置好之后Claude 的评论集中在并发访问没有加锁、异常没有向上传播、一个 API 返回了 null 但调用方没有判断。这些是真正会在生产环境炸的问题。我们现在用的 REVIEW.md 模板可以直接 copy 调整# Review 指南 ## Important 的定义 只有以下情况才标 Important - 会导致生产环境行为异常的逻辑错误空指针、数组越界、竞态条件 - 数据泄露风险PII 写入日志、未鉴权的接口 - 不向后兼容的 DB migration 或 API 变更 - 事务边界错误该加事务没加、范围过大 样式问题、命名建议、可选的重构最多标 Nit不标 Important。 ## Nit 上限 每次 review 最多输出 5 条 Nit如果找到更多在 summary 里说「还有 N 个类似问题」。 所有都是 Nit 时summary 开头写「No blocking issues」。 ## 跳过的内容 - src/gen/ 目录下的生成代码 - *.lock 文件 - 纯注释修改 - CI 已在检查的 lint/format 错误我们用 Checkstyle SonarQube ## 必须检查 - 新增 API 接口必须有对应的集成测试 - 日志里不能有用户 ID、邮件地址、手机号 - 数据库查询必须有 tenant 级别的隔离 ## 复审行为 第一次 review 之后如果又触发了 review只报 Important 级别的新问题不重复 nit。这个配置的核心逻辑是三件事定义清楚什么叫「重要」、限制噪音上限、把 CI 已覆盖的内容排除掉。实操上有个细节要注意REVIEW.md 的内容越短越好。我第一版写了 500 字后来压到 200 字效果反而更好。因为 Claude 在处理长指令时会稀释注意力精简的指令执行更一致。这和 CLAUDE.md 的最佳实践是一样的道理。可复用的 Prompt 模板如果你用的是本地会话而不是自动化 GitHub App可以用下面的 Prompt 替代裸的「帮我 Review 这段代码」。Prompt 模板一针对特定变更的精准 Review请 Review 以下 diff重点关注 1. 并发安全有没有共享状态没有加锁保护 2. 异常处理异常是否被正确捕获和传播是否有吞掉异常的情况 3. 空值处理可能返回 null 的地方调用方是否有判断 4. 边界条件数组/集合的空/单元素/超大集合场景是否都处理了 只报真正会在生产环境出问题的 bug不评论代码风格。 对每个问题说明触发条件是什么、会造成什么后果、建议怎么改。 --- [paste diff here]Prompt 模板二带业务上下文的 Review这是一个 [支付/订单/库存/用户] 模块的改动背景是 [一句话说改动的业务目的]。 请关注以下高风险点 - 幂等性同一个请求重试时状态会不会重复变更 - 事务边界数据库操作是否在正确的事务范围内 - 金额/数量计算是否有精度问题浮点数 以下是 diff [paste diff here] 请优先从业务正确性角度 Review其次才是代码质量。Prompt 模板三安全场景专项 Review请对这段代码做安全向的 Review重点检查 - 输入校验用户输入是否有充分的校验和转义 - 鉴权边界每个接口是否都有权限检查有没有越权读取的可能 - 敏感数据有没有把密码、token、PII 写入日志或错误信息 - SQL 注入 / SSRF / Path Traversal有没有直接拼接用户输入到查询/请求里 [paste diff here]这三个模板的共同逻辑是给 Claude 具体的检查维度而不是让它自由发挥。「帮我 Review」和「请从并发安全角度 Review找会在生产出问题的 bug」得到的结果质量差了不止一个数量级。真实数据两个月做了什么、发现了什么让我说说实际的数据而不是只讲感受。我们在一个 5 人后端团队做了两个月的实验给 3 个核心仓库开启了 Claude Code ReviewReview 覆盖率变化之前每个 PR 人工 Review 率大约 60%另外 40% 基本是「LGTM」走过场。引入 Claude 之后每个 PR 都有至少一次 AI Review人工 Review 的精力可以集中在 AI 标了 Important 的 PR 上。Bug 漏检率变化我们通过统计生产 bug 回溯到哪个 PR 来衡量。之前两个月有 7 个生产 bug 的根因可以追溯到「review 没发现」的 PR。引入 Claude 之后的两个月这个数字是 2——降幅约 70%。数据集小仅供参考不是严格统计Claude 找到的 bug 类型分布按我们自己的记录大概是空指针 / 空集合未处理约 35%异常处理不当吞异常、异常转换丢失原因约 25%并发问题HashMap 并发、静态变量竞态约 20%业务逻辑错误边界条件算错、状态机转换漏了分支约 15%其他SQL 注入、事务边界约 5%这个分布和 Anthropic 内部测试的数据方向一致对大 PR1000 行以上的发现率约 84%平均每个 PR 找到 7.5 个问题对小 PR50 行以下的发现率约 31%。成本我们用的是「PR 创建后触发一次」模式平均每次 review 约 $18-20按团队每周 15 个 PR 计算每月成本约 $1200。这个成本对于防止生产 bug 来说是划算的——一个生产故障的排查成本远不止 $1200。图两个月实验中 Claude 发现的 Bug 类型分布Claude Code Review 会在什么情况下失准这部分很重要但网上讲的人不多。AI Review 有它擅长的地方也有它看不见的盲区搞清楚这个才不会对它产生错误的期望或者在它误报时失去信任。失准场景一跨文件的业务逻辑错误Claude 可以分析整个仓库但对业务规则的理解依赖 CLAUDE.md 和代码注释。如果你的业务规则是「VIP 用户下单不扣积分」这个规则没有在代码里写清楚Claude 就不会发现「这里少了 VIP 判断」这类问题。解法把核心业务规则写进 REVIEW.md告诉 Claude「检查 VIP 路径」这类显式指令。失准场景二只看 diff 的局限自动 review 模式下Claude 看的是这次 PR 改动的代码不是整个函数/类的完整逻辑。有时候一个 bug 是「这次没改这行但这行和这次改动的那行组合在一起有问题」——这类隐性依赖Claude 会漏。解法对高风险改动加一句「请也检查改动文件里未变更的部分看有没有和本次改动存在隐性依赖的代码」。失准场景三性能问题几乎发现不了Claude 不会告诉你「这个查询在百万数据规模下会超时」它没有你的数据量。它能发现「SELECT * 没有加 limit」这类明显问题但对于需要结合业务数据规模来判断的性能 bug它基本失准。这类问题还是得靠压测和生产监控。失准场景四测试代码的逻辑 bug测试代码通常不在 Claude 的重点检查范围里除非你在 REVIEW.md 里显式要求。我们踩过一个坑一个单元测试 mock 错了对象导致测试「通过了但没有测到该测的逻辑」Claude 没发现我们也没发现直到生产出问题才反查出来。解法在 REVIEW.md 里加一条「检查测试代码的 mock 是否和被测逻辑一致」。失准场景五安全问题的误报Claude 有时候对安全问题的判断过于保守。比如它会标记「这个接口没有 rate limit」但在你们的架构里rate limit 在 API Gateway 层统一做了接口本身确实不需要。这类误报需要你在 REVIEW.md 里显式排除或者团队 reviewer 知道该怎么识别和忽略。和纯人工 Review 的合理分工引入 Claude 之后我们团队的 Code Review 分工变了不是用 AI 替代人而是重新定义了人的职责。Claude 负责机械性的正确性检查空指针、异常处理、并发安全、边界条件。这些检查有固定的模式人做反而容易因为疲劳或者赶时间漏看Claude 专注且不知疲倦。人负责理解改动的意图、评估架构决策是否合理、判断业务逻辑是否覆盖完整、发现「代码能跑但方向错了」的问题。这些是需要理解系统全貌和业务背景的判断AI 现在还做不好。一个 PR 的最优 Review 路径变成了Claude 先扫一遍 → 看 Claude 的 Important 评论 → 如果没有 Important人工 Review 可以更放松地关注架构和业务层面 → 如果有 Important重点看那些地方。这个分工有一个额外的好处Code Review 的「注意力成本」降低了。以前 reviewer 要从零开始扫描整个 diff认知负荷很高容易疲劳。现在有了 Claude 的先期扫描人的注意力可以集中在 AI 认为值得看的地方review 质量反而提高了。图AI Review 与人工 Review 的合理职责分工常见问题QClaude Code Review 和 CodeRabbit 比哪个更好用A取决于你的优先级。CodeRabbit 便宜$24/dev/月速度快约 3 分钟/次适合高频 push 的团队。Claude Code Review 贵$15-25/次慢约 18-20 分钟但评论质量更高——在我们的测试里它的 actionable rate 接近 100%几乎没有废话 comment。如果你们的 PR 频率每天超过 5 个CodeRabbit 的成本优势明显如果你们更在意 review 深度Claude 更合适。两个都试看团队反馈。QREVIEW.md 和 CLAUDE.md 同时存在时哪个优先AREVIEW.md 的内容直接注入 review agent 系统 prompt 作为最高优先级CLAUDE.md 作为项目上下文读取违反 CLAUDE.md 的问题默认标为 Nit 级别。简单说REVIEW.md 控制 review 行为CLAUDE.md 控制项目规范。两个都要配。Q我们用 GitLab不用 GitHub能用 Claude Code Review 吗A托管服务GitHub App目前只支持 GitHub。如果用 GitLab可以走 GitLab CI/CD 自托管路线在.gitlab-ci.yml里调用 Claude Code CLI效果类似但需要自己维护管道。Q对 Claude 发现的 bug它会自动修复还是只报告A只报告不自动修复。这个设计是刻意的——自动修复在代码库里没有人工确认很危险。Claude 的评论是 inline comment你需要自己决定要不要改、怎么改。如果你想让它修复可以在本地 Claude Code 会话里那条评论让它帮你改。Q团队成员会不会因为有 AI Review 就不认真做人工 ReviewA这个问题的答案是会如果你不调整流程。我们的做法是明确规定Claude 的评论不是人工 Review 的替代它只是帮你先过滤掉低级问题。每个 PR 仍然需要至少一个人工 reviewer approve不能因为 Claude 没发现问题就直接 merge。
我用 Claude Code 做 Code Review 两个月，Bug 漏检率从 41% 降到 11%
人仔细看。我当时的第一反应是人力不够。后来想明白了不是人力的问题是人力被用在了效率最低的地方。Code Review 里有大量机械性的工作——找空指针、查边界条件、验证错误处理逻辑——这些事 AI 比人做得更专注、更不会因为赶时间而漏看。这篇文章记录的是我们把 Claude Code 嵌入 Code Review 流程两个月的完整过程包括用什么姿势做、REVIEW.md 怎么配、Prompt 模板直接给你、成本怎么控制以及什么情况下 AI Review 会失准——这部分尤其重要网上几乎没有人认真说过。先搞清楚 Claude Code 的 Code Review 有几种用法很多人以为 Claude Code 做 Code Review 就是在聊天窗口把代码贴进去问「这段有没有问题」。这是用法之一但效率最低的那种。Claude Code 目前有三种做 Code Review 的方式适用场景完全不同搞混了会很痛苦。第一种本地命令/code-reviewv2.1.147 之前叫/simplify在本地 Claude Code 会话里对当前 diff 运行/code-review命令。它分析你本地未提交或未推送的改动把问题直接报在终端里。速度快适合提交前的自检。这种用法的局限是它只看当前 diff不读整个仓库的上下文。如果你改的一个函数在另一个模块里有副作用它可能看不出来。但作为提交前的「最后一道门」它能拦住大多数低级错误。第二种GitHub Actions 自动化通过配置.github/workflows在 PR 打开时自动触发 Claude Code Review。这是「自托管」的方式可以用在 GitHub Enterprise 或者不想开托管服务的团队。配置稍复杂但灵活度最高。可以控制触发条件、选择运行环境、集成进已有的 CI 流水线。第三种Claude Code Review GitHub App托管服务Anthropic 提供的托管服务在 Team 和 Enterprise 订阅里可用。安装 GitHub App 后可以给每个仓库单独配置触发方式每次 PR 创建触发一次、每次 push 触发、或者手动评论claude review触发。多个 Agent 并行检查代码平均 18-20 分钟出结果每次 review 成本约 $15-25。这三种用法不互斥我们现在的实践是本地/code-review做提交前自检GitHub App 在 PR 开后自动 review 一次。两道门覆盖不同粒度的问题。图三种用法的定位、适用场景和成本对比从零开始第一周我们做对了什么、做错了什么第一周我把 GitHub App 装好给几个核心仓库开启了「每次 push 触发」模式然后就等着 AI 把问题找出来。结果是噪音太多有用信号被淹没了。每次 pushClaude 都会 review 一遍包括 WIP 提交、格式修正、只改注释的 push。comment 量暴增团队成员开始忽略 Claude 的评论因为「反正里面很多是废话」。这正是最糟糕的结局——把一个可能有用的工具训练成了没人看的背景噪音。第一个教训触发策略比什么都重要。我们做了三个调整把大多数仓库从「每次 push」改成「PR 创建后触发一次」WIP 提交不 review对个别高风险仓库保留「每次 push」但在 REVIEW.md 里设了 nit 上限draft PR 不触发Claude 默认就支持这个手动触发claude review例外改完之后每个 PR 最多看到一次 review团队的注意力集中了很多。第二个教训没有 REVIEW.md 的 review 等于没有调教的员工。Claude 的默认 review 策略是「找所有正确性问题」它不知道你们仓库的特殊规则也不知道哪些问题是 CI 已经在检查的。等我配好 REVIEW.md 之后误报率明显下降找到的问题也更贴合我们的实际关注点。关于 REVIEW.md 的配置下一节详细说。REVIEW.md 配置实战这个文件决定 AI 的 Review 质量REVIEW.md 是放在仓库根目录的文件内容会被注入到每个 review agent 的系统 prompt 里优先级最高。它和 CLAUDE.md 的区别是CLAUDE.md 是给所有 Claude Code 任务用的REVIEW.md 只影响 Code Review 行为。一个没有 REVIEW.md 的 review和一个配好 REVIEW.md 的 review产出质量的差距大概是这样的没配置时Claude 会评论你的变量命名不够语义化、某个 import 可以简化、一个 method 可以抽成 util 函数。这些不是错但在一个实际工程团队里这类评论会被忽略因为大家有更重要的事。配置好之后Claude 的评论集中在并发访问没有加锁、异常没有向上传播、一个 API 返回了 null 但调用方没有判断。这些是真正会在生产环境炸的问题。我们现在用的 REVIEW.md 模板可以直接 copy 调整# Review 指南 ## Important 的定义 只有以下情况才标 Important - 会导致生产环境行为异常的逻辑错误空指针、数组越界、竞态条件 - 数据泄露风险PII 写入日志、未鉴权的接口 - 不向后兼容的 DB migration 或 API 变更 - 事务边界错误该加事务没加、范围过大 样式问题、命名建议、可选的重构最多标 Nit不标 Important。 ## Nit 上限 每次 review 最多输出 5 条 Nit如果找到更多在 summary 里说「还有 N 个类似问题」。 所有都是 Nit 时summary 开头写「No blocking issues」。 ## 跳过的内容 - src/gen/ 目录下的生成代码 - *.lock 文件 - 纯注释修改 - CI 已在检查的 lint/format 错误我们用 Checkstyle SonarQube ## 必须检查 - 新增 API 接口必须有对应的集成测试 - 日志里不能有用户 ID、邮件地址、手机号 - 数据库查询必须有 tenant 级别的隔离 ## 复审行为 第一次 review 之后如果又触发了 review只报 Important 级别的新问题不重复 nit。这个配置的核心逻辑是三件事定义清楚什么叫「重要」、限制噪音上限、把 CI 已覆盖的内容排除掉。实操上有个细节要注意REVIEW.md 的内容越短越好。我第一版写了 500 字后来压到 200 字效果反而更好。因为 Claude 在处理长指令时会稀释注意力精简的指令执行更一致。这和 CLAUDE.md 的最佳实践是一样的道理。可复用的 Prompt 模板如果你用的是本地会话而不是自动化 GitHub App可以用下面的 Prompt 替代裸的「帮我 Review 这段代码」。Prompt 模板一针对特定变更的精准 Review请 Review 以下 diff重点关注 1. 并发安全有没有共享状态没有加锁保护 2. 异常处理异常是否被正确捕获和传播是否有吞掉异常的情况 3. 空值处理可能返回 null 的地方调用方是否有判断 4. 边界条件数组/集合的空/单元素/超大集合场景是否都处理了 只报真正会在生产环境出问题的 bug不评论代码风格。 对每个问题说明触发条件是什么、会造成什么后果、建议怎么改。 --- [paste diff here]Prompt 模板二带业务上下文的 Review这是一个 [支付/订单/库存/用户] 模块的改动背景是 [一句话说改动的业务目的]。 请关注以下高风险点 - 幂等性同一个请求重试时状态会不会重复变更 - 事务边界数据库操作是否在正确的事务范围内 - 金额/数量计算是否有精度问题浮点数 以下是 diff [paste diff here] 请优先从业务正确性角度 Review其次才是代码质量。Prompt 模板三安全场景专项 Review请对这段代码做安全向的 Review重点检查 - 输入校验用户输入是否有充分的校验和转义 - 鉴权边界每个接口是否都有权限检查有没有越权读取的可能 - 敏感数据有没有把密码、token、PII 写入日志或错误信息 - SQL 注入 / SSRF / Path Traversal有没有直接拼接用户输入到查询/请求里 [paste diff here]这三个模板的共同逻辑是给 Claude 具体的检查维度而不是让它自由发挥。「帮我 Review」和「请从并发安全角度 Review找会在生产出问题的 bug」得到的结果质量差了不止一个数量级。真实数据两个月做了什么、发现了什么让我说说实际的数据而不是只讲感受。我们在一个 5 人后端团队做了两个月的实验给 3 个核心仓库开启了 Claude Code ReviewReview 覆盖率变化之前每个 PR 人工 Review 率大约 60%另外 40% 基本是「LGTM」走过场。引入 Claude 之后每个 PR 都有至少一次 AI Review人工 Review 的精力可以集中在 AI 标了 Important 的 PR 上。Bug 漏检率变化我们通过统计生产 bug 回溯到哪个 PR 来衡量。之前两个月有 7 个生产 bug 的根因可以追溯到「review 没发现」的 PR。引入 Claude 之后的两个月这个数字是 2——降幅约 70%。数据集小仅供参考不是严格统计Claude 找到的 bug 类型分布按我们自己的记录大概是空指针 / 空集合未处理约 35%异常处理不当吞异常、异常转换丢失原因约 25%并发问题HashMap 并发、静态变量竞态约 20%业务逻辑错误边界条件算错、状态机转换漏了分支约 15%其他SQL 注入、事务边界约 5%这个分布和 Anthropic 内部测试的数据方向一致对大 PR1000 行以上的发现率约 84%平均每个 PR 找到 7.5 个问题对小 PR50 行以下的发现率约 31%。成本我们用的是「PR 创建后触发一次」模式平均每次 review 约 $18-20按团队每周 15 个 PR 计算每月成本约 $1200。这个成本对于防止生产 bug 来说是划算的——一个生产故障的排查成本远不止 $1200。图两个月实验中 Claude 发现的 Bug 类型分布Claude Code Review 会在什么情况下失准这部分很重要但网上讲的人不多。AI Review 有它擅长的地方也有它看不见的盲区搞清楚这个才不会对它产生错误的期望或者在它误报时失去信任。失准场景一跨文件的业务逻辑错误Claude 可以分析整个仓库但对业务规则的理解依赖 CLAUDE.md 和代码注释。如果你的业务规则是「VIP 用户下单不扣积分」这个规则没有在代码里写清楚Claude 就不会发现「这里少了 VIP 判断」这类问题。解法把核心业务规则写进 REVIEW.md告诉 Claude「检查 VIP 路径」这类显式指令。失准场景二只看 diff 的局限自动 review 模式下Claude 看的是这次 PR 改动的代码不是整个函数/类的完整逻辑。有时候一个 bug 是「这次没改这行但这行和这次改动的那行组合在一起有问题」——这类隐性依赖Claude 会漏。解法对高风险改动加一句「请也检查改动文件里未变更的部分看有没有和本次改动存在隐性依赖的代码」。失准场景三性能问题几乎发现不了Claude 不会告诉你「这个查询在百万数据规模下会超时」它没有你的数据量。它能发现「SELECT * 没有加 limit」这类明显问题但对于需要结合业务数据规模来判断的性能 bug它基本失准。这类问题还是得靠压测和生产监控。失准场景四测试代码的逻辑 bug测试代码通常不在 Claude 的重点检查范围里除非你在 REVIEW.md 里显式要求。我们踩过一个坑一个单元测试 mock 错了对象导致测试「通过了但没有测到该测的逻辑」Claude 没发现我们也没发现直到生产出问题才反查出来。解法在 REVIEW.md 里加一条「检查测试代码的 mock 是否和被测逻辑一致」。失准场景五安全问题的误报Claude 有时候对安全问题的判断过于保守。比如它会标记「这个接口没有 rate limit」但在你们的架构里rate limit 在 API Gateway 层统一做了接口本身确实不需要。这类误报需要你在 REVIEW.md 里显式排除或者团队 reviewer 知道该怎么识别和忽略。和纯人工 Review 的合理分工引入 Claude 之后我们团队的 Code Review 分工变了不是用 AI 替代人而是重新定义了人的职责。Claude 负责机械性的正确性检查空指针、异常处理、并发安全、边界条件。这些检查有固定的模式人做反而容易因为疲劳或者赶时间漏看Claude 专注且不知疲倦。人负责理解改动的意图、评估架构决策是否合理、判断业务逻辑是否覆盖完整、发现「代码能跑但方向错了」的问题。这些是需要理解系统全貌和业务背景的判断AI 现在还做不好。一个 PR 的最优 Review 路径变成了Claude 先扫一遍 → 看 Claude 的 Important 评论 → 如果没有 Important人工 Review 可以更放松地关注架构和业务层面 → 如果有 Important重点看那些地方。这个分工有一个额外的好处Code Review 的「注意力成本」降低了。以前 reviewer 要从零开始扫描整个 diff认知负荷很高容易疲劳。现在有了 Claude 的先期扫描人的注意力可以集中在 AI 认为值得看的地方review 质量反而提高了。图AI Review 与人工 Review 的合理职责分工常见问题QClaude Code Review 和 CodeRabbit 比哪个更好用A取决于你的优先级。CodeRabbit 便宜$24/dev/月速度快约 3 分钟/次适合高频 push 的团队。Claude Code Review 贵$15-25/次慢约 18-20 分钟但评论质量更高——在我们的测试里它的 actionable rate 接近 100%几乎没有废话 comment。如果你们的 PR 频率每天超过 5 个CodeRabbit 的成本优势明显如果你们更在意 review 深度Claude 更合适。两个都试看团队反馈。QREVIEW.md 和 CLAUDE.md 同时存在时哪个优先AREVIEW.md 的内容直接注入 review agent 系统 prompt 作为最高优先级CLAUDE.md 作为项目上下文读取违反 CLAUDE.md 的问题默认标为 Nit 级别。简单说REVIEW.md 控制 review 行为CLAUDE.md 控制项目规范。两个都要配。Q我们用 GitLab不用 GitHub能用 Claude Code Review 吗A托管服务GitHub App目前只支持 GitHub。如果用 GitLab可以走 GitLab CI/CD 自托管路线在.gitlab-ci.yml里调用 Claude Code CLI效果类似但需要自己维护管道。Q对 Claude 发现的 bug它会自动修复还是只报告A只报告不自动修复。这个设计是刻意的——自动修复在代码库里没有人工确认很危险。Claude 的评论是 inline comment你需要自己决定要不要改、怎么改。如果你想让它修复可以在本地 Claude Code 会话里那条评论让它帮你改。Q团队成员会不会因为有 AI Review 就不认真做人工 ReviewA这个问题的答案是会如果你不调整流程。我们的做法是明确规定Claude 的评论不是人工 Review 的替代它只是帮你先过滤掉低级问题。每个 PR 仍然需要至少一个人工 reviewer approve不能因为 Claude 没发现问题就直接 merge。
