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

一、AI 审查不是替代 Code Review，而是先清掉低级噪声

前端项目一旦进入多人协作，Code Review 很容易被低级问题拖慢。

比如组件 props 命名混乱、状态来源不清、重复 hooks、CSS 覆盖链过长、异步请求缺少取消逻辑。这些问题不难，但很耗人。

AI 代码审查的价值，不是替代资深工程师判断架构。它更适合先把可规则化、可归纳、可预警的问题扫掉。

真正能落到工程里的 AI 审查，绝不是让模型对着 diff 轻飘飘来一句“代码质量不错”就算完事。

这种判断既拿不出证据，也根本没法进入正式流程。

至少得给出三类明确结果：

• 复杂度风险：重点看组件是不是过大、分支是不是过多。
• 运行时风险：主要看副作用、异步处理和状态一致性。
• 维护性风险：要看命名是否清晰、是否存在重复逻辑，以及边界抽象是否合理。

如果 AI 审查结果不能被开发者复现，它就是一段漂亮废话。

一个合格的审查系统必须给出文件、行号、证据、建议和严重等级。否则 Review 现场只会多一个噪声源。

二、审查链路：从 diff 到结构化风险报告

flowchart TDA[Git Diff] --> B[AST 解析]B --> C[规则扫描]B --> D[上下文裁剪]C --> E[确定性问题]D --> F[LLM 风险分析]E --> G[合并报告]F --> GG --> 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[]): Promise {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。

代码审查要提升交付质量，不应该制造新的流程内耗。