组件库演示顺畅后，仍要补齐的验证项

分类：[AI/大模型]

导语：把生成结果放回项目上下文

模型能生成组件草稿，但草稿是否适配项目取决于 Token 定义、组件 API、依赖版本和样式边界。比如生成结果可能引用不存在的 Token，或在嵌套弹窗中暴露样式作用域问题。

本文给出一个本地脚手架示例：将输入、依赖和校验步骤固定下来，在合入前检查生成结果。它不是对所有生成代码的质量保证。

1. Demo 效果与生产落地的三大“天然鸿沟”

为什么演示看起来极其丝滑，落地本地环境却频频踩坑？主要原因在于三点上下文缺位：

1. 上下文编排（Context Orchestration）缺失：通用大模型并不清楚你团队内部组件库（如 Element Plus / AntD / 自研 UI 库）的具体版本 API。它生成的代码往往混杂了过时的 Props；
2. Design Tokens 游离于编译链之外：演示阶段通常只展示 HTML/CSS 结构，但工程项目中 Tokens 依赖 Sass/Less/Tailwind 配置与 CSS Variables 构建产物；
3. 缺乏隔离的 Sandbox 验证环境：生成的代码未经 Shadow DOM 或 Storybook 可复现沙箱隔离，直接合入主干引发全局污染。

2. 核心突破：智能上下文编排与本地隔离脚手架

为了打通这一闭环，我们在团队本地开发环境中设计了一个 AI Context Orchestrator（智能上下文编排器）。该模块可以在 AI 生成代码前，自动从当前工程中提取最新的 Design Tokens 字典和组件 API 定义，拼接为严格的 System Prompt，并在 Vite 本地编译时提供安全沙箱。

核心实现代码：TypeScript / Node.js 研发脚手架

import fs from 'fs';
import path from 'path';
import { glob } from 'glob';

export interface ComponentMetadata {
  name: string;
  propsSchema: Record<string, string>;
  tokensUsed: string[];
}

/**
 * 1. 本地 Design Tokens 与组件元数据提取器
 */
export class DesignSystemContextExtractor {
  private tokensPath: string;
  private componentsDir: string;

  constructor(tokensPath: string, componentsDir: string) {
    this.tokensPath = tokensPath;
    this.componentsDir = componentsDir;
  }

  // 读取本地最新的 CSS 变量 / Token 定义
  public extractTokens(): Record<string, string> {
    if (!fs.existsSync(this.tokensPath)) return {};
    const content = fs.readFileSync(this.tokensPath, 'utf-8');
    const tokenMap: Record<string, string> = {};
    const regex = /--([a-zA-Z0-9-]+):\s*([^;]+);/g;
    let match;
    while ((match = regex.exec(content)) !== null) {
      tokenMap[`--${match[1]}`] = match[2].trim();
    }
    return tokenMap;
  }

  // 2. 组装给 LLM 的强化 Context Prompt
  public buildSystemContextPrompt(): string {
    const tokens = this.extractTokens();
    const tokenKeys = Object.keys(tokens).slice(0, 50).join(', '); // 截取核心 Token

    return `
你是一名严格遵守我们自研 Design System 规范的前端架构师。
生成 React 组件代码时，可按项目规范采用以下约束：
1. 只能使用以下定义好的 CSS Variables (Tokens)：[${tokenKeys}]
2. 若项目以 Token 管理颜色，避免内联硬编码 color，改用 `var(--token-name)`；
3. 对外导出的 Component 应提供清晰的 TypeScript 类型；
4. 根据现有样式策略使用 Scoped CSS 或 CSS Modules，并检查全局影响。
`;
  }
}

/**
 * 3. 本地沙箱隔离验证器 (结合 Vite / Esbuild)
 */
export class LocalSandboxValidator {
  public static async validateCode(codeSnippet: string): Promise<{ valid: boolean; errors: string[] }> {
    const errors: string[] = [];

    // 静态 AST 规则检查：检测是否有硬编码样式与非法 eval
    if (codeSnippet.includes('eval(') || codeSnippet.includes('dangerouslySetInnerHTML')) {
      errors.push('安全风险：禁止在智能组件中使用 unsafe 方法');
    }

    if (/#([0-9a-fA-F]{3}){1,2}\b/.test(codeSnippet)) {
      errors.push('规范校验失败：检测到 HEX 颜色硬编码，请更换为 Design Token');
    }

    return {
      valid: errors.length === 0,
      errors,
    };
  }
}

3. 怎样评估本地闭环

没有公开的项目、输入集和脚本时，不能把对比数字当作结论。可以在自己的仓库记录以下指标，并保留生成输入与依赖锁文件：

4. 复盘总结：工程脚手架才是智能化的基石

很多团队在推进智能化转型时，把 90% 的精力花在了选哪个大模型、调哪句 Prompt 上，却忽略了最底层的工程环境建设。

建议把 Token 与类型约束注入生成上下文，在独立环境运行 AST、样式与构建检查，并提交生成配置和锁文件。这样可以减少环境差异，但仍要保留代码评审与回归测试。

演示通过以后再验一次

这篇讨论的是前端组件与微前端里的“组件库演示顺畅后，仍要补齐的验证项”。判断不能只靠某一次顺利的结果，需要把页面、宿主应用、子应用、构建产物和浏览器控制台放回同一段执行过程里看。演示环境通常数据少、权限单一，顺畅不等于能交付。换一组边界输入，断开一个可选依赖，再让不熟悉页面的人照着任务完成一次。这样得到的是具体卡点，不是一句“看起来没问题”。

实际处理时，我会先选一个普通请求和一个边界请求，分别记下开始时间、关键输入与最终结果。若两者差异很大，就继续向下拆分，而不是马上把问题归因给某个工具。这里的目标不是把记录做得漂亮，而是让后来接手的人能够复走当时的路径。

交付前留下什么

对于这次“组件库演示顺畅后，仍要补齐的验证项”，先把可变条件列成两三项即可，例如版本、输入规模或权限状态。每次试验只调整其中一项，并保存前后的差异。这样即使结论是否定的，也能知道否定的是哪一种假设。

如果需要他人复核，不必转发整段日志。截取关联请求、关键状态和复现命令，并说明预期与实际的差别。复核者能在短时间内看懂问题，沟通成本会低很多。