企业官网建设流程全解析

1. 先想清楚：AI 代码审查到底替你扛哪部分活

我算过一笔账：过去三个月，我平均每天要花一个小时左右看同事的 PR，还不算 review 意见来回沟通的时间。时间久了你会发现，大部分 review 意见其实是重复劳动——要么是低级 bug 没人发现，要么是代码风格、错误处理方式不统一。真正需要人深度思考的架构层意见，可能一周也就那么一两条。于是我开始尝试用 Claude Code 做自动化代码审查，把 AI 当成一个 7×24 小时在线的初筛审查者。

这篇文章我会把整套实践过程完整讲一遍：从最开始的定位思考，到环境配置、审查提示词设计、接入 Git 工作流，再到跑了三个月之后看到的真实效果和踩过的坑。内容主要面向有过基本代码审查经验、想用 AI 减轻日常负担的开发者和技术团队负责人，也适合刚接触 Claude Code、想找一个正经落地场景的新手。

1.1 人工审查的三种痛，恰好都是 AI 的强项

我印象特别深的一次：某次上线前，一个同事在讨论区问"这个字段会不会是 null"，大家各自埋头看代码，半小时后才发现问题确实存在——而那个改动其实已经合并三天了。这类低级问题流失在人工审查里太常见了，因为人的注意力会被更复杂的东西占满。你看到一段写得漂亮的算法时，很容易忽略旁边那个空 catch 块。人的注意力是有限的，这不是态度问题。

AI 审查正好补在点上。它不会因为"这段代码看起来熟"就跳过检查，不会因为写代码的人是你朋友就不好意思提意见，更不会看了十行就开始惦记午餐。同一份 diff 你让它审十次，它的标准基本稳定。这三个特性——不疲劳、无情绪、标准一致——恰好就是代码审查最需要的品质。

1.2 AI 看不懂业务，所以别让它做架构决策

但也有非常明确的天花板。Claude Code 看一段 diff，能判断"这里可能抛异常""这里并发计数会丢"，但它判断不了"这个支付流程为什么要拆成两个服务"。业务上下文、历史包袱、产品决策，这些信息散布在几十个文件的注释里、几年前的讨论记录里，甚至只在某个老同事的脑子里。指望 AI 理解这些，是把工具用错了方向。

所以我的定位很明确：AI 负责第一遍初筛，专注缺陷层和一致性；人负责第二遍，专注架构层和业务语义。人这一遍因为不用再花时间找低级 bug，效率反而高了很多。为了方便团队理解，我把两类审查拆成了对比表。

这张表也直接决定了后面的所有配置方向：凡是"有客观标准"的检查都可以交给 AI，凡是"需要业务判断"的地方都要留给人。

1.3 哪些 PR 适合先上 AI，哪些不适合

我建议从"中小型、自包含"的改动开始试点。比如一个新增的接口、一个工具函数库的补充、一次内部重构这种，改动范围在几个文件以内，逻辑相对独立，AI 的审查准确率会高很多。跨模块的大改动、带着复杂迁移的 PR，AI 容易只见树木不见森林——它看每个文件都合理，但组合起来可能把整个架构带偏。

这类大 PR 我现在的做法是：拆成多次小 PR，或者至少让 AI 按文件逐个给意见，然后人来做全局整合判断。一句话，AI 审查最适合"diff 小、上下文清晰、规则明确"的场景。

2. 从零跑通第一条审查命令：环境配置与最小脚本

2.1 安装与授权：真正卡住人的通常是这一步

Claude Code 的安装本身不算复杂：装好命令行工具后，终端里执行claude命令，它会引导你完成登录授权。授权通过之后，同一个账号下的对话历史、项目配置都会同步。这里我想提醒的是，自动化审查和你自己手敲命令的场景不太一样——手动用的时候，出了错你还能现场改，自动化的脚本里如果授权过期了，CI 任务会在半夜悄悄红掉，你得第二天早上才发现。

所以我把授权相关的检查写成了脚本第一步：每次审查前先执行claude --version和一次极短的连通性请求，确认工具可用再继续。这个检查成本几乎为零，但能避免大量"脚本跑了一半才报错"的尴尬。另外，如果团队成员比较多，建议把账号策略提前定好，别让每个人用自己的个人额度去跑团队流水线，否则月底账单出来的时候，负责的同事会非常被动。

2.2 第一条审查命令：从"随便聊聊"到"按标准审 diff"

