最近总有同事跟我诉苦说自己的代码越写越烂需求急的时候先堆一坨改 bug 的时候再糊一层过上俩月回头一看连自己都认不出那是什么。我以前也这样直到我开始让 Claude 当我的代码审查员这个习惯彻底改变了我的编码方式。它不仅能一眼看出代码里的坏味道还能直接给我一份简化后的版本甚至把重构完的代码都替我写好了。今天我就把这一整套用法完整拆给你从环境准备、审查提示词怎么写再到怎么让它“顺手”改出简洁代码全程用真实案例说话。无论你是一个刚入行的新手还是已经要承担代码评审任务的组长只要你想让手头的代码质量往上走这篇文章都值得你花十分钟看完。这里没有高大上的理论全都是我踩过坑之后总结出来的实操经验。1. 为什么你的代码会越写越烂以及为什么需要AI审查1.1 代码腐化的真相不是你不努力是缺一双“旁观者眼”写代码这事和写文章很像。你自己写完初稿总是很难客观地发现毛病因为“刚才我就是这么想的”这种思维惯性会牢牢锁住你的视角。代码越写越烂往往不是因为技术能力不行而是因为你在代码里陷得太深缺少一个上帝视角的第三方来指出问题。我见过太多“坏味道”在项目里安家落户。比如一个函数体膨胀到三四百行里面塞了七八个嵌套 if比如某个状态处理逻辑在变更需求时被复制粘贴出现四次每次还有微妙的差异比如变量名从data进化到data2再从data2变成final_data_v3。这些问题的根源大多是开发时只想着“赶紧让功能跑起来”根本没有余力考虑可读性、扩展性和重复度。等到想重构的时候又害怕改出 bug于是继续在烂地基上盖楼越盖越歪。代码评审就是来治这个病的。正常流程里同事会帮你挑毛病但在真实的项目节奏中人工评审很难真正落地。一是大家都忙挤出半小时看一段不熟悉的代码效率很低二是面子问题互相指出问题容易让人际关系紧张三是思维定式同事之间往往用着同一套编码习惯你踩的坑他也可能正在踩审查效果自然大打折扣。1.2 人工代码审查的痛点AI正好补上人工审查有痛点而 AI 代码审查恰好能在很大程度上补齐这些短板。以大语言模型 Claude 为例它没有情绪不会因为不好意思就放过问题代码它也不会疲劳你扔给它 1000 行代码它也能保持初见识时的敏锐度。更关键的是它的知识库覆盖了海量开源项目和技术文档所以对各种“代码坏味道”的识别能力往往超出普通开发者。我最早尝试用 Claude 做审查其实就是抱着试试看的心理。把一段写得特别绕的函数丢给它它居然能从“重复代码”“嵌套过深”“魔法数字”三个维度列出一份清晰的评审清单比我那些效率手册靠谱多了。后来我慢慢总结出了经验Claude 特别擅长做“第一道过滤器”先把明显的问题扫出来我再针对它给的清单去做人工确认。这样既节省了精力又不会因为过度信任 AI 而把错误改进去。2. 把Claude调教成你的专属代码审查员准备与配置2.1 三种实操形态网页版、API、Code插件怎么选首先要明确用 Claude 做代码审查不是只有一种方式。我平时用过三种形态各有各的适用场景你按自己的习惯选就行。网页版 Claude是最容易上手的。直接打开你的 Claude 对话界面把代码粘进去加上提示词就能开工。它的优势是零配置、适合快速发一句“帮我看下这段代码”但缺点也明显长代码粘贴进去容易超出上下文窗口而且每轮都要手动复制粘贴效率不算高。更适合偶尔用一用、或者在做代码复盘时做深度问答。Claude API则适合批量化和自动化。如果你是个喜欢折腾的人可以写一个脚本把仓库里的代码文件遍历一遍批量发给 Claude 审查再把结果汇总成 Markdown 报告。这个方案非常灵活你可以控制模型参数、上下文长度也能结合自己的团队规范自定义审查规则。不过它对编程水平有一定要求至少要会点 Python 或 Node.js能处理接口调用和文本拼装。Claude Code 插件VS Code 版是我现在的主力工具。直接在编辑器里选中一段代码呼出 Claude 对话它就能基于完整文件甚至项目上下文给出审查意见。最爽的是它支持直接生成 diff你确认后一键应用省掉了拷来拷去的麻烦。如果你日常就在 VS Code 里写代码这绝对是效率最高的方式。三种形态之间可以组合使用。比如我用插件做日常实时审查用 API 做提交前的全量扫描遇到特别复杂的重构问题时再回到网页版慢慢追问原理。最关键的是无论哪种形态提示词都是决定审查质量的核心变量下面我详细讲怎么喂代码。2.2 给Claude“喂”代码的正确姿势上下文、格式、权限很多人觉得 AI 没审查好其实是“投喂”的姿势有问题。Claude 再聪明也需要你说清楚背景、目标和约束否则它只能给出泛泛而谈的建议。第一步说明项目背景。不要直接甩代码。先交代清楚这是什么项目、用的什么语言和框架、这个函数在业务里扮演什么角色。比如你可以写“这是一个订单处理模块里的函数输入是标准化的订单列表输出是用于展示的价格明细。”背景给得越具体Claude 的审查就越有针对性。第二步用代码块包好代码。我在提示词里永远用三个反引号包住代码标注语言类型。这样 Claude 能准确识别语法不会出现因为格式混乱导致的误判。如果是大文件我建议只粘贴核心函数或者类别把整个文件全塞进去上下文超长之后 Claude 容易丢前忘后。第三步明确审查维度和输出格式。如果你只说“帮我看看代码”它大概率给你一句“整体不错但可以改进”。这没什么用。我会给它一个非常明确的审查列表比如要求从可读性、重复度、嵌套复杂度、边界情况、命名规范五个维度来评估并要求每一条都标注严重程度输出格式用“问题清单 修改建议”。第四步设定边界条件。最重要的一点是告诉它哪些不能动。比如“不要改变函数的对外接口”“不要引入新的依赖”“不要修改业务逻辑只做结构优化”。如果你不设边界Claude 很可能自作主张把整个实现换了个写法看似精简了但行为变了测试挂了那就得不偿失。3. 一次完整的AI审查实战从“烂代码”到“简洁代码”3.1 实战案例一个典型的烂代码长什么样纸上谈兵没意思我准备了一个非常典型的例子。这是一个处理订单数据的函数业务逻辑不复杂但代码被写得很糟糕。你一看就知道这就是“需求催出来的代码”def process_data(data): result [] for item in data: if item[type] A: if item[value] 10: price item[value] * 0.9 if item.get(discount): price price * 0.95 result.append({name: item[name], price: price}) else: price item[value] result.append({name: item[name], price: price}) elif item[type] B: if item[value] 10: price item[value] * 0.8 if item.get(discount): price price * 0.9 result.append({name: item[name], price: price}) else: price item[value] result.append({name: item[name], price: price}) else: price item[value] result.append({name: item[name], price: price}) return result这段代码有什么问题第一A、B 两个分支的 if-else 结构几乎完全相同只有折扣率数字不同典型的重复代码。第二嵌套层数最多达到了四层读起来非常费劲。第三0.9、0.8、0.95这些魔法数字散落在逻辑里改配置时还得逐个找。第四type A和type B的处理逻辑都是“如果 value 大于 10 就打折”逻辑完全可以合并。这些坏味道叠加在一起就是将来线上 bug 的温床。3.2 Claude的审查意见我的提示词和输出我先把这段代码粘贴给 Claude配套提示词如下你是一位有10年经验的资深代码审查员。请审查下面的Python函数 重点关注 1. 代码重复和可维护性 2. 嵌套层级和复杂度 3. 命名和可读性 4. 潜在边界条件错误 不要直接改代码先列出问题清单然后给出重构建议。Claude 的输出大致是这样的重复代码A 与 B 的处理分支仅在折扣系数上不同导致if price 10和附加折扣的逻辑被复制了两遍。建议将类型对应的折扣率提取为映射表或者配置常量。嵌套过深for if if if一共四层嵌套违反“卫语句 提前返回”的常见实践建议用卫语句减少分支层数。魔法数字0.9、0.8、0.95散落在逻辑中建议定义成有业务含义的常量避免后续调整折扣时到处翻代码。可读性变量名data、item、result虽然不算错但语义太泛。更关键的是打折条件“value 10”没有说明含义建议提取为MIN_PRICE_FOR_DISCOUNT这样的常量。你看这四条意见条条都在点子上。如果这些话出自一位老同事之口你可能会觉得被教训了但 AI 说出来反而让你更容易心平气和地接受。3.3 如何让Claude“顺手帮你改简单”diff级别的修改请求列出问题只是第一步真正爽的是让 Claude 直接给优化代码。我不能让它推翻重写所以规定了边界请根据你前面的审查建议给出优化后的完整代码。 注意 1. 保持函数名和外部行为不变。 2. 不要引入第三方库。 3. 用diff格式输出让我可以直接查看改动。Claude 生成的简化版本是这样的MIN_PRICE_FOR_DISCOUNT 10 DISCOUNT_RATE {A: 0.9, B: 0.8} EXTRA_DISCOUNT_RATE 0.95 def process_data(data): result [] for item in data: price item[value] rate DISCOUNT_RATE.get(item[type]) if rate and price MIN_PRICE_FOR_DISCOUNT: price * rate if item.get(discount): price * EXTRA_DISCOUNT_RATE result.append({name: item[name], price: price}) return result这段代码比原来的短了将近一半而且逻辑清清楚楚。它把不同折扣率抽成了一个字典把魔法数字变成了常量把原来的两个分支合并成统一处理可读性和可维护性都上来了。最妙的是由于我用的是“保持外部行为不变”这个限制条件这个简化版本对输入输出的处理逻辑与原来完全一致可以直接替换。但我要提醒你一句如果项目里某个 type 没有对应折扣率DISCOUNT_RATE.get(item[type])返回的是 None这样rate and price MIN这个判断会直接跳过折扣结果就是原价——这跟原来else分支的处理结果是一样的所以边界行为也对得上。这就是为什么我强烈建议你在让 Claude 改完代码之后一定要自己检查 diff甚至跑一遍测试而不是闭着眼应用。4. AI审查必须避开的坑Claude不是神别让它瞎改4.1 常见问题与排查思路速查表用了这么长时间我也踩过不少坑。下面这张表是我总结出来的高频问题供你参考问题现象根源解决思路Claude 给出的修改建议很空泛提示词维度不明确指定五个具体审查维度并要求输出“问题清单严重程度”改完代码业务逻辑变了没有限定“保持外部行为不变”提示词加上“只做结构优化不改变输入输出逻辑”上下文太长导致 Claude 丢信息一次粘贴了多个超大文件按函数/模块拆分审查或者缩小上下文范围Claude 自作主张引入第三方库没有设置依赖约束明确写出“禁止引入新的依赖”输出经常中断只生成一半代码代码超长或上下文窗口接近上限拆成多个子函数分别让 Claude 审查或者改用 API 调大 max_tokens修改后代码风格不统一没有提供项目自身的编码规范在提示词里附上项目的风格规范或代码片段作为参考如果遇到 Claude 开始“天马行空”地重构比如把函数改成类、把显式循环改成列表推导式甚至改成了完全不同的算法架构先别急着骂它。你要做的是把约束条件重新声明一遍或者让它先解释清楚“你打算怎么改”确认思路之后再动手。AI 不是每次都想得对但它至少能当你的“方案讨论伙伴”帮你预先演练到底几种改法更合理。4.2 我的独家技巧如何让Claude改得“稳准狠”经过反复实践我总结了一套让 Claude 高效改“烂代码”的提示词模板直接抄就行请扮演一位代码审查专家对我的代码进行审查并直接优化。 背景这是{{项目名}}项目中的{{函数/模块}}负责{{业务功能}}。 要求 1. 先输出当前代码存在的主要问题列出3-5条按严重程度排序 2. 然后给出优化后的完整代码 3. 要求保持函数签名和外部行为完全不变 4. 不要引入第三方依赖 5. 输出请包含一个 diff 或改造说明方便我理解每处变动的理由。这套提示词最关键的是“先列问题再给代码”因为 Claude 一旦直接改代码很容易“闷头干”而忽略解释。让它先列问题相当于强迫它进行“诊断”等诊断结果确认了后面的修改自然更有依据。还有一个技巧是“层级审查”。对于大项目别让 Claude 一口气审查整个仓库而是先让它审查某个目录下的模块然后再逐个函数深挖。你会发现把大问题拆成小问题后Claude 的表现会稳很多修改的正确率也高。我习惯用它的 “Claude Code” 配合 Git 提交的 diff 做源码门禁每次 commit 之前让 Claude 扫一遍本次改动其实比事后补审查更有价值。另外不要盲目相信 Claude 的“简化”。它有时会把一个本来清晰的循环改成嵌套推导式看着很炫但可读性差了好多。这种时候你就要用追加问题把它掰回来“这个列表推导式虽然短但不容易理解请返回可读性优先的版本。” AI 很吃“风格偏好”这一套你明确告诉它你想要什么它往往就能给出符合预期的结果。写在最后我的真实体验其实说实话刚开始用 Claude 做代码审查那阵子我心里也嘀咕这玩意是不是就是个高级版 “查错工具”但用久了之后我发现它的价值不只在“改代码”上更多是改变了我的编码习惯。因为每次写完代码我都会不自觉地想一想如果 Claude 来评审它会说我哪里写得重复哪里嵌套太深哪些魔法数字会挨批这种“预防式审查”的心理暗示反而让我在写第一遍代码时就尽量写得干净一点。我也因为太信任 AI 吃过亏。有一次在重构一个支付模块时我手动确认了 Claude 生成的简化代码自认为逻辑没有变结果没注意它把if rate and price MIN中的rate判断条件给合并掉了导致某类订单直接跳过折扣。幸好测试用例把我拉回来了。所以我现在有个规矩Claude 改完代码必须跑一遍全量测试然后人工阅读 diff 逐行确认再入库。如果你现在也在苦恼“代码越写越烂”我建议你今天就试一试让 Claude 当你的代码审查员。先从一个小函数开始按我给的提示词跑一遍感受一下它的输出质量。等你习惯了这套流程再用到核心模块上。相信我它不会直接让你的代码变成诗但能帮你把那些臭不可闻的“坏味道”一点点揪出来改着改着你的代码自然就简洁了。