在代码审查门禁中接入大模型进行 Code Review最容易掉进的一个深坑就是“直接把 Diff 丢给通用 Prompt”。早期我们团队也这么干过结果审查结果沦为大型废话现场模型不是在纠结变量命名要不要加驼峰就是在洋洋洒洒地建议开发者把let改成const甚至提出一些脱离项目上下文的所谓“重构建议”。开发者不仅对 AI 审查产生了极强的厌烦心理反而让真正的架构反模式和性能缺陷从眼皮底下溜走了。通用大模型懂全世界的开源通用代码但它绝不可能无师自通地理解你们团队特有的 Monorepo 依赖隔离规范、双 11 防资损金钱格式化要求、以及 Vue 3.6 Vapor 模式下的闭包陷阱。要想让 AI 审查成为守护生产安全的特种兵必须建立一套像管理 ESLint 规则一样严肃、版本化且闭环迭代的定制化规则池Rule Registry。今天是国庆长假的最后一天也是我们团队 AI 审查规则池 1.0 版本正式封板的日子。本文系统复盘我们如何从 0 到 1 搭建规则池、度量有效率并压低误报率。规则池四维分级分类体系我们首先摒弃了“一个大 Prompt 包打天下”的旧思路将代码审查拆解为四个独立的防御维度。每个维度拥有独立的规则定义、触发条件与拦截等级Error / Warning / Info┌────────────────────────────────────────────────────────┐ │ 前端 AI 规则注册池 (Rule Pool) │ ├───────────────┬────────────────┬───────────────┬───────┤ │ 1. 资损与安全 │ 2. 架构边界守卫 │ 3. 性能防劣化 │ 4. DS │ │ (Sec-Audit) │ (Arch-Guard) │ (Perf-Guard) │ (DS) │ │ 级别: Error │ 级别: Error │ 级别: Warning │ Info │ │ 阻塞合并 │ 阻塞合并 │ PR 评论提示 │ 可忽略│ └───────────────┴────────────────┴───────────────┴───────┘1. 资损与安全红线Sec-Audit拦截等级Error规则 101浮点数价格直接计算拦截。在前端涉及金额、优惠券减免的逻辑中严禁直接使用 JS 原生 - * /操作符必须使用BigNumber或团队公共的currencyCent金钱库。规则 102XSS 与未清洗 innerHTML/v-html 拦截。任何大模型流式输出或服务端富文本注入必须显式经过DOMPurify清洗严禁裸调。2. 架构边界守卫Arch-Guard拦截等级Error规则 201业务组件反向依赖基础库拦截。业务模块代码绝不允许反向污染通用公共包禁止跨 Domain 越权调用未暴露的私有 Service。规则 202防腐层绕过拦截。遗留老旧系统的网络请求结果未经过Adapter.toDomain()映射前严禁在视图层组件直接解构。3. 性能防劣化门禁Perf-Guard拦截等级Warning规则 301高频事件未防抖节流警告。在scroll、resize、SSE 流式打字机事件回调中直接操作深层响应式对象或执行复杂计算。规则 302未闭合 EventListener / RAF 泄漏拦截。在组件onMounted绑定的全局事件或定时器在onUnmounted中未成对销毁。4. 设计系统一致性DS-Consistency拦截等级Info规则 401硬编码魔数颜色与间距提醒。在style或 Tailwind 类中出现非 Design Token 规范的任意十六进制色值如#f74221提示统一收敛到主题变量。规则的工程化定义规范Rule Schema每条规则都不是散乱的文本描述而是按照严格的 JSON/YAML Schema 结构化归档在.codex/rules/仓库中# .codex/rules/perf/perf-302-listener-leak.yml id: PERF-302 name: 未闭合全局监听器与定时器泄漏 category: performance severity: error target_files: - src/**/*.vue - src/**/*.ts ast_filter: callee_names: [addEventListener, setInterval, requestAnimationFrame] prompt_template: | 检查目标 Diff 中是否在生命周期或组件初始化时注册了全局事件、定时器或 RAF 但缺少在卸载阶段onUnmounted / cleanup中显式移除的配对调用。 若存在泄漏请输出具体代码行及标准清理示范。 few_shot_examples: - diff: | onMounted(() { window.addEventListener(resize, handleResize); }); verdict: violation explanation: 在 onMounted 监听了 window.resize但未在 onUnmounted 中调用 removeEventListener。 - diff: | const cleanup useEventListener(window, resize, handleResize); verdict: pass explanation: 使用了 VueUse 的自动化清理 hook不存在内存泄漏风险。关键技术突破AST 前置过滤与精准唤醒如果对每一个 Pull Request 触发所有几十条规则的 LLM 判定每次 CI 构建都需要花费数十元调用费并等待 2 分钟以上根本不可能在敏捷迭代中推行。我们实现的突破是AST 静态前置分析与动态规则路由代码扫描阶段利用babel/parser或ts-morph快速遍历本次 PR 的 Git Diff规则激活器Trigger Matcher只有当 Diff 中命中了该规则预设的 AST 特征例如检测到了addEventListener标识符或金额相关字段名才会将该条专用规则以及对应的 Few-shot 样例拼接进 Prompt分片并发审查被激活的 2~3 条高优先级规则并行下发给端侧或内网大模型将每次 PR 审查的上下文缩减了 80%响应耗时从 90 秒压制到 8 秒以内。核心度量看板有效拦截率与误报率任何质量门禁如果只谈功能不谈数据都是在自欺欺人。我们定义了门禁生命力的两大黄金指标$$\text{有效拦截率} \frac{\text{开发者主动采纳/修正的报警数}}{\text{总报警数}} \times 100%$$$$\text{误报率 (False Positive)} \frac{\text{被开发者标注为 Ignored / False Alarm 的次数}}{\text{总报警数}} \times 100%$$本周W1实跑数据表现在国庆前夕的最后一次双 11 预热发版中整个前端仓库产生了 84 次 PR 合并审查总审查代码行数14,290 行规则池命中告警数37 次真实有效拦截33 次包括 2 起潜在资损金钱计算误差、5 起组件销毁事件泄漏、11 起跨包非法依赖引入误报与忽略4 次误报率由上周的 24.5% 骤降至10.8%平均审查耗时每 PR 平均 6.4 秒。规则池版本灰度与淘汰机制没有一条规则是永恒正确的。随着业务框架升级到 Vue 3.6 和 Vite 7.0一些老旧规则如针对 Options API 的this指向校验已经沦为历史垃圾。我们建立了规则的生命周期管理机制实验期Draft新规则上线前先在后台静默运行 1 周只上报日志但不给 PR 贴标签或阻断流水线。如果 1 周内误报率超过 20%直接驳回打磨正式期Active通过实验考核的规则合入主规则池参与流水线阻断退役期Deprecated连续 60 天触发次数为 0或被连续标注为过时的规则自动归档降级为非活动规则。结语从杂乱无章的通用 LLM 审查到结构化、工程化的定制规则池代码审查工具终于从一个“爱挑刺但说不到点子上的实习生”进化成了“精通团队每一条规范红线的守卫者”。用严密的工程规范管理 AI再让 AI 捍卫工程规范这才是大模型落地在前端工程化的正确姿态。
在代码审查门禁中接入大模型进行 Code Review最容易掉进的一个深坑就是“直接把 Diff 丢给通用 Prompt”。早期我们团队也这么干过结果审查结果沦为大型废话现场模型不是在纠结变量命名要不要加驼峰就是在洋洋洒洒地建议开发者把let改成const甚至提出一些脱离项目上下文的所谓“重构建议”。开发者不仅对 AI 审查产生了极强的厌烦心理反而让真正的架构反模式和性能缺陷从眼皮底下溜走了。通用大模型懂全世界的开源通用代码但它绝不可能无师自通地理解你们团队特有的 Monorepo 依赖隔离规范、双 11 防资损金钱格式化要求、以及 Vue 3.6 Vapor 模式下的闭包陷阱。要想让 AI 审查成为守护生产安全的特种兵必须建立一套像管理 ESLint 规则一样严肃、版本化且闭环迭代的定制化规则池Rule Registry。今天是国庆长假的最后一天也是我们团队 AI 审查规则池 1.0 版本正式封板的日子。本文系统复盘我们如何从 0 到 1 搭建规则池、度量有效率并压低误报率。规则池四维分级分类体系我们首先摒弃了“一个大 Prompt 包打天下”的旧思路将代码审查拆解为四个独立的防御维度。每个维度拥有独立的规则定义、触发条件与拦截等级Error / Warning / Info┌────────────────────────────────────────────────────────┐ │ 前端 AI 规则注册池 (Rule Pool) │ ├───────────────┬────────────────┬───────────────┬───────┤ │ 1. 资损与安全 │ 2. 架构边界守卫 │ 3. 性能防劣化 │ 4. DS │ │ (Sec-Audit) │ (Arch-Guard) │ (Perf-Guard) │ (DS) │ │ 级别: Error │ 级别: Error │ 级别: Warning │ Info │ │ 阻塞合并 │ 阻塞合并 │ PR 评论提示 │ 可忽略│ └───────────────┴────────────────┴───────────────┴───────┘1. 资损与安全红线Sec-Audit拦截等级Error规则 101浮点数价格直接计算拦截。在前端涉及金额、优惠券减免的逻辑中严禁直接使用 JS 原生 - * /操作符必须使用BigNumber或团队公共的currencyCent金钱库。规则 102XSS 与未清洗 innerHTML/v-html 拦截。任何大模型流式输出或服务端富文本注入必须显式经过DOMPurify清洗严禁裸调。2. 架构边界守卫Arch-Guard拦截等级Error规则 201业务组件反向依赖基础库拦截。业务模块代码绝不允许反向污染通用公共包禁止跨 Domain 越权调用未暴露的私有 Service。规则 202防腐层绕过拦截。遗留老旧系统的网络请求结果未经过Adapter.toDomain()映射前严禁在视图层组件直接解构。3. 性能防劣化门禁Perf-Guard拦截等级Warning规则 301高频事件未防抖节流警告。在scroll、resize、SSE 流式打字机事件回调中直接操作深层响应式对象或执行复杂计算。规则 302未闭合 EventListener / RAF 泄漏拦截。在组件onMounted绑定的全局事件或定时器在onUnmounted中未成对销毁。4. 设计系统一致性DS-Consistency拦截等级Info规则 401硬编码魔数颜色与间距提醒。在style或 Tailwind 类中出现非 Design Token 规范的任意十六进制色值如#f74221提示统一收敛到主题变量。规则的工程化定义规范Rule Schema每条规则都不是散乱的文本描述而是按照严格的 JSON/YAML Schema 结构化归档在.codex/rules/仓库中# .codex/rules/perf/perf-302-listener-leak.yml id: PERF-302 name: 未闭合全局监听器与定时器泄漏 category: performance severity: error target_files: - src/**/*.vue - src/**/*.ts ast_filter: callee_names: [addEventListener, setInterval, requestAnimationFrame] prompt_template: | 检查目标 Diff 中是否在生命周期或组件初始化时注册了全局事件、定时器或 RAF 但缺少在卸载阶段onUnmounted / cleanup中显式移除的配对调用。 若存在泄漏请输出具体代码行及标准清理示范。 few_shot_examples: - diff: | onMounted(() { window.addEventListener(resize, handleResize); }); verdict: violation explanation: 在 onMounted 监听了 window.resize但未在 onUnmounted 中调用 removeEventListener。 - diff: | const cleanup useEventListener(window, resize, handleResize); verdict: pass explanation: 使用了 VueUse 的自动化清理 hook不存在内存泄漏风险。关键技术突破AST 前置过滤与精准唤醒如果对每一个 Pull Request 触发所有几十条规则的 LLM 判定每次 CI 构建都需要花费数十元调用费并等待 2 分钟以上根本不可能在敏捷迭代中推行。我们实现的突破是AST 静态前置分析与动态规则路由代码扫描阶段利用babel/parser或ts-morph快速遍历本次 PR 的 Git Diff规则激活器Trigger Matcher只有当 Diff 中命中了该规则预设的 AST 特征例如检测到了addEventListener标识符或金额相关字段名才会将该条专用规则以及对应的 Few-shot 样例拼接进 Prompt分片并发审查被激活的 2~3 条高优先级规则并行下发给端侧或内网大模型将每次 PR 审查的上下文缩减了 80%响应耗时从 90 秒压制到 8 秒以内。核心度量看板有效拦截率与误报率任何质量门禁如果只谈功能不谈数据都是在自欺欺人。我们定义了门禁生命力的两大黄金指标$$\text{有效拦截率} \frac{\text{开发者主动采纳/修正的报警数}}{\text{总报警数}} \times 100%$$$$\text{误报率 (False Positive)} \frac{\text{被开发者标注为 Ignored / False Alarm 的次数}}{\text{总报警数}} \times 100%$$本周W1实跑数据表现在国庆前夕的最后一次双 11 预热发版中整个前端仓库产生了 84 次 PR 合并审查总审查代码行数14,290 行规则池命中告警数37 次真实有效拦截33 次包括 2 起潜在资损金钱计算误差、5 起组件销毁事件泄漏、11 起跨包非法依赖引入误报与忽略4 次误报率由上周的 24.5% 骤降至10.8%平均审查耗时每 PR 平均 6.4 秒。规则池版本灰度与淘汰机制没有一条规则是永恒正确的。随着业务框架升级到 Vue 3.6 和 Vite 7.0一些老旧规则如针对 Options API 的this指向校验已经沦为历史垃圾。我们建立了规则的生命周期管理机制实验期Draft新规则上线前先在后台静默运行 1 周只上报日志但不给 PR 贴标签或阻断流水线。如果 1 周内误报率超过 20%直接驳回打磨正式期Active通过实验考核的规则合入主规则池参与流水线阻断退役期Deprecated连续 60 天触发次数为 0或被连续标注为过时的规则自动归档降级为非活动规则。结语从杂乱无章的通用 LLM 审查到结构化、工程化的定制规则池代码审查工具终于从一个“爱挑刺但说不到点子上的实习生”进化成了“精通团队每一条规范红线的守卫者”。用严密的工程规范管理 AI再让 AI 捍卫工程规范这才是大模型落地在前端工程化的正确姿态。
