企业官网建设流程全解析

这次我们聊一个正在发生的工程问题，不是某个具体模型发布：AI 编程工具的生产速度，已经明显超过人类代码审查的速度。Claude Code、Cursor 这类工具几分钟能生成几千行代码，一个 PR 合入几百上千行变更已经是常态，但评审者还是只有一双眼睛。结果要么是 PR 排队排到深夜，要么是为了赶版本放过一批没细看的改动。两种结局都很危险。

这篇文章不评价“AI 写代码好不好”，而是给出一个相对可落地的思路：AI 生成代码占比越来越高之后，审查流程怎么重新设计。我会先梳理审查瓶颈的核心原因，再给出一套分层审查体系，包含静态门禁、LLM 语义审查、批量存量扫描、接口调用和人工抽样复核，最后提供 GitHub Actions、pre-commit、Python API 调用模板和常见问题排查表。代码可以直接复制到自己的工程里改着用。

如果你正在用 Claude Code 或类似工具写代码，或者团队里 AI 生成代码的比例已经到了一半以上，这篇文章建议收藏。它不是讲某个工具怎么安装，而是讲一套“审查不过来时怎么办”的工程方案。

1. 方案核心能力速览

简单说，这套方案的核心是把“每个 diff 都让人类看完”改成“自动化先筛掉低风险，把高风险和语义问题留给人类复查”。

2. 为什么人工审查必然成为瓶颈

AI 辅助编程带来的是代码产出量结构性上升。过去一个开发者一天产出 200 行代码，现在用 Claude Code 这类工具可能一天产出两三千行。如果团队还沿用“人肉 review 每一个 diff”的老流程，瓶颈立刻出现。

这个瓶颈有三个具体表现：

第一，审查速度跟不上提交速度。一次 PR 的 diff 超过 1000 行，Reviewer 很难在半天内仔细看完。如果一天合并 20 个 PR，人力占用会直接爆掉。

第二，注意力资源被低价值改动耗尽。真正需要人思考的往往是并发问题、安全问题、数据一致性，但 Review 页面里大量是格式变化、变量重命名、IDE 自动生成代码。人把精力花在低风险内容上，高风险问题反而容易漏。

第三，AI 生成代码存在“看似合理但语义错误”的特点。这类代码能过编译，单测可能也过，但并发边界、资源释放、异常路径可能有问题。人类审查者如果没有时间和上下文，很容易被“代码很完整”的外表带过去。

所以现在的核心问题不是“要不要让 AI 写代码”，而是要把人类审查能力从“全部检查”变成“精准干预”。

3. 适用场景与使用边界

这套方案适合以下场景：

• 团队中 AI 编程工具使用比例高，PR 数量明显增长。
• 代码评审排队严重，合并后线上问题数量上升。
• 需要做存量代码治理，先批量找出高风险文件再逐步修。
• 希望引入 LLM 辅助审查，但不想替换掉现有 Git 工作流。
• 有统一 CI 平台，希望能把自动审查结果写回 PR 评论。

不适合的场景也很明确：

• 不允许代码离开本机或被第三方接口处理的情况下，不能直接把 full diff 发到外部 LLM 服务。
• 完全靠自动审查替代人工评审，任何自动化都做不到这一点。
• 项目本身没有测试基线，纯靠静态审查解决质量问题，效果有限。
• 团队没有 CI 或 Git 服务，脚本只能本地运行，覆盖范围小。

安全边界要单独强调：涉及支付、实名、加密、内部基础设施的代码，优先选择私有化部署的 LLM。如果使用外部 LLM 接口，需要先确认代码中是否包含密钥、Token、手机号、身份证号等敏感信息，必须做脱敏再提交审查。AI 编程助手生成了看似完整的命令或脚本时，不要盲目复制到终端执行，尤其来路不明的字符串，先拆开看清楚每一步在做什么。

4. 分层审查体系设计

要解决人工审查不过来，核心是建立四层漏斗：命令门禁过滤低级错误，静态分析过滤规范问题，LLM 语义审查过滤逻辑与安全风险，人工抽样复核兜底。这四层各干各的事，不要混在一起。

4.1 第一层：命令级门禁

门禁是速度最快的一层，覆盖可执行命令产生的风险，比如：

• 当前分支是否基于最新主干
• 代码能否编译通过
• 是否包含调试输出、临时代码、TODO
• 依赖文件是否被意外修改
• 是否包含明显的敏感信息，比如 AK/SK 字符串

这一层不需要 AI，成本低，适合放在本地 git hook 或 CI 的第一步。

4.2 第二层：静态分析规则

静态分析主要做规范层面检查，包括：

