前端 UI 生成的普遍问题
让通用大模型写 React 组件时，往往会产生许多违背团队设计系统的“野生样式”：比如自定义颜色值、未复用已有的 Button 或 Modal 基础组件。
建立设计系统上下文闭环
- Design Tokens 资源化：将团队的颜色、字阶、圆角变量封装为 MCP Resource (
design://tokens)； - Story 自动化生成：让 Agent 为每个新生成的组件同步编写
.stories.tsx，覆盖 Primary、Disabled、Loading 等多状态变体； - 视觉无头渲染核验：通过 Playwright MCP 在本地启动 Storybook 预览，截取组件渲染截图，利用多模态能力核验是否与 Figma 设计稿视觉一致。
五步落地流程
第一步盘点资产：整理组件清单与 tokens 变量表，明确"允许使用什么"。第二步接入上下文：把清单与 tokens 以 MCP Resource 暴露给 Agent，工具与资源的职责划分见MCP 核心抽象剖析：Tools、Resources 与 Prompts 的设计哲学与协同。第三步生成：给 Agent 的提示中强制"只准组合现有组件与 token，新增原始样式值须说明理由"。第四步验证：本地 storybook dev 起预览，Playwright MCP 截图比对。第五步入 CI：新增组件未附 stories 文件或 lint 检出硬编码色值，即判定构建失败。
野生样式压制手段对比
| 手段 | 机制 | 覆盖面 | 局限 |
|---|---|---|---|
| 提示词约束 | 声明禁用规则 | 依赖模型遵循度 | 长会话中会漂移 |
| Tokens 资源化 | 提供唯一取值来源 | 颜色/间距/字阶 | 不覆盖布局层错误 |
| ESLint 规则 | 检出硬编码色值与内联样式 | 机械可判定的违规 | 判不了视觉违和 |
| 截图视觉比对 | 基线快照加差异阈值 | 最终呈现效果 | 需维护快照基线 |
四层叠加使用，其中 lint 与截图比对是机器可判定的硬门禁，前两层只是降低犯错的概率。
验证方法：视觉回归的基线管理
截图核验的可操作做法是：每个 Story 首次人工确认通过后固化为基线快照，此后每次改动做像素级 diff，超阈值即挂起人工裁决，避免 Agent 的"善意微调"悄悄改变视觉。快照对渲染环境敏感，容器内字体与本机不同会产生系统性偏差，因此基线必须由 CI 容器生成，而不是开发者本地。性能层面的后续核验可以再接入利用 MCP 优化前端性能：Lighthouse 报告自动诊断与优化代码一键采纳的流程，浏览器自动化脚本的写法参考基于 Playwright 与 Browser-Use MCP 实现智能网页自动化与动态数据抓取。
常见故障速查
| 现象 | 原因 | 处理 |
|---|---|---|
| Agent 仍输出十六进制色值 | tokens 资源未被注入到实际上下文 | 检查 Resource 订阅配置而非加提示 |
| 截图比对全部失败 | 基线在本机生成、CI 在容器渲染 | 统一用 CI 容器重建基线 |
| stories 文件状态变体缺失 | 提示未列举必需状态 | 用清单模板强制 Primary/Disabled/Loading 全覆盖 |
| 动态内容导致 diff 抖动 | 快照含时间戳等不稳定文本 | 打桩固定随机与时间源 |
小结
这套体系是否成型，看一条可量化标准：连续一个月内的 AI 生成组件 PR 中，硬编码样式值与缺 stories 文件两项的检出数应趋近于零，且视觉 diff 的人工裁决率明显低于初期。若模型产出仍频繁越界，优先检查 tokens 是否真的到达了上下文，再考虑收紧 lint，而不是一味加长提示词。