这次我们聊一个正在发生的工程问题不是某个具体模型发布AI 编程工具的生产速度已经明显超过人类代码审查的速度。Claude Code、Cursor 这类工具几分钟能生成几千行代码一个 PR 合入几百上千行变更已经是常态但评审者还是只有一双眼睛。结果要么是 PR 排队排到深夜要么是为了赶版本放过一批没细看的改动。两种结局都很危险。这篇文章不评价“AI 写代码好不好”而是给出一个相对可落地的思路AI 生成代码占比越来越高之后审查流程怎么重新设计。我会先梳理审查瓶颈的核心原因再给出一套分层审查体系包含静态门禁、LLM 语义审查、批量存量扫描、接口调用和人工抽样复核最后提供 GitHub Actions、pre-commit、Python API 调用模板和常见问题排查表。代码可以直接复制到自己的工程里改着用。如果你正在用 Claude Code 或类似工具写代码或者团队里 AI 生成代码的比例已经到了一半以上这篇文章建议收藏。它不是讲某个工具怎么安装而是讲一套“审查不过来时怎么办”的工程方案。1. 方案核心能力速览能力项说明解决的核心问题AI 生成代码量增速超过人工评审速度导致漏审、积压、质量失控方案组成命令级门禁、静态分析规则、LLM 语义审查、人工抽样复核四层流水线审查对象PR/MR 中的新增 diff、存量仓库代码、AI 编程助手生成代码自动门禁支持 Git Hooks / pre-commit / GitHub Actions / 通用 CI 流程LLM 语义审查通过标准 HTTP API 将 diff 提交给 LLM 做逻辑、安全、并发性检查批量任务支持对历史代码目录批量扫描输出 CSV/Markdown 报告人工参与方式不替代人只做“风险分级”把高风险 diff 优先推给人工关键限制不能保证语义 100% 正确涉及敏感代码时建议走私有化 LLM 部署适用团队中大型研发团队、AI 辅助编程占比高的团队、需要存量代码治理的团队简单说这套方案的核心是把“每个 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(, shellTrue, INSERT INTO, DELETE FROM, DROP TABLE, ] SENSITIVE_PATTERNS [ re.compile(rAKIA[0-9A-Z]{16}), re.compile(rsk-[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-filterACM], capture_outputTrue, textTrue, checkFalse, ) return [line.strip() for line in result.stdout.splitlines() if line.strip()] def check_file(path): problems [] with open(path, r, encodingutf-8, errorsignore) 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/checkoutv4 - name: Setup Python uses: actions/setup-pythonv5 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_existtrue $GITHUB_OUTPUT - name: Post comment if: steps.review.outputs.report_exist true uses: actions/github-scriptv7 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(encodingutf-8, errorsignore) 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: fBearer {API_TOKEN}} response requests.post(API_URL, jsonpayload, headersheaders, timeout120) 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(fprocessing: {i} - {i len(batch)}) data review_batch(batch) results.extend(data.get(items, [])) except requests.exceptions.RequestException as e: print(fbatch failed: {e}) time.sleep(SLEEP_SECONDS) with open(review_output.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) print(fdone. 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(encodingutf-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_retries3): for attempt in range(max_retries): try: response requests.post(url, jsonpayload, headersheaders, timeoutREQUEST_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_asciiFalse, indent2), encodingutf-8) return result有了缓存和重试批量扫描就不会因为单个文件超时而整体中断。9. 资源占用与性能观察在 AI 代码审查方案里资源占用主要分两块本地计算资源和 LLM 接口调用成本。本地静态检查的资源占用很低通常几秒内完成不需要 GPU。LLM 语义审查是主要成本来源消耗取决于每次请求的上下文长度、输出 token 数量和调用频率。建议建立如下观察维度维度观察方法单次审查耗时记录 API 请求开始到结束的时间正常应该在 5 到 60 秒之间上下文消耗每次请求前打印输入 token 数量超过上下文窗口自动截断缓存命中率对比“被缓存直接返回的文件数 / 总请求文件数”批量任务吞吐统计每分钟能完成多少个文件的审查失败率统计超时、429、5xx 请求占比如果批量任务发现响应时间明显变长优先检查是不是一次发送的代码太长。把文件切成 200 到 600 行的代码块提交审查效果好于一次发送整个大文件。10. 常见问题与排查方法问题现象可能原因排查方式解决方案本地预审查脚本不执行pre-commit 钩子没有可执行权限检查.git/hooks/pre-commit权限执行chmod x .git/hooks/pre-commit脚本报编码错误文件包含非 UTF-8 字符查看文件编码读取时使用errorsignore或统一转码GitHub Actions 不触发workflow 文件名或触发条件写错检查 Actions 标签页和 yaml 缩进确认事件是pull_request且路径包含在仓库中LLM 接口返回 401/403API Key 未配置或权限不足在本地用 curl 测试接口鉴权检查环境变量、密钥有效期和账户余额状态大批量请求被限流并发过高或超过了接口配额查看响应头中的限流字段和日志降低并发数加重试退避增加缓存审查结果全是低风险提示词引导太宽泛查看输入 token 和上下文是否完整增加“规则”字段指定 security/concurrency 等检查项效果不稳定二次结果不一致LLM 采样温度过高观察接口响应参数将 temperature 调到 0 或 0.1固定输出格式敏感信息被发送到外部服务代码未经脱敏直接走外部接口检查批量脚本的预处理逻辑在打码、脱敏后再调用外部 LLM 服务卡住不输出等待响应时间过长查看服务端日志增加请求超时和数据块截断11. 最佳实践与使用建议第一先做小范围试点。不要在核心支付系统上直接开全量自动审查。先选一两个中等业务模块跑两周看看命中率和误报率再逐步推广。第二建立最小可运行配置。把“敏感信息扫描 静态分析 LLM 高风险标记 人工复核高风险项”作为最小闭环。不要一上来就堆二十条复杂规则规则越多越难维护。第三模型文件和输入素材分目录管理。审查服务的提示词、审查结果、代码样本、报告输出分开存放方便回溯。第四批量任务要加日志和失败重试。没有日志的批量扫描等于没跑。建议每次扫描都生成一份包含文件路径、风险等级、审查耗时的记录文件。第五接口服务要限制访问范围。审查服务如果是对内开放的必须加访问白名单和鉴权不能裸奔在公网。部署时优先绑定内网地址如127.0.0.1或内网 IP不要监听0.0.0.0。第六涉及人脸、声音、个人信息或版权素材的场景代码审查和 AI 生成都必须确认授权。AI 生成代码同样存在版权和法律风险尤其是在闭源商业项目里使用训练数据来源不明的模型生成代码时。第七发布前人工复核不可省略。自动审查是提升效率的漏斗不是免责工具。关键模块和线上事故高发模块必须有人工二次确认。12. 总结AI 生成代码已经是常态接下来要解决的核心问题不是让 AI 写得更快而是让人类审得更准。这篇文章给出的分层审查体系核心思路就是用命令门禁处理低级错误、用静态分析处理规范问题、用 LLM 处理语义风险、用人工抽样处理自动化无法覆盖的边界把人的精力集中到真正有风险的地方。建议先部署第一层和第二层它们成本低、见效快。跑通稳定之后再接入 LLM 语义审查和批量扫描。最容易踩的坑还是敏感信息外泄和不设防的接口服务这两点一定要先堵住。这套流程跑起来以后可以继续往两个方向扩展一个是用审查数据训练项目专属的代码纠错模型另一个是把审查结果接入内部质量看板做趋势预警。建议先把审查流水线接进日常 CI看到一周的运行数据后再决定要不要继续扩展。
