AI 辅助前端代码生成与智能代码审查实践：先收紧输入、状态与退出边界
1. 先收紧边界：LLM 接入 CI 的第一版目标
把 LLM 放进 CI 时，先不要把它当作能替代静态检查或人工复核的工具。模型输出会受上下文、提示词和服务状态影响；若直接让它修改代码或作为合并门禁，误报和不可预期的改动都会扩大风险。
第一版更适合做“风险提示器”：静态检查负责确定性问题，LLM 只对有限规则给出可追溯的建议。请求还应有输入大小、超时和失败降级策略，避免审查服务拖慢整条流水线。
2. 确定性架构设计：只让 AI 干它擅长的结构化提取
在设计第一版审查工具时，我们必须明确职责划分：
- 静态语法检查（ESLint/TSC）：负责确定性高的语法、类型与常规风格规范。
- AI 智能审查器：只负责深层的语义风险，比如 Vue3 响应式解构丢失、React 依赖项隐藏闭包陷阱、无限循环风险以及未处理的异步异常。
为了让输出可处理，流水线可以加三层边界：
整个审查流程的交互状态如下所示：
flowchart TD
A[Git Push 触发 CI 脚本] –> B[git diff 提取变更块]
B –> C[AST 分析器过滤无效修改]
C –> D{变更节点超过阈值?}
D — 是 –> E[按函数分片并发请求 LLM]
D — 否 –> F[单次打包请求 LLM]
E –> G[Zod Schema 校验返回格式]
F –> G
G –> H{校验是否通过?}
H — 否 –> I[自动修补 Prompt 重试 1 次]
H — 是 –> J[过滤低置信度 Warning]
I –> J
J –> K[输出 Markdown 审查报告到 MR 评论]
3. 核心审查流水线实现：基于 TypeScript 与 Schema 的防线
下面是我们落地并运行在 Node.js 环境下的第一版智能代码审查引擎的核心 TypeScript 代码。它展示了如何使用 Zod 结构化约束大模型输出，并包含超时熔断与重试逻辑。
import { z } from 'zod';
import { OpenAI } from 'openai';
// 1. 严格定义大模型必须返回的 JSON 架构
const ReviewIssueSchema = z.object({
filePath: z.string(),
lineNumber: z.number(),
ruleId: z.enum(['REACT_CLOSURE_TRAP', 'VUE_REACTIVITY_LOSS', 'UNHANDLED_PROMISE', 'PERF_PROP_DRILLING']),
severity: z.enum(['error', 'warning', 'info']),
confidence: z.number().min(0).max(1),
reasoning: z.string().max(200),
suggestedAction: z.string().max(300),
});
const ReviewResultSchema = z.object({
issues: z.array(ReviewIssueSchema),
overallScore: z.number().min(0).max(100),
});
export type ReviewResult = z.infer<typeof ReviewResultSchema>;
export class CodeReviewEngine {
private client: OpenAI;
private readonly timeoutMs: number = 8000;
constructor(apiKey: string, baseURL?: string) {
this.client = new OpenAI({ apiKey, baseURL });
}
/**
* 审查指定代码片段的分片
*/
async reviewSnippet(filePath: string, codeDiff: string): Promise<ReviewResult> {
const systemPrompt = `你是一位严苛的 TypeScript/React/Vue3 代码审查专家。
必须严格检查以下问题：
1. React useEffect 内的闭包陷阱与遗漏依赖
2. Vue3 setup 中解构 props 导致的响应式丢失
3. 未捕获的 Async/Await 异常与内存泄露风险
输出格式必须是合法的 JSON，不要添加任何 Markdown 格式包裹（如 \\`\\`\\`json ）。`;
const userPrompt = `文件路径: ${filePath}\\n代码变更 Diff:\\n${codeDiff}`;
try {
const responseText = await this.callLlmWithTimeout(systemPrompt, userPrompt);
const cleanedText = this.cleanJsonResponse(responseText);
const parsedData = JSON.parse(cleanedText);
// 使用 Zod 进行确定性数据校验
return ReviewResultSchema.parse(parsedData);
} catch (error) {
console.error(`[Review Engine] 文件 ${filePath} 审查失败或超时:`, error);
// 审查不可用不等于代码满分；交由确定性检查与人工 Review 继续处理
return { issues: [], overallScore: 0 };
}
}
/**
* 带超时控制的 LLM 调用
*/
private async callLlmWithTimeout(system: string, user: string): Promise<string> {
const controller = new AbortController();
const timer = setTimeout(() => controller.abort(), this.timeoutMs);
try {
const res = await this.client.chat.completions.create(
{
model: 'gpt-4o-mini',
messages: [
{ role: 'system', content: system },
{ role: 'user', content: user }
],
temperature: 0.1,
response_format: { type: 'json_object' }
},
{ signal: controller.signal }
);
return res.choices[0]?.message?.content || '{}';
} finally {
clearTimeout(timer);
}
}
/**
* 清理可能的特殊字符与标记
*/
private cleanJsonResponse(input: string): string {
return input.replace(/^```json\\s*/i, '').replace(/\\s*```$/, '').trim();
}
}
4. 关键代码取舍：为何放弃自动 Fix 而保留风险标记
在第一版开发中，我们团队内部针对“要不要让 AI 自动写修复代码”争论了整整两天。最后我拍板把 Auto-Fix 全删了。
原因很简单：在复杂的业务逻辑面前，AI 生成的“修复代码”往往比问题本身更有破坏力。
看一个具体的例子：
// 开发者原代码：
const handleUserSearch = (query: string) => {
setSearchText(query);
fetchData(query); // 缺乏防抖
};
AI 经常会自作聪明地改成：
// AI 建议自动替换的代码：
import { debounce } from 'lodash-es';
const handleUserSearch = debounce((query: string) => {
setSearchText(query);
fetchData(query);
}, 300); // 错误地在函数体内创建 debounce，导致每次渲染重置防抖！
这段示例本身并不会“在函数体内创建 debounce”，但若它定义在组件函数体内且没有稳定引用，确实会在每次渲染时重建。是否需要防抖、怎样取消在途请求，都依赖具体交互和数据源，适合由开发者确认后实现。
第一版的取舍策略总结如下：
- 舍弃：自动生成 Commit 提交、自动合并代码、全局泛泛总结。
- 保留：精准定位到行号的 Warning 警示、原因剖析（Reasoning）以及明确提示开发者“需手动检查闭包或响应式链条”。
5. 落地成果与第一版的合理边界
上线后，应以真实的 MR 样本复核效果，并记录误报、漏报、超时和开发者处理结果。统计脚本可以先输出原始计数：
node ./scripts/review-stats.js –period=14d
# 输出日志：
# [Stats] 审查请求数、超时数与 Schema 校验失败数
# [Stats] 按规则统计的提示数与人工确认结果
# [Stats] 单次耗时的 p50 / p95
第一版的重点是边界清楚：先把 AST 过滤、结构化输出、超时与审计日志做好，再根据人工复核结果逐步扩展规则。