装好后，先在仓库里手动跑一次，找感觉。我最开始直接用最朴素的问法：

cd my-project claude -p "请审查当前工作区的代码变更，给出问题清单"

这个命令能跑通，但结果基本没法用。它会东聊一句西聊一句，甚至给出"代码整体质量不错"这种正确的废话。原因很简单：你没有告诉它审查的标准是什么、输出格式是什么、关注点在哪里。AI 不是你肚子里的蛔虫，你不把"什么叫一次合格的审查"讲清楚，它就只能凭通用常识瞎猜。

正确的第一步，是先把审查规则写明白，用一条完整指令去测。我把我们团队的第一版审查提示词写成了单独文件，然后用命令直接读取文件内容加上 diff 一起丢给它。这样改规则不用改脚本，维护起来舒服得多。

2.3 最小可用的审查脚本：能放进 crontab 的那种

经过几轮迭代，我在本地用的是一个很朴素的 bash 脚本。它的逻辑只有四件事：确认工具可用、取到基线分支与当前分支的 diff、拼接提示词和 diff、把结果输出到终端或文件。

#!/bin/bash # review-diff.sh - 审查目标分支相对基线分支的代码变更 set -euo pipefail BASE_BRANCH="${1:-main}" OUTPUT_FILE="${2:-review-report.md}" # 1. 环境自检 if ! command -v claude &> /dev/null; then echo "claude 命令不存在，请先安装并完成授权" >&2 exit 1 fi # 2. 取 diff git fetch origin "$BASE_BRANCH" --quiet DIFF_BODY=$(git diff "origin/$BASE_BRANCH...HEAD" -- .) if [ -z "$DIFF_BODY" ]; then echo "没有检测到代码变更，退出" >&2 exit 0 fi # 3. 拼接提示词 REVIEW_PROMPT=$(cat docs/review-prompt.md) FULL_PROMPT="执行一次代码审查。\n\n【审查要求】\n${REVIEW_PROMPT}\n\n【代码 diff】\n${DIFF_BODY}" # 4. 调用 claude 并输出 claude -p "$FULL_PROMPT" --output-format text > "$OUTPUT_FILE" echo "审查报告已写入：$OUTPUT_FILE"

第一次看到自己的 diff 被 AI 审出问题的时候，你会产生一种微妙的感觉：这不是那种"帮你把代码格式化"的玩具工具，它是真的在按你的规则做事。但注意，我上面这个脚本能跑通，不代表审查质量就达标了——真正的分水岭在提示词，也就是下一节内容。

提示：git diff origin/main...HEAD用的是三点语法，表示"基线分支合并到当前分支之后，当前分支独有的变更"。如果习惯用两点语法，会把基线分支上别人已经合并的改动也带进来，审查报告会多出一堆莫名其妙的噪音。

3. 审查质量的关键：三层审查提示词的设计思路

3.1 一次审查不是一次提问，而是三件事

我最开始犯的错误，是希望一次提示词里塞进所有要求：既要查 bug，又要管风格，还要看架构，顺便把注释补上。结果就是每项都浅尝辄止，报告看起来很全面，实际上真正能落地的问题没几条。后来我把审查拆成三个层次，让 AI 分层输出，效果立刻不一样。

分层的好处有两个。第一，AI 不会把精力浪费在低价值问题上，缺陷层的意见永远优先级最高。第二，人看报告的时候可以按层跳过：我自己基本只看缺陷层和逻辑层，设计层偶尔瞄一眼；架构师同事则会重点读设计层，把 AI 的观察当作一种"统一视角的输入"。审查从"人盯代码"变成了"人盯 AI 的意见"，效率完全是两个量级。

3.2 给足上下文：diff、项目约定、输出格式三件套

层分好了，接下来是上下文。AI 审查质量高低，一半取决于你给了它什么。我固定给三样东西：代码 diff、项目约定、输出格式要求。

diff 是最核心的上下文，不用多说。项目约定是很多人会忽略的：你的团队里"正确"的标准，和别的团队可能完全相反。比如有的项目要求所有对外方法做 null 校验，有的项目默认调用方保证非空；有的团队严格要求 try-with-resources，有的项目因为历史原因全是手动 close。这些约定如果不在提示词里说明，AI 就会拿通用最佳实践硬套，结果就是一堆"与现有代码风格冲突"的建议。