• ESLint / Ruff / Checkstyle 等语言级 Lint
• 圈子复杂度检查
• 未使用变量和 import
• 明显的安全模式问题，比如 SQL 拼接、eval 执行
• 测试覆盖率变化

静态分析的问题在于它只能查出“模式错误”，查不出“业务逻辑错误”。但它能在大规模 PR 进来之前清除掉一批人不需要花精力看的低质量问题。

4.3 第三层：LLM 语义审查

这是 AI 代码审查最关键的一层，也是性能消耗最大的一层。把本次 PR 的 diff 按文件拆分成小块，交给 LLM 做面向“风险”的审查，而不是让模型通读整个仓库。

每次调用需要带上以下上下文：

• 变更所属模块
• 关键函数签名
• 本次修改目标
• 变更前后代码片段
• 需要重点检查的问题类型

提示词要明确限制输出格式，让结果稳定可解析，一般输出 JSON，包含风险等级、问题描述、涉及函数、修改建议。

4.4 第四层：人工抽样复核

人工不能退出流程，但要改变工作方式。人工只看三种内容：

• LLM 标记为高危的 diff
• 涉及资金、权限、数据删除等敏感模块的变更
• 统计抽样中随机抽到的变更

人工复核不是把 LLM 的结果当结论，而是看它给出的高风险项是否成立。这样审查者从“通读几千行”变成“聚焦几十个风险点”，单位时间产出高得多。

5. 审查指标：怎么量化“漏审”风险

很多团队引入自动审查后，不知道效果如何。我建议拆成四个指标来持续观察。

自动化覆盖率：进入 PR 的代码有多少比例被自动化规则或 LLM 检查过。目标是 100%。

高风险命中率：自动审查标为高风险的文件，人工复核后真正确认有问题的比例。如果命中率太低，说明阈值设置过松；太高，说明自动化能力还没发挥价值。

漏审风险分：可以对每个文件按“是否触碰核心函数”“是否涉及并发”“是否有复杂分支”“是否新增 API 接口”做加权计算，分数高的文件强制人工复核。

审查周期：从 PR 创建到人工复核结束的平均时长。如果这个指标降低了，说明分层审查确实有效。

建议在 CI 中输出一份指标 JSON，方便后续接入内部数据平台。

6. 工具链落地：VS Code、Claude Code 与 Open Code Review

实际使用中，多数开发者不是坐在 GitHub 网页上等 review，而是在 IDE 里直接提交。所以工具链必须要跟 IDE 和 AI 编程工具打通。

如果团队用的是 VS Code，可以做这么一层简单联动：

• 开发者用 Claude Code 生成代码。
• 生成结果先落到工作区，开发者在 VS Code 中查看 diff。
• 提交前运行本地 pre-commit，把 LLM 审查结果输出为注释或报告文件。
• 审查人打开 PR 时，能看到自动审查结论，再针对性启动人工复核。

热词里出现的 Open Code Review 类插件，本质是把“代码审查”从 Git 托管页面搬回 IDE。这类插件适合给单个开发者做“提交前自检”和“Reviewer 辅助审查”，但注意不要只看插件表面截图，要确认它到底是通过本地规则还是调用远端 LLM。

由于每个人的 IDE 版本、插件市场、网络环境不同，具体安装步骤建议以项目官方 README 为准。下面给出一套通用的 VS Code 联动思路：

# 在 VS Code 的 settings.json 中，自定义提交前命令 # 实际路径和命令需要按本机环境调整 "git.terminalAuthentication": true, "terminal.integrated.env.linux": { "REVIEW_API": "http://127.0.0.1:8000/review" }

真正能落地的组合是“AI 编程生成 + 本地规则检查 + 远端自动审查服务”。其中远端服务可以复用团队的代码评审机器人，也可以独立部署。

7. 自动审查流水线搭建

这里给两个可直接改造的模板，一个是本地 pre-commit 命令，一个是 GitHub Actions 的 PR 审查工作流。

7.1 本地 pre-commit 检查示例

先建一个脚本保存为scripts/pre_review.py，作用是对本次修改的 Python 文件做静态关键字和敏感信息扫描：

