来源：Claude Code Skills

用 AI 做严格代码评审的完整流程

概述

代码评审（Code Review）是软件工程中最重要的质量保障手段之一。但在 AI 辅助开发的时代，一个矛盾出现了：AI 帮你写了代码，你还需要评审吗？

答案是：更需要。

AI 生成的代码有一个独特的风险——它看起来非常专业、非常完整，这让人容易放松警惕。但「看起来对」和「真的对」之间，往往隔着微妙的逻辑错误、遗漏的边界情况、不合适的架构决策。而且，当代码看起来越专业，这些隐藏的问题就越难被发现。

这篇指南将展示一套完整的 AI 驱动代码评审流程，帮你建立代码质量的最后一道防线。

你将用到的核心技能：

• 请求代码评审（Request Code Review）
• 接收代码评审（Receive Code Review）
• 完成前验证（Pre-completion Verification）

第一步：发起评审

使用「请求代码评审」技能

当你完成一个功能的开发后，不要直接提交或合并。先发起一次正式的代码评审。

如何向 Claude Code 发起评审：

「请对以下变更做一次严格的代码评审：
- 变更范围：[描述你修改了什么]
- 变更目的：[为什么要做这个修改]
- 特别关注：[你自己不太确定的地方]」

提供上下文非常重要。没有上下文的评审只能检查语法和表面问题。当评审者理解了「为什么」之后，才能判断「怎么做」是否合理。

评审的维度

「请求代码评审」技能会从以下维度检查你的代码：

1. 正确性（Correctness）

   • 逻辑是否正确？有没有 off-by-one 错误？
   • 边界情况处理了吗？空值、超大值、并发访问？
   • 错误处理是否完善？异常会不会被静默吞掉？

2. 可读性（Readability）

   • 变量和函数命名是否清晰？
   • 代码结构是否直观？
   • 注释是否必要且准确？（多余的注释和缺失的注释一样有害）

3. 可维护性（Maintainability）

   • 代码是否容易修改和扩展？
   • 有没有硬编码的魔法数字或字符串？
   • 职责划分是否合理？

4. 性能（Performance）

   • 有没有明显的性能问题？（N+1 查询、不必要的全表扫描）
   • 有没有可以预见的性能瓶颈？
   • 缓存策略是否合理？

5. 安全性（Security）

   • 用户输入有没有正确验证和转义？
   • 权限检查是否到位？
   • 敏感数据（密码、Token）有没有被正确处理？

评审粒度建议

大型变更不要一次性评审。把它拆成逻辑上独立的小块，每块单独评审。一次性看 1000 行代码，评审质量会急剧下降。

第二步：处理反馈

使用「接收代码评审」技能

收到评审反馈后，不要急着逐条修改。先整体浏览所有反馈，把它们分类：

1. 必须修复（Must Fix）

   • 逻辑错误、安全漏洞、数据丢失风险
   • 这类问题不修复就不能合并

2. 建议改进（Should Fix）

   • 性能优化、可读性提升、更好的错误处理
   • 推荐修复，但不阻塞合并

3. 讨论项（Discussion）

   • 架构选择、设计理念上的分歧
   • 需要讨论达成共识

4. 了解即可（Nice to Know）

   • 风格偏好、未来改进方向
   • 记录下来，不需要立即行动

处理原则

对待「必须修复」： 逐一修复，每个修复都应该有对应的测试来验证。修复完成后，让 Claude 重新检查该项是否已正确解决。

对待「建议改进」： 评估投入产出比。如果一个改进只需要 5 分钟但能显著提升代码质量，就做。如果改动大且风险高，可以记录为后续优化项。

对待「讨论项」： 这是最有价值的部分。与 Claude 深入讨论这些架构和设计问题。例如：

「你建议使用策略模式（Strategy Pattern）替代当前的 switch 语句。
请详细解释：
1. 在当前项目规模下，策略模式的优势是什么？
2. 如果我们不改，未来可能遇到什么问题？
3. 改造的成本和风险是什么？」

通过这种对话，你不仅在做代码评审，还在提升自己的架构设计能力。