输出格式要求也很关键。如果不要求标注文件行号，AI 会给你一堆"某处存在潜在风险"这种没法定位的描述；如果不要求分级，它会平均用力，把严重问题和轻微建议混在一起。我上面脚本里引用的docs/review-prompt.md，核心内容就是下面这份模板。

3.3 一份可复用的审查提示词模板

你是一位有十年经验的后端代码审查工程师。请根据下方给出的代码 diff 和项目约定，完成一次代码变更审查。 审查分三个层次，按优先级输出： 1. 缺陷层：空值处理、资源释放、异常吞掉、并发安全、边界条件、敏感信息硬编码。 2. 逻辑层：重复代码、命名一致性、接口契约是否被破坏、该改动对既有调用方的影响。 3. 设计层：职责是否清晰、耦合是否可控、是否缺少必要的单元测试。 项目约定（团队规范）： - 对外方法必须做 null 校验，内部方法不做重复校验； - 资源操作一律使用 try-with-resources 或等价写法； - catch 块禁止为空，必须记录日志或抛出可追踪异常； - 不允许在本次改动中做与需求无关的重构； - 数据库查询必须走预编译，禁止字符串拼接 SQL。 输出格式： - 先输出"严重问题"清单，再输出"改进建议"清单； - 每一条必须标注文件路径和大致行号； - 每一条必须说明"为什么这是问题"和"建议怎么改"； - 如果某一层未发现问题，明确写"未发现问题"； - 禁止输出泛泛的赞美、鼓励性话术和与代码无关的评论。 以下是代码 diff：

这份模板可以直接抄走改改。这里我要特别强调"禁止输出泛泛的赞美"这一条。AI 天生倾向于讨好，如果不明确禁止，它会在一堆无害评论里夹杂"整体实现清晰、逻辑完整"之类的废话，人看报告时还得花时间过滤。把这条写死之后，报告的信息密度立刻上来了。

3.4 审查提示词与项目说明文件的配合

除了每次拼接的提示词，Claude Code 本身支持在项目里放一个说明文件，让它在每次运行时自动读取项目背景。我会把仓库的技术栈、目录结构、常见约定写进去，这样提示词里就不用重复一大堆背景信息。比如：

# 项目背景（示例） - 技术栈：Java 17 + Spring Boot 3，构建工具 Maven； - 包结构：controller -> service -> repository 严格分层，禁止跨层调用； - 异常处理：统一由全局异常处理器捕获，service 层禁止吞异常； - 测试要求：新增业务方法必须配套单元测试。

把这类信息沉淀在项目文件里，比每次在 prompt 里现写要靠谱得多。团队新成员加入时，这份文件本身就是很好的规范文档；AI 审查时自动遵守，人也顺手受益。我见过不少团队给 AI 写了几百字 prompt 却从没整理过团队规范，这个顺序其实可以反过来——先整理规范，再把它翻译成 prompt。

4. 自动化落地：Git Hook 与 CI 流水线两条路径

4.1 路径一：pre-push Hook，留一块"后悔药"

脚本跑通之后，第一个自然的想法就是让它自动触发。最简单的方式是 Git 的 pre-push 钩子：每次git push之前，自动执行一遍审查脚本，发现问题就提示你，甚至可以选择中断推送。我的第一版实现非常粗暴：

#!/bin/bash # .git/hooks/pre-push BRANCH=$(git rev-parse --abbrev-ref HEAD) if [ "$BRANCH" = "main" ]; then exit 0 # 主干分支不做阻塞检查 fi DIFF_BODY=$(git diff origin/main...HEAD) REPORT=$(echo "$DIFF_BODY" | claude -p "$(cat docs/review-prompt.md)" --output-format text) echo "$REPORT" if echo "$REPORT" | grep -q "严重问题"; then echo "发现严重问题，推送已中止。请先修复或人工确认。" >&2 exit 1 fi

这个方案的好处是反馈链路极短，问题在提交阶段就被拦住，不用等到 CI 跑完。坏处也很明显：如果提示词写得严格，那么任何一个标为"严重问题"的项都会让整个分支推不上去，哪怕其中两条其实是误报。我第二天就因为这个被堵了一次——某位同事改了配置文件的格式，AI 把"没有使用 try-with-resources"当成了严重问题输出。

从那以后，Hook 版本我只保留"提示不中断"模式，把是否拦截的判断完全留给 CI 阶段。本地 Hook 的定位就是给开发者的第一道提醒，而不是门禁。

