汇川技术｜DemoKit培训交流

Demokit介绍

完整介绍视频：http://xhslink.com/o/3feeXfAHzgH

👋嗨，我是范米花儿。

最近，我受邀给一家国内工业自动化领域的头部企业做了一场内部培训与交流。

沟通PPT：

沟通交流PPT.html

现场大概 90 人左右参与，既有设计同学，也有技术同学，甚至其他岗位。

这次邀请的起因，是他们看到了我在小红书上关于 Vibe Coding 以及 DemoKit 的一些分享，觉得和他们现在正在推进的事情比较接近。

他们的诉求很明确：

一是希望我做一场技能培训。

二是他们公司已经有自己的 Web 组件库和设计规范，希望进一步探索。

这次交流下来，我最大的感受是：很多企业已经开始进入 AI UI 的下一阶段。 大家关心的问题，已经从“AI 能不能生成 UI”，继续往下走到了：

• 已有组件库怎么接入 AI？
• 设计规范怎么变成 AI 能理解的规则？
• Figma 里的设计资产怎么和工程组件对齐？
• 多个设计师一起用 AI 时，怎么保证输出风格一致？
• AI 生成的页面，怎么进入真实项目？
• 已有的企业设计系统，怎么迁移到新的 AI 工作流里？ 这些问题都很具体，也很真实。

对方团队现在的探索方向

这家企业已经有自己的 Web 组件库，也有内部设计规范和技术团队。 他们当前的探索方向，比较偏 Markdown化的组件封装。 简单说，就是把原子组件、使用说明、代码片段、设计规则写进 MD 文件里。AI 接到页面需求后，先读取这些文档，再根据文档里的描述生成组件代码，然后拼接页面。

很多企业原本就有组件库、设计规范、代码片段和设计文档。AI 出现之后，第一步通常就是把这些内容整理成 AI 能读取的材料。 这条路径的优势很明显：

• 启动成本相对低。
• 适合沉淀规则和经验。
• 方便设计师理解和参与。
• 也能把团队里分散的页面经验重新整理出来。

同时，大家在实践里也遇到一个核心问题： AI 读懂规则之后，怎么稳定调用真实组件？

如果组件主要存在于文档描述里，AI 最后通常还要重新生成代码。只要重新生成，就可能出现尺寸、间距、圆角、状态、样式、交互细节上的偏差。

所以这次会议里，大家一直在围绕“稳定性”和“还原度”继续追问。

两条路径，侧重点不同

这次我也重点分享了 DemoKit的核心原理。

对方正在探索的路径，更适合沉淀规则、说明、边界和页面经验。

我在 DemoKit 里尝试的工程化 Kit 路径，更偏向把组件、规则文档、示例、Token、注册表、Showcase、Starter 放进一个可运行的工程环境里，让 AI 基于已有结构去选择和组合。

会议里大家最关心的几个问题

这场交流后半段，大家问得都很具体，也很接近企业真实落地时会遇到的问题。

第一个问题：企业已有组件库，能不能作为底层接进来？

可以。

前提是这套组件库本身已经代码化、可调用，并且有相对完整的组件覆盖。后续要做的是在它上面补充组件说明、Token 映射、使用规则、复合组件、页面模板和展示校验方式。

关键是让 AI 知道：有哪些组件可以用、适合什么场景、从哪里引入、哪些样式要遵循企业规范。

第二个问题：组件应该写在 Markdown 里，还是做成工程组件？

Markdown 更适合写规则，比如使用场景、组件边界、页面结构和注意事项。

工程组件更适合承载真实样式和行为，比如按钮高度、输入框间距、表格结构、弹窗阴影和交互状态。

文档讲清楚规则，工程组件提供真实实现，两部分配合起来会更稳定。

第三个问题：为什么复合组件重要？

真实后台页面很少只靠 Button、Input、Table 这些原子组件自然拼出来。

页面里更常见的是页头、筛选区、指标卡、数据表格、组织树、审批流、复杂表单、详情信息区等结构。

这些高频结构提前沉淀成复合组件后，AI 生成页面时就可以先调用稳定区块，再根据业务做局部调整，结果会更可控。

第四个问题：Token 和企业规范怎么对应？

企业已有的颜色、字号、间距、圆角、密度、阴影等规范，需要映射到工程变量里。

只改颜色比较简单。真正要长期使用，就要把 Token 和组件绑定起来，让 AI 知道按钮高度、表格行高、卡片间距、页面留白这些规则从哪里继承。

这样生成结果才更容易保持企业自己的设计风格。

第五个问题：多个设计师一起用 AI，怎么保证结果一致？

是建立一套共同底座：统一组件库、统一 Token、统一页面模板、统一规则文档、统一组件注册表、统一展示校验和输出标准。

这样不同设计师使用 AI 时，起点是一致的，AI 能调用的组件和规则也是一致的，最终结果就更容易落在同一个系统范围内。