避免常见陷阱

• 不要因为自尊心而拒绝反馈。 评审发现了问题不代表你写得差，而是说明评审流程在发挥作用。
• 不要无脑接受所有建议。 AI 的建议不一定都适合你的项目上下文。要批判性地思考每一条反馈。
• 不要只修表面不改根因。 如果同一类问题反复出现，说明你需要改变某个编码习惯，而不是每次事后修补。

第三步：验证闭环

使用完成前验证做最终确认

所有评审意见处理完毕后，不要直接合并。使用完成前验证做一次最终的全面检查：

1. 回归检查：评审修改有没有引入新问题？原有的功能还正常吗？
2. 测试完整性：为评审中发现的每个 bug，都有对应的回归测试吗？
3. 一致性检查：修改后的代码与项目整体风格一致吗？
4. 文档更新：如果变更影响了 API 或行为，文档更新了吗？

这一步的目的是确保评审-修改-验证形成一个闭环。不能评审发现了问题，修了，但修的过程中又引入了新问题。

闭环确认

最后，让 Claude 做一个简短的闭环确认：

「请确认：
1. 所有「必须修复」的评审意见都已处理
2. 每个修复都有对应的测试
3. 所有测试通过
4. 没有引入新的问题」

只有当所有条件都满足时，代码才能合并。

最佳实践

实践1：让评审成为习惯，而非例外

不要只在「大功能」完成后才做评审。每个 Pull Request，不管多小，都应该经过评审。小的、频繁的评审比大的、偶尔的评审效果好得多。原因很简单：评审 50 行代码时你能仔细看每一行，评审 2000 行时你只能走马观花。

实践2：评审前先自检

在让 Claude 评审之前，先自己快速过一遍代码。问自己：

• 这段代码我能解释清楚吗？如果不能，它可能太复杂了
• 有没有遗留的调试代码（console.log、TODO 注释）？
• 测试真的在测试有意义的行为，还是在测试实现细节？

自检不是要替代 AI 评审，而是先过滤掉低级问题，让 AI 评审能集中在更深层的问题上。

实践3：建立项目的评审检查清单

每个项目都有自己的特殊关注点。创建一份定制化的评审检查清单，例如：

• 数据库查询是否使用了索引
• API 响应是否包含分页
• 权限检查是否覆盖了所有端点
• 日志是否记录了关键操作
• 错误响应是否对用户友好

将这份清单作为技能的补充，让每次评审都覆盖项目特有的关注点。

实践4：记录评审中的学习

每次代码评审都是学习的机会。维护一份「评审学习笔记」，记录：

• 评审中发现的常见问题模式
• 有价值的架构建议
• 自己容易忽略的代码质量维度

随着时间推移，你会发现同类问题越来越少——这就是评审驱动成长的力量。

实践5：双重评审高风险代码

涉及支付、数据删除、权限变更等高风险操作的代码，建议做两轮评审：

1. 第一轮：标准代码评审，关注代码质量
2. 第二轮：安全专项评审，重点关注权限、数据安全、注入防护

告诉 Claude：「这段代码涉及支付逻辑，请从安全性角度做一次专项评审。」不同的评审视角会发现不同的问题。

最后的思考： 代码评审的终极目标不是找 bug——那是测试的工作。代码评审的真正价值在于：确保代码不仅「能工作」，还「好维护」。一段能工作但没人敢碰的代码，和一段不能工作的代码一样有害。让 AI 评审成为你开发流程的标准环节，你的代码库质量会持续提升，而不是随着项目增长逐渐腐化。

Source: Claude Code Skills

Complete AI-Powered Code Review Workflow

Overview

Code review is one of the highest-leverage activities in software development. A single review can catch a security vulnerability before it reaches production, identify a performance bottleneck before users experience it, or suggest an architectural improvement that saves weeks of future refactoring. Yet code review is also one of the most inconsistently practiced activities. Reviewers are busy, attention varies, and important issues slip through.

