AI 辅助前端代码生成与智能代码审查实践：模型输出异常时的降级边界
大模型调用具有延迟波动、网络失败和输出不符合约定等特征。生成式 UI 接入层应把它视为普通的外部依赖：请求可超时，返回值也必须在进入渲染层前校验。
如果直接把返回文本 JSON.parse 后渲染，截断 JSON、未知组件类型或异常属性都可能把错误扩散到页面。下面用一个 TypeScript 熔断与兜底示例，说明如何把这些失败限制在接入层。
1. 抓包排查：大模型超时与脏输入导致的死锁链路
为了定位之前生产环境的卡死问题，我在 Chrome DevTools 和 Chrome Performance 标签页里抓取了一组典型的异常 Trace。整个崩溃链条其实非常清晰：
问题的症根出在两个地方：第一，前端 Fetch 请求没有挂载基于 AbortController 的硬性超时机制，一直傻等大模型 Token 吐完；第二，拿到 LLM 吐出来的字符串后，直接 JSON.parse 就往 React/Vue 渲染树上挂，一旦遇到截断数据或者非法属性，整个 Virtual DOM 渲染节点瞬间崩塌。
2. 状态机隔离设计：超时、重试与静态兜底的防线
解决这个问题的关键，在于用确定性的软件工程代码，去隔离非确定性的 LLM 行为。我们不能只做简单的 try-catch，而是需要一套包含三种状态（Closed、Open、Half-Open）的降级熔断状态机。
这套隔离机制由三个核心构件组成：
3. 生产级 TypeScript 降级拦截器实现
下面是我们最终上线的代码实现。剔除了所有玩具 demo 里的假数据，完全按照生产级别的异常隔离标准编写。
// types/circuit.ts
export type CircuitState = 'CLOSED' | 'OPEN' | 'HALF_OPEN';
export interface ComponentSchema {
type: string;
props: Record<string, any>;
children?: ComponentSchema[];
}
export interface CircuitBreakerOptions {
failureThreshold: number; // 触发熔断的失败阈值
resetTimeoutMs: number; // 熔断冷却时间(ms)
requestTimeoutMs: number;// 单次请求超时时间(ms)
}
// errors/circuit-error.ts
export class CircuitBreakerError extends Error {
constructor(message: string) {
super(message);
this.name = 'CircuitBreakerError';
}
}
export class SchemaValidationError extends Error {
constructor(message: string, public rawInput: string) {
super(message);
this.name = 'SchemaValidationError';
}
}
// utils/ai-circuit-breaker.ts
export class AICodeGenerationCircuitBreaker {
private state: CircuitState = 'CLOSED';
private failureCount = 0;
private nextAttemptTime = 0;
constructor(
private options: CircuitBreakerOptions,
private fallbackSchemaProvider: () => ComponentSchema
) {}
public async executeGeneration(
llmFetcher: (signal: AbortSignal) => Promise<string>
): Promise<ComponentSchema> {
const now = Date.now();
// 1. 判断熔断器状态
if (this.state === 'OPEN') {
if (now < this.nextAttemptTime) {
console.warn('[AI-CircuitBreaker] 熔断器处于 OPEN 状态，直接触发降级兜底渲染');
return this.fallbackSchemaProvider();
}
this.state = 'HALF_OPEN';
}
// 2. 构造超时中断控制器
const controller = new AbortController();
const timeoutId = setTimeout(() => {
controller.abort();
}, this.options.requestTimeoutMs);
try {
// 3. 执行 LLM 请求
const rawResponse = await llmFetcher(controller.signal);
clearTimeout(timeoutId);
// 4. 运行时 Schema 强校验
const parsedSchema = this.validateAndSanitize(rawResponse);
// 请求成功，恢复熔断状态
this.onSuccess();
return parsedSchema;
} catch (err: any) {
clearTimeout(timeoutId);
this.onFailure(err);
console.error(`[AI-CircuitBreaker] LLM 执行异常: ${err.message}，降级到本地默认 Schema`);
return this.fallbackSchemaProvider();
}
}
private validateAndSanitize(rawJson: string): ComponentSchema {
if (!rawJson || typeof rawJson !== 'string') {
throw new SchemaValidationError('返回内容非有效文本格式', rawJson);
}
let parsed: any;
try {
parsed = JSON.parse(rawJson);
} catch (e) {
throw new SchemaValidationError('JSON.parse 语法解析失败，存在截断或非法字符', rawJson);
}
// 校验节点结构
if (!parsed || typeof parsed !== 'object' || !parsed.type) {
throw new SchemaValidationError('Schema 缺少必填根属性 "type"', rawJson);
}
return {
type: String(parsed.type),
props: typeof parsed.props === 'object' && parsed.props !== null ? parsed.props : {},
children: Array.isArray(parsed.children) ? parsed.children : []
};
}
private onSuccess(): void {
this.failureCount = 0;
this.state = 'CLOSED';
}
private onFailure(err: Error): void {
this.failureCount++;
if (this.failureCount >= this.options.failureThreshold || this.state === 'HALF_OPEN') {
this.state = 'OPEN';
this.nextAttemptTime = Date.now() + this.options.resetTimeoutMs;
console.error(
`[AI-CircuitBreaker] 触发熔断保护，状态转为 OPEN。下一次恢复重试时间: ${new Date(
this.nextAttemptTime
).toISOString()}`
);
}
}
public getState(): CircuitState {
return this.state;
}
}
4. 验证与降级兜底
上线前我在本地搭建了一套可复现的 Mock 实验脚手架，专门模拟 LLM 的各种极端坑爹场景：
验证时至少覆盖以下断言：超时后请求信号已中止且 Loading 状态退出；截断 JSON 不会进入渲染器；连续失败后不再发起远端调用；冷却期后的探针成功才能恢复服务。阈值、超时时间和并发数应按业务与服务端容量确定。
# 自动化测试脚本命令
npx tsx scripts/test-llm-circuit.ts –concurrency=20 –fault-rate=0.4
在 CI 中可把以上故障注入场景做成自动化测试，并记录触发熔断的次数、兜底命中率和恢复结果。不要把一次本地运行的耗时当作通用性能结论。
5. 前端 AI 落地避坑警示
生成式 UI 的可靠性来自可控边界：超时、运行时校验、可用的本地兜底，以及有条件的恢复探针。把这些行为写成测试，才能在服务波动时保持页面可用。