#!/usr/bin/env python3 import os import re import subprocess import sys HIGH_RISK_KEYWORDS = [ "eval(", "exec(", "pickle.loads(", "shell=True", "INSERT INTO", "DELETE FROM", "DROP TABLE", ] SENSITIVE_PATTERNS = [ re.compile(r"AKIA[0-9A-Z]{16}"), re.compile(r"sk-[a-zA-Z0-9]{20,}"), re.compile(r"(?i)(password|passwd|secret|token)\s*=\s*['\"][^'\"]+['\"]"), ] def get_modified_files(): result = subprocess.run( ["git", "diff", "--cached", "--name-only", "--diff-filter=ACM"], capture_output=True, text=True, check=False, ) return [line.strip() for line in result.stdout.splitlines() if line.strip()] def check_file(path): problems = [] with open(path, "r", encoding="utf-8", errors="ignore") as f: content = f.read() for keyword in HIGH_RISK_KEYWORDS: if keyword in content: problems.append(f"高危关键字: {keyword}") for pattern in SENSITIVE_PATTERNS: match = pattern.search(content) if match: key = match.group(0)[:8] + "****" problems.append(f"可能包含敏感信息: {key}") return problems def main(): failed = False for path in get_modified_files(): if not path.endswith((".py", ".js", ".ts", ".java", ".go", ".rs")): continue problems = check_file(path) for problem in problems: print(f"{path}: {problem}") failed = True if failed: print("预审查未通过，请先修改再提交。") sys.exit(1) print("预审查通过。") if __name__ == "__main__": main()

脚本只做了关键字和敏感信息匹配，没有语义判断。要在提交前自动执行，可以在项目根目录加一个.git/hooks/pre-commit钩子，或者配置 pre-commit 框架。

7.2 GitHub Actions PR 自动审查示例

下面是通用 CI 模板。它会在每个 PR 更新时提取变更文件名，调用一个本地或私有的审查服务，并把结果输出到 PR 评论。

name: ai-review on: pull_request: types: [opened, synchronize, reopened] jobs: review: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 - name: Setup Python uses: actions/setup-python@v5 with: python-version: "3.11" - name: Install dependencies run: | pip install requests - name: Run review script id: review env: REVIEW_API_URL: ${{ secrets.REVIEW_API_URL }} REVIEW_API_TOKEN: ${{ secrets.REVIEW_API_TOKEN }} run: | python scripts/ci_review.py > review_report.md echo "report_exist=true" >> "$GITHUB_OUTPUT" - name: Post comment if: steps.review.outputs.report_exist == 'true' uses: actions/github-script@v7 with: script: | const fs = require('fs'); const body = fs.readFileSync('review_report.md', 'utf8'); if (body.length > 60000) { body = body.slice(0, 60000) + '\n\n...truncated...'; } await github.rest.issues.createComment({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, body: body, });

这段模板重点在scripts/ci_review.py的内容。实际项目需要替换审查服务的 API 地址、Token 和过滤规则。只跑一个模板没有意义，必须接上审查服务。

8. 批量审查与接口调用

8.1 存量代码批量扫描

对于已经积累了大量 AI 生成代码的仓库，建议先做一次全量扫描，输出风险热力图。批量扫描不要一次把几十个文件全塞给 LLM，会有上下文长度和响应超时的问题。建议按文件列表分批处理，每批最多 20 个文件，中间加睡眠时间做限流。

8.2 LLM 接口调用模板

下面是一个最小可用的批量审查脚本，按实际接口地址和鉴权方式替换即可：

import time import json import requests from pathlib import Path API_URL = "http://127.0.0.1:8000/review" API_TOKEN = "your-token-here" BATCH_SIZE = 20 SLEEP_SECONDS = 2 def load_code(path: Path) -> str: return path.read_text(encoding="utf-8", errors="ignore") def review_batch(files): payload = { "files": [ {"path": str(p), "code": load_code(p)[:6000]} for p in files ], "rules": ["security", "concurrency", "resource_leak"], } headers = {"Authorization": f"Bearer {API_TOKEN}"} response = requests.post(API_URL, json=payload, headers=headers, timeout=120) response.raise_for_status() return response.json() def scan_directory(root: str): root_path = Path(root) code_files = [] for suffix in ["*.py", "*.js", "*.ts", "*.go", "*.java"]: code_files.extend(root_path.rglob(suffix)) # 排除依赖目录 code_files = [p for p in code_files if "node_modules" not in p.parts and ".git" not in p.parts] results = [] for i in range(0, len(code_files), BATCH_SIZE): batch = code_files[i:i + BATCH_SIZE] try: print(f"processing: {i} - {i + len(batch)}") data = review_batch(batch) results.extend(data.get("items", [])) except requests.exceptions.RequestException as e: print(f"batch failed: {e}") time.sleep(SLEEP_SECONDS) with open("review_output.json", "w", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2) print(f"done. total issues: {len(results)}") if __name__ == "__main__": scan_directory("./src")

使用时要特别注意API_URL指向的必须是项目内部私有化部署的审查服务或经过安全审批允许调用的外部接口，千万不要把源代码批量提交给不知名第三方服务。

8.3 并发、重试与缓存