Claude Code, equipped with the Code Review skill, brings consistency, thoroughness, and speed to the review process. It does not replace human judgment --- it augments it. The AI catches the mechanical issues (security patterns, performance anti-patterns, style violations, missing error handling) so that human reviewers can focus on the deeper questions: Is this the right approach? Does this align with our architecture? Will this be maintainable in six months?

This guide walks you through a complete AI-powered code review workflow, from requesting the initial review to closing the loop on every finding.

Step 1: Request a Review

Prepare Your Changes

Before requesting a review, make sure your code is ready to be reviewed. This means:

• All tests pass. Do not ask for a review of code that has failing tests. Fix the tests first. The reviewer's job is to find issues you could not find yourself, not to confirm that your code does not compile.
• Self-review first. Read through your own diff once before requesting an AI review. You will catch obvious issues --- commented-out code, debug print statements, TODO comments that should have been resolved --- and save the AI's attention for deeper analysis.
• Scope the review. If your pull request touches 50 files across 6 different concerns, consider breaking it into smaller, focused reviews. A review of a 200-line change in one module will produce more actionable feedback than a review of a 2,000-line change that spans your entire codebase.

Invoke the Code Review Skill

With your changes ready, ask Claude Code to review them. Be specific about what you want reviewed and any areas of particular concern.

Effective review requests include context:

Review the changes in this pull request. The goal of these changes is to add
rate limiting to our API endpoints. I'm particularly concerned about:
1. Whether the rate limiting logic handles edge cases correctly
2. Whether the Redis connection management is proper
3. Whether there are any race conditions in the counter increment logic

This focused prompt produces dramatically better results than a generic "review my code." The AI knows what the code is supposed to do, what technology is involved, and where you are least confident. It can allocate its attention accordingly.

What the AI Reviews

The Code Review skill examines your changes across several dimensions:

Security. It looks for common vulnerability patterns: SQL injection, cross-site scripting, insecure direct object references, missing authentication checks, hardcoded secrets, and insufficient input validation. For the rate limiting example, it might flag that the rate limit key includes user-supplied data that could be manipulated.

Performance. It identifies potential performance issues: N+1 database queries, missing indexes, unnecessary data fetching, inefficient algorithms, and memory leaks. For the rate limiting example, it might note that checking the rate limit and incrementing the counter should be an atomic operation to prevent race conditions.

Correctness. It checks for logical errors, off-by-one mistakes, unhandled edge cases, and incorrect assumptions. It verifies that error handling is comprehensive and that failure modes are handled gracefully.

Maintainability. It evaluates code clarity, naming conventions, function length, coupling between modules, and adherence to established patterns in the codebase. It suggests refactoring opportunities where code could be simpler or more expressive.

Best Practices. It checks for proper use of language features, framework conventions, and industry-standard patterns. It flags deprecated APIs, anti-patterns, and deviations from the project's coding standards.

Step 2: Handle Feedback

The AI review will produce a list of findings, ranging from critical issues to minor suggestions. Handling this feedback effectively is where most of the value is realized --- or lost.

Triage the Findings

Not all findings are equal. Categorize each one:

• Critical (must fix). Security vulnerabilities, data corruption risks, race conditions, and logic errors that produce incorrect results. These are non-negotiable. Fix them before merging.
• Important (should fix). Performance issues that will affect users at scale, missing error handling for likely failure scenarios, and maintainability concerns that will compound over time. Fix these unless you have a compelling reason to defer them (and document that reason).
• Minor (consider fixing). Style suggestions, naming improvements, and alternative approaches that are equally valid. Apply your judgment. If the suggestion makes the code meaningfully better, accept it. If it is a matter of preference, move on.
• False positives (dismiss). Occasionally the AI will flag something that is not actually an issue, usually because it lacks context about a project-specific convention or a deliberate design decision. Dismiss these, but consider whether adding a code comment would prevent the same confusion for future human reviewers.

Apply Fixes Systematically

For each finding you decide to address:

1. Understand the issue. Do not blindly apply the AI's suggested fix. Make sure you understand why the current code is problematic and why the suggested change is better. If you do not understand, ask Claude Code to explain in more detail.

