AI 代码审查（AI Code Review）
AI 代码审查指的是：把代码变更（diff）、相关上下文（项目约束、运行结果、需求说明）交给大模型，让它像“资深同事”一样帮你做问题发现、风险提示和修改建议。它不会替代人工评审，但非常适合在 PR 阶段提前扫一遍：把明显问题、遗漏的边界条件、潜在的构建/依赖风险尽早暴露出来。
这篇文章会重点结合前端“构建工具”场景：
package.json、锁文件、Vite/Webpack 配置、CI 脚本等内容，讲清楚如何把 AI 用在代码审查上，并给出可直接复制的提示词模板。
一、AI 代码审查能做什么（以及不能做什么）
1.1 典型收益
- 更快的首轮筛查：先把“低垂的果子”捞出来（明显的 bug、遗漏的 null 判断、未处理的异常分支）。
- 更稳定的评审覆盖面：按 checklist 系统性扫一遍（安全、性能、兼容性、可维护性、测试）。
- 更擅长“文本密集型”变更：例如构建配置、依赖升级、脚本调整、文档改动，它能快速总结影响面。
- 更好的知识补位：你不熟悉的工具/配置项（如 Vite/webpack 某个选项），AI 可以先给出解释与风险点，帮助你再做验证。
1.2 需要警惕的边界
- 它不会替你运行代码：能推理，但无法保证“跑起来就对”。最终要靠测试/构建结果确认。
- 它可能会“编造”不存在的原因或 API：尤其当上下文不足时；你必须要求它“基于 diff 证据回答”。
- 安全结论不能只靠 AI：涉及鉴权、加密、供应链、命令执行等高风险问题，AI 的结论只能当线索，必须再用安全工具与人工复核。
- 隐私与合规：不要把密钥、个人信息、商业敏感代码直接贴给不受控的模型/平台。
二、最适合用 AI 审查的前端构建类变更
在“构建工具”类仓库/目录下，AI 审查尤其适合以下几类 PR：
- 依赖升级与锁文件变更：
package.json、pnpm-lock.yaml、npmrc、pnpm-workspace.yaml- 关注：破坏性升级、peerDependencies 冲突、重复依赖、postinstall 脚本风险、license 风险。
- 构建配置调整：
vite.config.ts、webpack.config.js、tsconfig.json、Babel/PostCSS 配置- 关注：开发/生产差异、sourcemap 泄露、tree-shaking 失效、别名/路径解析、插件顺序、副作用包处理。
- CI/脚本修改：GitHub Actions、
scripts/*、package.json#scripts- 关注：缓存失效、Node 版本变化、构建产物路径变化、环境变量注入、命令执行安全。
- 性能相关变更：代码分割、压缩、图片处理、bundle 分析策略
- 关注：首屏体积、缓存命中、长缓存策略、source map 与错误上报的平衡。
三、推荐工作流：AI 放在“CI 之后、人工之前”
把 AI 当作“预审”，最常见也最有效的摆放方式如下：
这样做的好处是：先用 CI “证伪”明显错误（编译不过、测试挂了），再让 AI 做结构化审查，最后由人工把关“业务正确性 + 架构取舍 + 风险接受”。
四、给 AI 的上下文清单：越具体，越少胡扯
你可以把下面这份清单当作固定模板（建议每次 PR 都尽量补齐）：
- 变更目标：这次改动要解决什么问题？验收标准是什么？
- 影响范围：影响开发环境还是生产环境？影响哪些页面/模块？
- 关键文件：把本次 diff 里最关键的文件片段贴出来（不要只贴标题）。
- 项目约束：Node/包管理器版本、框架版本、是否 monorepo、是否 SSR 等。
- 运行证据：CI 日志（关键报错段）、本地构建/测试命令与输出。
- 你想让 AI 重点看什么：例如“重点审查安全与供应链风险”“重点看 Vite 构建产物体积”。
一个可直接复制的“上下文头部”示例：
项目背景：
- 前端：React + TypeScript
- 构建：Vite（生产构建）/ Webpack（遗留包）
- 包管理：pnpm
- Node：>= 20
本次目标：
- 升级依赖以修复漏洞，并调整构建配置减少产物体积
请你基于以下 diff 做 AI 代码审查，输出：
1) 变更摘要（3-5 条）
2) 风险点（按严重度：阻塞/重要/建议）
3) 具体修改建议（尽量给出可直接应用的代码片段或补丁）
4) 需要补充的测试/验证命令
5) 你仍不确定、需要我补充的信息
五、审查维度 Checklist（构建类 PR 版本）
下面这个表可以直接作为“提问清单”，让 AI 按项输出。
| 维度 | 你要检查什么 | 适合问 AI 的问题 |
|---|---|---|
| 正确性 | 配置是否写错、拼写是否错误、逻辑是否自洽 | “这段配置在 Vite/Webpack 里是否有效？有没有拼写错误或互斥选项？” |
| 兼容性 | Node/浏览器/依赖版本兼容、破坏性升级 | “升级是否有 breaking change？对 Node 20/浏览器支持是否有影响？” |
| 构建产物 | tree-shaking、sourcemap、chunk、资源路径 | “这会不会导致 tree-shaking 失效或产物变大？sourcemap 是否可能泄露源码？” |
| 依赖与供应链 | postinstall、二进制依赖、license、重复依赖 | “新增/升级依赖是否引入脚本执行风险？是否可能产生重复依赖或 peer 冲突？” |
| 安全 | 注入、命令执行、路径遍历、敏感信息泄露 | “是否存在可被用户输入影响的命令执行/路径拼接？是否把敏感配置打进包？” |
| 可维护性 | 可读性、可配置性、可观测性 | “有没有更清晰的写法？需要补充注释/文档吗？” |
| 测试与验证 | 该怎么验证变更有效且无回归 | “给出最小验证步骤：哪些命令、看哪些指标/日志？” |
六、提示词模板（直接可用）
6.1 通用 PR 审查模板（强烈推荐）
你是一个严谨的代码审查员。请基于我提供的 diff 审查代码，不要臆测仓库里不存在的文件或逻辑。
输出格式必须包含：
1) 变更摘要（要点列表）
2) 问题与风险（按严重度：阻塞 / 重要 / 建议）
3) 可操作的修改建议（给出具体代码片段；能给补丁更好）
4) 需要补充的测试与验证步骤（可复制命令）
5) 需要我补充的上下文问题（如果信息不足）
额外要求：
- 如果你指出问题，请引用对应的文件名与代码片段（来自 diff）。
- 不要泛泛而谈；每条建议都要说明“为什么”和“怎么做”。
6.2 构建配置变更（Vite/Webpack）专项模板
请专项审查本次构建配置相关变更（Vite/Webpack/TSConfig/CI）。
重点关注：
1) 开发 vs 生产的行为差异
2) tree-shaking / code splitting 是否可能失效
3) sourcemap、环境变量、路径别名是否可能导致泄露或构建失败
4) 插件/loader 顺序是否合理，是否有互斥或重复
5) 缓存策略与构建耗时：是否会让 CI 变慢
请输出：
- 风险清单（阻塞/重要/建议）
- 推荐的验证命令（例如 build、bundle 分析、产物体积对比）
- 如需修改，给出可直接复制的配置片段
6.3 依赖升级 + 锁文件变更专项模板
请审查依赖升级（package.json + 锁文件）相关风险：
1) 是否存在 breaking changes、peerDependencies 冲突
2) 是否引入新的 postinstall/prepare 脚本或二进制依赖
3) 是否可能导致重复依赖、包体积增大、构建速度下降
4) 是否需要同步更新 Node 版本、构建脚本或 CI 缓存键
请输出：
- 风险点（按严重度）
- 推荐的验证命令（install/build/test）
- 如果需要锁定版本/加 overrides/resolutions，请给出示例
6.4 安全与供应链专项模板（高风险变更时使用）
请以安全审查视角审查本次 diff，重点看：
1) 是否出现命令执行（child_process/exec）、危险脚本（postinstall）
2) 是否出现把敏感信息打包进前端（env、token、密钥）
3) 是否存在路径拼接、正则、反序列化等高风险点
4) 依赖引入是否可疑（来源不明、权限过大、脚本过多）
输出：
- 高风险点（阻塞）
- 中风险点（重要）
- 低风险点（建议）
- 需要进一步确认的证据/信息（例如 CI 日志、依赖来源说明）
七、让 AI 的输出“更像一个可合并的 Review”
建议你强制 AI 用结构化输出，减少“长篇大论但不可用”的情况：
- 严重度分级：阻塞（必须改）/重要（强烈建议改）/建议（可选优化）
- 建议必须落到动作：给出具体代码片段、配置项、验证命令
- 遇到不确定就提问：让它列出“我还缺什么信息才能下结论”
一个常用的 Review 输出骨架（你可以要求 AI 复用这个格式）：
变更摘要：
- ...
阻塞：
- [文件] 片段：...
原因：...
建议：...
重要：
- ...
建议：
- ...
验证步骤：
- pnpm install
- pnpm build
- （可选）产物体积对比：...
需要补充的信息：
- ...
八、实战示例：一次“依赖升级 + 构建配置调整”的 AI 审查
你可以把下面的 diff（示例）连同“输出格式要求”一起交给 AI，让它按 checklist 输出：
diff --git a/package.json b/package.json
@@
"dependencies": {
- "vite": "^5.0.0",
+ "vite": "^6.0.0",
"react": "^19.0.0"
},
"scripts": {
+ "postinstall": "node scripts/check-env.js",
"build": "docusaurus build"
}
diff --git a/vite.config.ts b/vite.config.ts
@@
export default defineConfig({
build: {
+ sourcemap: true,
rollupOptions: {
output: {
manualChunks: undefined
}
}
}
})
你期望 AI 能至少指出这些点（不代表全部）：
vite大版本升级是否可能有 breaking change（需要看迁移指南/实际构建结果验证）- 新增
postinstall脚本的供应链风险与可维护性（是否必要、是否会影响 CI、是否需要文档说明） build.sourcemap: true在生产环境可能带来的源码泄露风险（是否只对内部环境开启、是否上传到错误平台后再删除）manualChunks: undefined的真实效果是否如预期（是否反而让拆包策略失控）
九、把 AI 审查接入团队（可选）
常见接入方式（从低成本到高自动化）：
- 本地使用（个人）：提交 PR 前把 diff 贴给 AI，先修一轮。
- PR 机器人评论（团队）：CI 拉取 PR diff，调用模型产出结构化评论（注意脱敏与权限控制）。
- 与规则工具结合：AI 负责“理解与建议”，规则工具负责“证据与拦截”（lint、单测、SAST、依赖扫描等）。
关键原则：AI 的输出不要直接自动合并（除非你有非常强的约束与回滚机制），它更适合“辅助决策”而不是“自动决策”。
十、常见误区与最佳实践
- 误区 1：把 AI 当成权威结论：正确做法是把它当“线索生成器”，再用测试/构建/工具验证。
- 误区 2：只给一句话让它猜：正确做法是贴 diff + 约束 + 目标 + 输出格式。
- 误区 3：输出太泛，落不了地：正确做法是强制它给“可执行建议”（代码片段/命令/清单）。
- 误区 4：忽视数据安全：正确做法是脱敏、最小必要信息、使用受控模型与权限审计。
十一、面试高频问答
- AI 代码审查能替代人工 Code Review 吗？为什么？
不能。AI 缺少真实运行与业务语境，可能出现幻觉；最终责任需要由工程师承担。AI 更适合做首轮筛查与结构化建议。 - AI 审查和 lint/静态检查的关系是什么？
lint/静态检查是规则驱动、可证伪；AI 是语义驱动、善于发现“规则之外的问题”。最佳实践是“规则工具兜底 + AI 提升覆盖面 + 人工做关键决策”。 - 如何降低 AI 幻觉带来的误导？
给足上下文（diff/约束/日志），要求“引用证据回答”，并让它列出不确定项与需要补充的信息。 - 把 AI 放在流程的哪个位置最合适？
通常是 CI 之后、人工评审之前：先用 CI 过滤硬错误，再用 AI 输出结构化风险清单，最后人工聚焦关键点。 - 依赖升级时，AI 审查最该关注什么？
breaking changes、peerDependencies 冲突、postinstall/二进制依赖风险、重复依赖与体积/构建耗时变化、Node/CI 兼容性。 - 构建配置（Vite/Webpack）变更时，AI 审查最该关注什么？
开发/生产差异、tree-shaking 与拆包策略、sourcemap 与 env 泄露、插件/loader 顺序与副作用、缓存与构建耗时。 - 为什么说“安全结论不能只靠 AI”？
因为安全需要证据链与可验证手段（扫描/复现/审计）。AI 的强项是提示可疑点与推演攻击路径，但结论必须复核。 - 如何评估 AI 审查在团队中的效果？
看可量化指标：评审耗时是否下降、回归缺陷是否减少、阻塞问题提前发现率、误报率、开发者满意度等。 - AI 审查输出太长、不可执行怎么办？
在提示词里强制输出格式（摘要/风险分级/可执行建议/验证命令/待确认问题），并限制每个部分条数。 - 团队接入 AI 审查时，最重要的风险是什么？
数据泄露与权限滥用（把私有代码/密钥发到不受控平台），以及“自动化过度”导致未经验证的建议被直接采纳。