AI 辅助前端代码生成与智能代码审查实践：工具选型别只比较参数
给 AI 代码审查工具做选型时，最容易被模型基准分数带偏。HumanEval 之类的公开基准可以作为参考，却不能代替项目自身的回放测试：它不包含团队的组件封装、浏览器兼容策略和业务约束。
1. 先用项目样本验证，再讨论替换现有门禁
可以从近期 PR 中抽取已知问题、正常改动和兼容性代码，分别计算漏报、误报和人工确认成本。测试要记录模型版本、提示词、输入上下文、评判标准和复跑日期；否则不同工具的分数没有可比性。
通用模型尤其容易把兼容性兜底代码误判为冗余，也可能遗漏跨文件的状态依赖。因此，ESLint、类型检查等确定性规则仍应承担阻断职责；LLM 更适合提供需要人工确认的建议。
2. 核心架构拆解：AST 解析器与 LLM 提示词链的交互流
可落地的审查系统不应把整份大型文件原样交给模型。先用 TypeScript AST 做确定性提取，筛出相关节点和组件上下文，再将必要信息送入 LLM，成本和结果都更可控。
这套架构的重点是分工：AST 用于定位范围和提取结构，LLM 用于补充逻辑意图和上下文层面的检查。模型结论应保留证据片段，方便审查者判断。
3. 生产级审查引擎实现：TypeScript AST 提取与模型响应强校验
下面的 Node.js/TypeScript 示例提取 TS AST 节点，构造包含上下文的提示词，并校验 LLM 返回的 JSON。模型输出无法解析时，脚本返回本地 AST 提示；是否阻断 CI 应由团队按风险等级单独配置。
import ts from 'typescript';
import { z } from 'zod';
// 1. 定义审查结果的强校验 Schema
const ReviewResultSchema = z.object({
hasError: z.boolean(),
issues: z.array(
z.object({
line: z.number(),
severity: z.enum(['error', 'warning', 'info']),
category: z.string(),
message: z.string(),
suggestion: z.string(),
})
),
});
export type ReviewResult = z.infer<typeof ReviewResultSchema>;
// 2. 从源代码中提取 Hook 依赖与潜在隐患的 AST 节点
export function extractReactHookContext(code: string, fileName: string) {
const sourceFile = ts.createSourceFile(
fileName,
code,
ts.ScriptTarget.Latest,
true
);
const hookNodes: Array<{ name: string; line: number; deps: string[] }> = [];
function visit(node: ts.Node) {
if (ts.isCallExpression(node)) {
const expressionText = node.expression.getText(sourceFile);
if (expressionText === 'useEffect' || expressionText === 'useCallback') {
const line = sourceFile.getLineAndCharacterOfPosition(node.getStart()).line + 1;
const args = node.arguments;
let deps: string[] = [];
if (args.length > 1 && ts.isArrayLiteralExpression(args[1])) {
deps = args[1].elements.map((el) => el.getText(sourceFile));
}
hookNodes.push({ name: expressionText, line, deps });
}
}
ts.forEachChild(node, visit);
}
visit(sourceFile);
return hookNodes;
}
// 3. 执行智能审查主函数（失败时降级为提示，不阻塞 CI）
export async function reviewCodeWithGuard(
code: string,
fileName: string,
llmApiCaller: (prompt: string) => Promise<string>
): Promise<ReviewResult> {
const hooksContext = extractReactHookContext(code, fileName);
const prompt = `
你是一位严谨的前端代码审查专家。请对以下 TypeScript 代码进行审查。
已知代码中的 React Hook 节点信息：${JSON.stringify(hooksContext)}
待审查代码：
\\`\\`\\`typescript
${code}
\\`\\`\\`
请返回格式严密的 JSON，禁止包含任何 Markdown 标记。格式如下：
{
"hasError": true/false,
"issues": [
{ "line": 10, "severity": "error", "category": "闭包陷阱", "message": "描述", "suggestion": "建议" }
]
}
`;
try {
const rawResponse = await llmApiCaller(prompt);
// 清理可能存在的 markdown 换行符
const cleanedResponse = rawResponse.replace(/```json|```/g, '').trim();
const parsedData = JSON.parse(cleanedResponse);
// Schema 校验，拒绝不符合约定的模型输出
return ReviewResultSchema.parse(parsedData);
} catch (error) {
console.error('[Review Engine] LLM 响应解析失败，执行降级逻辑:', error);
// 降级返回：不阻塞 CI，但保留本地 AST 提示
return {
hasError: false,
issues: hooksContext.map((h) => ({
line: h.line,
severity: 'warning',
category: 'AST 兜底提示',
message: `请人工确认 ${h.name} 的依赖项列表 [${h.deps.join(', ')}] 是否完整`,
suggestion: '检查是否有漏写的响应式变量',
})),
};
}
}
4. 选型时比较什么：本地模型、云端 API 与静态规则
部署方式取决于数据边界、延迟预算、调用量和运维能力。下表列出评审时应核对的维度；具体延迟和成本应在目标网络、代码规模与模型版本下实测。
| 响应与容量 | 受模型、显卡和并发影响 | 受网络、限流和服务配置影响 | 通常成本较低且稳定 |
| 代码数据边界 | 可在内网处理，但仍需治理日志与权限 | 需确认供应商的数据处理条款与开关 | 不会把代码发往模型服务 |
| 适合解决的问题 | 可针对内部规则微调或检索 | 擅长解释和跨文件线索整理 | 适合明确、可编码的规则 |
| 维护成本 | 高，需显卡节点与量化部署 | 低，按量付费 | 极低，随项目代码打包 |
| 适用场景 | 数据不能出网且有运维资源 | 可接受外部服务并需要较强推理能力 | 所有项目的基础语法与规范门禁 |
如果项目规模较小或规则尚未沉淀，先完善 ESLint 和类型检查通常更划算。引入模型前，应明确它补充的是哪类人工判断，而不是把它当作现有门禁的替代品。
5. 结语：让工具各自处理擅长的问题
模型适合加快审查和信息整理，但不能替代对状态、DOM 和资源生命周期的验证。静态检查负责稳定、可编码的规则，LLM 处理需要上下文的提示，审查流程才便于复盘。
6. 用回放样本评估建议质量
试运行不必覆盖全仓。挑选近期合并的 PR，保留 diff、人工意见和最终修复，遮掉不该外发的内容后再交给工具。每条建议必须能回到具体代码位置，并说明关联的上下文；审查者接受或忽略时记录原因。一两周后再看漏报、误报和确认时间，才能判断它是在节省时间还是增加负担。没有证据片段的结论不应自动阻断合并，模型服务异常时也要回退到既有 lint 和类型检查。
