AI 代码审查落地：前端复杂度、风险与可维护性的三层扫描

AI 代码审查落地前端复杂度、风险与可维护性的三层扫描一、AI 审查不是替代 Code Review而是先清掉低级噪声前端项目一旦进入多人协作Code Review 很容易被低级问题拖慢。组件 props 命名混乱、状态来源不清、重复 hooks、CSS 覆盖链过长、异步请求缺少取消逻辑这些问题不难但很耗人。AI 代码审查的价值不是替代资深工程师判断架构而是把可规则化、可归纳、可预警的问题先扫掉。真正可落地的 AI 审查不能只让模型对着 diff 说“代码质量不错”。这类评价没有证据也不能进入工程流程。它至少要输出三类结果复杂度风险、运行时风险、维护性风险。复杂度风险看组件是否过大、分支是否过多运行时风险看副作用、异步和状态一致性维护性风险看命名、重复逻辑和边界抽象。如果 AI 审查结果不能被开发者复现它就是一段漂亮废话。一个合格的审查系统必须给出文件、行号、证据、建议和严重等级。否则 Review 现场只会多一个噪声源。二、审查链路从 diff 到结构化风险报告flowchart TD A[Git Diff] -- B[AST 解析] B -- C[规则扫描] B -- D[上下文裁剪] C -- E[确定性问题] D -- F[LLM 风险分析] E -- G[合并报告] F -- G G -- H{是否阻断合并} H -- 严重问题 -- I[阻断并要求修改] H -- 中低风险 -- J[评论提示]这条链路里AST 和规则扫描必须在 LLM 前面。原因很简单能确定的问题不要交给概率模型。未使用变量、Hook 调用顺序、依赖数组遗漏、循环中 key 不稳定这些都可以由规则或静态分析发现。模型更适合处理跨文件语义和模式识别比如某个状态被多个组件间接修改或者组件边界已经开始腐化。上下文裁剪也很关键。把整个仓库塞给模型既贵又不准。更好的做法是围绕 diff 找邻近函数、导入依赖、相关类型定义和测试文件。上下文太少模型会猜上下文太多模型会淹。三、实现示例规则结果和模型结果必须分层下面是一个 Node.js 侧的审查骨架。它把确定性规则和模型分析分开避免所有判断都变成黑盒。type Severity blocker | warning | info; interface Finding { file: string; line: number; severity: Severity; source: rule | llm; title: string; evidence: string; suggestion: string; } async function reviewChangedFiles(files: string[]): PromiseFinding[] { const ruleFindings await runStaticRules(files); const contexts await buildReviewContexts(files); const llmFindings await runLLMReview(contexts); return [...ruleFindings, ...llmFindings] .filter(item item.evidence.length 0) .sort((a, b) severityRank(a.severity) - severityRank(b.severity)); } function severityRank(severity: Severity): number { return severity blocker ? 0 : severity warning ? 1 : 2; }这段代码的重点是source字段。规则发现的问题和模型发现的问题不应混在一起。规则问题可以直接阻断模型问题更适合先作为建议除非团队已经为某类模型结论建立了稳定评测集。输出格式也必须稳定。建议每条评论包含“证据”和“建议”。只说“这里可维护性不好”没有意义。要指出哪段代码导致复杂度上升建议拆到哪个层级是否需要补测试。四、权衡分析AI 审查过严会伤害交付节奏AI 审查最大的风险是误报。误报多了团队会直接忽略所有评论。解决方式不是让提示词更温柔而是分级处理。阻断项只交给确定性规则和高置信模型项。模型建议默认不阻断只作为 Review 辅助。另一个风险是审查口径不稳定。今天说组件拆得太细明天又说组件过大。要避免这种情况需要把团队规范固化成审查规则并给模型提供明确准则。模型不是规范本身它只是执行规范的助手。AI 审查也不适合处理产品取舍。比如某个组件为了上线速度写得不够优雅但风险可控这类判断需要人决定。工具只能给出证据和代价不能替团队承担权衡。五、总结AI 代码审查的工程价值在于先过滤低级噪声再辅助发现跨文件风险。落地时必须把 AST 规则、上下文裁剪、模型分析和结构化报告分层处理。所有结论都要有文件、行号、证据和建议。建议先从 warning 模式开始不要一上来阻断合并。等误报率、漏报率和团队接受度稳定后再把部分高置信问题升级为 blocker。代码审查要提升交付质量不应该制造新的流程内耗。