智能组件评审如何识别隐性风险智能生成工具可以快速补出 React 或 Vue 组件但“能编译”与“适合合并”之间还有一段距离。模型通常依据局部提示生成代码它看不到项目完整的状态约定、组件库版本、可访问性规范和性能预算。评审这类代码时不能因为排版整齐、类型齐全就降低检查强度也不必把所有问题都归咎于生成方式。沿着输入、状态、渲染和清理路径检查问题会更具体。1. 先检查四类容易遗漏的问题下面四类问题同样可能出现在手写代码中只是生成代码更容易重复已有模式而没有核对项目约束。1.1 幻觉 API 与虚假类型推导组件属性看起来符合命名习惯不代表当前版本真的支持。评审者应对照项目锁定的类型声明和官方文档尤其留意as any、双重断言和关闭严格模式后才通过的代码。把类型错误压下去只会把问题推到运行时。1.2 隐式状态撕裂与 Context 滥用表单或弹窗生成代码常把每个字段拆成独立useState却没有说明提交、重置和关闭时怎样保持一致。看到 Context、全局 Store 或缓存时要继续追踪订阅范围哪些组件会因值变化重新渲染组件卸载后又有哪些请求、计时器和监听器需要取消。1.3 可访问性a11y与语义化缺失div onClick{handleClick}提交/div用鼠标可以点击却没有按钮的键盘行为和语义。优先换成原生button再处理禁用、焦点和可见标签。不要用堆叠role、tabIndex和键盘事件去模拟一个本来就有原生元素的控件。1.4 异步闭包陷阱与防抖失效带防抖搜索或轮询的组件若在渲染函数中创建防抖实例每次渲染都会得到一个新函数// 典型 AI 生成缺陷在渲染函数内直接创建 debounce 实例 const handleSearch lodash.debounce((val) { fetchData(val); }, 300);这种写法会让前一个实例仍保留待执行任务新的输入却进入另一个实例。修复时既要稳定函数引用也要在卸载时取消待执行回调并检查回调读取的状态是否已经过期。2. 自动检查负责确定性规则AST 规则适合检查可明确描述的模式例如可点击的非语义元素、危险类型断言以及渲染期间创建的防抖函数。规则应给出准确位置和修改理由并允许项目按组件库约定配置例外。视觉结果、业务状态和交互是否合理仍需通过组件测试、浏览器测试和人工评审判断。3. 自动化评审拦截器实现下面的 Babel AST 示例演示三类检查。它适合作为规则原型接入项目之前还要补充解析失败处理、文件范围、测试用例和组件库白名单。import * as parser from babel/parser; import traverse from babel/traverse; import * as t from babel/types; export interface CodeReviewIssue { line: number; type: CLOSURE_HAZARD | A11Y_MISSING | TYPE_CAST_RISK; message: string; } export function auditAIComponentCode(code: string): CodeReviewIssue[] { const issues: CodeReviewIssue[] []; const ast parser.parse(code, { sourceType: module, plugins: [jsx, typescript], }); traverse(ast, { // 检查 1: 扫描 div/span 上的 onClick 是否缺少 a11y 支持 JSXOpeningElement(path) { const tagName path.node.name; if (t.isJSXIdentifier(tagName)) { const isClickableDiv [div, span, i].includes(tagName.name); const hasOnClick path.node.attributes.some( (attr) t.isJSXAttribute(attr) attr.name.name onClick ); const hasRole path.node.attributes.some( (attr) t.isJSXAttribute(attr) attr.name.name role ); if (isClickableDiv hasOnClick !hasRole) { issues.push({ line: path.node.loc?.start.line || 0, type: A11Y_MISSING, message: ${tagName.name} 绑定了 onClick 但缺少 rolebutton 或 tabIndex存在可访问性风险。, }); } } }, // 检查 2: 拦截 TS 中的 as any 或 as unknown as Target TSAsExpression(path) { if ( t.isTSAnyKeyword(path.node.typeAnnotation) || (t.isTSTypeReference(path.node.typeAnnotation) (path.node.typeAnnotation.typeName as t.Identifier).name any) ) { issues.push({ line: path.node.loc?.start.line || 0, type: TYPE_CAST_RISK, message: 检测到强行类型转换 (as any)AI 可能制造了类型击穿请检查属性定义。, }); } }, // 检查 3: 检测组件内部裸写的 debounce/throttle CallExpression(path) { if ( t.isMemberExpression(path.node.callee) t.isIdentifier(path.node.callee.property) ) { const methodName path.node.callee.property.name; if ([debounce, throttle].includes(methodName)) { // 判断是否包裹在 useMemo 或 useCallback 中 let currentParent path.parentPath; let isMemoized false; while (currentParent) { if ( currentParent.isCallExpression() t.isIdentifier(currentParent.node.callee) [useMemo, useCallback, useRef].includes(currentParent.node.callee.name) ) { isMemoized true; break; } currentParent currentParent.parentPath; } if (!isMemoized) { issues.push({ line: path.node.loc?.start.line || 0, type: CLOSURE_HAZARD, message: 直接在组件渲染体中创建 ${methodName} 导致每次渲染重建请用 useCallback/useRef 包裹。, }); } } } }, }); return issues; }4. 用项目样例校准规则规则上线前从仓库中挑选已知正确和已知有问题的组件作为样本。正确样本用于控制误报有问题的样本用于确认规则确实能命中。每条规则都应有独立测试并记录为什么允许某些例外。若检查结果只写“疑似 AI 代码”开发者无法据此修改提示应落到具体行为例如“非按钮元素绑定点击事件且缺少键盘入口”。CI 中先以报告模式运行观察误报集中在哪些组件再决定哪些规则阻断合并。度量也应采用仓库真实数据例如规则命中后被修复、标记例外或证明误报的数量。没有可追溯样本时不应给出看似精确的效率提升或缺陷下降比例。5. 工程师 CR 操作 Checklist自动检查通过后评审者仍要围绕真实页面核对以下内容状态生命周期核对useEffect依赖卸载时清理 EventListener、Timer、WebSocket 和在途请求。界面状态实际触发loading、error、empty、禁用、超长文本和重复提交不只查看顺利路径。样式约定确认颜色、间距和响应式断点使用项目已有的 Design Token避免组件内另建一套规则。组件职责按状态和业务职责判断是否拆分不用固定行数代替设计判断。拆分后也要避免把状态散落到难以追踪的层级。DOM 与交互检查语义元素、焦点顺序、键盘操作和无意义嵌套并在真实浏览器中验证。智能组件评审不需要一套神秘的“AI 识别术”。把类型、状态、语义和生命周期变成可复现的检查项再让自动化承担确定性部分生成代码与手写代码就能使用同一套质量标准。