4.2 路径二：CI 流水线任务，把报告贴到 PR 评论里

真正作为团队门禁的是 CI 流水线。思路是：在 CI 里新增一个独立的审查任务，拉取代码后计算 diff，调用 claude 生成报告，然后把报告发布到 PR 的评论区。整个过程无人值守，合并代码的人打开 PR 就能看到 AI 的审查意见。

# CI 审查任务的关键步骤（以常见的 Git 托管平台流水线语法为例） # 步骤1：检出代码，并获取目标分支 git fetch origin main --depth=1 # 步骤2：计算当前分支相对 main 的 diff DIFF_BODY=$(git diff origin/main...HEAD -- .) # 步骤3：调用 claude 生成审查报告 REPORT=$(echo "$DIFF_BODY" | claude -p "$(cat docs/review-prompt.md)" --output-format text) # 步骤4：把报告写入文件，作为构建产物 echo "$REPORT" > ai-review-report.md # 步骤5：通过托管平台的 API，把文件内容发布到 PR 评论 # ci:api-comment "$REPORT"

实际落地时，平台差异主要集中在最后一步：有的托管平台提供现成的评论 API，有的需要借助机器人账号发帖。我们最终用的是平台自带的应用市场里一个现成的"自动评论"插件，把审查报告以 Markdown 格式贴到 PR 下，同时保留构建日志里的原始输出。

4.3 门禁怎么设：严重级别才需要卡合并

关于是否要"卡合并"，我和团队讨论过很久。第一种极端：AI 意见只是参考，不设任何拦截，靠人自觉去看。这种大概率会变成"没人看"——报告挂在 PR 下面，忙碌的开发者扫一眼标题就合并了。第二种极端：AI 发现严重问题就阻止合并。这种又会被误报折磨，需要反复调整提示词，团队沟通成本极高。

最后的折中方案是按级别分流：严重问题作为 CI 检查项之一，如果存在必须人工确认；改进建议只作为评论展示，不参与合并门禁。实现上不复杂，因为提示词里已经要求输出分级清单，CI 脚本只要在报告中检测"严重问题"小节下是否有内容即可。

这里我想说一个容易被忽略的点：自动化审查的门禁强度，必须要和团队的纠错能力匹配。人少的小团队、快速迭代的项目，卡得太死会让 AI 审查变成新的瓶颈；规模上来之后再逐步加严，反而是更平滑的路径。我们是从完全不卡，到"严重问题需确认"，再到运行稳定后把这条规则写进团队流程，一共花了大概三周。

5. 实测三个月：高价值命中、误报清单与调优过程

5.1 高价值命中：三类 AI 比人眼更稳的问题

三个月的运行记录里，AI 真正确实帮我们拦住过几次问题的类型，我总结成三类，给想评估效果的人一个参照。

第一类是"改动波及型"。一个方法签名变化，AI 能顺着 diff 和相关文件把所有调用方过一遍，找出"这里会编译失败""这里的判断逻辑失效了"。人看 diff 的时候容易只看改动点本身，而 AI 是按整个仓库的上下文来校验的。这类问题在我记录里占了大概四成。

第二类是"资源与异常型"。文件流没关、数据库连接在异常分支没释放、catch 块空着——这类问题 AI 的命中率出奇地高，因为它不是靠"记得"而是靠模式匹配。人的大脑特别容易在复杂逻辑里忽略这种"例行公事"的细节，AI 不会。

第三类是"静默错误"。最典型的是把一个函数的返回值直接丢掉了：someService.doUpdate(user)返回值表示更新是否成功，调用方没接收也没判断。这类 bug 不影响编译、不影响测试，但会在特定数据下悄悄出错。人类审查很难发现，AI 在提示词点明"注意被忽略的返回值"之后，命中率提升非常明显。

5.2 高发误报：AI 最容易"较真"的三个地方

诚实地说，误报也不少。我刚接上前两周，报告里超过一半的"严重问题"其实是误报。最常见的是三类。

一类是"风格判断当缺陷"。比如我们团队变量命名用驼峰，某个历史文件用了下划线，AI 会把"命名不一致"列为严重问题，而实际上那个文件是外部接口的映射类，根本不该改。这类误报的解法，是把这类豁免规则写进项目约定。