2. Write a test first. If the finding is a bug, write a test that exposes the bug before fixing it. This proves your fix actually addresses the issue and prevents the bug from recurring.

3. Make the fix. Apply the change. Keep fixes focused --- each fix should address one finding. Do not bundle unrelated changes into a single commit.

4. Verify the fix. Run the relevant tests. For security findings, manually verify that the vulnerability is no longer exploitable. For performance findings, run benchmarks if possible.

Engage in Dialogue

The review is not a one-way broadcast. If you disagree with a finding, explain your reasoning and ask Claude Code to evaluate your counterargument. Sometimes the AI's suggestion is technically correct but impractical given project constraints. Other times, your counterargument will reveal a gap in your own understanding.

This dialogue is valuable. It forces you to articulate why your code is correct, which either strengthens your confidence or reveals weaknesses you had not considered.

Step 3: Close the Loop

After addressing all findings, close the review loop to ensure nothing slipped through.

Re-Review Changed Code

Request a follow-up review focused specifically on the code you changed in response to the initial findings. New code can introduce new issues, even when it is fixing old ones. A fix for a race condition might introduce a deadlock. A fix for missing input validation might break a legitimate use case.

The follow-up review is typically much faster than the initial one because the scope is smaller and the context is fresh.

Run the Full Test Suite

Before merging, run the complete test suite --- not just the tests related to your changes. Code review findings often touch shared utilities, base classes, or configuration that affect multiple parts of the application. A passing test suite is your final safety net.

Document Decisions

For any finding you deliberately chose not to address, leave a comment in the code or the pull request explaining why. Future developers (including future-you) will encounter the same code and have the same questions. A brief note --- "Rate limit key intentionally includes the IP address despite the AI's suggestion to use only the user ID, because we need to limit unauthenticated requests" --- saves everyone time.

Best Practices

Make Reviews a Habit, Not an Event

Do not save code review for the end of a feature. Review early and often. A quick review of your database schema before building the API layer can catch design issues that would be expensive to fix after 2,000 lines of code depend on the schema. Review at natural checkpoints: after completing a component, before integrating with another system, and before merging any pull request.

Combine AI and Human Review

AI review and human review are complementary, not competing. Use AI review as the first pass to catch mechanical issues, then have a human reviewer focus on higher-level concerns: architectural fit, team conventions, business logic correctness, and long-term maintainability. This division of labor makes both reviews faster and more effective.

Calibrate Your Trust Over Time

When you first start using AI code review, verify every finding independently. As you gain experience, you will develop a sense for which types of findings are consistently reliable (security patterns, missing error handling) and which require more scrutiny (performance suggestions that depend on usage patterns, refactoring proposals that change public interfaces). Calibrate your trust based on your own experience, not on assumption.

Review Your Own Code First

The most effective AI reviews happen when you have already caught the obvious issues yourself. Read your diff, check for forgotten debug statements, verify that names are descriptive, and confirm that tests cover the important cases. The AI then functions as a second pair of eyes catching what you missed, rather than a first pair of eyes catching what you were too lazy to check.

Keep Pull Requests Small

The single most impactful practice for effective code review --- whether human or AI --- is keeping pull requests small and focused. A 200-line change to one module will receive a thorough, insightful review. A 2,000-line change spanning multiple features will receive a superficial review that misses critical issues buried in the volume. If your pull request is too large, split it. The extra overhead of creating multiple pull requests is negligible compared to the cost of shipping a bug that a focused review would have caught.

Use Reviews to Learn

Every review finding is a learning opportunity. When the AI identifies a security vulnerability you did not know about, research it. When it suggests a more efficient algorithm, understand why it is faster. When it points out a language feature you have not used before, experiment with it. Over time, the patterns you learn from reviews will inform how you write code in the first place, and you will need fewer corrections on each successive review.

Code review is not a gate to pass through on the way to deployment. It is a practice that continuously improves both your code and your skills as a developer. With Claude Code's Code Review skill as your consistent, thorough, and tireless first reviewer, every pull request becomes an opportunity to ship better software and become a better engineer.