批量调用 LLM 接口时，常见问题是限流和超时。

建议在脚本里加三样东西：

• 重试机制：对 5xx、429、超时做指数退避重试，最多 3 次。
• 结果缓存：按文件 hash 保存审查结果，文件未变化时跳过，避免重复消费。
• 并发上限：requests 并发不要拉满，建议 2 到 4 个并发，压测后再调大。

下面是一个带缓存和重试的最小封装：

import hashlib import time import json import requests from pathlib import Path CACHE_FILE = Path("review_cache.json") REQUEST_TIMEOUT = 120 if CACHE_FILE.exists(): cache = json.loads(CACHE_FILE.read_text(encoding="utf-8")) else: cache = {} def file_hash(content: str) -> str: return hashlib.sha256(content.encode("utf-8")).hexdigest() def post_with_retry(url, headers, payload, max_retries=3): for attempt in range(max_retries): try: response = requests.post(url, json=payload, headers=headers, timeout=REQUEST_TIMEOUT) if response.status_code == 429: time.sleep(10 * (attempt + 1)) continue if response.status_code >= 500: time.sleep(5 * (attempt + 1)) continue response.raise_for_status() return response.json() except requests.exceptions.RequestException as e: if attempt == max_retries - 1: raise time.sleep(3 * (attempt + 1)) def cached_review(path, content): content_hash = file_hash(content) if path in cache and cache[path].get("hash") == content_hash: return cache[path]["result"] payload = {"path": path, "code": content[:6000]} result = post_with_retry("http://127.0.0.1:8000/review", {}, payload) cache[path] = {"hash": content_hash, "result": result} CACHE_FILE.write_text(json.dumps(cache, ensure_ascii=False, indent=2), encoding="utf-8") return result

有了缓存和重试，批量扫描就不会因为单个文件超时而整体中断。

9. 资源占用与性能观察

在 AI 代码审查方案里，资源占用主要分两块：本地计算资源和 LLM 接口调用成本。

本地静态检查的资源占用很低，通常几秒内完成，不需要 GPU。LLM 语义审查是主要成本来源，消耗取决于每次请求的上下文长度、输出 token 数量和调用频率。

建议建立如下观察维度：

如果批量任务发现响应时间明显变长，优先检查是不是一次发送的代码太长。把文件切成 200 到 600 行的代码块提交审查，效果好于一次发送整个大文件。

10. 常见问题与排查方法

11. 最佳实践与使用建议

第一，先做小范围试点。不要在核心支付系统上直接开全量自动审查。先选一两个中等业务模块，跑两周，看看命中率和误报率，再逐步推广。

第二，建立最小可运行配置。把“敏感信息扫描 + 静态分析 + LLM 高风险标记 + 人工复核高风险项”作为最小闭环。不要一上来就堆二十条复杂规则，规则越多越难维护。

第三，模型文件和输入素材分目录管理。审查服务的提示词、审查结果、代码样本、报告输出分开存放，方便回溯。

第四，批量任务要加日志和失败重试。没有日志的批量扫描等于没跑。建议每次扫描都生成一份包含文件路径、风险等级、审查耗时的记录文件。

第五，接口服务要限制访问范围。审查服务如果是对内开放的，必须加访问白名单和鉴权，不能裸奔在公网。部署时优先绑定内网地址，如127.0.0.1或内网 IP，不要监听0.0.0.0。

第六，涉及人脸、声音、个人信息或版权素材的场景，代码审查和 AI 生成都必须确认授权。AI 生成代码同样存在版权和法律风险，尤其是在闭源商业项目里使用训练数据来源不明的模型生成代码时。

第七，发布前人工复核不可省略。自动审查是提升效率的漏斗，不是免责工具。关键模块和线上事故高发模块必须有人工二次确认。

12. 总结

AI 生成代码已经是常态，接下来要解决的核心问题不是让 AI 写得更快，而是让人类审得更准。这篇文章给出的分层审查体系，核心思路就是用命令门禁处理低级错误、用静态分析处理规范问题、用 LLM 处理语义风险、用人工抽样处理自动化无法覆盖的边界，把人的精力集中到真正有风险的地方。

建议先部署第一层和第二层，它们成本低、见效快。跑通稳定之后，再接入 LLM 语义审查和批量扫描。最容易踩的坑还是敏感信息外泄和不设防的接口服务，这两点一定要先堵住。

这套流程跑起来以后，可以继续往两个方向扩展：一个是用审查数据训练项目专属的代码纠错模型，另一个是把审查结果接入内部质量看板，做趋势预警。建议先把审查流水线接进日常 CI，看到一周的运行数据后，再决定要不要继续扩展。