第二类是"过度重构建议"。AI 倾向于在小改动里建议"你是否应该提取一个工厂类""这两个方法应该合并成一个抽象接口"。对于大型重构，这类建议有价值；对于只有三十行的工具方法，它就是在制造噪音。我在提示词里加了"不进行与本次改动无关的重构建议"，压下去不少，但偶尔还会冒出来，因为模型总是倾向于表现得"更聪明"。

第三类是"上下文错位"。最常见的是把测试代码当生产代码审，或者把一个兼容性代码块当成新逻辑。这种误报很难完全消除，我们的处理方式是在 PR 描述里加一个"审查范围说明"字段，让作者注明哪些文件无需 AI 审查。

5.3 调优过程：从第一版到稳定版的四个关键改动

结合上面的问题，我把提示词迭代了四个版本。第一版只有"请审查代码并给出问题"，效果最差。第二版加了缺陷/逻辑/设计分层和输出格式要求，可用性大幅提升。第三版加入了团队约定和豁免规则，误报率开始明显下降。第四版增加了"审查范围说明"机制，允许 PR 作者标注跳过哪些文件，到这里才真正达到团队可接受的标准。

这里说一句从结果倒推的体会：不要在第一天就追求完美提示词，先跑起来，把真实的误报收集起来，再逐条"喂"回去调。AI 提示词迭代和数据标注有点像，真实样本永远比猜重要。

5.4 成本与速度：数字层面到底值不值

最后说点现实的。自动化审查不是免费的：每次调用都要消耗 token，CI 上跑一次完整审查通常消耗量不小；同时审查时间也从秒级上升到了分钟级，取决于 diff 大小和模型负载。我们当时的实测，一个五百行以内的 diff，大约要一到三分钟出完整报告，费用按调用量计算，每个月加起来相当于一个中等价位午饭的开销。比起人工审查的几个小时，这笔账怎么算都划算。

但我要提醒一点：凡是把 diff 一次性塞进去的用法，都有上下文长度上限。超过一定行数的 diff，AI 会开始截断或者忽略中段内容，给出的意见质量明显下降。所以现在超过一定规模的大 PR，我会强制提示作者拆分。这是自动化审查在生产环境里真正需要面对的"工程问题"，不只是提示词问题。

6. 团队落地前必须想明白的几件事

6.1 自动化审查是纪律问题，不是工具问题

我见过几个团队兴致勃勃地接了 AI 审查，两周之后又默默关掉，原因几乎都是同一种：报告没人看，或者意见没人改。AI 把问题找出来了，但修复仍然需要人来做，需要人来跟踪、验证、关闭。如果团队本身没有"审查意见必须逐条回复"的纪律，那么再强的审查工具也只是在制造一份注定被忽略的报告。

我们团队的做法是：把"处理 AI 审查意见"写进 PR 的完成标准里，和跑通单元测试并列。不需要每条都采纳，但每条都需要给出处理结论。这个流程很朴素，但有它之后，报告的完成率从不到三成提升到了接近九成。

6.2 人看报告的方式也要变：先 AI 后人是种新节奏

自动审查真正改变的是审查节奏。以前同事们开 PR 之后，会等着人来看，节奏以人为中心。现在 AI 在 PR 打开十几分钟内就会给出一版初审意见，人再来看的时候，等于带着一份"问题地图"读代码。有经验的同事告诉我，现在看 PR 会先花两分钟把 AI 报告过一遍，然后只挑那些"AI 没看明白的地方"重点研究，整个人的注意力使用效率完全不同。

这个转变听着简单，实际上需要团队里的所有人都调整习惯。最开始的几周总有同事不看报告就直接点合并，后来把报告作为 CI 产物并默认展示在 PR 评论区，才慢慢扭转过来。

6.3 从试点到铺开：先挑一个团队跑一个月

顺带提一句，如果你想在公司里铺开这套东西，我的建议是先挑一个对工具接受度高的团队试点，跑满一个月再开会复盘。复盘的核心问题就两个：AI 帮你省了多少时间？AI 给你添了多少麻烦？这两个数字都诚实的话，铺不铺开就很好决策了。

我自己从第一版裸提示词跑到现在的稳定配置，最大的感触是：AI 代码审查不是"装个工具就行"，它是一个不断调提示词、调流程、调人的协作方式。工具今天能用，明天模型更新了、团队规范变了，都得跟着再调。但只要把流程想清楚，让 AI 去干那些重复的、费眼睛的、不该由人来做初筛的活，整个团队的审查效率提升是肉眼可见的。