AI 原生组件脚手架：基于 AST 注入实现大模型生成代码的自愈格式化

在推进前端团队全流程拥抱“AI 研发流（AI-First Development）”的过程中，许多工程负责人都有过类似的心累时刻：我们投入大量资源打通了“设计稿自动转代码”或“自然语言生成业务组件”的自动化流水线，大模型在 3 秒钟内交出了一段 200 行的 Vue 3 单文件组件代码。业务逻辑看起来八九不离十，但只要把这段代码丢进项目仓库，终端里就会瞬间爆出一连串刺眼的红色构建报错：

• TS6133: 'computed' is declared but its value is never read.（大模型习惯性地在文件顶层引入了一堆未使用的工具函数）；
• ESLint: Component name "Card" should always be multi-word.（组件命名不合规）；
• 缺少团队私有组件库的基础导入声明，或者属性排序完全杂乱无章，直接在 Git Pre-commit 阶段被 Husky 强行卡死。

面对这种代码，初级做法是把终端报错贴回给大模型：“你报了 TS6133，帮我修一下”。大模型道歉后重新跑了一遍生成，不仅白白浪费了几千个 Token 账单和十几秒等待时间，还常常在“修复格式”的过程中顺带破坏了上一版已经调通的核心业务逻辑。

治愈这种“细小格式神经质”的终极打法，绝不是继续指望概率生成的大模型，而是在大模型与本地文件系统之间，架设一道基于 AST 注入与规则修复的“自愈格式化脚手架（Self-healing Formatter Scaffold）”。

架构哲学：概率归概率，确定性归确定性

在 AI 原生前端工作流中，必须划分极其清晰的职责边界：

• 大模型（LLM）的职责：只负责攻坚最具不确定性、最具创造力的部分——业务状态机推导、DOM 骨架组装、样式令牌匹配；
• AST 编译器管线的职责：接管所有确定性的规则约束——死代码清洗、模块依赖补齐、代码树形格式化。

[大模型输出原始代码] ──> (可能夹杂无用 import、属性未对齐、格式轻度混乱)
│
▼
[AST 自愈管道 (TypeScript / Babel AST)]
1. 自动 Tree-shaking: 剔除一切声明但未使用的引用 (Pruning)
2. 依赖自动补齐: 扫描 template 标签，自动按白名单补齐组件导入 (Auto-injection)
3. 接口规范重排: 强制将 Props/Emits 规范对齐大厂契约 (Normalization)
│
▼
[Prettier 终态代码美化] ──> 零警告、零报错，直接合入仓库并一次性通过 CI

工业级自愈处理器实现：AstHealingPipeline

我们使用 TypeScript Compiler API 与 Babel 语法转换器，构建一个完全无感、可在 Node CLI 中即插即用的自愈净化器：

import ts from 'typescript';
import * as prettier from 'prettier';

export class ComponentCodeHealer {
// 核心入口：接收大模型吐出的原始代码字符串，返回工业级纯净代码
static async healAndFormat(rawTsCode: string): Promise<string> {
// 步骤 1: AST 语法树解析与死引用自动剔除
const prunedCode = this.removeUnusedImports(rawTsCode);

// 步骤 2: AST 依赖自动探测与补齐
const injectedCode = this.injectMissingCoreImports(prunedCode);

// 步骤 3: 终态 Prettier 严格格式化
const finalFormatted = await prettier.format(injectedCode, {
parser: 'typescript',
singleQuote: true,
semi: true,
trailingComma: 'all',
printWidth: 100,
});

return finalFormatted;
}

// 1. 借助 AST 自动剥离无用 Import 节点
private static removeUnusedImports(code: string): string {
const sourceFile = ts.createSourceFile('temp.ts', code, ts.ScriptTarget.Latest, true);

// 提取全局所有使用的标识符集合
const usedIdentifiers = new Set<string>();
function collectIdentifiers(node: ts.Node) {
if (ts.isIdentifier(node)) {
// 排除掉 import 声明自身的标识符，只收集被消费的标识符
if (!ts.isImportSpecifier(node) && !ts.isImportClause(node)) {
usedIdentifiers.add(node.text);
}
}
ts.forEachChild(node, collectIdentifiers);
}
collectIdentifiers(sourceFile);

// 转换器：对未使用的 import specifier 进行精准剪枝
const transformer: ts.TransformerFactory<ts.SourceFile> = (context) => {
return (rootNode) => {
function visit(node: ts.Node): ts.Node | undefined {
if (ts.isImportDeclaration(node)) {
const namedBindings = node.importClause?.namedBindings;
if (namedBindings && ts.isNamedImports(namedBindings)) {
// 过滤出真正被代码消费的元素
const validElements = namedBindings.elements.filter((el) => {
return usedIdentifiers.has(el.name.text);
});

// 如果所有引入项都没被使用，彻底删除整个 import 语句！
if (validElements.length === 0) {
return undefined;
}

// 若部分使用，生成精简后的 import 节点
const newNamedImports = context.factory.updateNamedImports(namedBindings, validElements);
const newImportClause = context.factory.updateImportClause(
node.importClause!,
node.importClause!.isTypeOnly,
node.importClause!.name,
newNamedImports
);
return context.factory.updateImportDeclaration(
node,
node.modifiers,
newImportClause,
node.moduleSpecifier,
node.assertClause
);
}
}
return ts.visitEachChild(node, visit, context);
}
return ts.visitNode(rootNode, visit) as ts.SourceFile;
};
};

const result = ts.transform(sourceFile, [transformer]);
const printer = ts.createPrinter();
return printer.printFile(result.transformed[0]);
}

// 2. 自动补齐基础依赖白名单
private static injectMissingCoreImports(code: string): string {
let output = code;

// 检查是否使用了 ref/computed 但忘记从 vue 导入
const needsRef = /\\bref\\s*\\(/.test(output) && !output.includes("from 'vue'");
if (needsRef) {
output = `import { ref, computed } from 'vue';\\n` + output;
}

// 检查是否使用了基础 UI 标签但忘记引入
if (output.includes('<CustomButton') && !output.includes("import CustomButton")) {
output = `import CustomButton from '@/components/CustomButton.vue';\\n` + output;
}

return output;
}
}

在终端研发脚手架中的无感集成

我们将这个自愈处理器封装进前端工程的 CLI 生成命令中：

# 开发者在终端直接驱动脚手架让 AI 生成组件
$ pnpm generate:ai-component –prompt "生成一个带倒计时的双11秒杀卡片"

整个流水线的幕后执行细节：

开发者从终端切回 VSCode 时，看到的直接就是一份格式完全对齐团队代码规范、没有任何无病呻吟的语法警告、可以直接通过 CI 构建的干净代码！

生产运用的两项避坑原则

让大模型负责宏观的才华，让静态编译器守护微观的秩序。把不确定性约束在确定性的工程流水线里，这就是 AI 原生前端开发流最迷人的魅力。