告别手动创建设计系统，利用Cursor高效开发风格统一的高品质UI | 源码已开源

告别手动创建设计系统，利用Cursor高效开发风格统一的高品质UI | 源码已开源 告别手动创建设计系统，利用Cursor高效开发风格统一的高品质UI | 源码已开源 Modified August 19, 2025 AI生成UI太粗糙？代码化设计系统提升人机协同美学 Unable to preview. Please download the file. 使用 stagewise 插件锚定目标元素 开发流程完整录屏回放： 以开发某个“我的简历”页面为例，可以看看完整的流程包括哪些环节，每个环节以什么样的方式，提供了什么样的上下文给到 cursor。类似复杂度的页面的样式开发时间在半小时左右，如果模型回复速度越快，效率越高。 No access myresume 00:00 效果示意 以下是基于作者预设的主题包，按照上述的工作流开发的几个产品页面，有些甚至只给了参考图，都没有给 PRD。经测试产出效果较为稳定，视觉风格统一，但肯定也不是一稿过，需要人工微调修改。 1️⃣ “我的简历”页面 提供了 PRD（含 数据结构）、竞品参考图（如下图） 最终页面： 2️⃣ “StubHub”的订票页面（redesign） 仅提供参考图（如下）。 最终页面： 3️⃣ “豆瓣”的电影排行榜页面（redesign） 仅提供参考图（如下）。 最终页面： 写在最后 AI 并不会取代设计师，但可以彻底重构我们构建设计系统和 UI 的方式。传统「设计 还原」流程里那种反复拉锯的低效协作，正在被一种更直接、更清晰的范式取代：先把美学标准代码化，再让 AI 按标准办事。 重要的是，这并不是一个梦想中的“全自动生成精致 UI”的神话，而是一套已经在实战中落地的工程实践。比起幻觉式的 AI 页面生成，作者选择了一个更务实的目标：用 AI 来解放重复性劳动、缩小 UI 实现成本、提升一致性和演进能力。 AI 是执行者，设计系统是约束条件，而人是规则的制定者和质量把控者。 AI生成UI太粗糙？代码化设计系统提升人机协同美学 Unable to preview. Please download the file. AI生成UI太粗糙？代码化设计系统提升人机协同美学 Unable to preview. Please download the file. 开发流程完整录屏回放： 以开发某个“我的简历”页面为例，可以看看完整的流程包括哪些环节，每个环节以什么样的方式，提供了什么样的上下文给到 cursor。类似复杂度的页面的样式开发时间在半小时左右，如果模型回复速度越快，效率越高。 No access myresume 00:00 No access myresume 00:00 效果示意 以下是基于作者预设的主题包，按照上述的工作流开发的几个产品页面，有些甚至只给了参考图，都没有给 PRD。经测试产出效果较为稳定，视觉风格统一，但肯定也不是一稿过，需要人工微调修改。 1️⃣ “我的简历”页面 提供了 PRD（含 数据结构）、竞品参考图（如下图） 最终页面： 2️⃣ “StubHub”的订票页面（redesign） 仅提供参考图（如下）。 最终页面： 3️⃣ “豆瓣”的电影排行榜页面（redesign） 仅提供参考图（如下）。 最终页面： 写在最后 AI 并不会取代设计师，但可以彻底重构我们构建设计系统和 UI 的方式。传统「设计 还原」流程里那种反复拉锯的低效协作，正在被一种更直接、更清晰的范式取代：先把美学标准代码化，再让 AI 按标准办事。 重要的是，这并不是一个梦想中的“全自动生成精致 UI”的神话，而是一套已经在实战中落地的工程实践。比起幻觉式的 AI 页面生成，作者选择了一个更务实的目标：用 AI 来解放重复性劳动、缩小 UI 实现成本、提升一致性和演进能力。 AI 是执行者，设计系统是约束条件，而人是规则的制定者和质量把控者。 🔗 mp.weixin.qq.com 点赞 110 分享 903 推荐 70 mp.weixin.qq.com mp.weixin.qq.com 点赞 110 分享 903 推荐 70 mp.weixin.qq.com 开篇 AI 生成页面能力乏善可陈 AI编程工具（如 cursor）直接生成页面能力很强，即便要求 AI 生成页面要美观，但也只是勉强可用级别（60 分水平），但不够精致。 因为现在的 AI 理解 UI 是类比式的，比较“守旧”，它见过很多例子，会模仿、套模板，比如：“大多数登录页是蓝色的+按钮在右边，那我也这么做。”但它并不真的懂「视觉均衡」「信息层级」「配色和谐」。 但是我们知道，好看的皮囊能创造溢价，为产品带来品质感和信任感。如果 AI 直出不能行，那难道非得让设计师来画图吗？你或许尝试过： • 要求 cursor 模仿某个成熟产品的风格（如 Airbnb）开发？容易出现风格跑偏的情况，虽然乍一看好像都是统一的，但细看可能相同的元素，一会儿圆角是4，一会儿圆角是6。 • 截图（或 抓取现成的前端样式代码）让 cursor 抄作业？容易出现“想抄没得抄”的尴尬情况，要自己扩展就比较吃力了。 虽然两种方法效果都比起之前有所提升，但随着产品复杂度的提高，页面越来越多， 就会不够用了。 还有什么办法？可以让AI做出既漂亮、又风格统一的 UI 呢？ 引入设计系统。设计系统就是一系列视觉变量，包含颜色、间距、圆角、阴影、文字、边框等等，若页面上所有的元素都是套用同一套漂亮的视觉变量衍生出来的，那自然效果不会差。 作者在不使用任何专业设计工具的前提下，只用传统模式10%不到的投入，定义了一套50+组件的web端的设计系统，特点： • 完全代码化的，AI 可读的 • 样式属性、组件可在线预览 • 主题还可灵活修改 同时，这并不是玩具，作者用它编排了一个人机协同的 UI 构建流程，能够让 cursor 基于草图生成符合规范的可运行的 React 页面，实测效果稳定，且已在真实项目中投入使用。 目前市面上也有诸多AI 辅助生成 UI 的产品（如 Galileo AI、Figma AI、Readdy.ai 等等），但当前阶段要么可控性很差、要么无法修改主题样式、要么无法联通代码化的设计系统、要么需要收费。 这套解决方案的最大的优势在于它是完全代码化的，和你的业务代码一起构成了完整的上下文，很有利于 cursor 一站式高效完成组件开发与维护、组件选取、一致性审查 等工作。 只要会用 cursor ，即便不懂设计，不使用设计工具，也能做出风格统一、细节克制、具备品质感的 UI；如果你本身有审美、有经验，那这套方式则是为你量身打造的放大器！尤其适合从 0 到 1 阶段开发相对复杂应用、追求敏捷性和可控性的个人或团队。 通过这篇文章，你将了解到： • 如何利用现成的工具快速定制一套专属自己的界面风格主题（web端产品） • 一套规整的设计系统应该具备什么样标准，包含哪些要素，有什么好处？ • 如何让 cursor 遵循规范开发页面样式？哪些工作 AI 能包揽？哪些还需要人？ 技术选型： • 核心框架：React + TypeScript • UI 解决方案：Tailwind CSS + shadcn/ui (底层:Radix UI) • 辅助开发工具：Vite + Storybook + stagewise 技术选型： • 核心框架：React + TypeScript • UI 解决方案：Tailwind CSS + shadcn/ui (底层:Radix UI) • 辅助开发工具：Vite + Storybook + stagewise 设计系统搭建 既然要遵循规范，自然要先定义规范。 基础变量 理想化的设计系统，是一套完全层级化的的界面语言。通过层层嵌套，实现所有组件共享同一套样式逻辑。 首先需要定义的是全局的基础变量（design tokens）： • 颜色：包括品牌色、功能色（如成功、错误、警告、信息）、中性色、背景色、边框色、阴影色等 • 间距：间距的梯度，用于控制内外边距、元素间的间隔 • 圆角：圆角大小梯度 • 阴影：投影类型（常规阴影、内投影、投影）、投影大小 • 边框：粗细、样式 • 文字：字距、行距、粗细、字体族、字号、行高 它们决定了产品气质和调性。 每个变量都需要提供若干种符合一定规律的梯度变化的样式选项，后续所有的UI组件会基于这些基础的视觉变量来设计和开发，不允许硬编码。 样式逻辑统一的好处是： • 把控性更强：所有的页面元素都是由你定义的有限的集合衍生而来。 • 方便扩展：要扩大可选范围，只需要基于一定的规律即可。 • 便于全局调整：比如调整布局的宽松/紧凑程度，只需要调整间距的梯度，整体就一起变化了。 不过，虽然很有工程美感，但这样搞下来岂不是工作量很大？好消息是已经 2025 年了，网络上已经有非常多现成的工具/解决方案可以帮我们快速搭建了。 作者没有采用传统的黑盒式的UI框架（如流行的 Chakra UI、Ant D），而是采用了 shadcn/ui + tailwind 这样源码开放、结构清晰、风格可编程的设计系统解决方案，因为对于利用了大量 github 项目训练的 LLM 来说也更熟悉，源码更透明便于灵活定制。 对比项 传统UI 框架(如Chakra UI / Ant Design） shadcn/ui（基于 Tailwind 的现代 UI 组件组合方式） 控制力 / 可塑性 中等偏低（组件封装度高） 高（原子类+组件可拆可重构） 组件功能丰富度 高（表单、表格、Modal 等齐全） 中（基础组件为主，需要手动组合进阶功能） 性能（体积、渲染） 一般（AntD 尤其偏重） 优（按需加载 + 原子 CSS，无冗余） 适合场景 通用后台、表单驱动型 B 端项目 高定制要求、设计统一性强的现代 Web 项目 对比项 对比项 传统UI 框架(如Chakra UI / Ant Design） 传统UI 框架(如Chakra UI / Ant Design） shadcn/ui（基于 Tailwind 的现代 UI 组件组合方式） shadcn/ui（基于 Tailwind 的现代 UI 组件组合方式） 控制力 / 可塑性 控制力 / 可塑性 中等偏低（组件封装度高） 中等偏低（组件封装度高） 高（原子类+组件可拆可重构） 高（原子类+组件可拆可重构） 组件功能丰富度 组件功能丰富度 高（表单、表格、Modal 等齐全） 高（表单、表格、Modal 等齐全） 中（基础组件为主，需要手动组合进阶功能） 中（基础组件为主，需要手动组合进阶功能） 性能（体积、渲染） 性能（体积、渲染） 一般（AntD 尤其偏重） 一般（AntD 尤其偏重） 优（按需加载 + 原子 CSS，无冗余） 优（按需加载 + 原子 CSS，无冗余） 适合场景 适合场景 通用后台、表单驱动型 B 端项目 通用后台、表单驱动型 B 端项目 高定制要求、设计统一性强的现代 Web 项目 高定制要求、设计统一性强的现代 Web 项目 Tailwind 的好处是，已经帮开发者预定义了一套主题，若我们不自定义，也会有默认值可以用。 Tailwind 默认主题视觉变量：除了前文提到的 颜色、间距、圆角、阴影、文字、边框，还有 断点（用于响应式设计）、容器宽度、模糊、透视、宽高比、动画类型、过渡曲线，可以提供更丰富、更动态的样式选择。 Tailwind 默认主题视觉变量：除了前文提到的 颜色、间距、圆角、阴影、文字、边框，还有 断点（用于响应式设计）、容器宽度、模糊、透视、宽高比、动画类型、过渡曲线，可以提供更丰富、更动态的样式选择。 自定义了的话，就会覆盖掉默认值。想要自定义也很容易，可以通过在线工具 tweakcn 选择自己喜欢的，也支持滑块拖动灵活调整，满意了直接 copy 样式主题代码即可，是完全符合 tailwindCSS 的语法规范的。 组件封装 组件的分类 而组件可以分为看得见的和看不见的： 看得见的：比如基础的按钮、下拉框，用于数据录入的输入框，用户数据展示的列表等等。这个很好理解。 作者在 shadcn/ui 的基础上，丰富了原有组件的变体并额外封装了20+个组件，扩展了适用场景。 比较容易忽视的是“看不见的”的部分：一般指页面级的、模块级的各种容器，这部分对于 AI 遵循规范来生成页面非常关键，决定了整体的视觉节奏。一个典型的容器包括： • 构成：包括哪些子元素 • 布局：子元素怎么分布、怎么对齐、尺寸、间距、定位方式、内容装不下怎么滚动 这部分 shadcn/ui 里面没有，灵活度较高，需要结合自己的项目来定义。 封装原则 为了让 AI 能够严格遵循这套规范生成页面，组件封装应遵循如下原则： • 不要无脑铺开，越少选择，AI 越容易选中。 ◦ 具备复用性才封装，不具备复用性或者会频繁调整的就不要封装（有一些还没想要要不要封装的，但是又觉得有必要统一的，可以先写成文档，让 AI 参考，比如 layout 文档）。 ◦ 基于未来一段时间的演进来抽象需要哪些组件，预留一定的包容性，不然开发新功能会很快发现组件不够用；但不要太多，避免过度发散，AI 选择会很困难。 ◦ 组件的变体包括两类：预先搭配好各个参数的组合（便当）、完全灵活勾选的组合（自助餐）。优先使用预设组合（便当），避免过于发散。 ◦ 具备复用性才封装，不具备复用性或者会频繁调整的就不要封装（有一些还没想要要不要封装的，但是又觉得有必要统一的，可以先写成文档，让 AI 参考，比如 layout 文档）。 ◦ 基于未来一段时间的演进来抽象需要哪些组件，预留一定的包容性，不然开发新功能会很快发现组件不够用；但不要太多，避免过度发散，AI 选择会很困难。 ◦ 组件的变体包括两类：预先搭配好各个参数的组合（便当）、完全灵活勾选的组合（自助餐）。优先使用预设组合（便当），避免过于发散。 • 颗粒度适中，职责清晰。 ◦ 即便一个组件有很多变体，但是他们都还是一个职责，那就没问题；反之，如果一个组件变体很少，但是职责有跨越，那 AI 也可能找不到。 ◦ 即便一个组件有很多变体，但是他们都还是一个职责，那就没问题；反之，如果一个组件变体很少，但是职责有跨越，那 AI 也可能找不到。 • 能嵌套就嵌套，避免重复造轮子。 ◦ 组件也是应该层层嵌套的，复杂的组件里面可能包含基础的组件；反之，若多个组件中具有相同的设计模式，也应该及时抽象出来。 ◦ 组件也是应该层层嵌套的，复杂的组件里面可能包含基础的组件；反之，若多个组件中具有相同的设计模式，也应该及时抽象出来。 把 AI 想象成与你合作的有血有肉的设计师和前端工程师，其实道理是一样的。 遵循设计系统的AI页面开发 有了良好的基建，就可以利用 cursor 遵循设计规范开发页面样式了。 先泼盆冷水，现阶段，传统的设计流程“需求产出 → 交互设计(低保真原型) → 视觉设计(高保真) ”并没有本质变化，除非是非常标准化的页面，否则跳过前序环节，让 AI 来定义产品框架、出高保真原型，很难符合预期。 举例：以之前作者开发的英语泛听应用“天天磨耳朵”为例，我对用户体验的预期是打开应用尽快能开始听力练习，因此做成了利用设备 ID 自动以游客账户直接进入产品主页面。但是 AI 的建议会更加传统，非让用户一上来先注册。（这里不讨论对错，仅讨论 AI 的建议能否符合预期） 我开发了音色、语速调节等功能，而我对用户体验的预期是可以简洁、直观、高效，减少信息架构和层级，因此把所有听力设置都合并在练习页面上，而保守的 AI 就会建议我开发一个设置页面，在我看来在设置项不多的情况下，就很多余。 由于 AI “守旧”的特点，对于要求不高的标准布局页面（如“个人中心”），大模型利用强大的推理能力，或许可以根据功能描述，跳过产品设计环节，无需低保真原型图，直接基于现有设计系统，推导出最适合使用的组件，生成高度贴合需求的高保真原型设计。但对于要求也比较高的且创新的功能页面/产品，产品设计环节还是逃不掉的。 需求设计环节 除了需求背景、目标等常规信息外，最好能额外提供详细的「数据结构、格式」，这对于 AI 准确地选择组件（及其属性）非常有帮助。因为纵观各种应用，无非都是数据的录入或展示，小红书如此、抖音如此、淘宝如此、美团外卖如此。 • 如果是数据录入类（比如表单），那 cursor 可以据此选择合适的控件类型（文本框、日期选择、单选、多选），并自动添加校验逻辑（必填、格式、长度等）。 • 如果是数据展示类（比如卡片、列表），cursor 会知道是否需要做文字截断、图片裁切、标签换行处理等 UI 细节。 结构明确，生成就精准；结构模糊，cursor 就只能瞎猜。 交互设计环节 交互稿通过图形化手段明确各功能模块的结构关系和信息层级，对于支持图文理解的多模态 AI 而言，不仅是重要的上下文输入，更是判断页面布局、组件嵌套方式等关键决策的依据，可显著提升生成页面的结构合理性与风格统一度。 假定你已经画完了交互稿（低保真原型），你还需要判断： 1. 现有的组件（包括看得见的控件、看不见的布局）是否够用 注：若该功能涉及多个页面，建议逐一开发。 为了最大化可控性，你可以增加如下的指令： 1. 限定 components 范围 ，配合 “组件仓库说明.md”使用 2. 要求基于主题 index.css来选样式 3. 参考某个最接近的页面来设计（参考“页面全景图（sitemap）”） 4. 基于“LAYOUT SYSTEM.md”文档来布局 1. 限定 components 范围 ，配合 “组件仓库说明.md”使用 2. 要求基于主题 index.css来选样式 3. 参考某个最接近的页面来设计（参考“页面全景图（sitemap）”） 4. 基于“LAYOUT SYSTEM.md”文档来布局 2. 能涵盖就直接开始开发；若不能涵盖，需要判断下是否需要封装新组件（原则上，具备复用性才封装，不具备复用性或者会频繁调整的就不要封装） 3. 若需要封装新组件，则封装完新组件再开发页面；若无需封装，则要求 AI 基于基于样式主题包（index.css）来开发。 正式开发环节 PRD 能提供关键的上下文、以及每个feature的信息、功能的规格；交互稿（低保真原型）可以提供完整的层次关系、布局参考；这 2 个材料都可以一并发给 cursor。 开发流程 1️⃣ 讨论 先让 cursor 判断需要会用到哪些组件，规划布局，确认无误后再执行。 2️⃣ 审查 你可以使用 storybook 查看页面，肉眼检查哪些地方设计不够规范，也可以在 cursor 中新起一个对话窗口，让 AI 自查： 1. 问cursor刚刚这个页面是否已经全部都按照规范来了，有没有遗漏 2. 让cursor将当前页面与之前开发完的某个已经符合规范的页面相比，有哪些规范上的差异 3️⃣ 修缮 对于组件选用不合理或布局不合理的地方，可以使用 stagewise 插件实现可视化微调，选中页面中的元素，再输入详细指令调教。