企业官网建设流程全解析

最近总有同事跟我诉苦，说自己的代码越写越烂，需求急的时候先堆一坨，改 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 开始“天马行空”地重构，比如把函数改成类、把显式循环改成列表推导式，甚至改成了完全不同的算法架构，先别急着骂它。你要做的是把约束条件重新声明一遍，或者让它先解释清楚“你打算怎么改”，确认思路之后再动手。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 当你的代码审查员。先从一个小函数开始，按我给的提示词跑一遍，感受一下它的输出质量。等你习惯了这套流程，再用到核心模块上。相信我，它不会直接让你的代码变成诗，但能帮你把那些臭不可闻的“坏味道”一点点揪出来，改着改着，你的代码自然就简洁了。