尧图网站建设 
如果把过去一年开发团队的技术讨论拉一个清单“AI 写代码”一定排在最前面。真正让团队紧张的往往不是代码量变大而是另一个更实际的工程问题AI 生成代码的速度已经超过人工审查的速度人类正在失去对代码的全量审查能力。代码评审原本默认一个前提——每个提交都由熟悉上下文的人逐行读完。可当一次需求可以由 AI 在几十分钟内产出几百行、甚至上千行代码时这个前提已经站不住。要解决的问题不是“要不要用 AI 写代码”而是当“审不完”成为现实后用什么流程、关卡和工具把风险控制在合理范围内。核心思路是停止和“逐行审完所有 diff”较劲把审查体系改造成三层机器拦截、AI 预审、人工重点核实。1. 为什么“代码审不完”是必然出现的工程问题1.1 代码生成速度与人工审查带宽存在剪刀差传统开发模式下一个开发者每天能产出的有效代码量有限评审者可以用相近的时间把 diff 看完。AI 编程工具接入后这个平衡被打破了。一个清晰的 prompt 可以生成一个完整的工具函数、一套单元测试、一次跨模块重构的初稿早晨还没结束分支上已经堆了好几个模块的代码。对比几个现实数字就能明白问题所在人工编写一个中型功能模块可能需要几天期间代码分多次提交每次 diff 可读。AI 编写同一个功能可以在几十分钟内形成初稿一次 commit 就包含过去几次提交的改动量。人工评审一个人全神贯注一小时能认真读掉的代码量有限而且连续阅读时间越长发现问题的密度越低。于是团队会出现三类典型信号MR 的 diff 行数明显变大一个合并请求包含过去两到三个请求的改动审查者只能看结构、看命名、看明显错误细节逻辑依赖提交者自测合入后缺陷变多修复成本高于在审查阶段拦截的成本。这里的关键不是“AI 生成的代码质量一定差”而是审查体系仍然按人工代码时代设计。人工互审假设每个提交都有另一个完整理解上下文的人逐行审阅。当这个假设不再成立真正的问题就从“审得细不细”变成了“审哪里、怎么审、用什么工具兜底”。1.2 审查策略要从“全覆盖”转向“风险分级”代码审查的真正目的不是完成“看完所有行”这个动作而是降低缺陷进入主干的概率以及降低后续修复成本。只要能在低成本环节拦截大部分机械问题让高层级审查集中处理机器和 AI 都判断不了的问题整体风险就会明显下降。新的审查流水线可以分成四步提交前自动检查格式、基础语法、明显错误。CI 阶段的静态分析和安全扫描类型错误、常见漏洞模式、敏感信息泄漏。AI 预审基于 diff 生成结构化审查意见作为第二道机器防线。人工按风险等级抽查和放行把时间集中在高风险区域而不是平均分配给所有行。这个模型不是放弃人工审查而是把人从“所有 diff 的全文阅读者”重新定位成“高风险变更的最终裁决者”。2. 先把机器能判断的关卡全部自动化2.1 机器先做三类检查格式、静态规则、安全敏感项第一类是格式与基础语法检查。代码格式化、未使用变量、缺少结束符这类问题没有任何讨论价值应当由工具直接拦截。常见的实现是 pre-commit 钩子进入版本控制前就完成。第二类是静态分析与类型检查。这类检查可以捕获空值访问、类型不匹配、未处理错误分支、明显的并发问题等。工具清单按语言和团队习惯组合检查类别常见工具拦截目标格式规范化Prettier、Black、gofmt缩进、引号、换行、排序语言级静态检查ESLint、Ruff、golangci-lint未用变量、复杂度过高、可疑分支类型检查TypeScript、mypy、pyright类型不匹配、空值传播安全静态扫描Semgrep、CodeQL、SonarQubeSQL 注入、路径穿越、不安全反序列化敏感信息扫描gitleaks、TruffleHog密钥、Token、连接串误提交第三类是安全敏感信息扫描。AI 在生成代码时经常把配置示例也写进代码里如果生成结果包含假密钥或真实可用的凭据人工很难逐行发现而 gitleaks 这类工具可以在一秒钟内扫出可疑模式。2.2 用一个最小配置把检查关卡落地先在仓库根目录创建一个 pre-commit 配置。以下示例用于说明思路实际项目要结合自己的语言和包管理工具调整版本# .pre-commit-config.yaml repos: - repo: https://github.com/pre-commit/pre-commit-hooks rev: v4.6.0 hooks: - id: check-json - id: check-yaml - id: end-of-file-fixer - id: trailing-whitespace - repo: https://github.com/astral-sh/ruff-pre-commit rev: v0.6.9 hooks: - id: ruff args: [--fix] - repo: https://github.com/pre-commit/mirrors-mypy rev: v1.11.2 hooks: - id: mypy additional_dependencies: [types-requests]安装并执行一次确认钩子生效pip install pre-commit pre-commit install pre-commit run --all-filespre-commit 的版本会持续更新落地前先查看当前可用版本不要把示例版本当成默认事实。CI 阶段需要做的是限制检查范围。AI 生成的代码往往改动量很大如果每次都在全仓库上跑 lint 和类型检查CI 会变得越来越慢最后团队会因为等待时间过长而绕过检查。推荐做法是只检查当前分支相对主干的变更文件#!/usr/bin/env bash set -euo pipefail BASE_REF${BASE_REF:-origin/main} CHANGED_FILES$(git diff --name-only ${BASE_REF}...HEAD || true) echo 变更文件清单 echo $CHANGED_FILES # 1. 只对变更的 JS/TS 文件运行 ESLint JS_FILES$(echo $CHANGED_FILES | grep -E \.(js|jsx|ts|tsx)$ || true) if [ -n $JS_FILES ]; then npx eslint $JS_FILES fi # 2. 对本分支的提交历史做敏感信息扫描 gitleaks detect --source. --log-opts${BASE_REF}...HEAD || true脚本里最关键的是git diff --name-only这一句它保证了检查范围是被这次分支真正影响到的代码而不是整个仓库。CI 配置里把这个脚本作为独立 job 执行即可。2.3 自动检查的边界必须明确机器检查能拦截语法、类型、明显漏洞和敏感信息但它判断不了三件事需求是否被正确实现、业务规则是否被遗漏、两个模块之间的交互是否符合预期。一个函数可以通过所有 lint 和类型检查却仍然把订单状态计算错。所以自动关卡是效率工具不是质量保证的全部。它要做的是把人从“这行少了个分号”“这里可能为空”这类低水平劳动里解放出来让人的精力能集中到机器无法判断的问题上。这个定位决定了自动关卡的设计原则宁可多花一点配置时间也要尽量多拦截、少误报。误报过多会导致团队不再相信工具输出最终把整个关卡关掉。注意不要把自动检查的结果当作“已经审过”。机器检查通过只能说明代码满足规则不能说明它满足需求。3. 用 AI 审查 AI把“审不完”变成“预审”3.1 AI 预审解决什么问题自动检查只能判断规则AI 审查可以做一些接近逻辑判断的工作发现空指针路径、状态未更新、资源未关闭、复制粘贴导致的重复逻辑、错误处理被吞掉等问题。也就是说静态检查回答“这行合不合法”AI 预审回答“这段逻辑可疑不可疑”。AI 预审不是替代人而是给每条变更生成一个带严重级别和行号的“风险地图”。人工拿到这份地图后可以直接跳到高风险位置精读而不是从头扫到尾。这个变化非常重要当 diff 从 200 行变成 2000 行时“先过滤再阅读”是唯一可行的方式。同时要明确 AI 审查的局限性它可能引用不存在的代码行这是大模型幻觉的直接表现。它可能把“风格不同”误报成“逻辑错误”需要人工忽略。它无法访问运行时数据不能替代测试。3.2 给 AI 审查一个结构化提示词模板AI 审查的提示词不能写成“帮我看看这段代码有什么问题”那样会得到一堆空泛建议。要限制输入范围、输出格式和关注类型方便人工快速消费结果。你是一名资深代码审查者。请审查下面 git diff 中的内容。 只关注四类问题 1. 逻辑错误边界条件、空值、并发、资源未释放。 2. 安全风险注入、敏感信息、权限校验缺失、异常被无信息吞掉。 3. 数据一致性字段丢失、状态未更新、事务边界错误。 4. 明显可维护性缺陷复制粘贴代码、注释与实现矛盾。 要求 - 先输出问题清单使用表格严重级别、文件、行号、问题描述、为什么是问题、修复建议。 - 再输出“需要人工确认”列表列出你风险高但不完全确定的内容。 - 不要编造 diff 中不存在的代码。 - 如果没有发现问题明确输出“未发现明确问题”。 diff 内容如下 {DIFF}实际使用时把{DIFF}替换成git diff origin/main...HEAD的输出。不要让大模型直接读整个代码库范围越大模型越容易关注无关内容也越容易产生幻觉。关键点在要求里写得非常具体先出表格再出人工确认列表禁止编造代码。这些约束不是可有可无的装饰它们直接决定了 AI 审查结果是否值得人工去读。3.3 在 VS Code、CLI 和自托管工具中落地AI 审查工具目前有几类落地方式在 VS Code 中使用支持 diff 上下文的扩展选中变更后发起审查。在 CLI 环境中用脚本把 diff 喂给模型接口把输出保存为审查报告。使用社区开源方案例如 Open Code Review 这类以 diff 为输入、生成审查意见的工具。这类工具通常会要求在 VS Code 里安装扩展然后配置模型接口。具体安装命令和配置项以官方文档为准因为开源项目迭代非常快。团队可以选择在 CI 中运行审查机器人每个 MR 自动发布一条审查意见类似一个“AI 评审人”。无论用哪种方式都要先处理连接配置。配置模型接口时团队可能会遇到两类典型报错。一类是 HTTP 401响应体里出现api_key_required之类的字段说明模型接口的密钥缺失或无效需要检查环境变量和配置文件。另一类是模型接口返回地区或区域不支持的信息这通常与账号所在地、组织配置有关需要确认组织的可用范围。这类错误不是代码问题排查顺序是先看密钥、再看网络、再看账号权限。注意不要把来源不明的 AI 提示词或脚本直接粘贴到终端、DevTools 控制台或带权限的目录中执行。任何会执行任意命令的提示词都要先读一遍再确认。4. 人工只盯高价值区域分层审查策略4.1 把变更分成四档人工审查不可能覆盖所有 diff但不代表每个 diff 风险相同。团队可以根据变更影响到的模块、代码位置和改动类型把变更分级然后给每级分配不同的审查深度。风险级别典型变更审查方式人工投入A 级支付、鉴权、核心状态机、数据迁移人工逐行审阅AI 预审先行高B 级批量任务、对外接口、数据库访问AI 预审 人工重点抽查 测试中C 级日志、页面展示、埋点、样式AI 预审 随机抽查低D 级实验原型、一次性脚本、文档示例自动检查即可最低分级不是让团队少做事而是把有限的注意力配置到风险密度最高的地方。一个支付模块的 50 行变更比一个宣传页面的 500 行变更更值得人逐行阅读。4.2 抽样式深度审查怎么抽对于 B 级和 C 级变更人工可以选择抽样。抽样不能随机抽否则可能抽到一段从未被调用过的辅助函数而真正危险的依赖更新没人看。推荐的抽样顺序先看变更文件列表找出过去六个月出现缺陷最多的文件。优先查看对外接口、数据库读写、异常处理相关的变更片段。用git log查看这个文件最近由谁修改、修改频率如何。高频修改文件往往承担高复杂度逻辑值得细看。对 AI 预审给出的“需要人工确认”列表逐条确认这比漫无目的地扫读效率高很多。一个可操作的做法是对 B 级变更至少精读 30% 的变更行且必须覆盖所有异常分支对 C 级变更至少精读变更后的入口和出口。这个比例不来自标准规范而是来自团队自己的缺陷数据统计几次合入后的线上问题后再调整比例。4.3 高风险变更必须强制人工放行如果团队把“人工放行”也交给自动流程那前面所有分级都是空话。A 级模块应当通过仓库保护规则强制要求指定负责人批准可以用 CODEOWNERS 声明所有者# .github/CODEOWNERS /payment/ pay-owner /src/security/ security-owner /db/migrations/ db-owner配置仓库保护规则时可以要求A 级模块的改动必须有一个明确 Owner 批准。所有 MR 必须通过 CI。AI 审查机器人可以发表意见但不能作为唯一批准人。高风险的库版本升级不允许由 AI 生成的代码分支直接合入必须有负责人核对变更说明。这里的核心逻辑是机器负责“过程正确”人负责“决策正确”。AI 生成的代码可以自动通过格式和静态检查但它是否进入主干必须以人工确认为前提。5. 常见问题与排查链路5.1 典型问题现象与处理方案问题现象可能原因检查方式处理建议CI 检查越来越慢每次都在全仓库跑检查而不是只跑变更文件查看 CI 日志中各步骤耗时改为只检查BASE_REF...HEAD的变更文件AI 审查意见指向不存在的代码提示词没有限定 diff 范围模型看到的上下文过多检查输入给的是 diff 还是整库代码只传变更文件或变更行AI 审查频繁误报提示词关注面太宽把风格问题当逻辑问题抽查误报内容的分布收窄关注类型禁止泛泛建议本地 pre-commit 没生效安装钩子后未执行pre-commit install或有人跳过钩子执行git commit观察是否触发钩子重新安装钩子并把关键检查放到 CI合并后才发现密钥泄露敏感信息扫描只配在本地没进 CI检查扫描工具是否在 CI job 中执行将 gitleaks 加入 CI并定期全库扫描审查疲劳意见变少所有 MR 都堆给一个负责人统计各 MR 的首次响应时间轮值制度结合模块 Owner5.2 按固定顺序排查问题当审查流水线出现异常时不建议直接改工具或加规则。先按下面这个顺序排查多数问题能在前两步定位确认输入是否正确diff 范围对不对是不是拿到了完整变更分支有没有推送到远端。确认路径和命名配置文件名、钩子目录、脚本路径是否与项目约定一致。确认版本匹配pre-commit 的镜像版本、ESLint 插件版本、模型接口版本是否和配置匹配。确认配置是否生效检查钩子是否安装、CI job 是否真的执行、环境变量是否注入。确认权限和网络密钥是否有效、CI runner 能否访问内网依赖、代码仓库的权限是否允许机器人读取。查看日志关键字CI 日志里出现timeout、401、403、unsupported_country_region_territory时按提示逐项处理。人工兜底工具全部正常但结果不合理时先人工确认问题是否真实再决定是否调整规则。6. 落地清单与下一步扩展6.1 团队接受 AI 代码前的检查清单下列清单可以直接复制到项目文档中作为发布前检查依据发布前检查清单 - [ ] 变更文件列表与需求范围一致没有夹带无关修改 - [ ] 自动检查关卡已运行格式、lint、类型检查、安全扫描 - [ ] 敏感信息扫描通过未出现密钥、Token、连接串 - [ ] AI 审查报告已生成人工确认了其中“高风险”和“需人工确认”项 - [ ] A 级模块已有指定 Owner 批准 - [ ] 高风险依赖升级有负责人核对变更说明 - [ ] 新增代码有对应测试测试在 CI 中通过 - [ ] 异常分支被覆盖空值、超时、失败回滚、部分成功 - [ ] 未将来源不明的提示词或脚本直接执行 - [ ] 回滚方案明确知道如何快速回退本次变更6.2 生产环境还要补的保障以上流程解决的是“代码合入前”的问题。合入后生产环境还需要额外的保障配置外置密钥、连接串、开关不写进代码库交给环境变量或配置服务。日志与监控高危模块要有足够日志关键业务操作需要有 traceId 串联。可观测告警审查阶段漏掉的问题靠监控和告警兜底越早发现修复成本越低。回滚机制每个版本明确回滚方式禁止只有一个负责人知道怎么回滚。依赖锁定AI 生成代码经常引入新依赖锁定版本并审查依赖来源。数据备份涉及数据迁移的变更必须先验证可回滚性。6.3 可以继续扩展的方向这套审查体系落地后团队可以继续往三个方向扩展。第一个方向是变更影响分析。根据调用关系自动判断一个函数被谁引用把“这个文件改了会影响哪些下游”变成机器可直接查询的事实。AI 生成的跨模块改动先做影响分析再决定是否需要更多人工关注。第二个方向是测试补充自动化。AI 生成代码的同时生成对应单元测试并把测试覆盖情况纳入合并门槛。这里的重点是审查测试质量而不是只看覆盖率数字。第三个方向是对 AI 审查结果做反馈闭环。记录每次 AI 审查意见最终是否被确认用这部分数据微调提示词和工具参数。AI 审查不是一次配置就结束的功能它和静态规则一样需要持续校准否则会因为误报增加而逐渐被团队忽略。回到最初的问题AI 写代码但人审不完怎么办。答案不是制造一个无所不能的审查机器人而是重新分配责任——机器负责能机械化判断的全部环节AI 预审负责生成风险地图人只对真正高风险、需要业务判断和长期上下文的部分做深度决策。这套体系不需要一次搭完可以先从“CI 只检查变更文件”和“一个结构化 AI 审查提示词”开始跑通两周后根据团队自己的缺陷数据加关卡。先让流程在最小范围内稳定再逐步扩大比一开始就设计一个全自动审查平台更可靠。 AI审不完代码？三层审查体系：机器拦截、AI预审、人工重点核实
如果把过去一年开发团队的技术讨论拉一个清单“AI 写代码”一定排在最前面。真正让团队紧张的往往不是代码量变大而是另一个更实际的工程问题AI 生成代码的速度已经超过人工审查的速度人类正在失去对代码的全量审查能力。代码评审原本默认一个前提——每个提交都由熟悉上下文的人逐行读完。可当一次需求可以由 AI 在几十分钟内产出几百行、甚至上千行代码时这个前提已经站不住。要解决的问题不是“要不要用 AI 写代码”而是当“审不完”成为现实后用什么流程、关卡和工具把风险控制在合理范围内。核心思路是停止和“逐行审完所有 diff”较劲把审查体系改造成三层机器拦截、AI 预审、人工重点核实。1. 为什么“代码审不完”是必然出现的工程问题1.1 代码生成速度与人工审查带宽存在剪刀差传统开发模式下一个开发者每天能产出的有效代码量有限评审者可以用相近的时间把 diff 看完。AI 编程工具接入后这个平衡被打破了。一个清晰的 prompt 可以生成一个完整的工具函数、一套单元测试、一次跨模块重构的初稿早晨还没结束分支上已经堆了好几个模块的代码。对比几个现实数字就能明白问题所在人工编写一个中型功能模块可能需要几天期间代码分多次提交每次 diff 可读。AI 编写同一个功能可以在几十分钟内形成初稿一次 commit 就包含过去几次提交的改动量。人工评审一个人全神贯注一小时能认真读掉的代码量有限而且连续阅读时间越长发现问题的密度越低。于是团队会出现三类典型信号MR 的 diff 行数明显变大一个合并请求包含过去两到三个请求的改动审查者只能看结构、看命名、看明显错误细节逻辑依赖提交者自测合入后缺陷变多修复成本高于在审查阶段拦截的成本。这里的关键不是“AI 生成的代码质量一定差”而是审查体系仍然按人工代码时代设计。人工互审假设每个提交都有另一个完整理解上下文的人逐行审阅。当这个假设不再成立真正的问题就从“审得细不细”变成了“审哪里、怎么审、用什么工具兜底”。1.2 审查策略要从“全覆盖”转向“风险分级”代码审查的真正目的不是完成“看完所有行”这个动作而是降低缺陷进入主干的概率以及降低后续修复成本。只要能在低成本环节拦截大部分机械问题让高层级审查集中处理机器和 AI 都判断不了的问题整体风险就会明显下降。新的审查流水线可以分成四步提交前自动检查格式、基础语法、明显错误。CI 阶段的静态分析和安全扫描类型错误、常见漏洞模式、敏感信息泄漏。AI 预审基于 diff 生成结构化审查意见作为第二道机器防线。人工按风险等级抽查和放行把时间集中在高风险区域而不是平均分配给所有行。这个模型不是放弃人工审查而是把人从“所有 diff 的全文阅读者”重新定位成“高风险变更的最终裁决者”。2. 先把机器能判断的关卡全部自动化2.1 机器先做三类检查格式、静态规则、安全敏感项第一类是格式与基础语法检查。代码格式化、未使用变量、缺少结束符这类问题没有任何讨论价值应当由工具直接拦截。常见的实现是 pre-commit 钩子进入版本控制前就完成。第二类是静态分析与类型检查。这类检查可以捕获空值访问、类型不匹配、未处理错误分支、明显的并发问题等。工具清单按语言和团队习惯组合检查类别常见工具拦截目标格式规范化Prettier、Black、gofmt缩进、引号、换行、排序语言级静态检查ESLint、Ruff、golangci-lint未用变量、复杂度过高、可疑分支类型检查TypeScript、mypy、pyright类型不匹配、空值传播安全静态扫描Semgrep、CodeQL、SonarQubeSQL 注入、路径穿越、不安全反序列化敏感信息扫描gitleaks、TruffleHog密钥、Token、连接串误提交第三类是安全敏感信息扫描。AI 在生成代码时经常把配置示例也写进代码里如果生成结果包含假密钥或真实可用的凭据人工很难逐行发现而 gitleaks 这类工具可以在一秒钟内扫出可疑模式。2.2 用一个最小配置把检查关卡落地先在仓库根目录创建一个 pre-commit 配置。以下示例用于说明思路实际项目要结合自己的语言和包管理工具调整版本# .pre-commit-config.yaml repos: - repo: https://github.com/pre-commit/pre-commit-hooks rev: v4.6.0 hooks: - id: check-json - id: check-yaml - id: end-of-file-fixer - id: trailing-whitespace - repo: https://github.com/astral-sh/ruff-pre-commit rev: v0.6.9 hooks: - id: ruff args: [--fix] - repo: https://github.com/pre-commit/mirrors-mypy rev: v1.11.2 hooks: - id: mypy additional_dependencies: [types-requests]安装并执行一次确认钩子生效pip install pre-commit pre-commit install pre-commit run --all-filespre-commit 的版本会持续更新落地前先查看当前可用版本不要把示例版本当成默认事实。CI 阶段需要做的是限制检查范围。AI 生成的代码往往改动量很大如果每次都在全仓库上跑 lint 和类型检查CI 会变得越来越慢最后团队会因为等待时间过长而绕过检查。推荐做法是只检查当前分支相对主干的变更文件#!/usr/bin/env bash set -euo pipefail BASE_REF${BASE_REF:-origin/main} CHANGED_FILES$(git diff --name-only ${BASE_REF}...HEAD || true) echo 变更文件清单 echo $CHANGED_FILES # 1. 只对变更的 JS/TS 文件运行 ESLint JS_FILES$(echo $CHANGED_FILES | grep -E \.(js|jsx|ts|tsx)$ || true) if [ -n $JS_FILES ]; then npx eslint $JS_FILES fi # 2. 对本分支的提交历史做敏感信息扫描 gitleaks detect --source. --log-opts${BASE_REF}...HEAD || true脚本里最关键的是git diff --name-only这一句它保证了检查范围是被这次分支真正影响到的代码而不是整个仓库。CI 配置里把这个脚本作为独立 job 执行即可。2.3 自动检查的边界必须明确机器检查能拦截语法、类型、明显漏洞和敏感信息但它判断不了三件事需求是否被正确实现、业务规则是否被遗漏、两个模块之间的交互是否符合预期。一个函数可以通过所有 lint 和类型检查却仍然把订单状态计算错。所以自动关卡是效率工具不是质量保证的全部。它要做的是把人从“这行少了个分号”“这里可能为空”这类低水平劳动里解放出来让人的精力能集中到机器无法判断的问题上。这个定位决定了自动关卡的设计原则宁可多花一点配置时间也要尽量多拦截、少误报。误报过多会导致团队不再相信工具输出最终把整个关卡关掉。注意不要把自动检查的结果当作“已经审过”。机器检查通过只能说明代码满足规则不能说明它满足需求。3. 用 AI 审查 AI把“审不完”变成“预审”3.1 AI 预审解决什么问题自动检查只能判断规则AI 审查可以做一些接近逻辑判断的工作发现空指针路径、状态未更新、资源未关闭、复制粘贴导致的重复逻辑、错误处理被吞掉等问题。也就是说静态检查回答“这行合不合法”AI 预审回答“这段逻辑可疑不可疑”。AI 预审不是替代人而是给每条变更生成一个带严重级别和行号的“风险地图”。人工拿到这份地图后可以直接跳到高风险位置精读而不是从头扫到尾。这个变化非常重要当 diff 从 200 行变成 2000 行时“先过滤再阅读”是唯一可行的方式。同时要明确 AI 审查的局限性它可能引用不存在的代码行这是大模型幻觉的直接表现。它可能把“风格不同”误报成“逻辑错误”需要人工忽略。它无法访问运行时数据不能替代测试。3.2 给 AI 审查一个结构化提示词模板AI 审查的提示词不能写成“帮我看看这段代码有什么问题”那样会得到一堆空泛建议。要限制输入范围、输出格式和关注类型方便人工快速消费结果。你是一名资深代码审查者。请审查下面 git diff 中的内容。 只关注四类问题 1. 逻辑错误边界条件、空值、并发、资源未释放。 2. 安全风险注入、敏感信息、权限校验缺失、异常被无信息吞掉。 3. 数据一致性字段丢失、状态未更新、事务边界错误。 4. 明显可维护性缺陷复制粘贴代码、注释与实现矛盾。 要求 - 先输出问题清单使用表格严重级别、文件、行号、问题描述、为什么是问题、修复建议。 - 再输出“需要人工确认”列表列出你风险高但不完全确定的内容。 - 不要编造 diff 中不存在的代码。 - 如果没有发现问题明确输出“未发现明确问题”。 diff 内容如下 {DIFF}实际使用时把{DIFF}替换成git diff origin/main...HEAD的输出。不要让大模型直接读整个代码库范围越大模型越容易关注无关内容也越容易产生幻觉。关键点在要求里写得非常具体先出表格再出人工确认列表禁止编造代码。这些约束不是可有可无的装饰它们直接决定了 AI 审查结果是否值得人工去读。3.3 在 VS Code、CLI 和自托管工具中落地AI 审查工具目前有几类落地方式在 VS Code 中使用支持 diff 上下文的扩展选中变更后发起审查。在 CLI 环境中用脚本把 diff 喂给模型接口把输出保存为审查报告。使用社区开源方案例如 Open Code Review 这类以 diff 为输入、生成审查意见的工具。这类工具通常会要求在 VS Code 里安装扩展然后配置模型接口。具体安装命令和配置项以官方文档为准因为开源项目迭代非常快。团队可以选择在 CI 中运行审查机器人每个 MR 自动发布一条审查意见类似一个“AI 评审人”。无论用哪种方式都要先处理连接配置。配置模型接口时团队可能会遇到两类典型报错。一类是 HTTP 401响应体里出现api_key_required之类的字段说明模型接口的密钥缺失或无效需要检查环境变量和配置文件。另一类是模型接口返回地区或区域不支持的信息这通常与账号所在地、组织配置有关需要确认组织的可用范围。这类错误不是代码问题排查顺序是先看密钥、再看网络、再看账号权限。注意不要把来源不明的 AI 提示词或脚本直接粘贴到终端、DevTools 控制台或带权限的目录中执行。任何会执行任意命令的提示词都要先读一遍再确认。4. 人工只盯高价值区域分层审查策略4.1 把变更分成四档人工审查不可能覆盖所有 diff但不代表每个 diff 风险相同。团队可以根据变更影响到的模块、代码位置和改动类型把变更分级然后给每级分配不同的审查深度。风险级别典型变更审查方式人工投入A 级支付、鉴权、核心状态机、数据迁移人工逐行审阅AI 预审先行高B 级批量任务、对外接口、数据库访问AI 预审 人工重点抽查 测试中C 级日志、页面展示、埋点、样式AI 预审 随机抽查低D 级实验原型、一次性脚本、文档示例自动检查即可最低分级不是让团队少做事而是把有限的注意力配置到风险密度最高的地方。一个支付模块的 50 行变更比一个宣传页面的 500 行变更更值得人逐行阅读。4.2 抽样式深度审查怎么抽对于 B 级和 C 级变更人工可以选择抽样。抽样不能随机抽否则可能抽到一段从未被调用过的辅助函数而真正危险的依赖更新没人看。推荐的抽样顺序先看变更文件列表找出过去六个月出现缺陷最多的文件。优先查看对外接口、数据库读写、异常处理相关的变更片段。用git log查看这个文件最近由谁修改、修改频率如何。高频修改文件往往承担高复杂度逻辑值得细看。对 AI 预审给出的“需要人工确认”列表逐条确认这比漫无目的地扫读效率高很多。一个可操作的做法是对 B 级变更至少精读 30% 的变更行且必须覆盖所有异常分支对 C 级变更至少精读变更后的入口和出口。这个比例不来自标准规范而是来自团队自己的缺陷数据统计几次合入后的线上问题后再调整比例。4.3 高风险变更必须强制人工放行如果团队把“人工放行”也交给自动流程那前面所有分级都是空话。A 级模块应当通过仓库保护规则强制要求指定负责人批准可以用 CODEOWNERS 声明所有者# .github/CODEOWNERS /payment/ pay-owner /src/security/ security-owner /db/migrations/ db-owner配置仓库保护规则时可以要求A 级模块的改动必须有一个明确 Owner 批准。所有 MR 必须通过 CI。AI 审查机器人可以发表意见但不能作为唯一批准人。高风险的库版本升级不允许由 AI 生成的代码分支直接合入必须有负责人核对变更说明。这里的核心逻辑是机器负责“过程正确”人负责“决策正确”。AI 生成的代码可以自动通过格式和静态检查但它是否进入主干必须以人工确认为前提。5. 常见问题与排查链路5.1 典型问题现象与处理方案问题现象可能原因检查方式处理建议CI 检查越来越慢每次都在全仓库跑检查而不是只跑变更文件查看 CI 日志中各步骤耗时改为只检查BASE_REF...HEAD的变更文件AI 审查意见指向不存在的代码提示词没有限定 diff 范围模型看到的上下文过多检查输入给的是 diff 还是整库代码只传变更文件或变更行AI 审查频繁误报提示词关注面太宽把风格问题当逻辑问题抽查误报内容的分布收窄关注类型禁止泛泛建议本地 pre-commit 没生效安装钩子后未执行pre-commit install或有人跳过钩子执行git commit观察是否触发钩子重新安装钩子并把关键检查放到 CI合并后才发现密钥泄露敏感信息扫描只配在本地没进 CI检查扫描工具是否在 CI job 中执行将 gitleaks 加入 CI并定期全库扫描审查疲劳意见变少所有 MR 都堆给一个负责人统计各 MR 的首次响应时间轮值制度结合模块 Owner5.2 按固定顺序排查问题当审查流水线出现异常时不建议直接改工具或加规则。先按下面这个顺序排查多数问题能在前两步定位确认输入是否正确diff 范围对不对是不是拿到了完整变更分支有没有推送到远端。确认路径和命名配置文件名、钩子目录、脚本路径是否与项目约定一致。确认版本匹配pre-commit 的镜像版本、ESLint 插件版本、模型接口版本是否和配置匹配。确认配置是否生效检查钩子是否安装、CI job 是否真的执行、环境变量是否注入。确认权限和网络密钥是否有效、CI runner 能否访问内网依赖、代码仓库的权限是否允许机器人读取。查看日志关键字CI 日志里出现timeout、401、403、unsupported_country_region_territory时按提示逐项处理。人工兜底工具全部正常但结果不合理时先人工确认问题是否真实再决定是否调整规则。6. 落地清单与下一步扩展6.1 团队接受 AI 代码前的检查清单下列清单可以直接复制到项目文档中作为发布前检查依据发布前检查清单 - [ ] 变更文件列表与需求范围一致没有夹带无关修改 - [ ] 自动检查关卡已运行格式、lint、类型检查、安全扫描 - [ ] 敏感信息扫描通过未出现密钥、Token、连接串 - [ ] AI 审查报告已生成人工确认了其中“高风险”和“需人工确认”项 - [ ] A 级模块已有指定 Owner 批准 - [ ] 高风险依赖升级有负责人核对变更说明 - [ ] 新增代码有对应测试测试在 CI 中通过 - [ ] 异常分支被覆盖空值、超时、失败回滚、部分成功 - [ ] 未将来源不明的提示词或脚本直接执行 - [ ] 回滚方案明确知道如何快速回退本次变更6.2 生产环境还要补的保障以上流程解决的是“代码合入前”的问题。合入后生产环境还需要额外的保障配置外置密钥、连接串、开关不写进代码库交给环境变量或配置服务。日志与监控高危模块要有足够日志关键业务操作需要有 traceId 串联。可观测告警审查阶段漏掉的问题靠监控和告警兜底越早发现修复成本越低。回滚机制每个版本明确回滚方式禁止只有一个负责人知道怎么回滚。依赖锁定AI 生成代码经常引入新依赖锁定版本并审查依赖来源。数据备份涉及数据迁移的变更必须先验证可回滚性。6.3 可以继续扩展的方向这套审查体系落地后团队可以继续往三个方向扩展。第一个方向是变更影响分析。根据调用关系自动判断一个函数被谁引用把“这个文件改了会影响哪些下游”变成机器可直接查询的事实。AI 生成的跨模块改动先做影响分析再决定是否需要更多人工关注。第二个方向是测试补充自动化。AI 生成代码的同时生成对应单元测试并把测试覆盖情况纳入合并门槛。这里的重点是审查测试质量而不是只看覆盖率数字。第三个方向是对 AI 审查结果做反馈闭环。记录每次 AI 审查意见最终是否被确认用这部分数据微调提示词和工具参数。AI 审查不是一次配置就结束的功能它和静态规则一样需要持续校准否则会因为误报增加而逐渐被团队忽略。回到最初的问题AI 写代码但人审不完怎么办。答案不是制造一个无所不能的审查机器人而是重新分配责任——机器负责能机械化判断的全部环节AI 预审负责生成风险地图人只对真正高风险、需要业务判断和长期上下文的部分做深度决策。这套体系不需要一次搭完可以先从“CI 只检查变更文件”和“一个结构化 AI 审查提示词”开始跑通两周后根据团队自己的缺陷数据加关卡。先让流程在最小范围内稳定再逐步扩大比一开始就设计一个全自动审查平台更可靠。