用Claude Code进行AI代码审查：从安装到实战的全流程指南

周五下午三点四十我刚把一个订单导出模块的改动推到 feature 分支越想越心虚。那模块我写了三天逻辑绕成了俄罗斯套娃测试能过但我不敢点“创建合并请求”——因为心里清楚这代码要是被组里那位老哥看到他大概率会先把我的注释逐行念出来。于是我做了一个看似明智、实则找骂的决定让 Claude Code 来一次彻头彻尾的代码审查。结果它连前 500 行都没看完就开始给我逐条列罪状用词之精准语气之刻薄让我一度怀疑它在我工位上装了摄像头。这个体验其实挺有代表性的。Claude Code 是一个能直接跑在终端里的 AI 编程助手它能读整个项目目录执行命令改文件小到给你实时补全代码大到把“审查代码”这种任务干得像一个较真的技术主管。前面几个星期我一直把它当编程搭档用写函数、补测试、解释晦涩报错都让它上整体体验就一个字爽。直到那次审查我才意识到它能从一个气氛组模式瞬间切换到面试官状态。如果你也像我一样写完代码总觉得隐隐不安但又不好意思次次拖着同事陪你 review这篇文章就是给你踩坑用的我会把安装、配置、审查指令、被骂案例、误报识别这些折腾过程一次讲清楚。1. 我为什么想起来让 AI 审我的代码1.1 起因周五下午那份不敢点提交的代码先交代背景。我之前在维护一个内部工具主要职责是把订单数据从业务库同步到数仓再生成报告。业务本身不复杂难在时间线状态机有创建、待支付、已支付、已取消还有各种退款状态。三个状态之间互相牵扯我为了省事把状态转换判断全部压在一个函数里函数长 180 行自测的时候手工跑通了 4 条用例就草草收工。功能确实能出数但每当有人问“如果支付回执在取消之后到了怎么办”我心里第一反应是“不太可能吧”。周五下午我终于把自己问毛了。与其把这份纠结送给同事当加班下酒菜不如先找个不会记仇的工具帮我过一遍。于是我想起了 Claude Code。平时我已经在终端里用它生成过不少抽象工具函数也让它读过一整个模块然后告诉我模块之间谁依赖谁它的上下文能力比我用过的其他聊天式助手都强一截。对我来说这种能看目录、能读文件、能定位代码的 CLI 工具天然就该拿来干代码审查。1.2 为什么偏要选 Claude Code而不是直接找同事这里有个很现实的问题代码审查这件事人工做最好但往往轮不到你。你的同事各自有排期让人家对着你 180 行的状态机函数看半小时嘴上不说心里也累更别说你还没接 IDE review 插件、团队也没强推四眼规则的时候“找人看代码”就是一道人情债。AI 没有这个问题你随时可以把它骂回去它对代码质量也不会记恨。当然选 Claude Code 而不是随便一个在线聊天助手是因为“审查”不是“逐段翻译”它需要几个关键能力。一是能读到完整文件而不是你粘贴的一小段二是能跨文件追踪一个函数在哪儿被调用、状态流转在哪儿中断三是能区分“这里的代码风格是脏但有用”和“这里的错误是真的会炸”。这三个要求其实很高。以前我试过直接把一套代码贴给聊天框让它找问题它要么只看得到片段要么动不动就建议我“优化性能”根本触不到痛点。Claude Code 在处理这类任务时的思路更接近工程师它会先看 diff、查调用链、读项目约定再输出一份有文件路径、有行号、有严重级别的报告。我用下来它在这三点的表现基本等于一个沉得住气的远程老同事前提是你在指令里把边界说清楚。2. 先把工具跑起来安装与基础配置避坑实录2.1 环境准备与最干净的安装路径放一下这次实践用的环境Windows 11 上跑了 WSL2Ubuntu 22.04Node.js 版本是 20 LTS另外我还在另一台 macOS 上试过同样的流程结论没有本质区别。安装 Claude Code 本身不复杂官方建议用 npm 全局安装一行命令npm install -g anthropic-ai/claude-code安装完成后在任意目录输入claude回车第一次会走浏览器授权登录。如果你之前拿到过 API Key也可以通过环境变量来注入这样不依赖交互式登录适合放在 CI 脚本里跑批量的审查任务。装完之后建议顺手验证一下claude --version能看到版本号就说明核心可用。VS Code 用户可以再去扩展商店里装一个 Claude Code 的官方扩展这样能在 IDE 侧边栏打开会话窗口还可以把当前选中代码直接带进上下文。这个扩展不是必须的但确实省了很多复制粘贴的功夫。如果你是 Windows 用户我强烈建议直接在 WSL2 的 Linux 环境里跑终端体验更顺文件路径也避免了一堆反斜杠转义的破事。2.2 登录与目录准备开工前先想清楚审查对象claude首次运行会引导登录登录后它默认会把当前目录当工作区。很多人第一次拿它审查代码习惯性打开一个感觉对的文件夹就开始说话结果它读了一堆 node_modules、dist 和 build 目录既浪费上下文窗口又容易串答案。我的习惯是这样审查之前先让当前目录干净到“看不懂的是问题”为止。首先要确保目录用 Git 管理。Claude Code 在识别“你改了哪些文件”时高度依赖 git diff如果目录没有 .git它能用的线索就少很多。其次把无关目录写进忽略规则比如在项目根目录的.gitignore或者 Claude Code 的项目记忆文件CLAUDE.md里明确写“不要读 dist/、vendor/、node_modules/”。这个步骤别看简单实际能省你一半的 token 预算。最后把当前分支切到要审查的功能分支确保git status没挂着一堆没提交的乱改否则它会把临时调试代码也当成正式代码来骂。2.3 安装过程中最容易踩的几个坑我先说一个最典型的自动更新失败报错auto-update failed: no write permission to npm prefix。这个错几乎都出在用系统级 Node 加全局安装上常见于直接用 apt 装 node 或者 Node 装在/usr/lib这类需要 root 才能写入的位置。Claude Code 启动时会尝试自己更新但没有写入权限就直接失败。千万别用sudo npm install -g硬扛那只会把权限问题绕开一时后面每次更新还要再 sudo。最省心的做法是用 nvm 安装 Node把全局包目录落在用户自己的目录下。执行完claude --version后再重启终端如果更新提示消失就说明权限这关过了。第二个坑是 Ubuntu 系统里装完命令找不到。claude装完在当前 shell 里能用重开一个终端就 command not found多半是 npm 的全局 bin 目录不在 PATH 里。执行npm bin -g看一下实际路径然后把它导进~/.bashrc或~/.zshrc就行这段内容每个项目都通用。第三个坑是网络层面的npm 下载慢或者超时。这个只要把 npm registry 切换成国内更容易访问的镜像源就能解决属于所有 Node 项目通用的操作跟 Claude Code 本身无关但新手常常在这里被卡住。还有一个不太起眼但烦人的问题VS Code 扩展装了但侧边栏不出现。多半是扩展版本和 CLI 版本不匹配去扩展市场更新到最新版再重启一次开发窗口基本能解决。3. 正式开工让 Claude Code 从“会写”切换到“会审”3.1 审查之前我建议你先做这三步很多人把审查想得特别简单对着终端说一句“帮我看看代码”就完了。结果回来的往往是一堆正确的废话请您多写注释建议提升代码可维护性。问题出在任务边界太模糊。Claude Code 确实能读项目但“看看”没有告诉它该往哪里看也没有告诉它你有多下得去手。我的第一步是做清场把本次审查改成单独一个 Session免得之前对话里的旧上下文污染判断。Claude Code 终端里可以执行/clear快速开新会话。第二步是给它一个范围比如“只审 git diff 里新增和修改的部分”或者“只审 src/export 目录和调用它的地方”。范围越小深度越深这个规律在 AI 审查里同样适用。第三步是先把项目背景交代成文字不用很长三五行就够例如“此项目是一个订单同步工具数据库表由另一个团队维护改动目标是修正退款后订单状态不更新的问题”。别觉得多此一举这行背景直接影响它判断哪些是业务约束哪些是坏味道。3.2 一份亲自试过、能直接抄的审查指令模板下面这个指令模板我最近每次提交 MR 前都会用直接放在 Claude Code 的交互窗口里发过去请以资深代码审查者的身份审查当前项目的 src/app/ 目录。 重点检查最近一次 git diff 涉及的所有文件不要只挑你熟悉的语言。 审查维度按优先级排列 1. 安全SQL 注入、命令注入、路径遍历、敏感信息硬编码、缺失鉴权 2. 健壮性异常被吞、边界输入、空指针、资源泄漏、并发问题 3. 可维护性函数职责是否单一、命名是否词不达意、是否存在复制粘贴结构、魔法数字 输出格式要求 - 每个发现给出文件路径:行号 / 严重级别critical/major/minor/ 问题描述 / 触发条件 / 修复建议 - 最后按严重级别排序并标注哪些可以后置处理 - 禁止直接改代码只输出报告等我确认后你再动手 另外可以毒舌一点挑毛病别客气。最后这句“毒舌一点”才是事故的导火索。Claude Code 收到指令后先是读了一遍 diff紧接着就开始按文件编号输出问题列表措辞非常直白比如“这个函数用 20 多个布尔型形参很难想象它面对的是一堆订单而不是一个灾难现场”。这些话虽然刻薄但不得不承认它每条都砸在我心虚的位置上。至于执行方式你可以在交互模式里直接粘贴上面这段也可以用单次执行模式claude -p 请按模板审查 src/app/重点看 git diff要求输出带行号的报告单次模式适合后续把审查流程写进脚本跑完一个 diff 直接出一份报告不占用交互窗口。3.3 现场实录它到底骂了什么我挑几段有代表性的记录放这里保持原话的战场气氛。第一段是目录下的src/export/job.pysrc/export/job.py:42-55 CRITICAL - 你在 WHERE 条件里直接拼接了 date_range 参数。 这个值来自前端请求参数虽然你外层加了 int() 看起来像防御但类型和值安全是两回事。 如果某天调用方传进来一个带引号的字符串这条 SQL 可以直接变成考勤表的独白。第二段是在我自己觉得最得意的状态机函数上src/order/status.py:120-180 MAJOR - 这个函数的职责是“状态迁移”但我看到的是 一半在算状态、一半在写日志、四分之一在给未知异常擦屁股。 建议拆成 process_transition、validate_transition、persist_transition 三个步骤 否则下一个维护者会需要在你的思维迷宫里自带声呐。第三段是关于单元测试的tests/test_order.py:32-45 MINOR - 这个测试叫 test_refund_after_cancel 但断言只覆盖了返回值没覆盖数据库行里的最终状态。 你在假装测试业务其实在测试赋值语句。被它一条条这么捋下来我当时的表情管理基本失控。可我冷静下来之后又不得不承认这些批评在人工 Review 里我可能挨一轮也未必能听全因为它瞄准的不是“风格”而是“我写的这段代码在其他场景下真的会出事”。它最后还在报告末尾补了一句“整体看下来模块最大的风险不是逻辑复杂而是你自己对这段代码失去了控制感。”这句话比前面所有行号加起来都扎心。4. 被骂之后的代码体检报告Claude Code 抓到了什么4.1 印象最深的四类问题我把它骂出来的几十条意见去重之后归纳成四类基本可以反映多数后端业务代码的常见病。第一类是安全层面的字符串拼接。我那个订单导出模块里有一处查询历史订单时拼日期区间自测时传入的值永远是自己生成的日期字符串所以没出问题。但 Claude Code 指出的触发条件很清晰这个导出功能是给运营同事用的入口虽然做了权限校验但没人保证未来不会增加新的调用方。真要出事就是一条 SQL 能把你整个订单表拖出来。第二类是接口约定不清晰。有些函数成功时返回 dict失败时返回 None还有一种失败情况会抛异常。调用方想安全使用得同时防御三种情况结果就是每个调用处都有 try-except 配合 if result is None代码量翻倍还容易漏。第三类是异常被吞。我写过太多except Exception: pass或者只print(e)就以为把错误处理好了Claude Code 会直接指出这个异常吞掉后上层拿到的 null 会被当成正常数据继续流转。这个提醒让我意识到失败的日志不是给机器看的是给出事之后凌晨三点爬起来查问题的你看的。第四类是命名和注释的懒惰。变量叫temp1、data、result注释写的是“如果状态不对就等下重试”它看过之后点评注释描述的是现象不是意图任何人维护这段代码都一样不知道为什么会重试。这类问题技术上不致命却会让维护成本悄悄膨胀。我把这四类问题整理成了一个小表格方便你对照自查问题类别典型表现触发后果修复思路参数拼接SQL/命令里拼接外部输入注入风险参数化查询或用内置转义返回类型混乱成功 dict、失败 None、异常三态并存调用处防御代码爆炸统一返回值异常交给上层异常被吞except 后无日志或无处理问题被掩盖链路无感知记录日志或让错误快速失败命名与注释失效temp1/data 横行维护者无法理解意图讲意图不讲现象4.2 一个重构例子从被骂到通过拿被骂得最狠的那段来演示。原始代码逻辑很简单根据用户 ID 和行为类型查最近一条操作记录并返回。我最初的版本长这样简化过def get_user_action(user_id, action_type): if user_id is None: return None sql SELECT * FROM user_action WHERE user_id str(user_id) AND action_type action_type ORDER BY id DESC LIMIT 1 result db.query(sql) if not result: return None data result[0] if action_type login: data[ip] data[ip].split(,)[0].strip() return dataClaude Code 对这段代码的意见共有 6 条核心三条是SQL 注入风险、参数为 None 时返回类型不统一导致调用方可能对 None 调用方法、以及函数隐式地承担了数据清洗职责。之后我按它的思路重构def get_user_action(user_id: int, action_type: str) - UserAction | None: if not isinstance(user_id, int) or user_id 0: raise ValueError(user_id must be a positive int) sql SELECT id, user_id, action_type, ip, created_at FROM user_action WHERE user_id :user_id AND action_type :action_type ORDER BY id DESC LIMIT 1 params {user_id: user_id, action_type: action_type} with db.cursor(persistentTrue) as cursor: cursor.execute(sql, params) row cursor.fetchone() if row is None: return None return UserAction.from_row(row).normalized_ip()改完之后返回类型统一了SQL 改成了参数化脏地址的清洗逻辑也从查询函数挪到领域对象的方法中。它再审了一遍这次只给了一个 minor 建议可以给返回对象加缓存。说实话这个重构质量比我平时自己改两个小时的还要稳。关键是它把“为什么这么改”讲得清清楚楚我不需要猜只需要判断它说得对不对。4.3 哪些是误报哪些才是真痛点AI 审得再准也不可能是圣旨。我在被骂得灰头土脸之后留了个心眼把输出结果逐条对照真实代码标记了一遍发现大概有百分之二十是误报或对项目的理解偏差。最典型的误报是它判定某处缺少鉴权但那个函数在网关层已经统一处理过 Token 校验Claude Code 看不到网关的配置自然认为裸奔。这种问题只要点开代码确认一次就能排除。还有一种常见误报是它把项目已经认可的重复模式重复提出来这段代码和另一段很像建议合并。但两个业务字段虽然相同后续迭代方向却完全不同强行抽公共类反而引入耦合。这类建议我会回给它一句不要改这个保持现状。它也会接受不会揪着不放。但反过来我发现自己对误报的容忍度其实应该更高一些。因为即便百分之二十是错剩下百分之八十也是真的痛点尤其是跨文件调用链路上我根本意识不到的问题。真痛点往往藏在我以为没问题的地方比如我从不怀疑的参数拼接、业务异常那一刻的盲目吞掉、以及一个函数居然同时承担着数据读取与字段清洗的杂活。人工 Review 时这种问题要看运气AI 不会漏。5. AI 代码审查的边界与协作经验5.1 它和人工 Review 的差异在哪儿我用了一个多月之后对这件事的定位越来越清晰Claude Code 审查不是用来替代人工 Review 的它更像一个不知疲倦的预审员帮你在走到正式评审之前把所有低级雷扫一遍。人工 Review 的价值在于业务判断和工程师之间的默契比如“这个需求其实没必要这样建模”“这块逻辑下周就会被新规则替代别浪费时间去抽象”。AI 没有这个业务嗅觉它只能在安全、健壮性、可维护性这些通用尺度上把住底线。如果把两者放在一起比较区别大概是这样的人工评审能理解上下文能在“这里技术不好看但业务必须这么搞”时妥协AI 不吃这一套你觉得是妥协的东西它只会从代码质量维度向你开火。反过来人工评审会累、会漏看到第 2000 行的时候注意力已经下线了AI 不会。我的结论是把 AI 审查当成第一道防线把人工 Review 的精力留给架构和业务产出最高人也轻松。现在组里偶尔让我 review 别人的 MR我会先让 Claude Code 过一遍再带着它的报告去看代码效率提升非常明显。5.2 怎么让审查结果更可用指令模板与 CLAUDE.md想让 AI 审得更准只靠每次临场输入指令是不够的。Claude Code 支持项目记忆文件CLAUDE.md你可以在里面写下项目约定、技术栈和已知的注意事项它每次进入项目都会优先读这个文件。我把我常用的项目约定写进去之后再跑审查误报率肉眼可见地降了而且它还会反过来用这些约定去衡量代码是否一致。比如我那个订单同步项目里的CLAUDE.md长这样# 项目约定 - 语言与框架Python 3.11SQLAlchemy 2.x - 时间字段一律使用 UTC 存储时区转换只在展示层做 - 所有数据库操作必须使用参数化查询禁止字符串拼接 SQL - 状态迁移逻辑集中在 src/order/transitions.py不允许散落在视图层 - 日志规范异常必须记录 stacktrace禁止 except Exception: pass - 单元测试对业务状态迁移要断言数据库最终状态不能只断言返回值写进去之后它后来审到一处页面前端时主动提醒我有一处把本地时间直接写进了数据库。这个发现如果靠我个人人工想很难想起来因为我一直只关注后端逻辑。模板固化也很重要我上面那个审查指令现在已经写成一个 shell 脚本每次提交前跑一遍生成的报告自动存到docs/review/下方便回溯。5.3 我的取舍标准和实操习惯现在我的工作流大体是这样的本地开发跑通功能之后先自己按模板让 Claude Code 审一遍critical 级别的问题立刻修major 级别的问题确认触发条件后决定要不要修minor 级别的问题攒着两周集中清一次。它对代码的所有修改建议我都不会直接答应必须是看懂了、确认有复现条件才说按这个方案改。毕竟它改出来的代码风格可能和我不完全一致业务注释也可能写得比岗位说明书还抽象。我还有一个不交给 AI 的清单涉及支付金额、优惠券叠加逻辑、权限角色边界这类业务模型不要全权交给它决定。它可以给建议但最终的那个“是”必须由人按下。这些边界说到底不是技术边界而是责任边界。AI 可以帮你审出很多问题但它不会在凌晨 2 点被人电话叫醒。这里再分享一个实用习惯每次启动审查前我都会在项目根目录跑一下git diff --stat确认改动范围确实是我预期的那几份文件。如果 diff 里混进了意外的文件优先处理掉再让 AI 看。否则它会把别人改的代码也算到你头上报告里出现一些你看不懂的条目白白浪费一轮对话。这个习惯帮我省了至少三次澄清时间。6. 常见问题速查与避坑技巧6.1 安装与运行问题速查表报错或现象原因解法auto-update failed: no write permission to npm prefixnpm 全局目录无写权限用 nvm 重装 Node避免sudo npm install -g重启终端确认运行claude提示 command not foundnpm 全局 bin 不在 PATH执行npm bin -g拿到真实路径加入~/.bashrc或~/.zshrc换一个目录就找不到历史会话每个目录是独立工作区在目标项目根目录启动claude查看历史会话可用claude --continue某些版本提到启动cowork失败版本功能命名有变化直接执行claude进入默认工作区用/查看当前版本支持的命令npm 安装时下载慢或超时registry 连接不畅把 registry 切换为可用的镜像源再执行安装命令VS Code 扩展侧边栏不出现扩展和 CLI 版本不匹配更新扩展到最新版重启开发窗口这几条都是我实际踩过或身边同事踩过的坑写出来帮大家省几分钟调试心情。6.2 审查结果太水的时候怎么办有几种情况会让 AI 审查变得沉默或只会夸夸其谈一是项目太大超出了一次上下文窗口它看了开头忘了结尾二是目录不够干净它忙着分辨 node_modules 里的代码三是你的指令太宽泛。对应解法也直接缩小范围一次只审一个 diff 或一个目录先把无关目录写进忽略规则把指令改成上面那种带严重级别和输出格式的模板。如果在某次审查中它给出的问题太少我一般会追加一句“请在安全维度再检查一遍所有数据库操作”逼它重新聚焦。还有一个场景是它已经对整个目录生成过报告你想再让它深挖单个文件但它已经开始偷懒只输出“整体质量不错”。这时候不要重复问同一个问题而是换一种输入比如把那个文件粘贴进新会话改成这样的 prompt请只审查这一个文件逐行阅读忽略格式问题专注逻辑漏洞。单文件上下文较短它的专注度会明显更高。审查反馈较好。另外对已经提交的老代码Claude Code 通常比对新增代码宽容因为它默认老代码是已存在的现状。想让它对老代码也严格一点可以在指令里明确写“不要因为历史代码就降低标准”否则你只会得到一份建议优化而不是逐行点名。6.3 一句话场景总结如果你是刚接触 Claude Code 的新手先别急着让它帮你狂写功能让它先审一次你已经写完的代码。这个反向操作看起来绕路实际上是最快的上手路径。因为审查场景会逼它读目录、理解调用链、输出结构化报告你顺便也就看懂了 Claude Code 擅长什么、会瞎猜什么、需要你补充什么背景。等你能把一份审查报告收到心里有数再让它帮你写新模块你会写得比现在放心得多。那天下午被它骂完之后我把订单导出模块重写了一遍提交前又让它复查。它这次没有骂人只说“当前没有发现 critical 或 major 问题”。就这样一句冷淡的认可我竟然比听到同事夸我写得还行还高兴。现在我已经把 AI 审查设成提交代码前的默认动作人工 Review 的精力全部留给架构和业务设计。如果团队里还没有这套流程我建议你今晚就把 Claude Code 打开挑一个自己最近写的小模块试试。被骂这件事多经历几次代码是真的会变好。