代码生成评审先看边界引入 AI 代码补全后代码产出会更快但副作用的生命周期仍要靠工程约束保证。一次 CI 检查中我们发现部分 Vue3 组件和 React Hook 创建了setInterval或 EventBus 监听却没有在组件卸载时清理。这类代码通常能正常运行问题会在多次进入、离开页面后才暴露。人工评审容易漏掉生命周期配对因此可以在 CI 中补充 AST 静态检查把可识别的风险提前反馈给提交者。1. 现场诊断智能补全带来的隐性内存泄漏可以用自动化回归构造反复切换路由的场景再结合浏览器内存快照检查定时器和订阅是否随组件卸载而释放。我们抽取出被拦截的典型 React 代码片段。AI 给出了如下的补全逻辑// 被 AI 生成助手“优化”过的图表轮询逻辑 import React, { useEffect, useState } from react; export const RealtimeChart: React.FC{ symbol: string } ({ symbol }) { const [data, setData] useStatenumber[]([]); useEffect(() { // AI 自动生成的定时拉取逻辑却漏掉了 return 清理函数 const timer setInterval(async () { const res await fetch(/api/market/${symbol}); const json await res.json(); setData(prev [...prev.slice(-19), json.price]); }, 1000); }, [symbol]); return div classNamechart-container{/* 渲染图表 */}/div; };用 Chrome DevTools 切到 Memory 面板抓了一份 Heap Snapshot。对比两次 Snapshot 发现RealtimeChart组件即使已经被 Unmount其内部闭包依然被setInterval的回调函数强行持有。每一次组件销毁再重建后台就多出一个永不停歇的拉取请求。LLM 在概率学上很擅长写出“能跑通”的代码但它没有内存周期的工程概念。如果门禁只停留在传统的 Linter 层很难识别出这种涉及生命周期匹配与闭包安全约束的综合问题。2. 门禁设计AST 校验与确定性防线对于 AI 参与生成的代码可用基于 AST抽象语法树的规则补足人工评审。整个审查链路分为三层大模型输出提炼层、AST 校验规则拦截层、以及自动修复与 CI 熔断层。Prompt 可以减少常见错误但不能替代校验。规则可关注useEffect、onMounted中创建的订阅、定时器和 DOM 事件并检查是否存在匹配的清理逻辑。3. 工程落地自定义 AST 审查插件实现为了在 TypeScript 项目里精准捕获这类 AI 引入的副作用泄露我们编写了一个标准的 ESLint 自定义规则。它通过遍历 AST 节点专门防范没有返回清理闭包的 Hook/Lifecycle。下面是该质量门禁的核心插件代码实现import { Rule } from eslint; import { Node, CallExpression, FunctionExpression, ArrowFunctionExpression } from estree; const hookEffectCleanCheck: Rule.RuleModule { meta: { type: problem, docs: { description: 捕获 AI 代码生成中未清理定时器或订阅的副作用隐患, category: Possible Errors, recommended: true, }, fixable: code, messages: { missingCleanup: 检测到在 Effect 中启动了资源订阅/定时器 ({{ resource }})但未提供 Unmount 清理闭包, }, }, create(context) { return { CallExpression(node: CallExpression) { // 识别 useEffect 或 useLayoutEffect 调用 if ( node.callee.type Identifier (node.callee.name useEffect || node.callee.name useLayoutEffect) ) { const callback node.arguments[0] as FunctionExpression | ArrowFunctionExpression; if (!callback || !callback.body) return; let hasAsyncResource false; let resourceName ; let hasReturnCleanup false; // 递归遍历 Effect 内部节点 const checkNode (childNode: Node) { if (childNode.type CallExpression childNode.callee.type Identifier) { const name childNode.callee.name; if ([setInterval, setTimeout, addEventListener, subscribe].includes(name)) { hasAsyncResource true; resourceName name; } } if (childNode.type ReturnStatement) { hasReturnCleanup true; } }; // 遍历函数体 AST 节点 if (callback.body.type BlockStatement) { callback.body.body.forEach(stmt { if (stmt.type ExpressionStatement) { checkNode(stmt.expression); } else if (stmt.type ReturnStatement) { hasReturnCleanup true; } }); } // 命中有危险资源分配但缺少清理返回值 if (hasAsyncResource !hasReturnCleanup) { context.report({ node, messageId: missingCleanup, data: { resource: resourceName }, fix(fixer) { // 如果是 setInterval自动提示或插入简单清理模板 if (callback.body.type BlockStatement resourceName setInterval) { const lastStatement callback.body.body[callback.body.body.length - 1]; return fixer.insertTextAfter(lastStatement, \n return () clearInterval(timer);); } return null; }, }); } } }, }; }, }; export default hookEffectCleanCheck;把这个 AST 拦截规则集成到前端项目的.eslintrc.js配置文件中module.exports { plugins: [custom-ai-gate], rules: { custom-ai-gate/hook-effect-clean-check: error, }, };当 AI 生成器写出包含未清理定时器的代码时构建流水线会在pre-commit或 CI 审查阶段立刻阻断合并并打印出具体的文件路径与修复提示。4. 落地避坑与规则演进 Trade-offs在质量门禁推进的过程中不能走向另一个极端的规则膨胀。如果把 AST 规则订得过于苛刻开发者会频繁遇到误报进而直接跳过门禁。我们需要处理三个典型的边界取舍问题防范伪清理逻辑AI 可能会为了规避 Linter 检查在useEffect末尾随意返回一个空函数return () {}。我们需要在 AST 校验层进一步分析返回的箭头函数体内是否真正调用了clearInterval或removeEventListener。性能与扫描时序全量解析大型项目的 AST 会显著拉长构建时间。我们将扫描切分为两级在 IDE 端做增量文件级别的即时 Lint 提醒在 CI 端针对 Gitstaged文件集中执行卡点。Prompt 强化与规则联动单纯用门禁去拦代码是末端治理。每次 CI 门禁拦截到特定类型的生成缺陷便将案例整理回传至团队的 Prompt 上下文库或 RAG 规则库中反向减少生成阶段的低级错误概率。规则的作用是把可验证的约束交给工具链执行生成工具负责提高产出效率边界与验收标准仍由工程团队维护。